Subject: Re: [dmarc-ietf] Mediation (was: Re: Header munging, not ARC, can solve the mailing list problem)

From: "Douglas E. Foster" <[email-masked]>
Date: Fri, 19 Jun 2020 16:05:48 -0400

Why is the state of the message-id important?   You have mentioned it twice.

It is not a required header.  It often uses a domain portion that is not a registered name.   The recipient has no way to know whether or not it has been changed during forwarding.  I have tried to imagine a way to use message-id in message evaluation, but have given up.

---

From: "Pete Resnick" <[email-masked]>
Date: Fri, 19 Jun 2020 17:01:34 -0500

> Why is the state of the message-id important?   You have mentioned 

So, we've been talking about the semantics of messages sent by a mailing 
list. My contention has been that for many mailing lists, and 
particularly the ones we've been talking about, the intent is that the 
mailing list is simply resending messages on to the subscribers to the 
list. The semantics of the message are revealed in the headers: The 
 From: header indicates who the author of the message is. And the 
message-id is a way for the resender of a message to indicate that it is 
"the same message" as a previous one that it received, and can used when 
"threading" messages in a conversation view or deleting duplicates for 
display purposes.

> It is not a required header.

Well, kinda sorta. My apologies if you already know this; perhaps useful 
to others:

Be careful about MUST/SHOULD/MAY in IETF documents. Of Message-ID:, RFC 
5322 says:

    Though listed as optional in the table in section 3.6, every message
    SHOULD have a "Message-ID:" field.  Furthermore, reply messages
    SHOULD have "In-Reply-To:" and "References:" fields as appropriate
    and as described below.

And if you have a look at RFC 2119:

    SHOULD   This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

Which is to say, "SHOULD" means "MUST unless you really know what you're 
doing". We don't do requirements the way other standards folks do. Also 
from 2119:

    Imperatives of the type defined in this memo must be used with care
    and sparingly.  In particular, they MUST only be used where it is
    actually required for interoperation or to limit behavior which has
    potential for causing harm (e.g., limiting retransmisssions)  For
    example, they must not be used to try to impose a particular method
    on implementors where the method is not required for
    interoperability.

We don't do "conformance" in IETF by using MUSTs and SHOULDs and MAYs. 
It's all about interoperability.

In this case, read the sentence as, "Use a Message-ID:, because if you 
don't you may screw up what the receiver of the message needs to do. 
That said, there might be circumstances where you simply can't produce 
one, and the recipient is going to have deal with that possibility, but 
you had better have a pretty good reason."

> It often uses a domain portion that is not a registered name.

It needn't be registered to be useful; only unique. That said, I'm not 
sure about "often".

> The recipient has no way to know whether or not it has been changed 
> during forwarding.

It could be signed, could it not?

> I have tried to imagine a way to use message-id in message evaluation, 
> but have given up.

Back to your original question: My comment about Message-ID: was not 
about whether it was particularly useful for DKIM/DMARC, but more about 
how its semantics are reflected in mailing list email messages.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

---

From: "John Levine" <[email-masked]>
Date: 19 Jun 2020 20:12:08 -0400

>Why is the state of the message-id important?   You have mentioned it twice.

A great deal of mail software assumes that if two messages have the
same message-ID, they're the same message. We use this to avoid
showing the user the same message twice, e.g., if one copy arrives
directly and another via a list.

This has been standard practice for decades. I'm surprised you're not
familiar with it.

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