> 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.%lx@%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
