SPF and mail forwarding (was Re: [nznog] Sendmail Question)
In message <001801c4d402$0e7ad2d0$0100000a(a)lennons>, "Lennon - Orcon" writes:
We have SPF and SRS implemented on our email servers and yes it does work.
Unfortunately there are also a considerable number of systems (including in New Zealand) which forward mail without rewriting the envelope from address, which is required by SPF. This means that when the mail is forwarded it suddenly appears to be coming from a mail server that isn't authorised to send messages for that domain, which results in it being rejected and bounced back to the originator. I've had to relax the SPF statements for some of the domains that I manage in order to compensate for this problem (changing from "-all" to "?all" -- ie, "won't come from anywhere else" to "umm, I guess you might see it from some others too"). It would be very helpful if operators that provide a mail forwarding service (eg, just about every ISP that provides mail services) were to do the forwarding in a SPF-compatible manner. Something like procmail's approach (forward message on with envelope from of the account triggering the forward) is sufficient -- you don't have to do SPF's convoluted envelope from rewriting if you don't want to. I suspect this issue (mail forwarding) will continue to be the biggest obstacle to widespread SPF adoption for quite some time. Ewen
It seems to me that its the people who decide to reject mail just because the the spf records on the incoming message don't match, are the people who will make sender id systems unusable. Having working spf records has nothing to do with being SPAM, in fact percentage wise SPAM is better for correct spf records. It is purely for verifing that the mail came from an authorised server, not whether it is SPAM or not. If you are rejecting mail because of the spf records then you are forcing people like Ewen here to open the records just to get the mail working. Hence the records become less useful. So you should hang your head in shame. </rant> -- Daniel
In message <001801c4d402$0e7ad2d0$0100000a(a)lennons>, "Lennon - Orcon" writes:
We have SPF and SRS implemented on our email servers and yes it does work.
Unfortunately there are also a considerable number of systems (including in New Zealand) which forward mail without rewriting the envelope from address, which is required by SPF. This means that when the mail is forwarded it suddenly appears to be coming from a mail server that isn't authorised to send messages for that domain, which results in it being rejected and bounced back to the originator.
I've had to relax the SPF statements for some of the domains that I manage in order to compensate for this problem (changing from "-all" to "?all" -- ie, "won't come from anywhere else" to "umm, I guess you might see it from some others too").
It would be very helpful if operators that provide a mail forwarding service (eg, just about every ISP that provides mail services) were to do the forwarding in a SPF-compatible manner. Something like procmail's approach (forward message on with envelope from of the account triggering the forward) is sufficient -- you don't have to do SPF's convoluted envelope from rewriting if you don't want to.
I suspect this issue (mail forwarding) will continue to be the biggest obstacle to widespread SPF adoption for quite some time.
Ewen
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
"Daniel"
It seems to me that its the people who decide to reject mail just because the the spf records on the incoming message don't match, are the people who will make sender id systems unusable. Having working spf records has nothing to do with being SPAM, in fact percentage wise SPAM is better for correct spf records. It is purely for verifing that the mail came from an authorised server, not whether it is SPAM or not.
You're right, it is pointless to whitelist just because the SPF records check out. It's like believing an email which has a PGP signature, without checking who signed it.
If you are rejecting mail because of the spf records then you are forcing people like Ewen here to open the records just to get the mail working. Hence the records become less useful. So you should hang your head in shame.
The SPF draft says that you MAY reject on a fail. It seems to me like this is a problem with the design of SPF, rather than a misconfiguration on behalf of mail admins. The SPF record is specifically telling you that the message is not legitimate - even though that might be because the mail list/exploder/forwarder is not doing the appropriate SRS magic. cheers, Jamie http://spf.pobox.com/spf-draft-200406.txt "3. SPF Record Evaluation An SPF client evaluates an SPF record and produces one of seven results: None: The domain does not publish SPF data. Neutral (?): The SPF client MUST proceed as if a domain did not publish SPF data. This result occurs if the domain explicitly specifies a "?" value, or if processing "falls off the end" of the SPF record. Pass (+): the message meets the publishing domain's definition of legitimacy. MTAs proceed to apply local policy and MAY accept or reject the message accordingly. Fail (-): the message does not meet a domain's definition of legitimacy. MTAs MAY reject the message using a permanent failure reply code. (Code 550 is RECOMMENDED. See [RFC2821] section 7.1.) Softfail (~): the message does not meet a domain's strict definition of legitimacy, but the domain cannot confidently state that the message is a forgery. MTAs SHOULD accept the message but MAY subject it to a higher transaction cost, deeper scrutiny, or an unfavourable score." -- James Riden / j.riden(a)massey.ac.nz / Systems Security Engineer Information Technology Services, Massey University, NZ. GPG public key available at: http://www.massey.ac.nz/~jriden/
participants (3)
-
Daniel -
Ewen McNeill -
James Riden