Meng Weng Wong [mengwong(_at_)dumbo(_dot_)pobox(_dot_)com] wrote:
I think we agree that a forwarder will have to do some kind of
twiddling.
The question is whether you want to twiddle the envelope or the headers.
This is a decision we can still make, but the window of opportunity is
closing fast. So let's go over the pros and cons.
Twiddling the Envelope
Pros: 1) can reject before DATA, saving bandwidth.
2) MTAs already capable of filtering on envelope commands,
can call out to plugins, etc.
3) rejection can occur on a per-user basis
Cons: 1) have to do stupid cookie tricks
2) violate the 64 char localpart limit
Twiddling the Headers
Pros: 1) don't have to do stupid cookie tricks
Cons: 1) MTAs have to parse headers
2) rejection has to occur after ".", at higher bandwidth cost
When using the envelope, we consider only the MAIL FROM return-path.
When using the headers, we would use one of Resent-Sender, Resent-From,
Sender, and From, in that order.
A forwarder would add Resent-Sender.
The envelope sender address would remain unchanged from end to end.
Meng Weng Wong [mengwong(_at_)dumbo(_dot_)pobox(_dot_)com] wrote:
The concern is that checking headers, which can be spoofed, will reopen
the door to joe-jobbing.
Avoidance of joe-jobbing was the carrot for the whole deal.
Maybe we can require that the Return-Path match the address chosen from
the headers.
A. On distinguishing envelope sender varieties
I think "return path", "envelope sender", "envelope from", and "MAIL FROM:" are
all the same, not only factually, but also conceptually. I think it doesn't
make sense to distinguish between "the address where bounces should go to" and
"the address that is sending the mail". The fact that the SMTP command is
called "MAIL FROM:" -- and not "BOUNCE TO:" or "RETURN TO:" -- does make that
very clear in my eyes.
B. Applying SPF to message headers instead of the envelope sender
I very strongly oppose applying SPF to anything other than the envelope sender,
for the same reasons Meng mentioned above: (1) rejection would have to occur
after ".", at higher bandwidth cost; and (2) the concern is that checking
headers, which can be spoofed, will reopen the door to joe-jobbing. Relying on
the headers for SPF-like sender authorization testing is a very bad thing!
C. No conceptual need to leave the envelope sender intact on forwarding
Like Alex van den Bogaerdt wrote[1], I think that although the person who set
up the forward and the person who owns the target address of the forward are
often identical, there's no direct relation between these two *in general*. On
forwarding a message, a forwarder should specify an envelope sender that
matches his own domain. Beyond that, it's up to him what he wants to do with
incoming bounces/DSNs -- track them back to the original envelope sender (using
a cookie or so), just use them locally, or simply discard them.
D. How to pass the original envelope sender to forwarding targets
Fourth, I think we do not have a "violate the 64 char localpart limit" problem.
If a forwarder chooses to actually forward to the original envelope sender any
bounces/DSNs he receives, I think it would be a good solution to generate a
lookup-able cookie as the localpart for the new envelope sender address. This
localpart doesn't need to contain the original envelope sender *explicitly*
encoded (like SRS suggests).
If a forwarder wants to enable his users (i.e. the target users of the
forwards) to perform filtering on the *original envelope sender*, it would be a
good solution to store the original envelope sender in the "Sender:" header
field, overwriting or renaming any such fields that already exist.
IMO this aspect (I wouldn't call it a problem) is separate from SPF, and SPF
shouldn't be changed in any way just because of that aspect. And certainly,
SPF shouldn't be changed to looking at headers instead of the envelope sender
because of that aspect.
[1] Message-ID:
<20040120234055(_dot_)B31593(_at_)slot(_dot_)hollandcasino(_dot_)net>
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)���v¼����ߴ� �1I�-�Fqx(_dot_)com