Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
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: 2000-Sep-13
Document File: 26 page(s) / 60K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

K. Moore: AUTHOR

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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 4% 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

. Requests to subscribe to the mailing

list should be addressed to .

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

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.