Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion

["Douglas E. Foster" <[e-mail]>]

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.  
 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" <[e-mail]>
Sent: Friday, May 31, 2019 12:41 AM
To: [e-mail]
Cc: "IETF DMARC WG" <[e-mail]>
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