RFC 577

Mail Priority ✨

Okay bestie, the title block first 🎀

• Network Working Group
• Request for Comments: 577
• Title: Mail Priority
• Author: D. Crocker, UCLA-NMC
• NIC: 19356
• Date: October 1973
• References: RFC 524, 539, 555
• Obsoletes, updates, category: none are listed in this one 👀

So in RFC 539 (NIC--17644,3d:gy), Postel and I suggested that mail senders be allowed to give their mail a degree of priority 💌. Then White (RFC 555--17993,6c:gy) objected to defining shades of urgency unless their effects on the Mail Protocol server were defined too 🙅‍♀️. Fair point, honestly.

If priority levels were getting assigned by automata, I'd agree with Jim 🤖. But the human sender is usually the one picking the priority, and humans are not consistent about it at all 😭.

Also, urgency is kinda baked into communication itself 🫠. If it weren't, we could just ignore it in the MP. It's not ignorable, though.

So distinctions in urgency are useful (necessary?) ✨. Humans will be the ones choosing specific urgency levels, which makes it impossible for server processes to automatically do the "right thing" with them 🥲. So we suggested only including the INFORMATION as part of the protocol 💅. The human and server-process receivers can then decide between themselves how the server-process should handle that information 🤝.

Now that I've argued all that, here are some interpretations for the urgency values 🎀. This way programmers can have automata-generated mail (for example, notifications about 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 ] 🌸