dmr@csli.Stanford.EDU (Daniel M. Rosenberg) (11/21/90)
Who maintains the set of standards for mail headers (like From: and
>Path: and whatever). Is it just sort of my mutual agreement of
people who write routers and mailers and readers?
And has anyone thought of adding a Priority: {High, Middle, Low} to
the list, with Low messages being the Madonna mailing list; Middle
being regularly scheduled meetings; High being time-sensitive, more
urgent information (and so forth)?
--
# Daniel M. Rosenberg // Stanford CSLI // Chew my opinions, not Stanford's.
# dmr@csli.stanford.edu // decwrl!csli!dmr // dmr%csli@stanford.bitnetbarmar@think.com (Barry Margolin) (11/21/90)
In article <16502@csli.Stanford.EDU> dmr@csli.Stanford.EDU (Daniel M. Rosenberg) writes: >Who maintains the set of standards for mail headers (like From: and >>Path: and whatever). Is it just sort of my mutual agreement of >people who write routers and mailers and readers? The format of mail on the Internet is specified by a document known as RFC-822, which can be accessed via anonymous FTP from NIC.DDN.MIL with the file name "RFC:RFC822.TXT". Internet standards are currently specified by the Internet Activities Board and the Internet Engineering Task Force, which I believe are supported by DARPA (there's an RFC that describes the charters of these organizations -- look it up in RFC:RFC-INDEX.TXT). >And has anyone thought of adding a Priority: {High, Middle, Low} to >the list, with Low messages being the Madonna mailing list; Middle >being regularly scheduled meetings; High being time-sensitive, more >urgent information (and so forth)? Adding a header field is almost certainly not enough. Mail transfer programs generally are not required to look at the header of the messages they are transfering. In the Internet SMTP protocol, all the information needed to deliver mail is provided separately as commands issued to the server (this allows messages to be delivered to addresses not mentioned explicitly in the header, e.g. for blind carbon copies or mailing list explosion). Priority would have to be specified externally in this manner. Other mail systems (such as the CCITT X.400 protocols) similarly provide a distinction between header attributes (intended for the recipient) and envelope attributes (used by the mail software). In fact, the CCITT X.400 envelope specification includes such an option. One word of warning, though: what prevents someone from being obnoxious and sending high priority mail to the Madonna mailing list? And if we were to extend SMTP to support such an option, what should happen if high priority mail has to go through a system that hasn't yet implemented the option? -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
argv@turnpike.Eng.Sun.COM (Dan Heller) (11/21/90)
In article barmar@think.com (Barry Margolin) writes: > >And has anyone thought of adding a Priority: {High, Middle, Low} to > >the list, with Low messages being the Madonna mailing list; Middle > >being regularly scheduled meetings; High being time-sensitive, more > >urgent information (and so forth)? > Adding a header field is almost certainly not enough. RFC822 (I think) specifies the Precedence: header that can be set to things like "junk" to indicate that if the mail can't be delivered, drop it on the floor (don't bother sending a mailer daemon). There are other values that are used to indicate high-volume mailing lists and things, but these are rarely used (in fact, all I've ever seen is "junk" :-). Admittedly, I should know more about this <gulp>. > Mail transfer > programs generally are not required to look at the header of the messages > they are transfering. That's rather sweeping, but I know what you mean. MTAs -are- required to look at and even change certain headers under certain circumstances. BTW, just FYI: The latest Mush has a "Priority" header specification that you can set yourself. Typically, this is used on your own messages (you can set five different priorities for messages); once done, you can sort by them and do other actions based on message priority. A particular organization can have a admin-based Mushrc file that does the same thing for "priority" mail and, provided everyone is using Mush, people can send messages around with varying priorities and (hopefully) the right thing will happen. We didn't specify anything more explicit with priorities in Mush since it's new. We want to give people the chance to play with them for a while before establishing any sort of defined action. But, remember, this is just on the MUA side and does not (and is not intended to) have anything to do with the MTA. -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.
barmar@think.com (Barry Margolin) (11/21/90)
In article <3235@exodus.Eng.Sun.COM> argv@turnpike.Eng.Sun.COM (Dan Heller) writes: >In article barmar@think.com (Barry Margolin) writes: ... >RFC822 (I think) specifies the Precedence: header that can be set to >things like "junk" to indicate that if the mail can't be delivered, >drop it on the floor (don't bother sending a mailer daemon). There >are other values that are used to indicate high-volume mailing lists >and things, but these are rarely used (in fact, all I've ever seen >is "junk" :-). Admittedly, I should know more about this <gulp>. I can't find the Precedence field in RFC822. >> Mail transfer >> programs generally are not required to look at the header of the messages >> they are transfering. >That's rather sweeping, but I know what you mean. MTAs -are- required >to look at and even change certain headers under certain circumstances. Those situations are primarily exceptional circumstances outside the scope of the Internet mail standards. For instance, when gatewaying between a network that uses domain addresses and one that uses old-style UUCP addresses (foo!bar!baz), the gateway must tranform addresses in the header; in this case, the application-level gateway is effectively a pseudo-user agent (consider the far-out extension to a gateway sitting in the middle of the Chunnel that translates the message between English and French). Or if a site wants to transform addresses of the form User@host.think.com to User@think.com (so that non-MX mailers can reply, and so that host names may be changed without causing problems when trying to reply to mail from those hosts) on the way out to the real network, it may add such a transformation. This is a convenience feature, not part of the protocol specification. Actually, SMTP MTAs are required to look at the first line of a message in order to update the Return-Path line, and must insert a Received line after it. These are actually considered to be the SMTP envelope. The Return-Path line is required to be first so that the MTA doesn't have to parse the entire header looking for it. Other than this, the only other mention of message format that I think RFC 821 (the SMTP specification) makes is that the message must conform to RFC 822. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
mpyoung@elaine49.stanford.edu (M. Pinghua Young) (11/21/90)
In article <1990Nov21.084347.25984@Think.COM> barmar@think.com (Barry Margolin) writes: >In article <3235@exodus.Eng.Sun.COM> argv@turnpike.Eng.Sun.COM (Dan Heller) writes: >>In article barmar@think.com (Barry Margolin) writes: >... >>RFC822 (I think) specifies the Precedence: header that can be set to >>things like "junk" to indicate that if the mail can't be delivered, >>drop it on the floor (don't bother sending a mailer daemon). There >>are other values that are used to indicate high-volume mailing lists >>and things, but these are rarely used (in fact, all I've ever seen >>is "junk" :-). Admittedly, I should know more about this <gulp>. > >I can't find the Precedence field in RFC822. Look it up in UNIX installation guide for sendmail. In addition to junk (which has a numeric value of -100), the precedence can also be set to bulk (-60), first-class (0, this is the default), special-delivery (100). All these work under sendmail. A side note: you can also specify a header of "Returned-Receipt-To: ", in which case the receiving sendmail will generate a receipt automatically to the e-mail address specified in that field. Another header which is mostly used in mailing list is called "Errors-To:". If this is present, any error messages will be delivered to the specified address in addition to the sender. Useful (obviously) for maintaining a mailing list. --Pinghua -- +---------------------------------------------------------------------------+ | M. Pinghua Young, P. O. Box 7886 | Bitnet: pinghua@suwatson.BITNET | | Stanford, CA 94309, (415)497-4510 | Internet: mpyoung@portia.Stanford.EDU | +---------------------------------------------------------------------------+
Craig_Everhart@TRANSARC.COM (11/21/90)
Start with RFC 822 and amend it as RFC 1023 suggests. Check the RFC index for similar standards, such as that for NNTP messages. Get RFCs by sending mail to SERVICE@NIC.DDN.MIL. Craig
barmar@think.com (Barry Margolin) (11/22/90)
In article <1990Nov21.095143.16696@morrow.stanford.edu> mpyoung@elaine49.stanford.edu (M. Pinghua Young) writes: >In article <1990Nov21.084347.25984@Think.COM> barmar@think.com (Barry Margolin) writes: >>I can't find the Precedence field in RFC822. >Look it up in UNIX installation guide for sendmail. The installation guide for sendmail is not a standards document. As you pointed out, sendmail includes quite a few extensions to RFC 822. >A side note: you can also specify a header of "Returned-Receipt-To: ", in >which case the receiving sendmail will generate a receipt automatically to >the e-mail address specified in that field. Multics provides something like this, but it has a different field name (Acknowledge-To). However, the receipt is generated by the user agent, so that you know when the user actually read the mail; it also sends a different receipt if the user deletes the message without ever reading it. Users who prefer privacy can tell their UA not to generate acknowledgements. >Another header which is mostly used in mailing list is called "Errors-To:". >If this is present, any error messages will be delivered to the specified >address in addition to the sender. Useful (obviously) for maintaining a >mailing list. That's what the SMTP "MAIL FROM" command is supposed to be for; X.400 has a similar envelope field. Errors-To may be necessary for some non-SMTP MTAs that store control information in the header, though. Ideally, though, all mail transfer protocols would pass MTA control information separately from the message data. This layered approach would allow the MTA protocols and the message format standards to evolve independently (e.g. if one wanted to use SMTP to transfer X.400-format messages). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
barmar@think.com (Barry Margolin) (11/22/90)
In article <8bGd7lL0BwwO4pk1oj@transarc.com> Craig_Everhart@TRANSARC.COM writes: >Start with RFC 822 and amend it as RFC 1023 suggests. Are you sure you meant RFC 1023? I haven't looked through it very much, but it doesn't seem like it would be relevant to RFC 822. 1023 describes HEMS, which looks like a precursor to SNMP. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
lear@turbo.bio.net (Eliot) (11/22/90)
barmar@think.com (Barry Margolin) writes: >Are you sure you meant RFC 1023? I haven't looked through it very much, >but it doesn't seem like it would be relevant to RFC 822. 1023 describes >HEMS, which looks like a precursor to SNMP. I believe he meant RFC 1123, the host requirements RFC. While RFC 1023 is interesting in its own right, RFC 1123 contains minor changes and updates to a bunch of standards including RFC 821 and 822. -- Eliot Lear [lear@turbo.bio.net]
Craig_Everhart@TRANSARC.COM (11/28/90)
Whoops; I meant RFC 1123, not RFC 1023. Also, the Return-path: header isn't updated by the MTA. It is not present on a message in transit. Rather, it is added at final delivery time by the final delivery agent, and its content is just the out-of-band envelope-from address information. This information is transmitted over SMTP, for example, via the MAIL FROM: command. Other protocols have other mechanisms for carrying this out-of-band envelope-from address. Craig
mattc@ncr-sd.SanDiego.NCR.COM (Matt Costello) (11/28/90)
In article <1990Nov21.170229.16590@Think.COM> barmar@think.com (Barry Margolin) writes: >The installation guide for sendmail is not a standards document. As you >pointed out, sendmail includes quite a few extensions to RFC 822. In that case, check out RFC 1148 "Mapping between X.400(1988)/ISO10021 and RFC 822". It lists a bunch of RFC 822 style headers that should be used to map X.400 elements into the RFC 822 world. One of them is "Priority:", with the possible values of "normal", "non-urgent", "urgent" and an escape value consisting of a decimal number. There is also an "Importance:" header with the possible values of "low", "normal", "high" and an escape value consisting of a decimal number. Disclaimer: This information actually came from RFC 987, which was later ammended by RFC 1026, then obsoleted by RFC 1138, which was then obsoleted by RFC 1148. It is possible the information above is no longer correct. Check RFC 1148 before you bet the farm on this. -- Matthew Costello <Matthew.Costello@SanDiego.NCR.COM> +1 619 485 2926 uunet!ncrlnk!ncr-sd!mattc