John R Levine writes: > We have lists where we would be unhappy if the added stuff went away, > e.g., a line at the front reminding people that the messages are private > and not to be forwarded.
OK, so that's new harm done by this behavior. On some such lists it might be mitigated by the fact that the mail actually gets through now. (But unambiguously in other cases the mail *was* getting through unscathed but now the recipient MTA decides to strip.) > Even in the unlikely event that MUAs would do this, MUAs, unlikely, I suppose. MTAs could do it too, and I think that's more likely. > which I find vanishingly unlikely, it doesn't do what lists > managers need. Stop exaggerating. It is not the case that anywhere near 100% of list managers actually *need* doodads, although a few (covering less than 1% of recipients, I bet) do need them, and many find them attractive. > I think it would be useful to limit ourselves to hacks that don't require > changes to MUAs, draft-kucherawy-dkim-list-canon requires no changes to MUAs, although mailbox + MUA providers *might* want to do it on the MUA side rather than the MTA side. > minimal changes to list software draft-kucherawy-dkim-list-canon requires no changes to list software, and it's purpose is to avoid changes to list configurations (or enable changes that currently must be avoided because of DMARC). > and sending mail systems, I don't see how draft-kucherawy-dkim-list-canon requires more changes of the sending *system* than draft-levine-dkim-conditional or draft-kucherawy-dkim-delegate does. True, the software would be more complex, but presumably it would be developed by Postfix, Exim, Sendmail, and Microsoft, plus maybe an independent milter project or two, and the "paranoid and easy" configuration is dead simple and possibly suitable as a default (although somewhat dangerous, see "unambiguously" above). > and don't use external oracles. I see no external oracles required. Oracles are optional and desirable, yes, but that's true of everything in mail filtering. > Then they might have some chance of adoption. _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
