ietf-asrg
[Top] [All Lists]

[Asrg] Re: reverse path

2006-02-06 13:24:29
Claus Assmann wrote:

Can you explain how you deal with the problems of "reverse
path", e.g., unauthorized relaying?

In the one case I've personally seen it was a "551 emulation",
already discussed here, I simply sent the mail again directly,
bypassing the 5.3.6(a) forwarder.

My ISP "offers" a MAIL FROM alias not covered by their SPF FAIL
sender policy - so far I never needed it in practice.  Actually
this alias always existed, this "feature" is unrelated to their
later introduction of SPF FAIL for their "normal" addresses.

You are certainly aware of those problems -- that's why the
SPF proponents proposed SRS -- so what's your solution?

If receivers don't address it at the forwarder (e.g. with SRS)
they have to address it at the next hop (e.g. white list the
forwarder), if that next hop otherwise rejects SPF FAIL.

If they do nothing at all, but test SPF behind their border it
generally can't work, SPF lists the sending IPs of the original
sender.  This set of "permitted" IPs normally won't include IPs
of any forwarders (starting with the IPs of the MXs).

How they do it depends on their situation.  In the worst case
they do nothing and won't receive forwarded mails.  Publishers
of SPF FAIL are happy to get a single "551 emulation" in months
instead of hundreds of bogus bounces daily - TINSTAAFL.

Mail providers wishing to support this could offer to "white
list" 5.3.6(a)-forwarders per user.  They could "white list"
5.3.6(a)-forwarders globally for all users.  They could use
a global list like <http://trusted-forwarder.org>.  They could
ignore this issue, simply "reject SPF FAIL" works as designed.

That's all discussed in chapter 9.3 of the SPF spec., see also
http://tools.ietf.org/html/draft-schlitt-spf-classic#section-9

                          Bye, Frank
P.S.:
If your question was about how it used to work before RfC 1123:
STD 10 offered 551 as alternative for 251.  It made no sense to
relay mail if they have no clue how to report errors later, the
bounces would queue up.  As stated for 251-forwarding in 821:

| The receiver takes responsibility for delivering the message.

Obviously the receiver is then also responsible to report errors
to the original MAIL FROM (i.e. to the RCPT TO of a bounce after
it reached the 251-forwarder).  Where that's impossible use 551.




_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg