On 7/15/2015 4:50 PM, Bill Cole wrote:
On 15 Jul 2015, at 15:52, Bowie Bailey wrote:
I am trying to use whitelist_auth to whitelist emails from
staplesbilling.com. This should work, as they have an SPF record:
$ dig staplesbilling.com txt +short
"v=spf1 a:hosts.rrdesp.com -all"
$ dig hosts.rrdesp.com a +short
162.27.43.121
162.27.247.118
162.27.247.119
162.27.247.120
162.27.247.121
162.27.43.107
162.27.43.118
162.27.43.119
162.27.43.120
But SA seems to be trying to find an SPF record for the connecting
server rather than for the sending domain.
dbg: spf: checking to see if the message has a Received-SPF header
that we can use
dbg: spf: using Mail::SPF for SPF checks
dbg: spf: checking HELO (helo=sr03a.SMTPNA11.rrdesp.com,
ip=162.27.43.120)
dbg: spf: query for /162.27.43.120/sr03a.SMTPNA11.rrdesp.com: result:
none, comment: , text: No applicable sender policy available
dbg: spf: already checked for Received-SPF headers, proceeding with
DNS based checks
dbg: spf: relayed through one or more trusted relays, cannot use
header-based Envelope-From, skipping
dbg: spf: def_spf_whitelist_from: already checked spf and didn't get
pass, skipping whitelist check
dbg: spf: whitelist_from_spf: already checked spf and didn't get
pass, skipping whitelist check
Why is it looking for an SPF record for rrdesp.com? That is the
sending server, shouldn't it be using the domain from the From or
Envelope-From instead? This SPF check looks backwards to me. Am I
missing something?
Yes: https://tools.ietf.org/html/rfc7208#page-8 Section 2.3
SPF can be used to check whether a HELO domain is authorized for used
by a particular IP AND can be used to check whether the domain part of
the Envelope-From (the argument to the SMTP 'MAIL' command, which is
not necessarily present in any message header) is authorized for use
in MAIL commands from a particular IP.
SPF is NEVER appropriate for use to check the domain part of the
"From:" header or any other header not KNOWN to be added by a trusted
MTA and to contain the Envelope-From address. For example, many MTAs
prepend a "Return-Path" header when passing a message to filters or to
the local delivery agent. If I'm reading that debug output correctly,
SA doesn't seem to be able to parse out an Envelope-From from the
message, so maybe a tweak to the MTA and/or explicit specification of
envelope_sender_header in local.cf is in order.
On the other hand, that debug output does seem to be making excuses
that don't make sense, so maybe I'm reading it wrong. For example,
"relayed through one or more trusted relays, cannot use header-based
Envelope-From" seems like an irrational non sequitur.
Thanks for the suggestions everyone. I haven't messed with SPF checking
in quite some time, so I wasn't thinking about it right. I was able to
get my MTA to add a Delivered-To header, which SA seems happy with, so
this should fix the original problem.
I still don't understand the query for sr03a.SMTPNA11.rrdesp.com. That
is a sending server parsed from one of the Received lines. What is the
expected result of checking SPF on a mail server address? If it got a
result back with it's own IP address in the list, would that be a pass?
(everything sent from this mail server is allowed to be sent from this
mail server...)
--
Bowie
