Per Jessen wrote:
[pseudo-551 "user not local"]
I'm curious as to how to work around this - or if I should.
In essence you have two options, either send directly to the
"new" address as indicated in the bounce, or risk to use an
unprotected MAIL FROM address. The latter is dangerous if
the spammers somehow find and abuse it.
The mail server at <anotherdomain> rejects it due to
<theirdomain> not being listed as a mailserver for
<spamchek.com>.
Should this really be happening?
Yes, SPF FAIL is designed this way. The only place where a
check of a MAIL FROM "sender policy" (nomen est omen) works
directly is at the border from sender to receiver, in other
words at any border MX of the receiver.
In your case the check was at a border MX of the new address,
the admin of the new address got it right. But they didn't
get the mail directly from the sender (you), the receiver
inserted a legacy forwarder in this route. The admin of the
legacy forwarder also got it right to some degree, they just
ignore the demise of real "reverse paths" (1989 in RFC 1123)
and SPF. They could do better, but that's their decision.
The receiver arranging this non-functional forwarding also
got it right to some degree, ordinary users have a right to
be clueless about obscure "IETF experiments" like RFC 4408.
You also got it right, you want to protect your MAIL FROM.
But then you're forced to face this consequence if forwarder
or receiver resp. ignore the issue. Working as designed, I
hope that won't disappoint you - for a summary compare the
Wikipedia article about SPF [1], or the openspf.org FAQ [2].
Frank
1: http://en.wikipedia.org/wiki/Sender_Policy_Framework
2: http://www.openspf.org/FAQ/Forwarding
-------
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