At 11:23 26/11/2009 Thursday, Ian Eiloart wrote:
--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.
I'm not seeing where you disagree with my point here {that -all dosnt equate to
dosn't emit email, only v=spf1 -all does that
but i agree that few are using -all and ~all records and thus most publishing
spf, are not actually using it for its designed purpose of limiting/stopping
forgery {they are using it to say mail that passes IS good, mail that fails...
treat it like it has no SPF {ie take it too}
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.
well yes domains like that should also block forgeries of their
hosts/subdomains i was just citing the most common example in pretty much every
domain
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.
I just {understandably} didn't see the move from Publisher of SPF role to
receiver of mail role
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.
{only if his server is capable of SRS few are} 90% of servers i see day to day
are just plain incapable M$ exchange being the most common
and few admins decide to feorward mails, this is usually the choice of the end
user {management with blackbery or road-warrior wanting to use gmail}
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!
well actually they could {if you didn't already do srs} they could get a
provider like ourselves to middle-man the mail
{by setting yours to forward to us}
so we make it SRS compliant and before it reaches the whitelisting incapable
end destination {like a lot of businesses with exchange have to}
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!
they shouldn't have to but you just {like us} have a big button allowing them
to whitlist the sender {in webmail} {only shown if the mail appeared to be
forwarded} that brings them to the whitlisting of forwarders section of the api
{or in our case a link in our web based "your mail that was rejected log"
beside any rejected due to SPF fail
but the means are many, hotmail do it by encouraging users to give their
forwarding-here address and i suspect then probing them to see if they need
whitlisting or not
{i must play with this option for our own few users who arn't techies, luckily
very few atm}
{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!
if it does is very new
its long been my argument against sender-id that if it was any use M$ would at
least make its own exchange capable of forwarding in a sender-id compliant way
{which of course is even more complex than SRS as it involves body re-writing
too, and it wasn't even capable of the SRS based bit}
{they of course allow you to block on sender-id fail, making all forwarding
within an exchange only group impossible, DOH!}
*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
-------------------------------------------
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