Mailing List Archive

How reliable is it to block/reject on SPF fail?
What is the current thinking on rejecting at the SMTP transaction if you
encounter an SPF fail? Are there a lot of false positives?

I'm trying to decide whether to to remove the "warn_on_reject" in
Postfix's main.cf to go ahead and return a 550 5.7.1 error code.

smtpd_recipient_restrictions =
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
permit_sasl_authenticated,
permit_mynetworks,
reject_unauth_destination,
warn_on_reject check_policy_service unix:private/policyspf,
permit_auth_destination,
reject

I'm using the Perl postfix-policyd-spf-perl v2.007, configured in the
postfix master.cf file. Everything seems to be working fine for the
past day.


-------------------------------------------
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/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com
Re: How reliable is it to block/reject on SPF fail? [ In reply to ]
On Sat, Nov 21, 2009 at 09:29, Thomas Harold <thomas-lists@nybeta.com> 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?

That all depends on the quality of the SPF record you're checking.

My personal experience is that problems aren't common.

--
Please keep list traffic on the list.

Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche


-------------------------------------------
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/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com
Re: How reliable is it to block/reject on SPF fail? [ In reply to ]
The three most common sources of (mostly) legitimate messages getting
SPF Fails are:

1) Forwards
2) Misconfigured clients (i.e., your users sending through their home
ISP's email server)
3) Web apps that try to send as your user's email address

These are most easily corrected by:

1) The forwarder implementing SRS or whitelisting if you know/trust them
2) Correcting the configuration to use the proper SMTP server
3) Modify the web app to follow the web best practices
(http://www.openspf.org/Best_Practices/Webgenerated)

We reject on SPF fail and every failure we've seen has fallen into one
of these 3 categories and we've been able to work around them. We've
only had to SPF whitelist a mail servers which are part of our network
but run by other departments.

Andrew


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?
>
> I'm trying to decide whether to to remove the "warn_on_reject" in
> Postfix's main.cf to go ahead and return a 550 5.7.1 error code.
>
> smtpd_recipient_restrictions =
> reject_non_fqdn_recipient,
> reject_unknown_recipient_domain,
> permit_sasl_authenticated,
> permit_mynetworks,
> reject_unauth_destination,
> warn_on_reject check_policy_service unix:private/policyspf,
> permit_auth_destination,
> reject
>
> I'm using the Perl postfix-policyd-spf-perl v2.007, configured in the
> postfix master.cf file. Everything seems to be working fine for the
> past day.
>
>
> -------------------------------------------
> 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/1020/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/1020/
> 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/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com
Re: How reliable is it to block/reject on SPF fail? [ In reply to ]
At 15:00 21/11/2009 Saturday, Andrew Culver wrote:
>The three most common sources of (mostly) legitimate messages getting SPF Fails are:
>
>1) Forwards
>2) Misconfigured clients (i.e., your users sending through their home ISP's email server)
>3) Web apps that try to send as your user's email address
>
>These are most easily corrected by:
>
>1) The forwarder implementing SRS or whitelisting if you know/trust them
>2) Correcting the configuration to use the proper SMTP server
>3) Modify the web app to follow the web best practices (http://www.openspf.org/Best_Practices/Webgenerated)
>
>We reject on SPF fail and every failure we've seen has fallen into one of these 3 categories and we've been able to work around them. We've only had to SPF whitelist a mail servers which are part of our network but run by other departments.
>
>Andrew

this also i see but i and myusers know
1 non-srs-forwards
if the user sets up a forward to his mailbox here
then the user also sets up spf whitlisting for the forwarders ip(s) here
{or looses the mail due to beening an eejit}
{the whitlisting requires no trust between me and forwarder as only mail to that users envilope_recipient address is spf whitelisted, and like all whitelists is maintained by the recipeint}

2 misconfigured clients elsewhere {their admin dosnt want us to accept mail from them so we dont argue}
{for internal clients that want to send via relays other than our submission server, whatever the reason, we just alter their SPF to match {as all our SPF records are per-address}

3 were glad to not see those forgeries, as they are usually due to "invite your friends" grooming sites for phishers, that idiots have handed their webmail id/passwords too in violation of their hotmail/gmail/yahoo TOS {pity those providers dont kick users when they see them breaking same TOS, or firewall off fakebook and those other sites that groom victims for the next big phish by teaching them that handing over their mail id/password is "normal"



-------------------------------------------
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/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com
Re: How reliable is it to block/reject on SPF fail? [ In reply to ]
On Sat, 21 Nov 2009 04:29:55 -0500 Thomas Harold <thomas-lists@nybeta.com>
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 others have said, it varies a lot. Personally I think it's generally
fine as long as you offer a mechanism for whitelisting of non-SRS
forwarders. My pypolicyd-spf has such a capability and is configured to
reject SPF Fail by default. Unlike some of the other design choices I've
taken in that application, I've never gotten a complaint about it being on
by default.

Scott K


-------------------------------------------
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/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com
Re: How reliable is it to block/reject on SPF fail? [ In reply to ]
On 21-Nov-09, at 3:39 PM, Scott Kitterman wrote:

> On Sat, 21 Nov 2009 04:29:55 -0500 Thomas Harold <thomas-lists@nybeta.com
> >
> 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 others have said, it varies a lot. Personally I think it's
> generally
> fine as long as you offer a mechanism for whitelisting of non-SRS
> forwarders. My pypolicyd-spf has such a capability and is
> configured to
> reject SPF Fail by default. Unlike some of the other design choices
> I've
> taken in that application, I've never gotten a complaint about it
> being on
> by default.
>
> Scott K


In addition, whitelisting should really only be used to allow for non-
SRS forwarders from trusted sources and not as a solution to fix mis-
configured SPF policies. Of course, temporarily whitelisting a mis-
configured sender address is fine but it shouldn't be used as a
permanent solution. At some point those mis-configured SPF policies do
need to be fixed and they won't if we don't fail them.

Incidentally, in the five or so years that I've been rejecting mail on
SPF FAIL I've only ever encountered one false positive and it was due
to a mis-configuration. They were temporarily white-listed until the
policy was fixed.

--
Gino Cerullo

Pixel Point Studios
21 Chesham Drive
Toronto, ON M3M 1W6

416-247-7740



-------------------------------------------
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/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com
Re: How reliable is it to block/reject on SPF fail? [ In reply to ]
Gino Cerullo wrote:
> On 21-Nov-09, at 3:39 PM, Scott Kitterman wrote:
>> On Sat, 21 Nov 2009 04:29:55 -0500 Thomas Harold
>> <thomas-lists@nybeta.com>
>> wrote:
>>> What is the current thinking on rejecting at the SMTP transaction if you
>>> encounter an SPF fail?
>>
>> As others have said, it varies a lot. Personally I think it's generally
>> fine as long as you offer a mechanism for whitelisting of non-SRS
>> forwarders.
>
> In addition, whitelisting should really only be used to allow for
> non-SRS forwarders from trusted sources and not as a solution to fix
> mis-configured SPF policies. Of course, temporarily whitelisting a
> mis-configured sender address is fine but it shouldn't be used as a
> permanent solution.

Those limitations only make sense because whitelisting is done by
IP. Whitelisting by sender's authenticated id would allow
fine-grained control --see http://fixforwarding.org/. For a
forwarder, it is easier to use SRS than to obtain proper
whitelisting for each forwarding recipe it sets up, though.

> At some point those mis-configured SPF policies do need to be fixed
> and they won't if we don't fail them.

That's after the lack of an established mechanism to report
"softfail". DSNs are not always sent, while abuse-reporting
mechanisms are still obscure.

> Incidentally, in the five or so years that I've been rejecting mail on
> SPF FAIL I've only ever encountered one false positive and it was due to
> a mis-configuration. They were temporarily white-listed until the policy
> was fixed.

How did you know the forwarder belonged to the sender's side? Until
the policy hadn't been changed, you couldn't have discerned
mis-configuration from plain violation.



-------------------------------------------
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/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com