|
RE: Using headers instead of SRS
2004-01-25 04:50:08
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.
--Julian Mehnle <lists(_at_)mehnle(_dot_)net> wrote:
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.
Hey Julian,
I appreciate your taking the time to reply. I really do think we agree in
more important ways than we disagree.
It's entirely possible that I communicated poorly, but I don't believe I
have a "serious misconception". Please do me the favor of giving me the
benefit of the doubt.
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.
Look, don't jump on me, it's not MY suggestion we are discussing here, my
"qualified sense of agreement" was intended to be a direct response to Meng
Wong's question "Should SPF use headers instead of SRS?"
SPF is going to find itself (or has already found itself) in direct
competition with other proposals that do use headers. Most users don't
know what an envelope sender is or where to find it in the message.
As a big SPF supporter, I'm certainly not suggesting that the envelope
sender approach is bad -- far from it. I'm just saying that we need to be
aware of headers in some respect. If the envelope sender can be counted on
to always equal at least one of four key headers (From, Sender,
Resent-From, Resent-Sender) then we might, just might, have some leverage
against competing proposals (like one MS would like to push quickly
forward).
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.
Actually, that's a great suggestion. We still probably need some field
research to say whether the envelope sender is ever different from Sender:
(or From: if no 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".
I accept your terminology. However, businesses that do this may still
refer to themselves as "forwarders".
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.
I think my point, which I didn't state very clearly, is that SPF breaks
forwarding (which we all knew) and SRS is not being well-received. So,
perhaps some kind of whitelisting will always go hand-in-hand with spf v1.
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!
Again, I am answering/partially agreeing with Meng's question; please don't
jump on me too hard. You and I agree more than you might think. I am
basically saying that it's too late to change the behavior of SPFv1. SPF
is usable now and should be used now.
SPF also has its flaws. Forwarding is one. Single-minded devotion to the
envelope sender as the end-all and be-all of verification is another. I
don't think it's going to take long for spammers to realize that all they
need to do is spit out something different in the envelope sender that
doesn't appear anywhere in any header, and it passes right through SPF,
even if the Sender: and From: are both bgates(_at_)microsoft(_dot_)com(_dot_)
But, let's cross that bridge when we come to it. That's what SPFv2 is for.
If we change the behavior of spammers, we will have shifted some costs back
to them, and that might get us some positive notice.
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.
Please don't put words in my mouth. No, I'm not saying that.
Also, you referred me to the archives twice in this message, which is
interesting since you seem to have joined the list a bit more recently than
I. Please try to be respectful rather than patronizing. The archives will
show some examples where I fundamentally disagree with a couple different
people and manage to do so respectfully.
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.
Yes. Now we're cooking.
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.
Agreed.
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.
Agreed.
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.
I see "forwarding pretty much breaks" as a pretty big incentive to make
sure SPFv2 fixes it. Also, any approach that pays no attention to headers
at all will be of limited benefit to users. I see those as pretty big
targets for SPFv2 to try and fix.
My thought (again, based on Meng's original question, and reviewing some
competing proposals, not my own off-the-wall idea) is that if there is an
approach that solves both problems, we should consider it.
You and I agree that basing everything on the envelope sender is great for
SPF. I'm saying we should keep our eyes open for alternatives, competing
proposals, etc.
Perhaps I'm being too paranoid, but let's say SPF causes spammers to change
their behavior, but they adapt relatively quickly, and scramble the
envelope sender to not match the headers. If SPF causes relatively little
pain for spammers, and much more pain for forwarders, administrators will
find themselves looking at alternate proposals. If that happens, let's be
ready with v2.
Again, I'm certainly not saying that SPF is flawed. It's a great tool and
I'm already using it. It's going to be a moving target, that's all.
Talk to you soon,
gregc
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)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;±¤Ö¤Íµø?¡
|
|