Michael Deutschmann wrote:
One idea to bring some "end-user education" into the picture, is to also
include in the extension an extra "I'm forwarder X, has recipient Y
whitelisted me?" probe command.
If they didn't the legacy-forwarder gets an SPF FAIL reject, and creates
a bounce message to the envelope sender. That's working as designed if
the next hop plays by the rules.
If the next hop somehow manages to drop SPF FAIL it won't work as
expected,
but if MTAs start to drop mail for whatever reasons they're already so
far
away from a reliable SMTP model that the details don't matter.
Let's face it, the original (working) SMTP never had a "keep the reverse
path as is" for forwarding, and RFC 1123 5.3.6(a) was the worst error in
protocol design I'm aware of. "Modify RCPT TO and keep MAIL FROM as is"
is a doomed strategy.
a forwarder afraid of the IP-blacklist-training effect could ask Spamcop
or AOL for an all-clear before submitting a stream of mail that might not
be 100% ham but must be 100% delivered.
If users have a chance to get something wrong they'll do it. Stuart's
recipe "stop service immediately" is probably the best solution, it's in
the spirit of the original SMTP:
"251 user not local" is for users knowing what they do
"551 user not local" is for less trustworthy receivers
And a rejected SPF FAIL after forwarding is a 551-emulation. At least
the
sender should know why checking SPF policies behind the border MX is
FUBAR.
Frank
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735