Keith Bierman writes: > While the process of revising the RFC should have been followed,
No revision of the RFC was made, and Yahoo! followed the RFC in updating its own DMARC policy. That's where DMARC sucks[tm]. > it does seem that they are trying to solve a real problem. Perhaps. > Mail should come from who it says it comes from, not make it > trivial to pretend to be someone one isn't. Well, maybe. But DMARC doesn't solve that problem. It's still trivial to pretend to be someone you aren't. Just get an address at Yahoo! I suppose what you mean is phishing, ie, pretending to be a specific other someone. Well, if you want to be sure of identity, insist that your correspondents digitally sign their mail. Effective checks must be done in the MUAs because it's still very easy to spoof somebody (use "Chase Bank" <chase-b...@0xdeadbeef.my>, for example) even with DKIM or SPF. What needs to be done to make this user-friendly is for the MUAs to provide a simple way to configure "trusted partners" such as your bank and your psychotherapist. The bank would probably be very easy (it uses DKIM so the MUA can check it). Web-based MUAs can do this for you (Google's "Gold Key" program). The personal relationship problem is harder, but basically you need a convenient way to distribute PGP public keys and add them to specific correspondent records. For licensed professionals, governments could maintain third-party authorization mechanisms a la OpenAuth. > So why not adopt a standard where the *sender* is always the list? Because Internet mail makes a specific distinction between *sender* and *author*. we already *have* a way to identify the *sender*, and we already *do* identify the list as the sender IIRC (Resent-* headers), and in most cases we do make it clear that the list is a list (RFC 2369 headers). However, in their bottomless contempt for the average user, the DMARC authors chose to insist on authenticating the *author* with the *sender's* credentials because that's the best that can be done without cooperation from the recipient and her MUA. > The obvious downside is that "reply to poster" stops working, but > do these "security" tools care if the reply-to is different from > sender? if the list default is "reply to poster" set the reply to > as the original sender, but "correctly" identify the message as > coming from the mail server automation ... not the original sender. > > Other than noncompliance to the existing RFC(s), what am I missing? Nonconformance to RFCs means that you break all conforming implementations. "Reply-To Munging Considered Harmful" is just the start. Internet governance is based on the RFC process. If you allow large companies to disregard RFCs for their convenience, they *will* break things badly. (Small companies will break things, too, but not so badly.) Note that Yahoo! has initiated a denial of service attack on millions of innocent list subscribers. *This is not a one-time problem.* This will happen again every time a new domain changes its policy to reject, because even if we break *future* Mailman to conform to Yahoo!'s Brave New World, *past* Mailman installations will continue to exist and many of them will have taken stopgap measures (eg, moderating all Yahoo! subscribers). We have to take a stand against this kind of behavior. ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org