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

From: "Douglas E. Foster" <[email-masked]>
Date: Sun, 26 May 2019 08:22:25 -0400

Problem
  
 DKIM verification failures are difficult to debug because the recipient 
cannot detect where the problem occurred or why.
  
 Proposed Solutions
  
 1) Identify the point of failure
  
 It would seem helpful to support a DKIM trace record that a device can use 
to indicate that it detected a DKIM failure.  I am suggesting a header of 
the form "DKIM-InputFail", followed by the contents of the signature header 
that could not be verified.  This puts an upper bound on the location of 
the problem.  (Once the failure is documented, it should not be repeated by 
downstream servers.)
  
 A downstream MTA is still free to evaluate the original signature.   For 
example, an intermediate MTA may have reported the failure incorrectly 
because of a software bug.   
  
 2) Recover from Subject header changes that break signatures.
  
 One expected cause of DKIM verification errors is Subject header 
modification, either by spam filters or by list servers.   These types of 
changes can also be mitigated by trace headers.   If a device makes a 
change to the subject, it should add headers for "Subject-AsReceived" and 
"Subject-AsSent".  Any downstream system can then reconstruct which header 
text was in place when any signature was applied, regardless of how many 
Subject header changes occur during transmission.
  
 Downstream servers would also have the option of restoring the Subject 
header to its original value.   This would be appropriate when the Subject 
was tagged by the spam filter upon arrival to an administrative domain, and 
then is auto-forwarded to a different administrative domain.   If the 
outbound MTA restores the original subject, it increases the likelihood 
that the message will be accepted downstream.  
  
 The concept could be applied to other headers.   For example, I have seen 
messages with DKIM failures because an auto-forward server replaced the 
internal Message-ID with one of its own.   I don't know if there are 
legitimate reasons for intermediate MTAs to tamper with other headers.

---

From: Дилян Палаузов <[email-masked]>
Date: Sun, 26 May 2019 16:22:40 +0300

Hello Douglas,

1) Check the Authentication-Results header. An implementation could put there additional information as comment. A downstream MTA will reevaluate the DKIM-Signature anyway, if it does nkt trust the previous hop. Common case: aliases to random servers.

2) Check ARC, https://tools.ietf.org/wg/dmarc/ .

3) To fix the origin of a bad dkim signature problem the sender has to be notified about the inconsistencies so that the sender can take actions and correct the signing process, asuming the problem is not on verifier’s side. Propagating and logging the mismatched signature does not help correcting the source of the problem.

Part of the DKIM magic is the volume of papers one has to read in order to understand it, and fix whenever something goes wrong. Here come other email protocols: submit, mta-sts, dane for smtp, dmarc, https://starttls-everywhere.org/, wrong certificate purpose … and you end having very few people being able to understand and correct a problem, even when all the necessary informarion can be extracted from logs or error reports. If you cannot run different dkim verifiers towards a single dkim-signature with corresponding message, and if the sender repeatedly does not answer on emails, no further normative text helps you.

By the way, why writing you directly earlier today I got as reply '“reason: 550 Sender IP reverse lookup rejected”?

Regards
  Дилян

---

From: "John Levine" <[email-masked]>
Date: 26 May 2019 10:48:47 -0400

In article <[email-masked]> you write:
>-=-=-=-=-=-
>
>Hello Douglas,
>
>1) Check the Authentication-Results header. An implementation could put there additional information as comment. A
>downstream MTA will reevaluate the DKIM-Signature anyway, if it does nkt trust the previous hop. Common case: aliases
>to random servers.

That would be my suggestion.  You can put whatever you want into comments in the A-R header.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "John Levine" <[email-masked]>
Date: 26 May 2019 10:51:28 -0400

> 2) Recover from Subject header changes that break signatures.

This idea has come up, let us say, once or twice before.  If you're
trying to undo what mailing list software does and reconstruct the
signature, that is a rathole of no return.  Also keep in mind that
malicious parties can change the signature, too, and there's no way
I know of to tell a malicious rewrite from a benign one.

ARC is designed to deal with this situation.  Take a look.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 30 May 2019 11:20:41 -0700

On Sun, May 26, 2019 at 7:49 AM John Levine <[email-masked]> wrote:

> >1) Check the Authentication-Results header. An implementation could put
> there additional information as comment. A
> >downstream MTA will reevaluate the DKIM-Signature anyway, if it does nkt
> trust the previous hop. Common case: aliases
> >to random servers.
>

At one point in the early DKIM days we were discussing a way to have DKIM
verifiers return enough information to signers to indicate what the
mutation was that invalidated a message.  This was supremely useful in the
early days of DKIM when we were just figuring out how to interoperate; if I
keep a copy of the the canonicalized header and body of something outbound,
and then on receipt you find the signature doesn't validate, then you send
me the canonicalized header and body you saw, and I get to diff them to see
what mutation broke the signature.

We ended up with RFC6651 and the ones to which it references.  OpenDKIM
implements this, but I don't think any other implementation does, so its
use is obviously very limited.

And as John said, there have been numerous proposals over the years of ways
to annotate a message with what "standard" mutations were done so that at
verification time the receiver could decide which mutations it was willing
to forgive, but the community showed no interest in such complexities.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 30 May 2019 17:18:47 -0400

> to forgive, but the community showed no interest in such complexities.

It is my impression that the proponents of this idea tended not to be very 
familiar with mailing list software and imagined that most mutations were 
simple, like adding a subject tag or a text footer.  Those happen, but 
they are the very tip of the iceberg.  Modern list managers add, delete, 
and reorder MIME parts, flatten HTML into text, and a huge list of other 
things that no mutuation catalog could plausibly describe.

That's one of the reasons that ARC doesn't try to say what's changed, just 
what the authentication results were before and after.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Douglas E. Foster" <[email-masked]>
Date: Thu, 30 May 2019 22:49:03 -0400

Thank you for the education The IETF list processor seems to be an 
illustration of your point.
  	It invalidates the orginal sender's signature 	Then it adds an ietf.org 
signature 	Then the message is relayed internally within a single IETF 
server, where the IETF signature is invalidated. 	The the message is signed 
a second time with an valid IETF signature 
 I rather hoped that IETF would be the poster-boy for list processing done 
correctly.  Why is the message manipulation that you describe necessary or 
acceptable?
  
 Deeply puzzled,
  
 Doug Foster

----------------------------------------
 From: "John R Levine" <[email-masked]>
Sent: Thursday, May 30, 2019 5:19 PM
To: "Murray S. Kucherawy" <[email-masked]>
Cc: "IETF DMARC WG" <[email-masked]>
Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- 
suggestion   

Regards,

_______________________________________________
dmarc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmarc

---

From: Dave Crocker <[email-masked]>
Date: Thu, 30 May 2019 21:41:27 -0700

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

---

From: "Douglas E. Foster" <[email-masked]>
Date: Fri, 31 May 2019 06:59:24 -0400

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" <[email-masked]>
Sent: Friday, May 31, 2019 12:41 AM
To: [email-masked]
Cc: "IETF DMARC WG" <[email-masked]>
Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- 
suggestion   

"Correctly"?

d/

---

From: Dotzero <[email-masked]>
Date: Fri, 31 May 2019 07:47:15 -0400

On Fri, May 31, 2019 at 6:59 AM Douglas E. Foster <
[email-masked]> 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.

>  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

Perhaps you should go back and read the history and purpose of DKIM.

> 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.

> doing "harmful" fraud to that recipient.

You are certainly entitled to your opinion.

> 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.

> lack support for DMARC or lack good exception mechanisms for SPF, DKIM, and

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.

> 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

---

From: "Doug Foster" <[email-masked]>
Date: Fri, 31 May 2019 08:08:24 -0400

Tactically, what I meant was "IETF should be able to ensure that IETF
messages are only released with verifiable IETF signatures".  

This would mean that either the first signature is not applied, the message
is not altered after the first signature is applied, or the first signature
is removed after the message is altered.   The current configuration leaves
open the suspicion that IETF has rogue software operating in its
environment.  I am aware that the DKIM specification says to treat an
unverifiable signature as a non-signature.   This is not a sufficient reason
to release your own organization's signatures onto the internet when you can
or should know that they will fail validation. 

Doug Foster

-----Original Message-----
From: Dave Crocker [mailto:[email-masked]] 
Sent: Friday, May 31, 2019 12:41 AM
To: [email-masked]
Cc: IETF DMARC WG
Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion

"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.

d/

---

From: "John R Levine" <[email-masked]>
Date: 31 May 2019 09:02:26 -0400

> correctly.  Why is the message manipulation that you describe necessary or

That's completely backwards.  Mailing lists have been around for 30 years 
and were doing what they do long before anyone thought of mail 
authentication like SPF, DKIM, or DMARC.  SPF and DKIM on their own work 
fine with lists -- a list puts its own envelope address and its own DKIM 
signature on outgoing mail which a receipient can use.

DMARC egregiously fails to handle them and was never intended for mail 
that goes through lists, but that's a story that's been told plenty of 
times already.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Fri, 31 May 2019 15:39:54 +0200

> Agency and signatures are well understood legal concepts.   3000 years 

The signature at issue here is done with DKIM.

Are you sure you are clear about the what the agency is it vets and what 
the scope of use for that vetting is?  I suspect you are assuming a 
different type and scope of authentication than DKIM is intended to 
perform.  It's not that your goal is unreasonable -- and indeed, s/mime 
and openpgp seeks to perform it -- it's that DKIM wasn't designed to do 
that.  DKIM was designed for use during tranfer to the point of 
delivery.  For this discussion, that means to the list processor (mailbox)

> 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 

Please note my earlier point about delivery and re-posting.  That 
implies a role for list processing that is considerably more than a 
courier's.

> sealed part of a message unaltered.   Envelope marks are acceptable.
> A digital signature is supposed to provide non-repudiation.  If I submit 

DKIM is a transfer-level signature.  That is, really, MTA-MTA (or, 
really, MTA-MDA).

A list processor is an MUA-level actor.  (cf, RFC 5598.)

> would do well to document and address them.

Perhaps, but that's not at issue here.

> The first that comes to mind is MTA comment fields.

Huh?

> information came from the MTA rather than the original sender.

You mean like adding a header field, outside of the ones signed by DKIM?

That's already permitted.  It's one of the reasons that the signer gets 
to decide what header fields to cover.

However, it looks as if you think presenting such information to users 
will be useful.  It won't.

d/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 31 May 2019 15:44:01 +0200

> email message was authorized by a particular domain.

Nit-picking time.  I'd apologize for indulging, but I'm not really sorry:

Even "authorized" is too strong a label for what DKIM officially does.

"Touched" is more in line with what the spec defines, although "took 
some responsibility for" is a more ponderous way of saying that.

Specific sites have DKIM usage policies based on much stronger 
semantics, but that's outside the DKIM specification.  Hence, no one 
down the handling sequence can rely on just the specification and know 
of that stricter semantic.

d/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 31 May 2019 15:50:19 +0200

> messages are only released with verifiable IETF signatures".

I'm not exactly sure what the above sentence means, in terms of 
technical details.  So while the language all sounds fine, its meaning 
is far more ambiguous that I suspect you intended.

In any event, are you aware of the recent work on ARC?  For some case(s) 
of what you might mean, above, that's it's goal.

> open the suspicion that IETF has rogue software operating in its

A message from the IETF list processor has an ietf.org DKIM signature. 
How does that support your concern?

d/

---

From: "John Levine" <[email-masked]>
Date: 31 May 2019 09:50:40 -0400

In article <[email-masked]> you write:
>  I am aware that the DKIM specification says to treat an

Not to belabor the obvious, but the spec says what it says even if you
personally wish it said something else.  The way to make systems
interoperate is to implement the actual spec.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Fri, 31 May 2019 10:03:20 -0400

On 5/31/2019 8:08 AM, Doug Foster wrote:>

> or should know that they will fail validation.

If I may.

In principle, I agree the IETF should be the "poster-boy" of the 
technologies and methods it helps engineer.

Unfortunately, it is an ideal concept but not always practical nor 
possible to implement the proposals.  In fact, with DKIM, there is a 
standard base but with the DKIM POLICY model, there is no standard. 
DMARC is not a proposed standard. It is an Informational Status 
document, meaning, it really has no "power."   You can try to throw 
"the book" at someone's face for non-compliance  and will throw it 
right back saying "its not a standard. I don't have to follow it."  So 
that is one thing that needs to be corrected.

There is only one simple reason why DMARC was introduced as an 
Informational Status guide.  Under this status, it would not have to 
go through IETF engineering and review process.  There was a period a 
few years back where this Info Status method was used to "fast track" 
documents.   If DMARC was introduced as a proposed standard, it would 
of, undoubtedly, had a rough time getting endorsed, especially since 
the IETF was just told to abandoned ADSP for problems DMARC never 
resolved.

DMARC came after many years with earlier versions of DKIM Policy 
proposed methods with many heated discussions between Policy Model 
advocates and Non-Policy Trust Model advocates.

History of DKIM Policy (as I lived it):

Before DKIM, there was Domainkeys (DKEYS) and DKEYS introduced the 
powerful concept of Signature Policy with the "o=" tag:

     o = Outbound Signing policy ("-" means that this domain signs all
         email, "~" is the default and means that this domain may sign
         some email with DomainKeys).

So you had two Policy options:

    o=-  Exclusive Signing. Mail is always signed.
    o=~  Neutral, Maybe you signed, maybe you didn't.

This was a powerful new concept and many people, the news rags, got 
really excited about it because for the first time, we had a 
deterministic method to reject mail based on a published rules by the 
domain on what to expect.   SPF offered this too via the hard -ALL 
fail policy which was catching on with more domains using -ALL.   I 
expected the same would happen with DKIM Policy.  In fact, DKEYS was 
viewed as a replacement for SPF because SPF had the "Node IP 
Transition" problem in multi-hops.  With Domain Signature Policies, 
ideally, we could avoid the SPF IP problem.  If the domain said "My 
Mail MUST be signed by Me" and the mail was in fact, not signed or was 
invalid, then the receiver had a new gained power and permission by 
the domain to reject/filter mail with no questions asked. In other 
words, it was no longer censorship.  We were given the legal power to 
reject based on what the DOMAIN publicly published.  SPF and DKIM 
Policy were the only protocols to offer this to mail developers.

But what about 3rd party signatures?  What if other domains signed on 
your behalf?  What about List serves?  Can we publish some rules about 
3rd party signers?

Following DKEYS lead, DKIM was introduced with extended "o=" policies 
called SSP (Sender Signature Policies or Practices).  After much WG 
discussions,  they were summarized:

    DKIM-SSP/WG Proposed Policies

    o=-  STRONG  (1s party signature required, 3rd party allowed?)
    o=~  NEUTRAL (signature optional, 3rd party allowed)
    o=!  EXCLUSIVE (signature required, no 3rd party)
    o=?  WEAK (signature optional, no 3rd party)
    o=.  NEVER  (no mail expected)
    o=^  USER

One of the questions with DKEYS "o=-" was if it supported a 3rd party 
signature.  Did the domain expect it to be routed via middle ware with 
additional signatures?

The tag "o=!: was introduced to clear up that question, making it an 
exclusive, restrictive signing practice.

But we also worked on how we can authorize a 3rd party and that was 
where little agreement could be reached.  We could not agree on what 
the ser Policy (o=^) would be. How will that lower granularity of 
authorization work?  How would we deterministically trust a list 
server resigning a message that will break the 1st party signature?

This complexity is the reason early DKIM drafts was split into 
DKIM-BASE and DKIM-POLICY using SSP, but SSP was replaced with ADSP 
which reduced the policies to just:

    DKIM=DISCARDABLE
    DKIM=ALL

effectively attempting to remove the 3rd party signature issues.

Unfortunately, while it tried to get systems to ignore the 3rd party 
question, the reality was when a list submission occurred, the 
receivers would reject the invalid signatures and now the process of 
unsubscribing list members when the distribution failed at the 
receivers.  We didn't see occured with ADSP but we knew it can happen. 
Not many receivers, if any, were yet supporting or honoring ADSP and 
certainly none of the List Servers supported policy.  So it did what 
it always did.

This was the main reason ADSP, a Proposed Standard, was abandoned. But 
ironically, DMARC replaced ADSP as an informational status document 
for avoid the IETF engineering process. It did not address the ADSP 
problem.  I think people wanted the reporting part of it to learn the 
reasons and locations of failure/rejects.   But DMARC, as we all well 
know, has the same problem and once receivers began to honor it and 
domains began to use DMARC p=reject, we began to see the problems we 
always expected could happen and it did - big time when Yahoo.com 
published the DMARC p=reject policy.

Nonetheless, DMARC took off. The reason why it took off was because 
since day one, since DomainKeys invented it,  we could not remove that 
powerful concept of Exclusive DKIM Policy Signature models where we 
have a permissible mechanism to reject/discard mail.   That is a 
powerful concept and it only has a problem with the 3rd party 
signatures that we have refused to tackle in earnest.

Stepping back to the 3rd party authorization design need. There is/was 
a 3rd party signature authorization proposal called ATPS (Authorized 
Third Party Signature).   This is a simple mechanism that allowed you 
to published which 3rd party domains are allowed to sign on your behalf.

My package supports ADSP+ATPS and now DMARC+ATPS.  ATPS works.  You 
can create records using these wizards:

http://www.winserver.com/public/wcadsp
http://www.winserver.com/public/wcdmarc

So there you go.  Short history as I lived it.

I've been involved with this whole thing since day one. I am firm 
believer in the DKIM POLICY model. The concept is too strong and "it's 
scary" as one prominent person here once put it, and I think one day, 
we will finally figure it out.

I just hope we don't waste too much time with ARC.

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Fri, 31 May 2019 11:02:14 -0400

On 5/31/2019 6:59 AM, Douglas E. Foster wrote:

> invalidated by forwarding, so DMARC said that the two techniques
> should be evaluated together.

Unfortunately, DMARC did not have a policy that offered that output.

   SPF >> FAIL
   DMARC >> PASS?

Overall, DMARC failed to cover all the possible scenarios of mixed 
signatures.

To cover all aspects, the DKIM POLICY model has to offer 3rd party 
signature conditions.   In the DSAP proposal, it highlighted this as 
the broader possible options:

     https://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-4.2

     +-----------------------------------------------------------------+
     | op=         | 3p=        | Domain Policy Semantics              |
     |=================================================================|
     | empty       | empty      | No mail expected                     |
     |-----------------------------------------------------------------|
     | never       | never      | No signing expected                  |
     | never       | always     | Only 3P signing expected             |
     | never       | optional   | Only 3P signing optional             |
     |-----------------------------------------------------------------|
     | always      | never      | OP signature expected                |
     | always      | always     | Both parties expected                |
     | always      | optional   | OP expected, 3P may sign             |
     |-----------------------------------------------------------------|
     | optional    | never      | Only OP signing expected             |
     | optional    | always     | OP expected, 3P expected             |
     | optional    | optional   | Both parties may sign.               |
     +-----------------------------------------------------------------+

That covered all possible combinations.

We actually wrote an IETF functional spec regarding Sender Signing 
Policies:

    rfc5016 Requirements for a DKIM Signing Practices Protocol
    https://tools.ietf.org/html/rfc5016

    Abstract

    DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism
    for domains to assert responsibility for the messages they handle.  A
    related mechanism will allow an administrator to publish various
    statements about their DKIM signing practices.  This document defines
    requirements for this mechanism, distinguishing between those that
    must be satisfied (MUST), and those that are highly desirable
    (SHOULD).

But then something happen as this document was being completed -- list 
administrators got scared that DKIM Policy was gaining tractions and 
stepping into their market toes.  After all, we had "30 years" of 
legacy list operations, we did not want DKIM Policy interfering with 
the broad range of established list distribution operations. So this 
RFC5016 "Blocker" was written at the last minute to preempt it from 
happening:

   Section 5.3, Item 10
   https://tools.ietf.org/html/rfc5016#section-5.3

    10. SSP MUST NOT provide a mechanism that impugns the existence of
        non-first party signatures in a message.  A corollary of this
        requirement is that the protocol MUST NOT link practices of first
        party signers with the practices of third party signers.

          INFORMATIVE NOTE: the main thrust of this requirement is that
          practices should only be published for that which the publisher
          has control, and should not meddle in what is ultimately the
          local policy of the receiver.

That was basically, a "Don't step on my turf!!" requirement. It also 
meant "Local Policy Always Prevail" regardless of what a Domain 
published which is always the case anyway. Does not need to be stated. 
  But overall, this is what help demote SSP, ADSP, ATPS and DKIM 
policy in general.  ADSP was abandoned.

But no one can kill a good idea,  the proof of concept was too 
powerful, hence it returned as DMARC but as an informational status 
document to avoid the IETF mch higher review process.

I have no idea how a high overhead, complex ARC will resolve this 
problem unless
it comes with a 3rd party signature concept with an extended DMARC 
"arc=y" tag:

   arc=y  If the 1st party signature failed, then authorize the XYZ
          domains using ARC seals to promote a failure to a pass.

How would you specify the 'authorization" of XYZ domains and do so at 
scale?

-- 
HLS

---

From: Elizabeth Zwicky <[email-masked]>
Date: Fri, 31 May 2019 08:16:16 -0700

RFC 7960 has an extensive discussion of mail flows that modify mail (as well as other cases that are problematic for DMARC). Mailing lists are not the only case, and, as John has pointed out, reformatting and part stripping are things that happen in mail flows. 

Elizabeth 

> On May 31, 2019, at 8:02 AM, Hector Santos <hsantos=[email-masked]> wrote:
> 
> Overall, DMARC failed to cover all the possible scenarios of mixed signatures.
> 
> To cover all aspects, the DKIM POLICY model has to offer 3rd party signature conditions.   In the DSAP proposal, it highlighted this as the broader possible options:
> 
> We actually wrote an IETF functional spec regarding Sender Signing Policies:
> 
> But then something happen as this document was being completed -- list administrators got scared that DKIM Policy was gaining tractions and stepping into their market toes.  After all, we had "30 years" of legacy list operations, we did not want DKIM Policy interfering with the broad range of established list distribution operations. So this RFC5016 "Blocker" was written at the last minute to preempt it from happening:
> 
>  Section 5.3, Item 10
> That was basically, a "Don't step on my turf!!" requirement. It also meant "Local Policy Always Prevail" regardless of what a Domain published which is always the case anyway. Does not need to be stated.  But overall, this is what help demote SSP, ADSP, ATPS and DKIM policy in general.  ADSP was abandoned.
> 
> But no one can kill a good idea,  the proof of concept was too powerful, hence it returned as DMARC but as an informational status document to avoid the IETF mch higher review process.
> 
> I have no idea how a high overhead, complex ARC will resolve this problem unless
> it comes with a 3rd party signature concept with an extended DMARC "arc=y" tag:
> 
> How would you specify the 'authorization" of XYZ domains and do so at scale?
> 
> -- 
> HLS
> 
>

---

From: Hector Santos <[email-masked]>
Date: Fri, 31 May 2019 11:46:14 -0400

Yes, RFC 7960 summarized/gathered what was already well known.  We 
also have a List Server product, for practically "30 years," too and I 
am very aware of how mail flows works.   One problem is the fallacy 
that we didn't want to change software.  Well, I was ready to do so, 
and did, and only until others were force to do so, other list servers 
began to do the 5322.From rewriting thing.  Not my preference to be 
tampering with the author address, I do recognize it helped address 
the issue.   The better rand more logical alternative (imo) is for the 
list to:

     - Deny Restrictive Domains in the name of security, both for
       subscriptions and submissions into a list.

Finally, in my opinion,  extended policy designs need to be revisited 
as an simplified alternative to the experimental status, a high 
overhead, expensive ARC design which really doesn't promise anything, 
yet, other than record what kind of failures happened.  I can't find 
convincing ARC design logic that suggest this will help address the 
unauthorized 3rd party resigner problem unless as I suggested, it 
comes with an extended DMARC tag that gives receivers the "authority" 
to check the "ARCness" of a failed DKIM message.  Even though, I would 
only like to do so with authorized domains I trust.

-- 
HLS

---

From: "Stan Kalisch" <[email-masked]>
Date: Fri, 31 May 2019 13:34:08 -0400

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.
> 
> - 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.
> 
> *From*: "Dave Crocker" <[email-masked]>
> *Sent*: Friday, May 31, 2019 12:41 AM
> *To*: [email-masked]
> *Cc*: "IETF DMARC WG" <[email-masked]>
> *Subject*: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion 
>