|
RFC Home |
Full RFC Index |
Recent RFCs |
RFC Standards |
Best Current Practice |
RFC Errata |
1 April RFC |
|
||||||
|
IETF RFC 561
Standardizing Network Mail Headers Last modified on Friday, September 19th, 1997 Permanent link to RFC 561 Search GitHub Wiki for RFC 561 Show other RFCs mentioning RFC 561 RFC # 561 Abhay Bhushan (AKB) MIT-DMCG NIC # 18516 Ken Pogran (KP) MIT-MULTICS Ray Tomlinson (RST) BBN-TENEX Jim White (JEW) SRI-ARC 5 September 73 Standardizing Network Mail Headers One of the deficiences of the current FTP mail protocol is that it makes no provision for the explicit specification of such header information as author, title, and date. Many systems send that information, but each in a different format. One fairly serious result of this lack of standardization is that it's next to impossible for a system or user program to intelligently process incoming mail. Although the long-term solution to the problem is probably to add commands for specifying such information to the mail protocol command space (as suggested in RFC 524 -- 17140,), we hereby propose a more quickly implemented solution for the interim. We suggest that the text of network mail, whether transmitted over the FTP telnet connection (via the MAIL command) or over a separate data connection (with the MLFL command), be governed by the syntax below: Example: From: White at SRI-ARC Date: 24 JUL 1973 1527-PDT Subject: Multi-Site Journal Meeting Announcement NIC: 17996 At 10 AM Wednesday 25-JULY there will be a meeting to discuss a Multi-Site Journal in the context of the Utility. Y'all be here. Formal Syntax: <mailtext> ::= <header> <CRLF> <message> <header> ::= <headeritem> ! <headeritem> <header> <headeritem> ::= <item> <CRLF> <item> ::= <authoritem> ! <dateitem> ! <subjectitem> ! <miscitem> 1 NWG/RFC# 561 AKB KP RST JEW 5-SEP-73 11:19 18516 Standardizing Network Mail Headers RFC 561 / NIC 18516 <authoritem> ::= FROM: <SP> <user> <SP> AT <SP> <host> <dateitem> ::= DATE: <SP> <date> <SP> <time> - <zone> <subjectitem> ::= SUBJECT: <SP> <line> <miscitem> ::= <keyword> : <SP> <line> <date> ::= <vdate> ! <tdate> <vdate> ::= <dayofmonth> <SP> <vmonth> <SP> <vyear> <tdate> ::= <tmonth> / <dayofmonth> / <tyear> <dayofmonth> ::= one or two decimal digits <vmonth> ::= JAN ! FEB ! MAR ! APR ! MAY ! JUN ! JUL ! AUG ! SEP ! OCT ! NOV ! DEC <tmonth> ::= one or two decimal digits <vyear> ::= four decimal digits <tyear> ::= two decimal digits <zone> ::= EST ! EDT ! CST ! CDT ! MST ! MDT ! PST ! PDT ! GMT ! GDT <time> ::= four decimal digits <user> ::= <word> <host> ::= a standard host name <message> ::= <line> <CRLF> ! <line> <CRLF> <message> <keyword> ::= <word> <line> ::= a string containing any of the 128 ASCII characters except CR and LF <word> ::= a string containing any of the 128 ASCII characters except CR, LF, and SP <CRLF> ::= CR LF <SP> ::= space Please note the following: (1) <authoritem>, <dateitem>, and <subjectitem> may each appear at most once in <header>; <miscitem> may occur any number of times. The order of <authoritem>, <dateitem>, and <subjectitem> is insignificant, but they must proceed all occurrences of <miscitem>. (2) The case (upper or lower) of keywords -- specifically, 'FROM', 'DATE', 'SUBJECT' ,'AT', <host>, <zone>, <vmonth> and <keyword> -- is insignificant. Although 'FROM', for example, appears in upper-case in the formal syntax above, in the header of an actual message it may appear as 'From' (as in the example), or 'from', or 'FrOm', etc. (3) No attempt has been made to legislate the format of <user>, except to exclude spaces from it. (4) The time has no internal punctuation. (5) No provision is made for multiple authors. We recommend that mail-sending subsystems which prefix header information to the text of the user's message be modified 2 NWG/RFC# 561 AKB KP RST JEW 5-SEP-73 11:19 18516 Standardizing Network Mail Headers RFC 561 / NIC 18516 appropriately, and that other hosts recommend the above conventions to their users. 3 Standardizing Network Mail Headers RFC TOTAL SIZE: 6159 bytes PUBLICATION DATE: Friday, September 19th, 1997 LEGAL RIGHTS: The IETF Trust (see BCP 78) |