MH Michael Hammer (5304) wrote:
I posted a write up on an issue with DKIM/ADSP and missing message-ids
at CircleID that might be of interest to people:
I'm going to try to spend a little more time focusing on some of the
implementation "gotchyas" related to DKIM/ADSP for a while.
It is bad practice for receiving software to be adding an originating
header such as a Message-ID. Especially, is this receiver software
has gain some DKIM smarts (its active developed software).
The BCP for all exporting software to add the Messages-ID for its own
tracing and dupe checking purposes.
Yes, the problem sometimes today with increase dumb mail creation
software that only pushes out:
and some that only do:
with the presumption the exporting software will add the rest.
If the exporting software also has DKIM software, then it needs to be
compliant here with 2822/5322.
But overall, I think this is just another issue regarding policy and
domain mail expectations.
Just consider, even without DKIM, there is a POLICY idea where a
receiver can check the From: domain for what is expected as far as
level of mail compliants:
That might means the standard headers are expected.
It might also have:
v=ietf rfc5322=required msgid=example.domain.com
which might say that the message-id RSH must have example.domain.com
as the source.
We can further extend it to add ADSP support
v=ietf rfc5322=required msgid=example.domain.com dkim=all
Anyway, I am not quite sure if there an issue here with Message-ID
because it is pretty well established.
The problem is protocol consistency. The signer within the domain
network needs to make sure it adds the missing headers. And receivers
really should not be adding one - especially if it is as you say, DKIM
NOTE WELL: This list operates according to