On Fri, May 31, 2019 at 6:59 AM Douglas E. Foster < fost...@bayviewphysicians.com> wrote:
> I cannot speak to IETF consensus, since I am new to that process and I > seem to be an outlier already. > Perhaps the onus is on you to take the time to understand IETF and it's processes before demanding changes. Just a thought. > > 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. A courier is responsible for keeping the signed and sealed part of a > message unaltered. Envelope marks are acceptable. > > Perhaps you should go back and read the history and purpose of DKIM. > 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. > Non-repudiation is not the purpose of DKIM signing. The purpose was (and is) to provide a mechanism for mailbox providers to evaluate whether an email message was authorized by a particular domain. > > 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. > You are certainly entitled to your opinion. > > There are some obvious use-cases for MTA changes to a message, and we > would do well to document and address them. > Perhaps the you part of "we" should submit an Internet Draft undertaking the work you want done. > > 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. > Can you please show us the documentation that supports your assertion that " DKIM was supposed to provide sender authentication when SPF was invalidated by forwarding"? When I read the DKIM RFC I find nothing to support your assertion. DKIM was the result of the merging of Internet Identified Mail (IIM) and Domain Keys (DK) proposals. Quite a few of us were around at the time it happened. These things happened in parallel to SPF and not as a "fix" to SPF. Thank you for your creative attempt to rewrite history. > > 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. > > Thank you for your proposal. To channel a long time participant, I invoke King Canute. If you believe major players should take a particular action in unison then perhaps you should be reaching out to those major players. (Side note to major players, no need to thank me for pointing this out) > More discouraged than ever, > Hope springs eternal. Michael Hammer >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
