Hello!
On Fri, Oct 29, 2004 at 10:43:44PM +0200, Frank Ellermann wrote:
[...]
The last practical question came from Hannah, and if she
was talking about Schlund that's several _millions_ of
hosted domains. Some of them forwarding all mails sent
to whatever(_at_)hosted(_dot_)domain(_dot_)example to say their address
at AOL.
AFAIK there are limits for the left and right hand sides
of a mailbox address found in a return path.
Maybe it's something like 64 + 256, but you never know,
or do you reject "unrewritable" addresses ?
An obvious idea would be some kind of hash table, where
the <encoded-x-for-y> is the hash, and you can find the
original <x> for all bounces to <encoded-x-for-y>.
Actually you don't need <y>, you only need a <hashed-x>
as local part of the MAIL FROM in mails forwarded to <z>
for <y> resp. forwarded to any <z'> for any <y'>.
Because there are too many different <x> you also need
a "last access" time stamp in your <hashed-x> table.
And from time to time you would remove "old" <hashed-x>
entries from your table. Where "old" is defined by
the last usage of <x> plus say 14 days.
Is that how you do it ? And if so what's your hash
function, and how big is the table ? Does it survive
an attack by one million different very long <x> ?
Now, that solution has been rejected by my boss. We have a quite
distributed mail system and this (rewriting
whatever(_at_)some(_dot_)domain(_dot_)example
to some_random_string(_at_)srs(_dot_)schlund(_dot_)de or so, keeping the
association
some_random_string -> whatever(_at_)some(_dot_)domain(_dot_)example in a
database for a
while) would introduce the need for a potentially big shared read-write
database and maintenance stuff for removing old entries, and that's
a no-no.
Or do you use a direct scheme encoding the complete
return path where possible, plus a hash table only for
odd cases where the local part would be too long ?
That would be an idea perhaps but I don't feel that they'd like
a database for that at all.
I'm a bit more fond of SES, especially as that doesn't put a burden
on random forwarders (which might decide not to deal with spf at all),
but on the sender's site, i.e. to the same party that decides to
restrict the use of their domain name anyway (e.g. by publishing spf
with the exists:... hack for SES or by using spf + SES-extensions).
SRS loads the problems (say bad side-effects of a not completely bad
idea) from the interested parties (sender, recipient) to parties
that *might* not be interested in spf&co (3rd party forwarders).
Kind regards,
Hannah.