Terry Zink writes: > Franck Martin writes: > > I'm more concerned that the implementation at Microsoft does not > > reject the message when p=reject but move the email to the spam > > folder (with all payloads disabled, etc...) > > It’s done this way because it works better for our overall user > base than flat-out rejecting the message in SMTP.
This has been obvious to mailing lists from the very beginning. I understand the rationale for reject in the case of transactional mail flows, but for that, the p values should have been "unauthorized" [please reject], "suspicious" [do not deliver normally], and "none" [no inference or action needed], with the bracketed text being glossed in the text. And there should have been language in the RFC making clear that originating systems are really refusing to authorize mail flows that fail From alignment, including prospectively (eg, mailing lists whose processing invalidates DKIM signatures should reject). @Franck: I'm sorry, I understand why your use case wants "reject" to mean reject, but it wasn't in the cards given use cases like Yahoo!/ AOL. Receivers simply were not going to throw away large quantities of "good" mail their users actually requested, and Mediators weren't going to stop providing their value-added processing or violate RFCs for you. I don't recall you pushing hard for a clear "use only for transaction flows" clause in the RFC, nobody really did. Without that, such mechanisms always find other uses, which make a hard-line policy untenable for other communities. Please accept that, and think instead about the next step. For example, GNU Mailman is currently working[1] on implementing Authenticated Received Chain, an I-D with some promise for alleviating the pain of mailing lists receiving posts from p=reject sites. Footnotes: [1] Yes, we recognize that this kind of processing is much better done in the MTA. However, many mom-and-pop lists don't have control over their MTA, but do have control over Mailman. _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
