Browse Prior Art Database

SMTP Service Extension for Delivery Status Notifications (RFC1891)

IP.com Disclosure Number: IPCOM000004146D
Original Publication Date: 1996-Jan-01
Included in the Prior Art Database: 2019-Feb-12
Document File: 31 page(s) / 40K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

K. Moore: AUTHOR

Related Documents

10.17487/RFC1891: DOI

Abstract

This memo defines an extension to the SMTP service, which allows an SMTP client to specify (a) that delivery status notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS-TRACK]

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 6% of the total text.

Network Working Group K. Moore Request for Comments: 1891 University of Tennessee Category: Standards Track January 1996

SMTP Service Extension for Delivery Status Notifications

Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

1. Abstract

This memo defines an extension to the SMTP service, which allows an SMTP client to specify (a) that delivery status notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent.

Any questions, comments, and reports of defects or ambiguities in this specification may be sent to the mailing list for the NOTARY working group of the IETF, using the address <notifications@cs.utk.edu>. Requests to subscribe to the mailing list should be addressed to <notifications-request@cs.utk.edu>. Implementors of this specification are encouraged to subscribe to the mailing list, so that they will quickly be informed of any problems which might hinder interoperability.

NOTE: This document is a Proposed Standard. If and when this protocol is submitted for Draft Standard status, any normative text (phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in this document will be re-evaluated in light of implementation experience, and are thus subject to change.

2. Introduction

The SMTP protocol [1] requires that an SMTP server provide notification of delivery failure, if it determines that a message cannot be delivered to one or more recipients. Traditionally, such notification consists of an ordinary Internet mail message (format defined by [2]), sent to the envelope sender address (the argument of

Moore Standards Track [Page 1]

RFC 1891 SMTP Delivery Status Notifications January 1996

the SMTP MAIL command), containing an explanation of the error and at least the headers of the failed message.

Experience with large mail distribution lists [3] indicates that such messages are often insufficient to diagnose problems, or even to determine at which host or for which recipients a problem occurred. In addition, the lack of a standardized format for delivery notifications in Internet mail makes it difficult to exchange such notifications with other message handling systems.

Such experience has demonstrated a need for a delivery status notification service for Internet electronic mail, which:

(a) is reliable, in the sense that any DSN request will either be honored at the time of final delivery, or result in a response that indicates that the reques...

Processing...
Loading...