Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!bcm!tmc.edu!sob
From: sob@tmc.edu (Stan Barber)
Newsgroups: news.software.nntp
Subject: Re: NNTPD hates Message-IDs with TWO '@'s in them.  (BIG log file attached to this posting)
Message-ID: <6014@gazette.bcm.tmc.edu>
Date: 15 Jun 1991 15:47:00 GMT
References: <1991Jun9.232828.17956@europa.asd.contel.com> <5930@gazette.bcm.tmc.edu> <1991Jun13.043253.20660@zoo.toronto.edu>
Sender: usenet@bcm.tmc.edu
Organization: Baylor College of Medicine, Houston, TX
Lines: 88
Nntp-Posting-Host: tmc.edu

In article <1991Jun13.043253.20660@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>In article <5930@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes:
>What is a "bad" message ID?  RFC1036 does not outlaw multiple @s, although
>it warns you that RFC822 does.

Hmmm. As I read RFC1036, it follows RFC822/1123 for all headers defined in
those documents and sets standards for those headers not defined in
RFC822/1123. To me, that means that a Date field that does not conform to
RFC823/1123, it is illegal. You and Geoff seem to agree with that. Now,
we have Messages IDs that don't conform and you say that that is ok
despite what RFC822/1123 say.

Does this mean we need a new RFC that sez which RFC822/1123 fields we will
follow as defines and which we won't?

Here is some quotes from the RFC1036.

[From the introduction....]
    The primary consideration in choosing a message format is that it
    fit in with existing tools as well as possible.  Existing tools
    include implementations of both mail and news.  (The notesfiles
    system from the University of Illinois is considered a news
    implementation.)  A standard format for mail messages has existed
    for many years on the Internet, and this format meets most of the
    needs of USENET.  Since the Internet format is extensible,
    extensions to meet the additional needs of USENET are easily made
    within the Internet standard.  Therefore, the rule is adopted that
    all USENET news messages must be formatted as valid Internet mail
    messages, according to the Internet standard RFC-822.  The USENET
    News standard is more restrictive than the Internet standard,
    placing additional requirements on each message and forbidding use
    of certain Internet features.  However, it should always be possible
    to use a tool expecting an Internet message to process a news
    message.  In any situation where this standard conflicts with the
    Internet standard, RFC-822 should be considered correct and this
    standard in error.

2.1.5.  Message-ID

    The "Message-ID" line gives the message a unique identifier.  The
    Message-ID may not be reused during the lifetime of any previous
    message with the same Message-ID.  (It is recommended that no
    Message-ID be reused for at least two years.)  Message-ID's have the
    syntax:

                     <string not containing blank or ">">

    In order to conform to RFC-822, the Message-ID must have the format:

                          <unique@full_domain_name>

    where full_domain_name is the full name of the host at which the
    message entered the network, including a domain that host is in, and
    unique is any string of printing ASCII characters, not including "<"
    (left angle bracket), ">" (right angle bracket), or "@" (at sign).
    For example, the unique part could be an integer representing a
    sequence number for messages submitted to the network, or a short
    string derived from the date and time the message was created.  For
    example, a valid Message-ID for a message submitted from host ucbvax
    in domain "Berkeley.EDU" would be "<4123@ucbvax.Berkeley.EDU>".
    Programmers are urged not to make assumptions about the content of
    Message-ID fields from other hosts, but to treat them as unknown
    character strings.  It is not safe, for example, to assume that a
    Message-ID will be under 14 characters, that it is unique in the
    first 14 characters, nor that is does not contain a "/".

    The angle brackets are considered part of the Message-ID.  Thus, in
    references to the Message-ID, such as the ihave/sendme and cancel
    control messages, the angle brackets are included.  White space
    characters (e.g., blank and tab) are not allowed in a Message-ID.
    Slashes ("/") are strongly discouraged.  All characters between the
    angle brackets must be printing ASCII characters.

This sez to me that in all cases RFC822/1123 definitions hold, even if they
conflict with RFC1036.

If this is true and CNEWS does not police this, like it does the Date: header,
then CNEWS is doing the wrong thing as defined by the appropriate RFCs.

NNTP is assuming that RFC822 conforming messages ids are the only ones
in valid articles. While this assumption SHOULD be valid, it is not.
This will be addressed in NNTP 1.6.


-- 
Stan           internet: sob@bcm.tmc.edu         Director, Networking 
Olan           uucp: rutgers!bcm!sob             and Systems Support
Barber         Opinions expressed are only mine. Baylor College of Medicine