When MHonArc encounters a message w/o an ID, it internally creates its
own ID. ... Including the body as part
of the MD5 sum would provide better chance of uniqeness, but would
require code restructuring (and a performance penalty) for questionable
gain.
Cool. So if you're having problems getting a message into the
archive because of the Message-Id: already existing, you could
remove it and just try resubmitting.
You can just grep it out, or if you're worried about snagging one
in the message body for whatever reason, this procmail recipe will
remove a Message-Id: header (formail auto-generates one):
:0 fhw
| formail -I "Message-Id:"
Or if you want to build a more traditional Message-Id: for incoming
messages (i.e. if you use the -add flag to auto-update your archives):
:0 fhw
| formail -I "Message-Id:" | formail -a "Message-Id:"
This overwrites the existing Message-Id:, and isn't really recommended.
But if you're having problems with lots of duplicates it might be a
help...
I have been considering a resource to disable Digest::MD5 usage
for non-ID messages since it is possible for two different messages
to be tagged as the same if the message header data is exactly
the same (but the body data is different). However, in the
real world, I do not know is this case will ever happen.
If someone's really worried about the MD5sum Message-Id: headers,
you can use procmail/formail to check for duplicate headers and
only generate a new Message-Id: if it's already been used:
# change the cache size (32768) as necessary
:0 Whc: msgid.lock
| formail -D 32768 msgid.cache
# Message-Id: was in the cache, so let's make a new one!
:0 a
{
:0 fhw
| formail -I "Message-Id:" | formail -a "Message-Id:"
}
Alternatively, you could do it with perl, but formail's is just as unique
(but I like the way the perl one looks more :):
MSGID=`perl -e 'use
Sys::Hostname;printf("<%lx(_dot_)%lx(_at_)%s>",time(),$$,hostname());'`
:0 fhw
| formail -I "Message-Id: $MSGID"
Earl, I hope you'll forgive all of the procmail-isms. As you know,
it's kind of a "hobby"... :) But seriously, this is another alternative
if someone is worried about the md5sum-based header values, and could
be another reason to create a resource to disable Digest::MD5-based
headers...
Chris
