Zitat von Martijn Brinkers <martijn(a)djigzo.com>om>:
The main question is "should a modified message
get a new message-id"?
You could argue that when you send a message to one recipient that the
message should keep the same message-id even though the message is
encrypted or signed by the gateway. My view is that the message was
altered and the message should therefore get a new message-id. Now to
make things a bit more complicated, what should the message-id be when a
message is sent to multiple recipients with different encryption
requirements. For example recipient A cannot read encrypted or signed
email so no encryption, recipient B requires S/MIME encrypted email,
recipient C only wants digitally signed email and recipient D wants to
receive it encrypted by PDF. Djigzo splits the message into 4 different
messages because the 4 recipients have non-compatible requirements. Do
you expect all the 4 messages to have the same message-id? My view would
be that every message should have a different message-id.
From my point of view and what can be read from RFC 2822 the
message-ID is a MUA thing and identifies a message by the means of the
MUA. It is used to correlate answers, so yes, the message-ID should be
the same for all instances of the same outgoing message. A MTA should
never alter the message-ID, the only option should be to create one if
Different messages with the same message-id can lead
to problems. For
example Exchange has a filter that removes messages with a duplicate
message-id. This means that messages can sometimes magically 'disappear'.
The duplicate suppression based on the message-ID should only be
applied per final recipient (mailbox) all other schemas would be badly
A possible 'solution' I have been thinking of,
but I have not yet
implemented, is to add a "X-Original-Message-ID" header that contains
the message ID of the source message.
Any insight which client actually use such a header?
Note that only messages that are modified
(signed/encrypted etc.) have a
But this is the whole intention of Djigzo, isn't it?
Fact is that the actual behavior makes djigzo unusable for us because
our sending system depends on the message-ID to get a threading like