On June 22, 2006 at 17:40, Ed Wildgoose wrote: > > Only a problem if you have software that creates message-ids that > > include actual email addresses. This is unusual, and with the spam > > world we live in today, not recommended. > > Aha.... This finally explains the huge unstoppable spam runs I have been > seeing against my mailserver. I thought it was some dumbass who was > trying some wierd number based dictionary spam on my server (despite > plenty of 554 responses), but now I see that it was all my msgid's that > were being harvested! > > Is it possible to at least mangle them in some way so the dumb robots > don't think they are real.
A good argument to use something like the MD5 hash of the message-id as linking/threading handle versus the ID itself. This should be technically possible w/o having to redesign mhonarc code. It may be possible to MD5 the message-id and references/in-reply-to data when a message is first read and use the resulting values for threading calculations. Some extra work is needed for the auto-link of message-ids in message bodies. The message-id in the body would have to be hashed first before checking if it can be linked. Of course, those doing anti-harvesting customizations (e.g. SPAMMODE) on their archives, message-id linking in irrelevant (since message-ids look like addresses and gets masked/obfsucated). RMM will need to be made aware of such things since it can take message-ids. What needs to be determined is if hashing of IDs should always be done or if it should be controled by a resource (e.g. HASHMESGIDS). Since a perl installation may not have the MD5::Digest module installed, mhonarc would definitely need to work with and w/o hashing. --ewh
