RFC 4146

Simple New Mail Notification 💖

Okay bestie, here's the tea on RFC 4146 🎀

• RFC number and title: RFC 4146, "Simple New Mail Notification" ✨
• Author: Randall (Randy) Gellens of QUALCOMM 💅
• Category: Informational 🧚
• Date: August 2005 📅
• Obsoletes / Updates: the header doesn't list either one, so it doesn't obsolete or update anything 🙈
• Stream: Network Working Group 🌸

---

Status of This Memo 📝

This memo gives information to the Internet community. It is not a standard of any kind, and it can be distributed as widely as you like 🦋

Copyright Notice ©️

Copyright (C) The Internet Society (2005) 🌈

Abstract 🔥

Okay so this one documents a long-running trick that lots of mail servers support, where you get pinged the second new mail shows up 📬 Plenty of clients do this too, from full email apps all the way down to tiny little programs whose entire job is to catch the ping and wake up your mail app 💜

The vibe is literally this: the server sends the string "nm_notifyuser" followed by CRLF to the finger port on the IP address (either the configured one or the last one used) of the user who got new mail 🎀

Table of Contents 📚

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Conventions Used in this Document . . . . . . . . . . . . . . 2
3.  Simple Mail Notification . . . . . . . . . . . . . . . . . .  2
4.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5.  Security Considerations  . . . . . . . . . . . . . . . . . .  3
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  3

1. Introduction 🦋

This is a long-standing technique that a ton of mail servers support, and it's how users get notified about new mail 📬 Lots of clients use it too, from full email clients to super specialized little clients whose only purpose is to catch new mail notifications and alert a mail client 🧚 People call it "notify mail" (after a shareware client with the same name), "biff", and the "finger hack" 💅

2. Conventions Used in This Document 🎀

In examples, "C:" marks lines sent by the client and "S:" marks lines sent by the server 💖 Line breaks inside a command example are just for editing purposes, and line breaks in the protocol itself are shown as "CRLF" ✨

3. Simple Mail Notification 🔥

So here's how it goes: the server sends the string "nm_notifyuser" immediately followed by CRLF to the finger port on the IP address of the user who got new mail. The finger port is 79. Note that only the finger port gets used. The finger protocol itself is not used at all 🙈

The IP address can be configured, or the server can use the IP address the user last used to check mail 🌸 This is usually a per-account setting 💜

On the client side, a process has to be listening on the finger port for any of this to be useful 👑 When it gets the "nm_notifyuser" string, it takes some configured action, usually telling a mail client to go fetch mail 📬

Normally, the server opens a TCP connection to the target computer, sends the "nm_notifyuser" string, and closes the connection without waiting for a response 🦋

Sometimes UDP is used instead of TCP, but the default and most common practice is TCP. Even though only one message goes in one direction with no reply, TCP is used most often, probably for reliability 💅

There's an assumption that the client listening on an IP address is only responsible for one email account. If a client can check multiple accounts and gets the "nm_notifyuser" string, it has no idea which account actually got the mail 😭

There's also a requirement that a finger daemon not be active on the client 🚫

4. Example 🧚

This example assumes new mail has arrived at the server mail.isp.example.com for the account fastness@example.net. The server has figured out an IP address to send the notification to ✨

   C: <listens on TCP port 79>
   S: <opens TCP connection to IP address port 79>
   C: <accepts inbound connection on port 79>
   S: nm_notifyuserCRLF
   S: <closes TCP connection>

5. Security Considerations 💀

Heads up, this section is kind of a big deal 😭

There's no assurance that the "nm_notifyuser" message is going to the correct IP address. The listening agent on the client also has no assurance that an "nm_notifyuser" string was sent by a mail server that actually received new mail for the user 🙈

It is trivial for an attacker to send huge numbers of "nm_notifyuser" messages to a targeted system. Client systems that are listening for this message SHOULD implement protections against being flooded with notifications. Lots of server systems already have protections against users logging in and checking mail too often 🔥

Because this protocol needs a port open with an agent listening on it, if that agent has vulnerabilities, it may create a remotely exploitable attack. For example, buffer overflows could let an attacker run arbitrary code on the client system with the agent's permissions 💀 As usual with any process listening on a port, the process should run with the least possible privilege level and access 👑

6. IANA Considerations 🌈

The notify mail hack (and this document) should be included as an additional usage for port 79 🎀

7. Acknowledgments 💜

The NotifyMail shareware utility was written by Scott Gruby 🫶

Author's Address 🧚

Randall Gellens
QUALCOMM Incorporated
6455 Lusk Blvd.
San Diego, CA  92121-2779
USA
EMail: randy@qualcomm.com

Full Copyright Statement ©️

Copyright (C) The Internet Society (2005) 🌸

This document falls under the rights, licenses, and restrictions in BCP 78. Except as set out there, the authors keep all their rights 💅

This document and the info in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 💀

Intellectual Property 🔥

The IETF doesn't take a position on whether any Intellectual Property Rights that might apply to this technology are valid or how far they reach, and it doesn't say whether licenses would be available 🙈 It also hasn't made any independent effort to find such rights. Info on how rights work for RFC documents is in BCP 78 and BCP 79 📚

Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses, and the results of any attempt to get a general license for implementers or users are available from the IETF's online IPR repository at http://www.ietf.org/ipr 🦋

The IETF invites anyone to bring it any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to ietf-ipr@ietf.org 💜

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society 🌈