I've seen some comments on IRC, so I thought I'd better clarify them,
since I'm in and out of buildings at the moment.
DATABASING IS OPTIONAL
======================
I think people are being confused by the fact that I offered two systems:
One conforming to the SRS "standard" and possibly allowing compaction
without store. (The SRS rewriting system).
The other offering the SRS functionality, but within the existing SMTP
rules. (The database driven system).
The choice of system has significant impact on what data goes where.
On Fri, 6 Feb 2004, Shevek wrote:
> What information should be encoded into the SRS address?
>
> Clearly required fields:
> * Original sender.
In general, there is no database. In that case, in order to do the
reversal, this must be embedded in the SRS address. The secondary system
in my Perl code offers the ability to use the database, in which case all
that is required is the cryptographic hash. In general, I do not see
people using the database solution, unless they have a particular need to
store more data than is stored in the standard SRS format.
IF someone does choose to use a database, they could use either the
standard SRS remailing address as the key or just the hash (which is what
mine does). In the first case, compaction is possible. In the second, it
is not.
> * Cryptographic hash with secret to avoid remailing.
>
> Useful fields:
> * Timestamp.
Again, IF you have a database, then this is not required. And if you want
so much more of a complex system, then you can probably run a database
anyway.
If you're going to limit the number of bounces that can go through a
particular SRS address, then you need to store a counter per address,
which means you're running a database anyway, which means ... use the
database solution.
CRYPTOGRAPHY AND FORMAT
=======================
About the cryptography and whether the recipient host can decode the SRS
to work out where the original mail came from:
I want to remove the concept of "reversible hash" from the discussion.
There's no such concept, and even if there was, there wouldn't be any
point. There are N bytes of data in the sender address (where there is no
bound on N), and simple information theory says that you can't compress N
bytes of arbitrary data into a 48-byte MD5 hash.
Cryptographically, the best way to do it is to give the data in-clear and
add a MAC (message authentication code). I mean, simply, what is desired
is that we pass the information, and prove it authentic. This is served by
passing... the information and an unforgeable authentication code.
PRIVACY AND ANONYMITY
=====================
This is where the database-driven solution comes into its own. You want to
forward a mail. You don't want to pass on the sender address. But you want
to be able to return bounces. The database solution provides all of these.
But if you don't want to pass on the sender address, then you have to
store the mapping somewhere. I happened to use a DBM because it was the
simplest solution available. You may well find the same. Just put the
fields into a struct and add it as a value for the hash key.
I'm afraid I'm not at a terminal all the time. I can work to whatever
schedule people want to set, but please mail me to keep me updated, since
I am likely to miss things on IRC.
S.
--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h
since I'm in and out of buildings at the moment.
DATABASING IS OPTIONAL
======================
I think people are being confused by the fact that I offered two systems:
One conforming to the SRS "standard" and possibly allowing compaction
without store. (The SRS rewriting system).
The other offering the SRS functionality, but within the existing SMTP
rules. (The database driven system).
The choice of system has significant impact on what data goes where.
On Fri, 6 Feb 2004, Shevek wrote:
> What information should be encoded into the SRS address?
>
> Clearly required fields:
> * Original sender.
In general, there is no database. In that case, in order to do the
reversal, this must be embedded in the SRS address. The secondary system
in my Perl code offers the ability to use the database, in which case all
that is required is the cryptographic hash. In general, I do not see
people using the database solution, unless they have a particular need to
store more data than is stored in the standard SRS format.
IF someone does choose to use a database, they could use either the
standard SRS remailing address as the key or just the hash (which is what
mine does). In the first case, compaction is possible. In the second, it
is not.
> * Cryptographic hash with secret to avoid remailing.
>
> Useful fields:
> * Timestamp.
Again, IF you have a database, then this is not required. And if you want
so much more of a complex system, then you can probably run a database
anyway.
If you're going to limit the number of bounces that can go through a
particular SRS address, then you need to store a counter per address,
which means you're running a database anyway, which means ... use the
database solution.
CRYPTOGRAPHY AND FORMAT
=======================
About the cryptography and whether the recipient host can decode the SRS
to work out where the original mail came from:
I want to remove the concept of "reversible hash" from the discussion.
There's no such concept, and even if there was, there wouldn't be any
point. There are N bytes of data in the sender address (where there is no
bound on N), and simple information theory says that you can't compress N
bytes of arbitrary data into a 48-byte MD5 hash.
Cryptographically, the best way to do it is to give the data in-clear and
add a MAC (message authentication code). I mean, simply, what is desired
is that we pass the information, and prove it authentic. This is served by
passing... the information and an unforgeable authentication code.
PRIVACY AND ANONYMITY
=====================
This is where the database-driven solution comes into its own. You want to
forward a mail. You don't want to pass on the sender address. But you want
to be able to return bounces. The database solution provides all of these.
But if you don't want to pass on the sender address, then you have to
store the mapping somewhere. I happened to use a DBM because it was the
simplest solution available. You may well find the same. Just put the
fields into a struct and add it as a value for the hash key.
I'm afraid I'm not at a terminal all the time. I can work to whatever
schedule people want to set, but please mail me to keep me updated, since
I am likely to miss things on IRC.
S.
--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h