On Friday, April 10, 2015 05:08:56 PM John Levine wrote: > >I wouldn't go so far as to say I like this, but it's definitely the least > >bad solution I've seen so far. > > That's how I intended it: This one stinks 47% less than the others! > > >1. Doesn't help third party originators (which may be a feature). > > I wouldn't say it's a feature, but third parties are a much harder > problem. The least bad I can think of for that scenario is some sort > of browser oauth thing that lets the third party log into the user's > account to send the message, which is OK for individual mail an > article but not for the PTA's mailing list.
Yeah. I don't think it's possible to allow sending by arbitrary 'authorized' third parties without also making it possible to allow sending by anyone. > >2. Enables third parties to send arbitrary content that will pass (yes, > >this is the point, but it's also a negative to some degree). ... > > > >I do wonder though if there's a potential replay issue. > > I'm hoping that signing the Message-ID will limit the damage there. > Many mail systems combine multiple messages with the same ID even if > they don't have the same contents. I know Message ID is supposed to be globally unique, I don't think that Message ID has historically been viewed as a security property. I got two copies of this message from you with Message ID Message-ID: <[email protected]>. One was sent directly to me and one via the mailing list. If I were tracking Message IDs for reuse, one of those messages would be considered bad. My system doesn't combine them, but if it did, I don't know what content would be displayed. For replay protection, I think the Message ID could work, but I think the list would have to change to use its own Message ID associated with its signature. The need to keep and consult a database of historical Message IDs does add a substantial negative in my book. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
