spf-discuss
[Top] [All Lists]

Re: [spf-discuss] Revising FAIL

2008-01-05 07:09:34
On Sat, 5 Jan 2008, Graham Murray wrote:
Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net> writes:
I think this is folly.  It's a chicken game, with four states:

1A - forwarders use SRS, recipients do not enforce SPF
1B - forwarders use SRS, recipients enforce SPF
2A - forwarders operate traditionally, recipients do not enforce SPF
2B - forwarders operate traditionally, recipients enforce SPF

3 - forwarders use their own address in the RFC2821 Mail From.

Okay, I was lazy and said "use SRS" when I really meant "do anything to
the MAIL FROM: so that SPF won't fault it".  So your 3 is just a minor
variation on 1A/1B. 

Still, this brings up one thing that I'd probably do if called to
forward. Rather than do either traditional forwarding or SRS, I'd adopt a
strategy I call "Sham SRS".

In Sham SRS, the MAIL FROM is rewritten to the same address for every
forward.  The address cannot be the same as the forward address (otherwise
a bounce creates a mail-laser), but might be a trivial modification.

So if <jane_roe(_at_)example(_dot_)com> writes to 
<john_doe(_at_)example(_dot_)org> who is
really <joe_smith(_at_)example(_dot_)net>, the MAIL FROM on the second leg 
might be
<forward-john_doe(_at_)example(_dot_)org>.

Unlike SRS, this doesn't handle bounces.  But we don't care.  If someone
tries to mail from <> to <forward-john_doe(_at_)example(_dot_)org>, I might 250 
the
RCPT TO: line merely to bypass any SAV nonsense.  But at DATA, the would
be bouncer gets:

550 That was forwarded mail.  It's NOT BOUNCABLE.

So if the ultimate recipient tries to spamfilter forwarded mails, his
server fills up with doublebounces and I just laugh.

(This will earn an RFC-Ignorant listing, but even fewer people care about
RFCI than SPF.  And taking the RFC-Ignorant hit avoids the more dangerous
backscatterer.org blacklisting, since it is not viable for a forwarder to
refuse incoming mail with ambiguous or absent SPF information.)

There's still the problem of 550s in-transaction when the forwarder sends
to the ultimate recipient, but that problem has solutions and is not
unique to Sham SRS.

---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: 
http://v2.listbox.com/member/?member_id=2183229&id_secret=82146879-6b38f2
Powered by Listbox: http://www.listbox.com

<Prev in Thread] Current Thread [Next in Thread>