spf-discuss
[Top] [All Lists]

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

2009-11-27 02:47:51
alan wrote:
At 11:23 26/11/2009  Thursday, Ian Eiloart wrote:
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}

The decision that is up to users is to enable either forwarding by one server or fetching by the other one. Gmail and many other servers offer fetching: it is the solution with fewer problems.

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}

However, the middle address will be visible in case the final server rejects a message because the mailbox is full. That may be unacceptable in case the first (vanity) address bears utter significance.

BTW, what you call "SRS compliant" should actually be called "SPF compliant". SRS is not the only technique to change envelope senders and thus avoid breaking SPF.

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}

I cannot understand this. Webmail servers only have the chance to determine that a message appears to be forwarded, and hence present the big button, _after_ they have already accepted the message. What do they do if the user does _not_ whitelist the sender at that stage?




-------------------------------------------
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