Re: [dmarc-ietf] Fwd: New Version Notification for draft-fosterd-dmarc-spf-best-practices-00.txt

Ale, I am disappointed by your characterization of it as "might be useful",
but I appreciate that you engaged with the topic quickly.

I feel as much passion about exception management as the rest of the group
feels about mailing list damage.

Consider this simple and common authentication problem:

"Example.com has started using Outlook.com as their hosting service, but
they forgot to update their SPF record.  Now their messages are returning
SPF FAIL.  They don't have a DKIM signature or a DMARC policy, so there is
no SPF override."

The safe and SPF-equivalent exception will link the "Example.com" SMTP
domain to the "Outlook.com" server domain.  Creating a rule based on source
IPs is impractical, because the number of servers is large and unknowable.
 The necessary solution is to check that a host name ends with "
outbound.protection.outlook.com" and can be forward confirmed to the source
IP.  For Outlook.com, only the Reverse DNS is verifiable.  For most other
large hosting services, HELO is verifiable.

Every email filtering product should be able to provide this safe solution
to a common problem.   But you cannot buy a product that can do so.
Instead, you get these one of these two "solutions":

   - Lower-end filtering products solve this problem by whitelisting
   Example.com and hoping that it never gets impersonated.

   - Higher-end filtering products say that it is all handled perfectly by
   their Artificial Intelligence layer, which is too complicated to explain,
   but it is nothing to worry about.  Nonetheless, it is impossible to
   configure a rule like that manually.

Since product developers don't know how to handle this simple exception, I
blame the specification for failing to define an exception management
strategy.   Since the group seems unwilling to include exception management
in the specifications, I am hoping at minimum that we can document it in a
Best Practices document.,

Doug

On Mon, May 15, 2023 at 4:25 AM Alessandro Vesely <vesely@tana.it> wrote:

> On Sun 14/May/2023 13:32:18 +0200 Douglas Foster wrote:
> >  From the document:
> >
> >     "Without exception management, Sender Authentication dies as soon as
> an
> >     exception is necessary. A poorly designed exception process may
> enable the
> >     very impersonations that Sender Authentication is intended to
> prevent."
> >
> >
> > It could also be subtitled, "How to use Sender Authentication without
> damaging
> > mailing lists."
>
>
> The I-D seems to be conceived like a postmaster manual.  In that respect,
> it
> might be useful, and an occasion to clarify the impact of email
> authentication
> over "traditional" filtering techniques.  However, it is not clarified
> what
> kind of mechanisms provide the evaluator feedback which allows continuous
> improvement.
>
> The parallel between DMARC and SPF needs to rule out layer violations,
> since
> SPF is one of the DMARC mechanisms.
>
> Use of SPF is not fully explained.  In particular, Section  2.5,
> Non-privileged
> Messages with Sender Authentication FAIL and Content Filtering PASS,
> doesn't
> take into account that SPF fail, -all, can imply rejection at MAIL or RCPT
> commands, whereby the message content won't be available.  (The topic is
> well
> described in Appendix D of RFC 7208.)
>
> DNS white lists could be mentioned as an example of alternate
> authentication.
>
>
> Best
> Ale
> --
>
>
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>