Tony Hansen writes: >> That doesn't help the DMARC situation now, but DMARC could be >> given other options once that happens. > > I agree completely that a change to DMARC is needed in conjunction > with having clear ML specs.
A change to the protocol? What? I don't see it. The protocol actually in use by many domains seems to actually do what it's designed for quite well. "p=reject" makes a lot of sense for banks, for example. I don't think it can be removed from the spec, and its proper use doesn't cause widespread problems for mailing lists. It's use outside the design space that causes problems. Those uses are by desperate organizations, and they'll ignore any change that attempts to prohibit them because they are desperate. > I've heard it said that the majority of the mailing lists out there > are managed by only a handful of ML management systems. I maintain > that these ML packages are in the same boat as openssl. It sure > would be nice if we could get some of that consortium money thrown > at that handful of ML management systems. I'm sorry, but that's nonsense for the volunteer-maintained MLMs like GNU Mailman. We already have implemented multiple mitigations, and it doesn't take much code. We just hate them all and leave it up to mailing list operators to choose the one they dislike least. If other MLMs haven't done so already, I doubt it involves all that much effort for them. > That's a political solution for this current technical problem. Mailing lists don't have a *technical* problem. If DMARC were used as designed, we'd never have noticed. The problem is political: we have a wounded 800-lb gorilla on the loose (not to forget a wounded 500-lb gorilla joining the fun). > However, before it can happen: we NEED clear specs as to what > should be done by ML systems, at least in the face of DKIM and SPF > (and DMARC) SPF and DKIM are now ancient history, at least as far as Mailman development goes. We've already done what's technically possible. We'll see what more our users want us to do about DMARC, if anything. There just isn't anything technical to be done AFAICS. I can't speak for other MLMs, but I think that if there's going to be real progress, the answer is with the MUAs. 1. If identity alignment fails, *all* links, scripts, and forms in the message should be deactivated, even if it's already in the spam folder. 2. If there's a type=password field in the message, *all* links and forms in the message should be deactivated, even if it's already in the spam folder. 3. Ditto misaligned MIME type and file name. 4. Ditto active or unknown attachments. 5. On activation of the message, all href and src URIs should be displayed clearly, along with an intrusive warning that ID theft is very common, so the user should check everything carefully (preferably call the author on the phone) before doing anything suggested by the message, even if it's already in the spam folder. I'm sure there are other things they could do, but those are off the top of my head. Finally, Tim Draegen is right, it's not just about mailing lists. Let's not forget all the other use cases that are stomped on by the inappropriate use of "p=reject". Steve _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
