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}
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
You should reject an SPF fail.
i think you mean publish an spf fail ie "v=spf1 -all"
{rejection being down to the recipient}
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}
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
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}
{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}
*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