ietf-asrg
[Top] [All Lists]

[Asrg] Re: Default SPF Enablement?

2006-01-31 10:50:34
Bill Cole wrote:

Unfortunately, forwarders do indeed *need* to change their
behavior if they wish to avoid breaking SPF, but few have
bothered to do so, as apparently they don't much care about
whether SPF works.

They will have to change even without SPF FAIL.  Something is
awfully wrong if accepted (not limited to forwarded) mails are
rejected later.  For a forwarder the only way to get a clue
about such issues directly is to use its own error handling
MAIL FROM addresses.  Some kind of RfC 1123 5.3.6(b) or SRS.

It makes no sense to forward mails that are rejected later.

What it *is and always has been* for functional forwarding
systems is the original value, unmodified by the forwarder.

That's wrong, STD 10 clearly demanded to add the host to the
reverse path.  

For a host forwarder.example and MAIL FROM:<user(_at_)do(_dot_)main(_dot_)test>
that became MAIL FROM:<@forwarder.example:user(_at_)do(_dot_)main(_dot_)test>

The reverse path _was_ modified before 1123.  That's why it's
still called a "path" as in Return-Path: and not an "address".

If you change that to an address which was originally a
target of the message, any DSN  will loop rather than go
back to the actual sender.

Yes, MAIL FROM = RCPT TO can't work, worse than 1123 5.3.6(a).

MAIL 
FROM:<use(_dot_)551(_dot_)for-receiver(_dot_)at(_dot_)next(_dot_)hop(_at_)forwarder(_dot_)example>
could do the trick (ignoring some technical details) from the
POV of a forwarder, same idea as for mailing lists.  

After all the final receiver shouldn't reject (or worse bounce)
mails forwarded to her/him.

SRS addresses that, but it demands more of forwarders than I
think they can be expected to do reliably. Call me cynical.

No issue, let them emulate 551 and die in peace.  Bye, Frank



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