On October 6, 1999 at 23:51, Christopher Lindsey wrote:
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.
Yep. But one would have to wonder why you would want to do this?
message-ids are supposed to be unique. If you have a case where
two different messages have the same message-id, then the problem
has to do with someone's mail software.
Note, it does seem more common now with PC-based mail software
where message-id creation is not done properly, causing a higher
probability of a conflict. The big error is that I see message-ids
with out FQDNs (fully-qualified domain names).
I've seen this problem even under poorly configured Unix/sendmail systems
(which I have had to fix).
The main problem with mucking with message-ids is that you lose
any decent threading.
[nice procmail stuff deleted]
This overwrites the existing Message-Id:, and isn't really recommended.
Agreed.
But if you're having problems with lots of duplicates it might be a
help...
One needs to check that the "duplicates" are really duplicates or not.
[more procmail stuff deleted]
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...
The Digest::MD5-based message-ids are only done when no message-id
is present. If procmail is adding a message-id, then MHonArc will
just use what is already there.
--ewh
