Dan Egli wrote:
> J.D. (Jack) Bitters wrote:
>>
>> headers_remove = Message-ID
>
> REALLY bad idea. This could have all sorts of consequences. Not the
> least of which is this will effectively break any threading done by
> Message-ID (which most threading is done by).
>
> Adding if not present is fine, but don't remove it if it is already
> there. So what if it doesn't look the same? It WORKS and that is what
> is important.
I'm a pretty picky person myself, and I guess I could remotely see a reason
(not really a good one though) to do this. I know that when SpamAssassin
gets ahold of a message and logs that it's scanning a message, it uses the
Message-ID header in the logfile to denote what file it's handling. It sure
would be nice if that corresponded to the Exim internal message ID - but
that's just for cosmetic log formatting reasons and that's about it. Not to
mention Exim logs the given Message-ID line from the client anyways so it's
not the end of the world.
However, that being said, an option if you STILL want to do this is to do
the following (for cosmetic reasons):
* incoming message has no message-id header:
* give them one ala format you want - no harm done
* incoming message has a message-id header ala format you want - do nothing,
no harm done
* incoming message has a message-id you want to reformat:
* store the message-id header in to a new custom header like x-message-id
* rewrite the message-id header the way you want
* do whatever to the message right up until delivery
* at delivery, rewrite message-id to whatever x-message-id is, then remove
x-message-id
That way, you get your nice looking cosmetic changes that I assume you want,
but in the end you don't break the message-id and it's left as it was
initially. Now, this really comes at a cost - logs and such will be whacked
with a new message-id in some places, and if you use that for any sort of
administrative debugging when clients have problems, you just sat on your
own fork.
Eli.
