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 ]