- From: Keith Moore <moore@cs.utk.edu>
- Date: Tue, 02 May 2000 12:33:52 -0400
- To: "Tim Moors" <moors@ieee.org>
- cc: discuss@apps.ietf.org, "Atiquzzaman, Mohammed" <MAtiquzz@engr.udayton.edu>
[end2endinterest removed...not on topic for that discussion] in general you don't want to do duplicate suppression based on message-id alone, because sometimes the same message-id really is used for significantly different messages (sometimes due to software bugs, but if duplicate supression were widespread it would probably be a target of malice ... to keep someone from seeing a message, send them a different message using the same message-id). some lists significantly modify messages without modifying the message-id. (and you probably don't want them to modify the message-id - it's what lets you trace a message back to its source) you can use message-id to find potential duplicates, and then compare the messages themselves and use heuristics to determine whether they really are more-or-less the same. or a user agent could remove extraneous information (e.g. received headers) from every message it received, hash the result, and compare the hashes for duplicates. I don't know of any user agent that does either of these, and unless one gets lots of duplicate mail, it might not be worth the bother. mail delivery systems should probably not try to eliminate duplicates on behalf of their users. sometimes you actually want to know that you got a copy of the message that was sent through a list even if you already received a copy by other means. so the user agent would need to do the duplicate suppression if it is to be done at all. I don't think we need to find a technical solution to every social problem that exists with email. the problem exists in other fields as well - people sometimes get more than one copy of the same mail-order catalog, for instance - and we don't lose too much sleep over it. in general, the purpose of apologies are to avoid getting compliants from people who are naive enough to think that this is the sender's problem rather than the recipient's. Keith
Received on Tuesday, 2 May 2000 12:35:06 UTC