Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Hector Santos <[e-mail]>]

On 7/21/2020 11:51 AM, Dave Crocker wrote:

> Also then consider that the existing MLM behavior has existed and been
> useful for roughly 45 years.
>
> The problem, here, is DMARC's imposing a change in email semantics.

Dave, there are different ways of looking at this. I've work with and 
developed MLM/MLS for as many years, and there are "mail engineering 
ethics" here to consider.

The first is Mail Tampering, which is part of 1986 US ECPA guidelines, 
   Mail Tampering was an exception, not a rule, with the MLM/MLS to 
allow for body changes. This was not a normal expectation except to 
allow a very basic overhead level with headers/footers. Absolutely no 
tampering with the context, the "gist" of the copyrighted messages, is 
never expected to be altered. It was never expected for the Author 
field to be changed unless you had a digest or something like it where 
clearly the mail was not coming from you.  In general, it would have 
been a US ECPA violation.  It was not something you often seen done, 
if ever.  The Newspaper Publisher industry is the only industry where 
legal concept of "Print To Fit" was acceptable for 100+ years.  But if 
a MLM/MLS is considered a publisher, would it be exempt?  Even then, 
the From is not changed in your letter to the editor.

Second, DMARC is imposing a new security protocol based on the premise 
the "From" is not expected to be changed. How will the MLM/MLS fit?

It can:

1) Supports the security protocol and the problem is solved. 
Exclusive domains made a published policy statement for exclusive 
signing.  The Exclusive Domains does not expect its users to be using 
their domains outside the work place. The policy is honored.

2) Unintentionally ignorant of the security protocol, does nothing. 
This is your true legacy system.

3) Intentionally ignorant of security protocol while continue to 
resign mail. This is not a legacy system if it has adapted to resign 
mail and chose to neglect and ignore the security protocol.

4) Same as #3 but also rewrites From field.

#1 and #4 will resolve the problem.  The proper protocol engineering 
fit is with #1. While #4 resolves the issue, it is perpetuating an 
undesirable design that can have serious mail engineering consequences 
simply by watering down the value of persistent 5322.From.  The #2 and 
#3 MLM/MLS will be remain as problems until they change or the user is 
made aware he can't use his exclusive domain on a public forum.


-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos