Re: Using headers instead of SRS
2004-01-24 17:41:12
--Meng Weng Wong <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com> wrote:
| To make myself clear, we're talking about changing the subject of
| authentication from MAIL FROM envelope sender to header Sender.
|
| This brings a number of benefits, including this one: postfix-users got
| rather riled about changing the return-path, and this lets us keep them
| happy.
|
| This is not as major a change as it might seem. In almost every case
| I've seen so far, Sender: matches the return-path, and when Sender: is
| not present, From: matches the return-path. Is this true for you guys?
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.
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.
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.
Is it possible to create a hybrid approach, where the mail-from is examined
within 1 sec of the connection being opened, but the receiver may also use
SPF to validate the From, Sender, Resent-From, Resent-Sender? In other
words, could we make effective use of all the effort that has gone into SPF
to apply it to this problem as well? It is a different problem but aspects
of it are similar.
Question 1.
Is there a required correlation between MAIL FROM and the header fields?
Is there an RFC on this? If we can justify bouncing, strongly downgrading,
or even dropping mail that does not follow this, then it makes sense to
check MAIL FROM when the transaction start, on the assumption that the
header fields will match.
If the mail is accepted anyway, but the header fields do not match, what is
the appropriate action? The least-damaging would be to add a note to the
headers that says "Warning, SPF check was based on envelope sender
<xxx(_at_)yyy(_dot_)com>". If SPF was passed based on mail-from, but that address
doesn't match the other headers, SPF has done its job according to the
design. The disclaimer is just there to point out that SPF is working, but
something else about the message is suspicious other than MAIL FROM:
If there is an RFC or other strong precedent for the MAIL FROM to match a
certain set of headers, AND if some data-gathering at large incoming mail
hosts shows no (or very little) legitimate mail that doesn't follow this,
that might be an appropriate application of some additional rules. We
could call this "SPF phase 2". This needs more research and field-testing
before it is invoked however.
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.
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.
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.
There still needs to be a strong correlation between the IP address and *at
least one* header. Some larger mail houses have reported that they now get
more spam than legitimate mail, and that they get more bounces from forged
spam than legitimate bounces. It should be considered Very Bad Form to
send a bounce to an unverified sender. Therefore, there should still be
some checks on the Mail-From, but over time we can establish a strong
correlation between Mail-From and the appropriate headers.
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
This breaks the 64-char limit on the LHS, but always provides a way to get
the bounce back to the original sender. This is probably the best approach
for large-scale forwarders.
Solution 2. Modified SRS
Something else is used to keep the LHS under 64 chars, though this 64-char
limit may not really be used in the real world. Once choice would be to do
some DNS wildcard entries so that the rewritten sender is something like
"sendername(_at_)aol(_dot_)com(_dot_)<cookie>.bounces.forwarder.com"
Solution 3. Generic "bounces" address, and scan bounce body
Forwarder accepts bounces at "bounces.forwarder.org" and then searches the
message for the original sender and cookie. If the bounce message doesn't
contain the full headers, the bounce can't be forwarded on to the original
sender. An administrator should be alterted that the bounce was malformed.
Solution 4. Generic "bounces" address, and keep track of original senders
Forwarder accepts bounces at "cookie(_at_)bounces(_dot_)forwarder(_dot_)org" and the
original sender is kept on file. This could apply to all bounces, or only
the bounces that don't forward original headers along, to reduce demand on
the data lookup (or logfile-search)
Solution 5. Forwarder doesn't send bounces back to the sender.
The forwarder might have an arrangement with the customer (receiver) to
turn off forwarding and hold his mail in the event of bounces, or to just
hold the bounces, or to fall back to another known-good address for the
recipient in case the recipient's ISP is having problems. Or, the
forwarder might be small enough that the administrator is willing to deal
with bounces manually.
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.
Since forwarding is a pretty significant barrier right now, perhaps
forwarders need a large menu of options to choose from...
That's all for now. Feedback welcome of course.
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;±¤Ö¤Íµø?¡
|
|