Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!apple!agate!ucbvax!bloom-beacon!eru!hagbard!sunic!news.funet.fi!funic!hks From: hks@nic.funet.fi (Harri Salminen) Newsgroups: news.software.b Subject: Re: Ideas for Message-ID's Message-ID: <1991Apr25.190244.14730@nic.funet.fi> Date: 25 Apr 91 19:02:44 GMT References: <3427@litchi.bbn.com> <3434@litchi.bbn.com> <1991Apr16.174706.4963@nic.funet.fi> <1991Apr17.212354.12236@zoo.toronto.edu> Reply-To: hks@funet.fi Organization: Finnish University & Research Network Lines: 82 henry@zoo.toronto.edu (Henry Spencer) writes: >In article <1991Apr16.174706.4963@nic.funet.fi> hks@funet.fi writes: >>Would it be possible to have after the time a checksum calculated over >>the most of the message? The checksum calculation should could include at >>least the newsgroup name and subject if not everything. It's unlikely >>that even an automatic program sends within one second two messages >>with same subject to same newsgroup... >I'm not sure what your objective is here. What this is essentially >doing is adding a random number to the message ID. Using the process ID >accomplishes the same thing, with random numbers that are *guaranteed >unique* over the whole system, making collisions essentially impossible. We need an unique identifier, but defining the PID to be part of it might not mean it's unique, since some systems don't rotate pids, others might not have them all and third group of system might not even use separate processes for each message. Of course implementors choose some way (even a counter) to make them unique but I thought the idea was to put some meaning to the randomness and utilize it. The idea of one way unique encryption sounds fine if one can find a suitable algorithm which may be hard... You could use RSA or some other public key system but the message-ID's might get several lines long :-) Wasn't there an RFC on authenticated mail that could be utilized? >>Including the newsgroup name would make it possible to munge the >>message-ids to become consistently different when gatewayed to two >>different newsgroups from mail. In theory you shouldn't tamper with >>message-ids if they are already present but in practise you might have >>to or the message might get lost. >Can you explain this in more detail? I don't see why you ever have to >tamper with a legal message ID, and you most certainly should never have >to assign more than one to the same message. I believe that gateways should be liberal in what they accept but output only "legal" format. Although it's rare nowadays, you'll sometimes get messages with illegal characters in message-ID's (Zmailer is the only RFC-822 mailer I know that really cares what the message-ID looks like...). Some popular gateways just map them to legal ones and pass through. The same applies to other headers. I don't like systems that discard or return the message if it has just some minor errors (like "non-existing" timezone) and has already reached all list subscribers without problems. Zmailer does quite nice compromise by letting it through and informing very clearly what was wrong according to which rfc. It even checks message-ID and references fields... >Gatewaying to multiple >newsgroups should be done with a cross-posting, not by posting the same >article to each newsgroup in turn! It's almost impossible to do crossposting when you have multiple gateways in different places. To do so each gateway would have to decipher from the mail headers and a global gateway database to which groups it's going (sometimes even impossible since the list name might not even be in X-Resent-Cc: field in the message body not to mention the millions of variations a list's addres can be represented). The only reliable method, unless you gateway a listserv list with right newsgroup header insertion) is to have alias for each incoming list in the gateway host. Sometimes the same list gatewayed to two different distributions untill one of the groups is removed. We need to define mailing lists better and coordinate gateways to improve the situation. When a message ends up via two different gateways to two different newsgroups it will be shown only in the first one it arrives. Fortunately it's common that the person reads both groups so you can live with it because the message is at least somewhere... To solve this small problem you either need different message-ID's or history checking that includes the newsgroup. Maybe the latter is cleaner way after all? >>The other advantage of this style of message id (marked with some special >>delimiter?) could be used to detect problems in message transport... >-- >And the bean-counter replied, | Henry Spencer @ U of Toronto Zoology >"beans are more important". | henry@zoo.toronto.edu utzoo!henry -- Harri K Salminen - Finnish University & Research Network project hks@funet.fi, LK-HS at FINHUTC, tut!hks, OPMVAX::hks, OH2LGE@OH2RBI FUNET c/o VTKK/TLP, PL 40, 02101 Espoo, Finland - +358-0-4572288 "Virtually, I don't work, I just netWORK :-)"