IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM -TheIPPNotification I-Ds will now go the IESG)]

IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM -TheIPPNotification I-Ds will now go the IESG)]

ned.freed at innosoft.com ned.freed at innosoft.com
Fri Aug 18 12:55:50 EDT 2000


> > Then, when NOTARY, with its structured report format came out...

> Can you give us a very brief summary of what NOTARY is, and perhaps
> a pointer or two to some online info?

NOTARY was an IETF working group that worked on the general problem of
(non)delivery notifications for Internet mail. The group ended up standardizing
a bunch of stuff:

(1) A standard report MIME multipart subtype that can be used for all kinds
    of notifications. The key feature of this format is that it contains
    both a human readable part and a machine readable part.

(2) An elaboration of (1) specifically intended for (non)delivery
    notifications.

(3) An SMTP extension that lets message originators specify what sort of
    notifications they want back (including notification of successful
    delivery) as well as additional information that makes the content of
    notifications more meaningfui and useful.

(4) A more precise set of error codes for SMTP.

(5) A mechanism for embedding such codes in SMTP responses.

See RFCs 1891-1894 for the specifics. (1) is really the relevant piece to IPP;
RFC 1892 describes it. This format has been used for things besides NOTARY
since it was developed; see RFC 2298 for an example.

				Ned

P.S. NOTARY is implemented by almost all modern MTAs, so support for it is very
widespread. (I'm not sure we can take credit for this -- the need to update
MTAs to block message relay is likely more responsible for the infrastructure
upgrade that NOTARY was.) And while some aspects of NOTARY, especially (3),
made implementation somewhat tricky, AFAIK the new format was not found to be
hard to support.



More information about the Ipp mailing list