Re: [dmarc-ietf] Give up on SPF alone

[Douglas Foster <[e-mail]>]

Sorry Hector, but you are wrong on the theory and off topic.   DMARC and
SPF authenticate different things.  DMARC is designed to override SPF Fail
to handle the case of forwarding without SRS, which would be optimal if all
messages were signed.

Bandwidth optimization was an issue when we were on dial-up, but now we
size capacity to need, and use other defenses for DDoS attacks that
saturate bandwidth.

Discarding DMARC is not feasible, because you cannot revoke an RFC and you
cannot make people stop knowing what they already know

DF

On Sat, Apr 15, 2023, 10:52 AM Hector Santos <[e-mail]> wrote:

>
>
> On Apr 14, 2023, at 7:31 PM, Dotzero <[e-mail]> wrote:
>
> On Fri, Apr 14, 2023 at 5:55 PM Hector Santos <[e-mail]
> <[e-mail]>> wrote:
>
> Yes, it is simple DeMorgan’s Theorem where you use short-circuiting logic.
>>
>> DMARC says that any FAIL calculated via SPF or DKIM is an overall DMARC
>> failure.  In standard boolean logic is it an OR condition:
>>
>> IF SPF FAILS or DKIM FAILS Then Reject.
>>
>
> You have it absolutely backwards.
>
> DMARC says if either (aligned) SPF validates or (aligned) DKIM validates,
> it passes.
>
>
> Hi Mike,
>
> Appreciate your comment.
>
> This OR gate logic will short-circuit DKIM with SPF validating.
> Optimizing means not processing the payload and just issue a 250 which is
> ‘absolutely' not what we want. In fact, DMARC logic is an AND gate of two
> protocols; one standard, one informational with some controversial
> constraints (alignment).  I think you maybe meant:
>
> SPF predates ADSP/DMARC. It is a 5321 level technology.  It is not a
> payload 5322 technology.   Interestingly, you might be thinking in terms of
> SenderID which was a 5322 technology which offers SPF with the PRA
> (5322.From) as a new identity to evaluate.
>
> I know it’s hard to believe for many but there is still a good percentage
> of domains that do not do ADSP or DMARC and maybe not even DKIM.  Just
> consider platforms using Integrated Mail Bots to automate things and they
> who don’t need the overhead. SPF is good enough.
>
> Using Pareto, SPF is the only thing needed for hard reject policy (-ALL).
> DMARC is useless at this point unless you want it to override SPF hardfail
> rejects and record and send reports,  That would be a local policy.  An
> implementation detail.
>
> Over 88% of the time, when SPF fails, DKIM/ADSP/DMARC, if available would
> also fail.  So the payoff is high to short-circuit and lowered when you
> needless transfer a potential large and harmful payload.
>
> But for SPF soft failures (~ALL), that is when the interest of coupling
> SPF soft fail results  with ADSP results got traction.
>
> SPF verifiers will pass SPF weaker policy results in meta-header data and
> that meant the payload protocol can help here.  Microsoft explored this
> method and had a secret source to determine how soft failures can be
> coupled with ADSP results.
>
> DMARC never considered partial results. DMARC see SPF as a pass not
> soft-fail.  So if DKIM passes and all four (4) domain identities are
> aligned, the transaction passes.  That’s an AND gate and you don’t need to
> even to process SPF or do DKIM validation if the domains do not align.
>
> —
> HLS
>
>
>
>
>