With the SRS scheme that pobox uses, you can recover the original envelope sender from the SRS version. But I don't know if that's guaranteed to be possible (an MTA might keep a database rather than copying all the information into the SRS version), or how many different SRS schemes are likely to be in play. Definitely beyond my level of expertise...
http://spf.pobox.com/srs.html contains info on SRS. Links from there eventually link to http://www.libsrs2.org/srs/srs.pdf. This describes what looks like the SRS scheme that pobox.com implements.
For the very first forwarder in a chain of forwarders (or the only forwarder) then an SRS0 style envelope sender is used when forwarding mail. For subsequent forwarders, and SRS1 style address is used. Reasons are in the above link.
Now, the format for SRS1 style addresses is rigid, and everyone must use it (last paragraph section 3.3) and hence could theoretically be reversed by TMDA for whitelist comparison. Note that part of an SRS1 style address is (part of) a previous hop's SRS0 style address.
However, the format for SRS0 style addresses is open - any SRS system is free to implement it differently - e.g. to support database lookups instead of crypto in the address itself (that being the example implementation in the paper).
This means that it's impossible, in general, to reverse an SRS0 address, and hence by induction impossible to, in general, reverse an SRS1 address.
That said, if any SRS implementation happens to adopt the paper's example SRS0 format, it's pretty trivial to reverse it.
So, it is impossible, in general, to update TMDA to reverse the SRS addresses for whitelisting etc.
That said, one could put in explicit support for pobox's rewriting rules, which would work for anyone using pobox, and anyone who's forwarder used the same scheme. Is there any guarantee pobox won't change their format?
Perhaps somebody should lobby the SRS spec writer so that a valid return path can always be extracted from the encoded SRS address, but also allow optional fields for e.g. a database key. However, this would mean using much longer email addresses where the database key was actually used, and hence non-empty...
So, I'm not sure how whitelisting is supposed to work in an SRS world, at least using the envelope sender, which is what SPF is supposed to protect. I'm guessing the final answer is for SPF to protect the "From:" header too, and then use that for whitelisting purposes. I get the impression that's what might come out of the SPF/Microsoft-caller-id merge, judging by whipping through some presentations on caller id integration?
Wow, what a long email! _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
