To continue with the example that I used with Hector yesterday: You figure out that you need to configure this rule for a particular mailing list:
"Subscriber evaluators need to trust any From address for messages that are verifiably from the List Server's MailFrom address." Of course, you only come to this realization AFTER a bunch of messages were blocked, because your filtering product does not have a test mode for DMARC. But then you realize that your filtering product also does not provide a way to implement that rule at all. So you turn off DMARC, get mad at your vendor, and start looking for a vendor who does understand email filtering. But you never stop looking because there is not a vendor out there that can do this. So then you have to go to your management and say, "I know we are spending $20 per employee per year for email filtering, but the vendors don't understand Sender filtering, so we need a manpower commitment to build a custom solution based on a freeware product called PostFix." Within the last few weeks, I posted on a vendor forum that I could not use his DMARC implementation because it did not provide an adequate exception mechanism. In all seriousness, the support moderator asked "Why would you need an exception to DMARC Fail?" This is my world. Doug Foster On Mon, May 15, 2023 at 4:25 AM Alessandro Vesely <ves...@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 >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
