On Fri, May 31, 2019, at 6:59 AM, Douglas E. Foster wrote: > I cannot speak to IETF consensus, since I am new to that process and I seem > to be an outlier already. > > Agency and signatures are well understood legal concepts. 3000 years ago, > people sealed their letters with a signet ring stamped in warm clay. Signing > technologies have changed in that time, but the principle has not.
It would probably behoove you not to lecture experts in Internet messaging about 3000 years of history on a public mailing list. I'm just saying. Thanks, Stan > > A courier is responsible for keeping the signed and sealed part of a message > unaltered. Envelope marks are acceptable. > > A digital signature is supposed to provide non-repudiation. If I submit a > signed message to a list processor, and the list processor voids the > signature, it has given me verifiable repudiation, the opposite of what > either sender or receiver want. > > A closed group on a single server can use whatever rules they choose to > implement in that community. For example, a web forum operates on the rules > of the forum operator. However, an open group using the email infrastructure > has to work within the infrastructure it uses. In the email infrastructure, > the recipient has to deal with fraud, and any recipient accommodation to > "harmless" fraud facilitates the people who are doing "harmful" fraud to that > recipient. > > There are some obvious use-cases for MTA changes to a message, and we would > do well to document and address them. > > The first that comes to mind is MTA comment fields. > - A list processor wants to add a comment indicating something about the list > that sent it. > - A spam filter wants to add a tag indicating that the message is suspicious, > but not sufficiently suspicious to be blocked. > > IETF would do well to specify a mechanism for MTAs to add information which > MUAs present to the user, while identifiying that that the information came > from the MTA rather than the original sender. > > Another use-case is related to body sections. IETF only forwards plain text, > while most email solutions send messages in HTML+Text. I assume that IETF > also drops attachments. DKIM cannot handle this because it hashes the entire > body. A signature system that signed each section individually would allow > sections to be dropped, with notification to the user, without breaking the > signatures on the other MIME types. > > DKIM was supposed to provide sender authentication when SPF was invalidated > by forwarding, so DMARC said that the two techniques should be evaluated > together. I am realizing that if SPF is invalidated, DKIM is probably > invalidated as well, so we have no usable sender authentication technology. > This may explain why so many products that I have examined lack support for > DMARC or lack good exception mechanisms for SPF, DKIM, and DMARC. > > It seems that email needs something like "DNS Flag Day", where major players > announce a date after which certain behaviors that will no longer be > tolerated. But as others have said, IETF is not that organization, and the > organization may not exist. > > More discouraged than ever, > > Doug Foster > > > > > > > > > > *From*: "Dave Crocker" <[email protected]> > *Sent*: Friday, May 31, 2019 12:41 AM > *To*: [email protected] > *Cc*: "IETF DMARC WG" <[email protected]> > *Subject*: Re: [dmarc-ietf] Debugging and preventing DKIM failures- > suggestion > > On 5/30/2019 7:49 PM, Douglas E. Foster wrote: > > I rather hoped that IETF would be the poster-boy for list processing > > done correctly. > > "Correctly"? > > A message to a list is 'delivered' to the list. As in, it goes to the > specified addresse... the list. A message from a list has been > re-posted by the list. > > There are no constraints on the changes that are permitted to a message, > before it is re-posted. There are no specifications that limit or > direct the behaviors of a list processor. > > Different groups want and probably need different behaviors by a list > processor. Periodic efforts to create such constraints have failed. > > So while it would certainly make things easier to have list processors > behave in a simple, consistent manner, there's ample evidence that ain't > gonna happen. > > If you can link the 'correctly' you are suggesting, to some documented, > community consensus, please cite it. > > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
