Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!decwrl!sun!gnu
From: gnu@sun.uucp (John Gilmore)
Newsgroups: net.mail.headers
Subject: Re: Checksum as a replacement for missing Message-ID.
Message-ID: <2043@sun.uucp>
Date: Wed, 13-Mar-85 08:03:11 EST
Article-I.D.: sun.2043
Posted: Wed Mar 13 08:03:11 1985
Date-Received: Fri, 15-Mar-85 03:12:07 EST
References: <9102@brl-tgr.ARPA>
Organization: Sun Microsystems, Inc.
Lines: 49

> Suppose one and the same message gets forwarded, directly or
> indirectly, to two different mailing lists, and that a certain
> user is a member of both lists. If the intermediate hosts handling
> the mailing list created a checksum, this could be used by the
> host for the recipient user to stop displaying the same message
> twice, or, to tell him that it is the same message which he gets
> twice.

The user's mail reader can do the comparision itself without using
checksums and without trying to make some kind of network standard out of it.

> If two mailing lists are members of each other (which has advantages,
> but cannot be done with present practices on Arpanet because of the
> risk for loops) then if the list maintaining program kept a list
> of the ID-s of messages sent via the list (COM does this) then
> it could stop re-sending the message when it comes around the
> second time.

This is exactly the situation with Arpanet mailing lists gatewayed
to&from Usenet newsgroups.  I don't know the algorithm, but it clearly
works, without requiring message-ids -- and even works on digests,
where this method would fall down.
 
> Only using TEXT CONTENT is NOT acceptable. Suppose in a voting
> application that two people wrote messages with the only content
> being the word "Yes!". Only using TEXT CONTENT would hide the very
> important fact of the names of the people who voted "Yes!". Not
> using Date/time is also not acceptable, suppose the same person
> voted "Yes!" on two different issues, this fact would then be
> hidden.

Anybody who casts a vote on an issue by sending a message consisting
solely of the word "Yes" deserves whatever random thing they vote for.
The subject line will distinguish, for real-world messages.

If we ever come up with a naming scheme that everybody can implement,
and routing to match, then there won't be a problem with munged From:
addresses.  For now, and for the foreseeable future, there is.

----

Actually, the whole idea of intermediate nodes throwing messages away
because they happen to checksum like a message that came thru the
preceding day strikes me as a really bad idea.  You'd better compare
the "envelope" as well as the message, since a message can go thru a
host several times as aliases are resolved on its way to a final
destination.  I'd argue for comparing the entire message content,
which of course defeats the whole purpose, rather than throw away
a message.  We lose enough already.