Subject: [lemonade] RFC 4146 on Simple New Mail Notification

From: "Eric Burger" <[email-masked]>
Date: Mon, 22 Aug 2005 11:09:20 -0400

Ugly, but FYI.

-----Original Message-----

A new Request for Comments is now available in online RFC libraries.

        RFC 4146

        Title:      Simple New Mail Notification
        Author(s):  R. Gellens
        Status:     Informational
        Date:       August 2005
        Mailbox:    [email-masked]
        Pages:      5
        Characters: 8561
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-gellens-notify-mail-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4146.txt

This memo documents a long-standing technique, supported by a large
number of mail servers, which allows users to be notified of new
mail.  In addition to server support, there are a number of clients
that support this, ranging from full email clients to specialized
clients whose only purpose is to receive new mail notifications and
alert a mail client.

In brief, the server sends the string "nm_notifyuser" CRLF to the
finger port on the IP address (either configured or last used) of the
user who has received new mail. 

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

..

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Mark Crispin <[email-masked]>
Date: Mon, 22 Aug 2005 08:54:55 -0700 (Pacific Daylight Time)

> Ugly, but FYI.

The publication of this RFC reminded me.

A little over three years ago, I put together a prototype notification 
protocol, lightweight compared to some of the over-engineered suggestions 
I've seen recently, but a bit more capable than the RFC 4146 protocol. 
For various reasons, this project got shelved; but it was never formally 
abandoned.

The basic architecture involves a notification server.  Clients to the 
server are of two types: event generators (spammers) and event receivers 
(spam eaters).  An event generator sends an event, which consists of an 
event type, an event object identifier (OID), and an event payload, to the 
notification server.  An event receiver indicates its willingness to 
receive events of a particular type and OID.  The notification server 
accepts the spam from the spammer, sees if there any spam eaters want to 
be fed that particular spam, and either discards the spam or feeds the 
eater(s).

In the case of mail notifications, the MDA would be an event generator.  I 
hope that the reason is obvious and doesn't need belaboring.

Either the MUA or the IMAP server could be the event receiver, although 
obviously I would prefer that the MUA receive the events.  I see no 
compelling reason for IMAP to be a middleman (plus, why require an IMAP 
connection for notifications?) but I'm not strongly opposed to it either.

I wrote a basic notification server, which runs as a single process for 
all events, and event generator/receiver libraries.

I'm willing to dust this work off, if there is interest.

I should emphasize the lightweight design and intent of this protocol.  I 
believe that it is important for notification to be trivial enough that 
nobody would mind adding it once there is a notification protocol.  That 
is also the attraction of RFC 4146.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 22 Aug 2005 12:55:27 -0700

>  Ugly, but FYI.

Ugly, but long-standing and fairly widely deployed.  I wrote it up 
mostly because a number of people had never heard of it.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
"SFPD Homicide: Our Day Begins when Yours End" --Slogan seen on back of
San Francisco Police Jacket, as reported by Herb Cain in SF Chronicle

---

From: Randall Gellens <[email-masked]>
Date: Mon, 22 Aug 2005 13:00:55 -0700

At 8:54 AM -0700 8/22/05, Mark Crispin wrote:

>  a bit more capable than the RFC 4146 protocol.

Not hard to do.

>  I should emphasize the lightweight design and intent of this 
> protocol.  I believe that it is important for notification to be 
> trivial enough that nobody would mind adding it once there is a 
> notification protocol.  That is also the attraction of RFC 4146.

I'd agree with this.

-------------- Randomly-selected tag: ---------------
A logician saves the life of a space alien and is rewarded with
an offer to answer any question.  After a thought he asks: What
is the best question to ask and the correct answer to it?  After
a brief panic the alien consults her computer and says: The best
question to ask is the one you just did and the correct answer
to it is the one I gave.