Index Journeys
RFC 577 UNKNOWN EMAIL · DESIGN

Mail priority

Argues for allowing users to assign priority levels to mail messages.

On rfc-editor.org ↗
PUBLISHED
October 1973
AUTHORS
D. Crocker
STREAM
Legacy
SUGGESTED PRIORITY SCALE
0 to 10
HIGHEST URGENCY (10)
Phone in the middle of the night, if necessary
IMMEDIATE DELIVERY (8)
Deliver to user's terminal NOW
JUNK MAIL (0)
Lowest priority
DOI
10.17487/RFC0577

RFC text

Original text · RFC Editor View on rfc-editor.org ↗ 
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 ]

AI ELI5

On this page
PROBLEMSome messages are more urgent than others, but early mail protocols did not allow senders to indicate importance to recipients.
MECHANISMThe proposal is to add a priority field to mail messages, allowing senders to mark messages with a numeric urgency level from 0 (junk mail) to 10 (phone in the middle of the night). Though humans may not consistently assign priorities, including the information gives recipients a way to manage urgent messages.
WHY IT MATTERSPriority levels provide a way for senders to communicate urgency, and allow mail servers and human recipients to decide how to handle messages based on that information. While perfect consistency may be impossible, the feature is fundamentally useful.

§1The Case for Priority

An earlier proposal (RFC 539) suggested that mail senders be able to assign a priority to their messages. Jim White objected in RFC 555, arguing that urgency levels are meaningless without defined effects on the mail server. This RFC responds by noting that while human senders may not be perfectly consistent in assigning priorities, the concept of urgency is fundamental to communication. Excluding it from the protocol would be a loss.

One person said mail should have urgency levels. Another said that doesn't make sense unless the mail system does something specific with them. The author agrees urgency is real and people will use it, even if imperfectly.

§2Priority Levels and Their Meanings

The RFC suggests a scale from 0 to 10, with suggested interpretations for automated messages. Level 10 means phone the recipient in the middle of the night if necessary. Level 8 means deliver to the user's terminal immediately. Level 6 means deliver only if the user is at the command level. Level 4 means deliver after sign-on or before sign-off. Level 2 means deliver to the standard mailbox. Level 0 means junk mail. Intermediate levels are available for fine-grained distinction. The proposal notes that automated programs (like notification systems) can use these suggested values to communicate message importance, even though human senders may be inconsistent.

From 10 (wake them up!) to 0 (garbage), the numbers tell the receiver how much to care about a message.

§3Why Urgency Matters

The author emphasizes that urgency is a fundamental part of human communication. While automated systems cannot guarantee consistent priority assignment, the simple inclusion of priority information in the mail protocol is valuable. Individual humans and servers can interpret the urgency levels however they see fit. The benefit of having the information available outweighs the cost of inconsistent human judgment.

Even if people don't always mark things correctly, having a way to say something is important is better than having no way to say it at all.

§4References

[RFC539]RFC 539Postel, J. and Crocker, D., "Mail Protocol Proposal Suggestion"July 1973[RFC555]RFC 555White, J., "Response to RFC 539: Another mail protocol suggestion"July 1973