Received: from localhost (daemon@localhost) 
        by CS.UTK.EDU with SMTP (cf v2.9s-UTK)
	id IAA29489; Mon, 12 Aug 1996 08:06:32 -0400
Received: by CS.UTK.EDU (bulk_mailer v1.6); Mon, 12 Aug 1996 08:05:49 -0400
Received: from pool.pipex.net (pool-eth0.pipex.net [158.43.128.24]) 
        by CS.UTK.EDU with SMTP (cf v2.9s-UTK)
	id IAA29414; Mon, 12 Aug 1996 08:05:44 -0400
Received: (qmail-queue invoked from smtpd); 12 Aug 1996 11:58:07 -0000
Received: from pool.pipex.net (158.43.134.17)
  by pool.pipex.net with SMTP; 12 Aug 1996 11:58:07 -0000
To: drums@cs.utk.edu
Subject: Unusual header field names
Date: Mon, 12 Aug 1996 12:58:06 +0100
From: Tim Goodwin <tim@uunet.pipex.com>
Message-ID: <AABOlzIPHE4ADjZT@pipe.pipex.net>

According to RFC 822, and also John G Myers' draft syntax of 1996-03-06
(the latest one I can find), the syntax of header field names is this.

     field-name  =  1*<any CHAR, excluding CTLs, SPACE, and ":">

Unless I'm missing something, this is an extremely broad definition,
which permits header fields like this one.

    E@t.th|$_su(|<er!: foo

I suspect that many parsers will choke on this.  The problem is that
section 3.3 apparently presents a lexical syntax for an entire message
header; in fact, it only applies to header field bodies.  In field
names, "specials" aren't.

I don't see a compelling reason for such freedom in field names.  So
far as I'm aware, standard defined fields use only ALPHAs and `-'.  In
extension fields and user defined fields, I've seen DIGITs and `_'
reasonably often, and occasionally `.'.

I suggest changing the defition to this, which would permit the section
3.3 lexer to handle entire message headers.

    field-name = atom

Tim.