Greg Connor [gconnor(_at_)nekodojo(_dot_)org] wrote:
Setting aside forwarding for the moment, I like the idea of tying in
with headers, for one thing, because users notice the From: header a
LOT more than the Return-Path: header (if they are even able to see
Return-Path: at all). From a non-technical standpoint, this means that
SPF protects from joe-jobs even if the envelope info is different from
what's in the headers.
You have a serious misconception here. The "From:" header was never *meant* to
be the sender. "From:" specifies the author of the message, while "Sender:"
specifies the sender of the message. Only when there's no "Sender:" specified,
the author is also the sender.
No, and I still don't think that SPF should ever be required to check the
headers. Please read the mailing list archive for many good reasons why not.
Using only the envelope MAIL FROM, it is possible to reject the mail
before seeing the headers. This is great, and I think it is worth the
effort. But that in itself doesn't provide complete value, because the
end user will pay attention to the From: address and there is a steep
education curve to getting everyone to notice/regard highly/value the
MAIL FROM, since most MUA's don't even show it.
MUAs will usually also show "Sender:", and if they don't, they're broken. So
one option would be to require MTAs to put the envelope sender into the
"Sender:" field, overwriting or renaming it if it already exists. That way,
MUAs would display the envelope sender.
OK, back to the question of forwarding.
Case 1. IF sender is not rewritten:
Let's call this "simple" forwarding. Since the envelope is not
rewritten, additional hops will not be able to check the SPF info.
This is usually called "relaying", not "forwarding".
Solution 1. White list trusted forwarders
Those sites will need to be globally white-listed (something like
trusted-forwarders.org) or locally white-listed by the receivers who
have mail forwarded to them. White-listing a trusted forwarder should
only be done if the forwarder is checking SPF before forwarding takes
place.
Small forwarders with a small user base may be able to get away with
this, if white-listing is easy to implement within SPF. In other
words, they are checking SPF based on the original envelope, and asking
their receivers to turn off SPF where the down-stream mail goes.
Medium to large forwarders who would like to be listed in
trusted-forwarders.org should be asked to help mirror the zone.
The "trusted-forwarders.org" thing is meant to go away eventually. It's a bad
idea to plan having it around forever.
Solution 2. Modify SPF to not use Mail-From
Let's call this the "SPF V2" approach. SPF doesn't work like this now,
but in the future if SPF is modified, then it may be possible to make
Mail From go back to its original meaning (that is, who should receive
non-delivery notifications) and SPF will work its magic on the
appropriate headers.
Pardon me, but this doesn't make sense. First, where do you take it from that
"where to send DSNs" is the original meaning of the envelope from (I call it
the envelope sender)? Second, if SPFv1 already enforces the envelope sender to
mean "where the message came from", it absolutely doesn't make any sense to
change that "back" in SPFv2. (Almost) everyone will already be accustomed that
the envelope sender must be "where the message came from" -- this is what SPFv1
is all about!
If you really think that SPFv2 should take the envelope from/sender as "where
to send DSNs" only, then you should also say that we shall stop the
distribution of SPFv1 ASAP, otherwise it's no use. And I really thought we had
discussed this issue at enough length. Please see the mailing list archives.
There still needs to be a strong correlation between the IP address and
*at least one* header.
I suggest that we simply require MTAs to put the envelope sender into the
"Sender:" header field.
Case 2: Forwarder rewrites envelope
This is required by medium to large forwarders, where they don't want to
depend on the downstream receivers to whitelist them. The bounces will
come back to the forwarder and the forwarder must decide what to do with
them.
Solution 1. SRS
Solution 2. Modified SRS
Solution 4. Generic "bounces" address, and keep track of original
Solution 5. Forwarder doesn't send bounces back to the sender.
I say, let the forwarders decide for themselves. If we want to help
forwarders, we may want to provide all these solutions, so all they need is to
pick one, download it, and integrate it into their MTAs. It's no use forcing
any forwarder to do exactly one of these solutions. There's no need for
interoperability here.
Solution 3. Generic "bounces" address, and scan bounce body
No, this is too fragile.
In summary, I like the idea of using headers, but it needs more thought
and more research, so it's probably not a quick-fix to make SPF
acceptable to forwarders. It's a pretty significant rewrite... perhaps
we could call this "version 2" of SPF. This allows people to start
using SPF immediately and provides a good user base to introduce the
new SPF to people.
I seriously doubt the next version of SPF should be *fundamentally* different
from SPFv1 without good reasons, and I don't think you have provided these.
Please see the mailing list archives for lengthy discussions of why SPF should
not be required to check the headers.
Since forwarding is a pretty significant barrier right now, perhaps
forwarders need a large menu of options to choose from...
Agreed.
-------
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