On 25 Jan 2004 at 10:24, Julian Mehnle wrote:
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.
This is true.
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.
NO, NO, NO, NO, Don't even thing about this. I stated this one in error
but the sender is NOT to have a copy of the "MAIL FROM". The correct
header field, as stated in the RFCs, is the "Return-Path". It's already
in the RFCs so don't even think about changing it since it would NEVER
get through.
Given that the "Sender" is very likely to be the same as the "MAIL
FROM" but it does not have to be.
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.
There is no reason for it now.
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.
Again, NO, NO, NO, it's the "Return-Path".
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.
The forwarders just need to use their own e-mail address in the "MAIL
FROM" and everything will work without any changes. Everyone is making
this just too complex when the solution is already there. Now what they
could do in the "MAIL FROM" that does not seem to bypass the RFC is
something like:
forwarder-name(original-sender-name(_at_)somedomain(_dot_)tld)@forwarding-
domain.tld
You know who the forwarder is and the sender of the message. SPF would
only do it's check on the "forwarding-domain.tld" part. BTW, remember
that there are many more valid useable characters on the left of the
"@" than the right.
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_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡
----------------------------------------------------------------------
John Warren
+--------------------------------------------------------------------+
| Any and all use of my email address for bulk email without my |
| expressed permission is prohibited. This means NO JUNK EMAIL, SPAM.|
| Support the anti-Spam amendment, Join at http://www.cauce.org/ |
+--------------------------------------------------------------------+
-------
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_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡