From: Frank Ellermann
Sent: Wednesday, October 27, 2004 3:03 PM
<...>
Do you have BATV and SRS on your list with known problems of
2822 From ~ 2821 MAIL FROM equivalence schemes ? And PRA has
similar issues, "let's all add Resent-headers" is not really
a solution (but a good joke for all spammers ;-) Bye, Frank
Good point on BATV/SRS/SES, Frank. Good joke on PRA, too. I believe we can
still get the originating domain from BATV/SRS/SES by recognizing which
protocol it is and taking it apart. I haven't looked at the latest BATV
draft, but the earlier ones did leave the domain intact, similar to SES.
SRS is easy to unwind, too.
Out of all of these, I think PRA is the only one that would break any
equivalence that existed when the message was first sent. With PRA, the
original information is all there, but I can't think of a way to tell which
was the "original" 2822 sender header. I suppose you could start from the
newest Resent-From: and go backwards until you got a domain to match with
2821, but how would you tell if it was sent that way? A worse problem would
be a mixture of sites handling a message, some of whom used Resent-From: to
indicate the current submitter (PRA semantics) and some of whom used it for
remailing (RFC2822 semantics). I don't think the end recipient could
reliably detect a 2822 forgery if that happens. The last hop will be right
but the originator will be uncertain.
The best thing would be if PRA were to use some other header than
Resent-From: to put their current submitter information so PRA email stays
compatible with conventional email. If they created a new header and called
it "Forwarded-By:" or "Forwarded-From:" or just "Forwarder:", it wouldn't
break anything. This way, you would never confuse a PRA forwarder with a
2822 remailing originator.
--
Seth Goodman