Mail priority
An argument for carrying sender-assigned urgency in mail.
Crocker, D., "Mail priority", RFC 577, DOI 10.17487/RFC0577, October 1973, <https://www.rfc-editor.org/info/rfc577>.
@misc{rfc577,
series = {Request for Comments},
number = 577,
howpublished = {RFC 577},
publisher = {RFC Editor},
doi = {10.17487/RFC0577},
url = {https://www.rfc-editor.org/info/rfc577},
author = {D. Crocker},
title = {{Mail priority}},
pagetotal = 2,
year = 1973,
month = oct,
} RFC text
Network Working Group D. Crocker Request for Comments: 577 UCLA-NMC NIC: 19356 October 1973 References: RFC 524, 539, 555 Mail Priority In RFC 539 (NIC--17644,3d:gy) Postel and I suggested that mail senders be allowed to assign a degree of priority to their mail. White (RFC 555--17993,6c:gy) objected to defining shades of urgency, without having their effects upon the Mail Protocol server also defined. If priority levels were to be assigned by automata, I would agree with Jim. Unfortunately, the human sender of the mail will usually be the one to assign the priority, and humans will not be consistent in that assignment. Also unfortunately, the concept of urgency is an integral part of communication. If it weren't, we could ignore its inclusion into the MP. Since distinctions in urgency are useful (necessary?) and since humans will be the ones assigning specific degrees of urgency (thereby making it impossible for server processes to automatically do the "right thing" in response), we suggested only including the INFORMATION as part of the protocol. Let the human and server- process receivers decide between themselves how the server-process should deal with that information. Now that I have argued all that, let me suggest interpretations for urgency values. This is so that programmers can have automata- generated mail (e.g., notification of the status of previously sent mail) carry reasonable urgency values: 10 Phone in the middle of the night, if necessary. 9 8 Deliver to user's terminal NOW. 7 6 Deliver to user's terminal only if user is at "exec" level. 5 4 Deliver immediately after sign-on or before sign-off. 3 2 Deliver into standard mailbox. 1 0 Junk Mail [ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Martin Lyngvig 7/99 ]
ISO Plain Language
On this page
§1Priority as Information
RFC 539 proposed letting mail senders assign a degree of priority. RFC 555 objected that the effects of urgency on the mail server had not been defined. RFC 577 responds that people, rather than automated systems, will usually assign priority and may do so inconsistently.
The author argues that urgency is still part of communication. The protocol should carry that information and let human recipients and server processes decide how to handle it, rather than require an automatic response for each value.
The author argues that mail should carry urgency information even if senders do not use it consistently. The receiver, not the protocol, can decide what action each value should trigger.
§2Suggested Urgency Values
The RFC suggests values from 0 through 10 and gives example meanings for some of them. A value of 10 could justify a phone call in the middle of the night if necessary; 8 means delivery to the user's terminal now; 6 means delivery there only when the user is at the exec level; 4 means delivery after sign-on or before sign-off; 2 means standard-mailbox delivery; and 0 means junk mail. The author offers these interpretations to help programs that generate mail assign reasonable values.
The scale gives examples of how urgent different values might be, from ordinary mailbox delivery to immediate attention. These are suggested meanings, not automatic actions required of every mail server.
§3Who Decides What Happens
The proposal separates the priority information from its handling. The sender supplies a value, but the RFC does not define a fixed server action for every level. Human recipients and server processes may decide together how to respond to the information.
A priority value tells the receiver what the sender thinks, but does not force a particular delivery action. People and mail programs can use the information as they choose.