On 19 Jun 2020, at 15:05, Douglas E. Foster wrote:
Why is the state of the message-id important? You have mentioned
it twice.
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
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
