DKIM+SPF says "our domain, including subdomains covered by this policy,
will never use an ESP".  (Since most ESP messages pass SPF based on the ESP
domain)

This seems unlikely to be a reliable assertion, so the effect on
disposition is likely to be strongly negative, even without the effect on
forwarders.  I oppose.

Similarly, SPF only seems unlikely to provide improved dispositions.
Evaluators are unlikely to find it worth honoring.

All I think we need is a tag that says,nl "ignore SPF if you understand
DMARC" .   Since only DMARC-aware evaluators will be looking for the policy
which contains the tag, I see no obstacles.



On Mon, Jun 26, 2023, 12:14 PM Alessandro Vesely <[email protected]> wrote:

> On Mon 26/Jun/2023 14:51:34 +0200 Barry Leiba wrote:
> > If we consider this sort of thing, I want to push to keep one thing
> > off the table:
> >
> > Saying that SPF *and* DKIM *both* have to pass is a VERY BAD approach.
> > Let's please just remove that from consideration.  It has not been in
> > DMARC up to this point, and it would be really bad to add it.
> > Deliverability would be worse than ever because we would get the worst
> > of both: fragility of SPF when messages are relayed/forwarded, *and*
> > problems caused by misconfigurations in *either* SPF *or* DKIM.
>
>
> I agree it'd be an extreme setting.  It could only make sense in very
> extreme
> cases.  However, in those cases it might make sense.
>
> In addition, if ARC-driven forwarding setups will gain the ability to
> override
> DMARC, at least for established forwarding paths, the forwarding
> prohibition
> would then be softened.  After all, spf-all requires a comparable behavior
> (except that SPF allows intermediate results) and many domains use it
> satisfactorily.
>
> The conundrum is protecting users from self-injury versus unleashing the
> full
> power of the combined mechanisms.
>
>
> > I can accept some mechanism for the sender to say "SPF only", "DKIM
> > only", or "either SPF or DKIM".  I cannot except a version of DMARC
> > where *both* must pass.
>
>
> Frankly, I cannot imagine the usefulness of auth=spf only.  People who
> don't
> implement DKIM or don't like it don't bother publishing a policy to
> explicitly
> excluding it.  It's enough not to sign.  Excluding DKIM would be useful if
> keys
> have been compromised, an they have a long lifetime while, by chance,
> DMARC
> policy is given with TTL 3600.  It doesn't seem to be realistic.
>
> Still, I'd allow that possibility for symmetry reasons.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
> _______________________________________________
> dmarc mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmarc
>
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to