spf-discuss
[Top] [All Lists]

Re: [spf-discuss] Re: [spf-help] How reliable is it to block/reject on SPF fail?

2009-11-26 06:47:13


--On 25 November 2009 17:35:29 +0000 alan <spfdiscuss(_at_)alandoherty(_dot_)net> wrote:

At 15:58 25/11/2009  Wednesday, Ian Eiloart wrote:


--On 21 November 2009 15:10:04 +0000 "G.W. Haywood"
<spf(_at_)jubileegroup(_dot_)co(_dot_)uk> wrote:

Hi there,

On Sat, 21 Nov 2009, Thomas Harold wrote:

What is the current thinking on rejecting at the SMTP transaction if
you encounter an SPF fail?  Are there a lot of false positives?

As I understand it, most "-all" records are for domains that don't emit
email at all. But, they're not widely published.

if you mean "v=spf1 -all"
ie a record with no passing syntax before the -all
but if you mean records ending with -all you would be incorrect most
people with established spf have there records terminated with a -all
?all being really equivalent to not having any restriction on
forgery/spf-non-believer ~all being a little better but still effectively
saying you want the receiver to consider accepting forgeries also {but
possibly via spam-folder}

Not according to the only stats that I've seen on the matter. They say 9.9% of domains publish SPF, 46.8% of those publish "-all" records, and 70.2% of those are "v=spf1 -all".

For those with "v=spf1 -all" everyone would agree that it can never be wrong to reject the email, surely? For the other 29.8%, you should still respect the publisher's policy, but that might result in rejecting wanted email. Minimise those false positives by allowing your recipient users to whitelist their forwarders.

That's one of the clearest use cases for SPF though. You can publish an
A record without establishing an email domain.

yes like the common www.example.com

Yes, but more importantly, we have hundreds of machines registered in the sussex.ac.uk domain, but none of them are email domains.


You should reject an SPF fail.

i think you mean publish an spf fail ie "v=spf1 -all"
{rejection being down to the recipient}

Actually, I meant what I said. If you see an SPF fail, you should reject the email. This comment wasn't related to machines that aren't email domains. Your next comment is useful though, I wasn't aware of this possibility. I wonder how many MTAs handle this correctly? I guess they can't do worse than ignore the record.

and i wholeheartedly agree and recommend this approach
{i also reccomend publishing a null MX record so mta's not checking spf
can see they cannot send mail to the domain and should not attempt
"fallback to A" {broken} standard behaviour {thus any checking the
validity of incoming adress's in DNS get an explicit fail too} this is
done via
xxx.example.com  IN MX 10 .

Any "false positives" can squarely be blamed on the publisher of the
record or the forwarder of the email.

true, {as to the publisher}

the non-srs-forwarder is blameless though as well his-server his-rules as
far as how he checks incomming mail for validity and non-srs-forwarding
is done on behalf of the shared-user of both systems  {ie user who has
account with non-srs-forwarder and the final reciever}

His server, his rules. Agreed. However, if he knowingly forwards mail with broken SPF, then that's nobody else's fault.

so in that case its a failure of the user to {select a non-srs-forwarder
with adequate inbound filtering} and to inform the end-recieving system
to not perform spf filtering on mail non-srs-forwarded to him from
non-srs-forwarders-ip

But many people don't "select" their forwarders. For example, our students can opt to have their "sussex.ac.uk" email forwarded to a third party account. They can't choose who does the forwarding, though!


if user has no method of disabling spf-checking on mail to him from
non-srs-forwarders-ip then he should be selecting a different
end-reception supplier as the current one is ill equipped to accept
non-srs-forwards {and thus should either ban non-srs-forwarding or not
reject on spf-fail}

Perhaps they'd be well advised to. Unfortunately, most end users don't know about SPF. And, they don't know that they don't know!

{srs-based-forwarders re-write the envelope sender so couldn't fail SPF}

*yes anyone rejecting on spf fail needs to have a system for allowing
users to whitelist their non-srs-forwarders, the software capable of
doing this has been around for long enough, and unfortunately srs is
still not common enough in most low end MTA's {like exchange}

True. Though I believe that the latest version of Exchange forwards email with the return-path set to the original recipient address. Not good, but it doesn't break SPF!

*we see a non-insignificant demand for our offering to corporate
customers of forward re-handling ie they non-srs-forward to an alias
here, we srs-forward on to the actual destination
blackberry/gmail/hotmail/whatever as their is a legit need for
forwarding, but too many end-receivers give no method for users to
whitelist their non-srs-forwarders-ips and also reject on SPF fail


--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/


-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/
[http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com



-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/
[http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com



--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/


-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ 
[http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com