spf-discuss
[Top] [All Lists]

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;±¤Ö¤Íµø?¡