spf-discuss
[Top] [All Lists]

[spf-discuss] Re: Forwarder whitelisting reloaded

2008-01-10 21:59:32
David MacQuigg wrote:

Is this a good model, or at least good enough that we can
use it as a basis for simple discussions, and clarify when
we need to add something?

Let's stick to the existing terminology, as you have noted 
there's one special case where we use "forward" as shorthand.

The "border" enters the picture when an MTA on the side of 
the sender figures out that a mail is not "local" and has
to be forwarded / relayed / sent to a third party.  For that
job a border MTA on the side of the sender (not necessarily
the MSA, it could be behind the MSA) has to query=mx, with
an address fallback where query=mx yields nothing.  It then
finds a working MTA on the side of the receiver.

The border MTA on the side of the receiver has to decide if
it accepts or rejects the mail.  After that decision it can
do whatever it needs to do to deliver the mail in its "own"
receiving network.  That can include forwarding / relaying /
sending from secondary to primary MX, and the secondary MX
can be a backup MX elsewhere, but as far as "sender policy"
is concerned it did its job at te border, SPF doesn't (and
can't) worry about whatever the receiver does to deliver an
accepted mail.  The receiver can even "bounce later" if an
accepted PASS goes to e.g. a mailbox over quota.

Things the receiver can do includes to resolve aliases, and
if these are local aliases "change RCPT TO, keep MAIL FROM"
can't cause havoc, IOW the receiver only needs to make sure
to check SPF once, at the border, that's fairly simple.

An MTA on the side of the receiver can find that an RCPT TO
is a mailing list, it then replaces the MAIL FROM with its
own list-bounce address, maybe it manipulates the header by
adding a corresponding Sender (for PRA, or just anyway), and
then sends / forwards the mail to the various list members.
Also no problem for SPF (but maybe a problem for PRA).

And the last case, that's what we are talking about here, is
a non-local alias, where the receiver changes RCPT TO a 3rd
party, and forwards the mail across a *second* border, again
coupled with query=mx etc. as at the first border.  Because
this is a third party it can normally check SPF again, and
for an unmodified MAIL FROM this either FAILs, or at least
it can't PASS.

After that the game can simply repeat, but for SPF it won't
introduce new cases.  Typically when we talk about "forward"
it's the one and only interesting case for SPF, "forward to
third party".   We ignore cases where MAIL FROM is adjusted
(as for mailing lists), that's good enough for SPF (not for
PRA, but here is not senderid.discuss :-)   We also ignore
cases where a new RCPT TO is a local alias, as that doesn't
cross another border where it could cause havoc.  

 Frank

-------------------------------------------
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=84582257-0589b1
Powered by Listbox: http://www.listbox.com

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