Re: [Asrg] Re: Why SPF? (was: Anti-spam laws do work, FYI. There's proof.)

[der Mouse <mouse at Rodents.Montreal.QC.CA>]

> I do not believe that SMTP "forwarders" exist, except in certain
> limited situations such as off-site backup MX's.  Let me explain in
> detail.

> An off-site backup MX is accepting a stream of SMTP traffic [...]
> For logging purposes, each message is changed solely by the backup MX
> adding a "received" line.

If you check into it, I suspect you'll find that a lot of secondary-MX
sites do a lot more than just adding Received: headers.  (Any that run
sendmail, for example, will add missing message-IDs, add domains to
from-lines that don't have them, that sort of thing.)

> When an SMTP server "forwards" email on behalf of a user, I will use
> the term "email forwarder".  [...]  However, on an SMTP level, the
> SMTP headers have been re-written, so the SMTP traffic *cannot* be
> said to be forwarded.

This sounds as though you're saying "the envelope has changed" in a
rather complicated way: that an "SMTP forwarder" is something that
doesn't change the envelope and an "email forwarder" is something that
does.  Would that be an accurate summary?

> That model works for IP, TCP, and NAT.  I don't see why it wouldn't
> work for SMTP & email.

Perhaps it would.  Feel free to try it.  Try to set up an email
forwarder that maintains sufficient state to DTRT with responses.

Myself, I think the state storage requirements put it out of reach,
especially given how long the email state needs to persist.  Perhaps
I'm wrong; that's why I suggest trying it.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg