Re: [dmarc-ietf] WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

[Douglas Foster <[e-mail]>]

On SPF, our document should say simply,
" a DMARC-compliant evaluator MUST NOT reject a message, based on SPF
result, prior to receiving the Data section and checking for aligned and
verifiable signatures."

Of course, evaluators may still reject early base on known-bad server or
known-bad Mail From domain, but not based on SPF alone.

I weary of the notion that the solution to all authentication problems is
to stop authenticating.

DF


On Sun, Mar 31, 2024, 6:41 AM Alessandro Vesely <[e-mail]> wrote:

> On Sat 30/Mar/2024 21:05:17 +0100 Seth Blank wrote:
> > This is a real operational problem, so I wanted to expand guidance. The
> note
> > about best practice may or may not be appropriate here, but I think it
> works.
> > There are multiple M3AAWG documents which cover this use case, and we
> can also
> > link them if valuable.
> >
> > [...]
> >
> > Since DMARC only relies on an SPF pass, all failures are treated
> equally.
> > Therefore, it is considered best practice when using SPF in a DMARC
> context
> > for domains that send email to end records with a soft fail ("~" /
> "~all").
>
> The last phrase is overly strict.  To /consider using/ soft fail ("~") or
> neutral ("?") should be enough.  For example, I use an SPF record
> terminating
> like so:
>
>     ?exists:%{ir}.list.dnswl.org -all
>
> It can be criticized for imposing DNS usage, but it works too.  One could
> also
> use ~include:vast.whitelist.example before -all; it would work as well.
>
> Using ~all is akin to use p=none.  Be armed but only load blanks.  Its
> being
> best practice bears witness to the weakness of domain based
> authentication.
> Currently we are in the mid of a swamp, but if we hope to ever get out we
> can
> start by softening these kind of requirements.
>
>
> Best
> Ale
> --
>
>
>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>