How to NOT reject if FAIL is for policy in test mode?

Asked by jasonsuser

I run pypolicyd-spf as a Postfix filter.

It seems to be working for mismatches.

But I caught this in my postscreen log

    Apr 13 09:13:26 main01 postfix/psint/smtpd[9154]: NOQUEUE: reject: RCPT from herndon-51.LastPass.com[38.127.167.51]: 550 5.7.1 <email address hidden>: Recipient address rejected: Message rejected due to: domain owner discourages use of this host. Please see http://www.openspf.net/Why?s=helo;id=herndon-51.lastpass.com;ip=38.127.167.51;<email address hidden>; from=<email address hidden> to=<email address hidden> proto=ESMTP helo=<herndon-51.lastpass.com>

Checking the "http://www.openspf.net/Why?..." link

    <email address hidden> rejected a message from a mail server claiming to be herndon-51.lastpass.com.

    <email address hidden> received a message from herndon-51.LastPass.com (38.127.167.51) from a mail server claiming to be herndon-51.lastpass.com.

    The domain herndon-51.lastpass.com has declared using SPF that it does not send mail through herndon-51.LastPass.com (38.127.167.51). However, the domain is still testing its SPF policy, so the message should not have been rejected.

& an SPF test (http://www.kitterman.com/getspf2.py) returns

    SPF record lookup and validation for: herndon-51.lastpass.com
    SPF records are published in DNS as TXT records.

    The TXT records found for your domain are:
    v=spf1 mx ip4:38.127.167.0/28 ip4:74.84.128.0/24 ip4:74.84.130.0/24 ip4:209.40.99.0/24 ip4:209.40.97.0/24 ip4:209.40.100.91 ip4:96.255.24.80/29 ip4:128.121.22.0/24 include:_spf.google.com ~all
    v=spf2.0/pra mx ip4:38.127.167.0/28 ip4:74.84.128.0/24 ip4:74.84.130.0/24 ip4:209.40.99.0/24 ip4:209.40.97.0/24 ip4:209.40.100.91 ip4:96.255.24.80/29 ip4:128.121.22.0/24 include:_spf.google.com ~all

    Checking to see if there is a valid SPF record.

    Found v=spf1 record for herndon-51.lastpass.com:
    v=spf1 mx ip4:38.127.167.0/28 ip4:74.84.128.0/24 ip4:74.84.130.0/24 ip4:209.40.99.0/24 ip4:209.40.97.0/24 ip4:209.40.100.91 ip4:96.255.24.80/29 ip4:128.121.22.0/24 include:_spf.google.com ~all

    evaluating...
    SPF record passed validation test with pySPF (Python SPF library)!

I understand that they're in "~all" testing mode.

I don't want to reject on these then.

What, in pypolicyd-spf config do I need to set to NOT block on test mode fails?

Here's my pypolicyd-spf config

    cat python-policyd-spf/policyd-spf.conf
        debugLevel = 1
        defaultSeedOnly = 1
        HELO_reject = SPF_Not_Pass
        Mail_From_reject = Fail
        PermError_reject = False
        TempError_Defer = False
        skip_addresses = 127.0.0.0/8,::ffff:127.0.0.0/104,::1
        Header_Type = AR
        Authserv_Id = policyd-spf.mail01.example.com

Question information

Language:
English Edit question
Status:
Answered
For:
pypolicyd-spf Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Scott Kitterman (kitterman) said :
#1

That is a rejection due to the HELO check not passing (unlike Mail From testing, there aren't reasons like transparent forwarding that would likely cause SPF to fail when it is being rolled out, so the default value for HELO is different). Specifically, change HELO_reject = SPF_Not_Pass to HELO_reject = Fail to do what you are asking.

That said, they seem to be using the same HELO argument for a wide variety of machines which is non-standard. If you have any relationship with the sender, you might suggest they fix their SPF record. Changing:

ip4:38.127.167.0/28

to

ip4:38.127.167.0/26

would do it.

Revision history for this message
jasonsuser (b3411936) said :
#2

> Specifically, change HELO_reject = SPF_Not_Pass to HELO_reject = Fail to do what you are asking.

I understand the difference now.

I'm not sure why a 'default', or any other, would execute any action-trigger if a policy is in 'test'

But given the SPF docs'

        Statement Result Meaning
        +all pass Allow all mail
        -all fail Only allow mail that matches one of the
                              parameters (IPv4, MX, etc) in the record
        ~all softfail Allow mail whether or not it matches the
                              parameters in the record
        ?all neutral No policy statement

It seems to me that for those of us who start with default, that's a dangerous one. IT obviously rejects things that, per the spec, should not be.

Just my $0.02.

> you might suggest they fix their SPF record.

Done, thanks.

Revision history for this message
Scott Kitterman (kitterman) said :
#3

The SPF RFCs (4408 and 7208) do not specify what receivers are supposed to do, so from a standards perspective, there is no right or wrong answer. I chose that default about a decade ago because it seemed a low risk way to get rid of additional forgeries. I hear complaints about it approximately once every several years, so I continue to believe that was a reasonable decision.

Of course, people have different opinions, so it is configurable. If you have any suggestions for the included documentation that would have made it easier to resolve this on your own, I would appreciate it.

Revision history for this message
jasonsuser (b3411936) said :
#4

> Of course, people have different opinions, so it is configurable. If you have any suggestions for the included documentation that would have made it easier to resolve this on your own, I would appreciate it.

A blunt, clarifying statement of the functionally-obvious-to-those-that-already-know.

E.g., something to the effect of

'This default was chosen because it seemed a low risk way to get rid of additional forgeries.

You should note that this default will ALSO reject 'softfails'.

That means that senders whose policy is published as being in test mode (~all) will have their email rejected by you, even though they've explicitly stated that that should NOT be done.

If, OTOH, you want compliance with the senders' policy, change

change 'HELO_reject = SPF_Not_Pass' to 'HELO_reject = Fail' in your config.'

Ideally right in the 'policyd-spf.conf.commented' file.

Of course edited to correctness by someone with better detailed understanding of the spec!

-OR-

even though "The SPF RFCs (4408 and 7208) do not specify what receivers are supposed to do", choose instead to use *defaults* that comply with senders' published policies. It should be the user-defined/controlled EXCEPTION to defaults that allows us to " get rid of additional forgeries" at our discretion.

In any case, 'my' problem is solved, so thanks!

Can you help with this problem?

Provide an answer of your own, or ask jasonsuser for more information if necessary.

To post a message you must log in.