I know SPF generates some polarizing views, but my view is this:
- if you can trust that legit mail will have a 100% pass rate for legit email,
use a hardfail and those operators who evaluate it and use it will see benefit.
Win.
- if you can't trust that pass rate, publish a soft fail and let other measures
come into play.
It's hard to penalise people for correctly using the standard. So in the OP
scenario the move to soft fail was the right call IMO.
Mark.
On 7 December 2018 3:15:40 PM NZDT, Brandon Long via mailop <mailop@mailop.org>
wrote:
>I'd say you're likely to get two types of receivers: those that know
>that
>spf policies are useless so they'll ignore -all, and those who think
>that
>they should do what the policy says.
>
>I'd say that most people who believe the latter are smaller operators.
>
>I don't see any reason to publish -all if you are planning to send any
>messages in that domain, it doesn't gain you anything.
>
>Brandon
>
>On Thu, Dec 6, 2018 at 6:00 PM Autumn Tyr-Salvia <tyrsal...@gmail.com>
>wrote:
>
>> Hello Mail Operators,
>>
>> My job is to help large organizations figure out their email
>> infrastructure and authenticate everything legitimate with the goal
>of
>> going to DMARC p=reject. A customer recently reported an issue to me
>about
>> receiver behavior that I hadn't heard before, so I wanted to reach
>out to
>> get a feel for whether this is more widespread than I realized or if
>this
>> particular receiver is behaving strangely.
>>
>> It's a bit of a long story why things are set up in the way they are
>for
>> this particular situation, and in the interests of not writing a
>novel
>> here, I'm going to cut to the chase:
>>
>> Customer is sending messages that pass DKIM with first party signing,
>so
>> they pass DMARC. Unfortunately, SPF fails, and the SPF record uses a
>-all,
>> so it's a hard fail. There is an SPF entry at the sending subdomain,
>and
>> the SMTP MAIL FROM domain is aligned, but the SPF record does not
>include
>> the sending IPs. There are complicated reasons why they can't just do
>that
>> easily.
>>
>> DMARC requires only one aligned method of authentication to pass,
>either
>> SPF or DKIM. Since these messages pass with aligned DKIM, they pass
>DMARC.
>> In theory, all should be good, right?
>>
>> We have received reports that a particular organization they are
>sending
>> to is seeing the SPF hard fail and choosing not to further evaluate
>DKIM,
>> and is rejecting these messages on SPF hard fail alone. I don't have
>the
>> bounce message handy, but it said something like "SPF hard fail: your
>> organization's security policy does not permit this message." The
>> organization they're sending to is a small nonprofit, but the MX
>record
>> shows that they are using GoDaddy's hosted email.
>>
>> When one of the email admins involved had the recipient ask their
>email
>> vendor about it, they were explicitly told that if senders use an SPF
>-all,
>> if messages fail SPF, they will not accept them even if they pass
>DKIM and
>> DMARC. As a consequence, I had them try setting the domain to use a
>soft
>> fail ~all and test, and initial reports say that delivery was
>successful.
>>
>> I have a lot of experience with SPF, though admittedly, I don't have
>as
>> much experience with SPF failures (I see a lot of cases of no SPF, or
>> passing but not aligned SPF, but comparatively few actual failures),
>but I
>> haven't heard this distinction between hard and soft fail modes
>before.
>>
>> How common is it to have receiver systems set so that SPF hard fail
>will
>> reject messages even if they otherwise pass DKIM and DMARC, but to
>accept
>> them on the DKIM pass if the domain uses SPF soft fail?
>>
>> Given this situation, the customer is now considering whether they
>want to
>> move every domain they own to SPF soft fail instead, so I wanted to
>ask
>> around and get a feel for how common this is before they change all
>of
>> their many domains.
>>
>>
>> Thanks,
>>
>> Autumn Tyr-Salvia
>> atyrsalvia@agari
>> tyrsalvia@gmail
>> _______________________________________________
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
--
Sent from a mobile device.
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
