MSGTRK pre-drafts

Eric Allman <[email protected]> Tue, 11 Jul 2000 09:55:07 -0700

Newsgroups	gmane.ietf.msgtrk
Message-ID	<[email protected]>

Enclosed are two "pre-drafts" -- they really aren't up for draft status yet,
but I did want folks here get a glimpse of where they are going.

eric

draft-ietf-msgtrk-smtpext.txt (text/plain, 10.2 KB)

Internet Draft E. Allman

draft-ietf-msgtrk-smtpext-00.txt Sendmail, Inc.

Valid for six months July XXX, 2000

SMTP Service Extension

for Message Tracking

<draft-ietf-msgtrk-smtpext-00.txt>

Status of This Memo

This document is an Internet-Draft and is in full conformance

with all provisions of Section 10 of RFC2026. Internet-Drafts are

working documents of the Internet Engineering Task Force (IETF), its

areas, and its working groups. Note that other groups may also dis-

tribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six

months and may be updated, replaced, or obsoleted by other documents

at any time. It is inappropriate to use Internet-Drafts as reference

material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at:

http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at:

http://www.ietf.org/shadow.html

IInntteerrnneett DDrraafftt MMeessssaaggee TTrraacckkiinngg EESSMMTTPP EExxtteennssiioonn JJuullyy XXXXXX,, 22000000

This document is a submission by the MSGTRK Working Group of the

Internet Engineering Task Force (IETF). Comments should be submitted

to the [email protected] mailing list. An archive of the mailing list

may be found at

http://www.ietf.org/archive/msgtrk

Distribution of this memo is unlimited.

11.. AAbbssttrraacctt

This memo defines an extension to the SMTP service whereby a

client may query an SMTP server for the status of a message.

22.. IInnttrroodduuccttiioonn

22..11.. GGooaallss

22..22.. OOtthheerr ddooccuummeennttss

draft-ietf-msgtrk-model-01.txt

draft-ietf-msgtrk-trkstat-01.txt

DSN

MDN

RFC 1894

AAllllmmaann [[PPaaggee 22]]

IInntteerrnneett DDrraafftt MMeessssaaggee TTrraacckkiinngg EESSMMTTPP EExxtteennssiioonn JJuullyy XXXXXX,, 22000000

22..33.. CCoonnffoorrmmaannccee

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",

"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and

"OPTIONAL" in this document are to be interpreted as described

in RFC 2119 [RFC-KEYWORDS].

33.. SSMMTTPP EExxtteennssiioonn OOvveerrvviieeww

The Message Tracking SMTP service extension uses the SMTP ser-

vice extension mechanism described in [XXX]. The following service

extension is hereby defined:

(1) The name of the SMTP service extension is "Message Track-

ing".

(2) The EHLO keyword value associated with this extension is

"MTRK".

(3) No parameters are allowed with this EHLO keyword value.

Future documents may extend this specification by specifying

options. XXX Should we indicate the maximum amount of time

this server is willing to hold tracking info?

(4) One optional parameter using the keyword "MTRK" is added to

the MAIL FROM command. In addition, the ENVID parameter (as

defined in RFC 1891 section 5.4) must be supported, with

extensions as described below.

AAllllmmaann [[PPaaggee 33]]

IInntteerrnneett DDrraafftt MMeessssaaggee TTrraacckkiinngg EESSMMTTPP EExxtteennssiioonn JJuullyy XXXXXX,, 22000000

(5) The maximum length of a MAIL FROM command line is increased

by XXX characters by the possible addition of the MTRK key-

word and value.

(6) One additional SMTP verb "MTRK" is defined by this exten-

sion.

33..11.. TThhee MMeessssaaggee TTrraacckkiinngg SSMMTTPP SSeerrvviiccee EExxtteennssiioonn

33..22.. XXXXXX aannyy mmooddeell iinnffoo wwee nneeeedd

44.. TThhee EExxtteennddeedd MMAAIILL FFRROOMM CCoommmmaanndd

The extended MAIL FROM command is issued by an SMTP client

when it wishes to inform an SMTP server that message tracking

information should be retained for a specified period. The

extended MAIL FROM command is identical to the MAIL FROM command as

defined in RFC 821 [XXX], except that a MTRK parameter appears

after the address.

44..11.. TThhee MMTTRRKK ppaarraammeetteerr ttoo tthhee EESSMMTTPP MMAAIILL ccoommmmaanndd

Any sender wishing to track a message must tag that message

as trackable using the MTRK parameter to the MAIL FROM command.

This parameter has the following syntax:

mtrk-parameter = "MTRK=" mtrk-certifier [ ":" mtrk-timeout ]
mtrk-certifier = base64 ; authenticator
mtrk-timeout = 1*9digit ; seconds until timeout

XXX need to import base64 from somewhere

AAllllmmaann [[PPaaggee 44]]

IInntteerrnneett DDrraafftt MMeessssaaggee TTrraacckkiinngg EESSMMTTPP EExxtteennssiioonn JJuullyy XXXXXX,, 22000000

The mtrk-timeout field indicates the number of seconds

until this tracking information will time out. Servers MAY

ignore this value if it violates local policy. [XXX see draft-

newman-deliver-03 for an explanation of why TTL instead of abso-

lute time]

The mtrk-certifier field is stored in the tracking database

and used to authenticate future tracking requests. XXX Need

expansion.

44..22.. UUssee ooff EENNVVIIDD

To function properly, Message Tracking requires that each

message have a unique identifier that is never reused by any

other message. For that purpose, if the MTRK parameter is

given, an ENVID parameter MUST be included, and the syntax of

ENVID from RFC 1891 section 5.4 is extended as follows:

envid-parameter = "ENVID=" unique-envid
unique-envid = xtext "@" fqhn
fqhn = xtext

Any retransmissions of this message MUST assign a new ENVID.

XXX define retransmission

55.. MMTTRRKK CCoommmmaanndd

The MTRK ESMTP command is used to request tracking status

information for a message that has previously been processed.

AAllllmmaann [[PPaaggee 55]]

IInntteerrnneett DDrraafftt MMeessssaaggee TTrraacckkiinngg EESSMMTTPP EExxtteennssiioonn JJuullyy XXXXXX,, 22000000

55..11.. CCoommmmaanndd ssyynnttaaxx

The syntax of the MTRK command is:

mtrk-command = "MTRK" LWSP unique-envid LWSP mtrk-authenticator
mtrk-authenticator = base64

The unique-envid corresponds to a message that may have

been previously seen by this MTA.

The mtrk-authenticator validates the rights of this sender

to request tracking information for the indicated unique-envid.

55..22.. CCoommmmaanndd sseemmaannttiiccss

The MTRK command behaves as follows:

(1) The indicated unique-envid is looked up in the local mes-

sage tracking database. If that key is not found, the

receiving MTA MUST immediately return a "no information"

5XXX response.

(2) If the unique-envid is found in the database, the stored

mtrk-certifier is compared against the transmitted mtrk-

authenticator by computing the hash of the unique-envid

concatenated with the mtrk-authenticator and comparing

that to the stored mtrk-certifier. If these do not

match, the sending MTA has not provided the correct mtrk-

authenticator, and the receiving MTA MUST immediately

return a "no information" 5XXX response.

AAllllmmaann [[PPaaggee 66]]

IInntteerrnneett DDrraafftt MMeessssaaggee TTrraacckkiinngg EESSMMTTPP EExxtteennssiioonn JJuullyy XXXXXX,, 22000000

(3) If the certification phase succeeds, the receiving MTA

returns a response as described below.

66.. RReessppoonnssee ssyynnttaaxx

The response syntax obeys standard SMTP response syntax. Each

line of response is prefixed with "250-2.5.6" (XXX the new 2.5.6

code must be standardized).

The content of the response is the body of a message/tracking-

status as defined in draft-ietf-msgtrk-trkstat-00.

XXX Side comment: I notice that 2034 doesn't exempt EXPN and

VRFY from enhanced status codes. This makes them potentially non-

parseable. This may not be a problem.

77.. EExxppiirriinngg SSttaattuuss IInnffoorrmmaattiioonn

Most hosts will want to expire tracking status information

after some amount of time. When a sending MTA requests that mes-

sage tracking information be kept, it may optionally ask for a spe-

cific timeout.

88.. SSeeccuurriittyy IIssssuueess

XXX who can track a message

Once a message is tracked, someone can sniff and re-use

AAllllmmaann [[PPaaggee 77]]

draft-ietf-msgtrk-trkstat.txt (text/plain, 13.4 KB)

Internet Draft E. Allman

draft-ietf-msgtrk-trkstat-00.txt Sendmail, Inc.

Valid for six months July XXX, 2000

The Message/Tracking-Status MIME Extension

<draft-ietf-msgtrk-trkstat-00.txt>

Status of This Memo

This document is an Internet-Draft and is in full conformance

with all provisions of Section 10 of RFC2026. Internet-Drafts are

working documents of the Internet Engineering Task Force (IETF), its

areas, and its working groups. Note that other groups may also dis-

tribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six

months and may be updated, replaced, or obsoleted by other documents

at any time. It is inappropriate to use Internet-Drafts as reference

material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at:

http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at:

http://www.ietf.org/shadow.html

IInntteerrnneett DDrraafftt MMeessssaaggee//TTrraacckkiinngg--SSttaattuuss JJuullyy XXXXXX,, 22000000

This document is a submission by the MSGTRK Working Group of the

Internet Engineering Task Force (IETF). Comments should be submitted

to the [email protected] mailing list. An archive of the mailing list

may be found at

http://www.ietf.org/archive/msgtrk

Distribution of this memo is unlimited.

11.. AAbbssttrraacctt

This memo defines a MIME type for message tracking in the same

spirit as RFC 1894, ``An Extensible Message Format for Delivery

Status Notifications''. It is to be used in conjunction with

draft-ietf-msgtrk-smtpext-01.txt.

22.. IInnttrroodduuccttiioonn

This memo defines a MIME [XXX] content-type for reporting mes-

sage tracking status information. A tracking status is issued to a

requestor upon request. This memo defines only the format of the

status information. An extension to SMTP [XXX] to label messages

for further tracking and request tracking status is defined in a

separate memo [XXX].

22..11.. GGooaallss

Message Tracking is expected to be used to determine the

status of undelivered e-mail upon request. Tracking is used in

conjunction with Delivery Status Notifications [XXX]; generally,

AAllllmmaann [[PPaaggee 22]]

IInntteerrnneett DDrraafftt MMeessssaaggee//TTrraacckkiinngg--SSttaattuuss JJuullyy XXXXXX,, 22000000

a message tracking request will be issued only when a DSN has

not been received within a reasonable timeout period.

22..22.. OOtthheerr ddooccuummeennttss

draft-ietf-msgtrk-model-01.txt

RFC 1894. Sections 1.3 (Terminology), 2.1.1 (General con-

ventions for DSN fields), 2.1.2 ("*-type" subfields), 2.1.3

(Lexical tokens imported from RFC 822), 2.2.2 (The Reporting-MTA

DSN field), 2.3.5 (Remote-MTA field), and 2.XXX of RFC 1894 are

included by reference.

DSN

MDN

RFC 2119. The key words "MUST", "MUST NOT", "REQUIRED",

"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",

"MAY", and "OPTIONAL" in this document are to bbe interpreted as

described in RFC 2119 [RFC-KEYWORDS].

33.. FFoorrmmaatt ooff aa MMeessssaaggee TTrraacckkiinngg SSttaattuuss NNoottiiffiiccaattiioonn

A MTSN can be returned as the body of an MTRK reply, or as a

subtype of a MIME message with a top-level content type of multi-

part/report (defined in [XXX]). When a multipart/report content is

used to transmit a MTSN:

(a) The report-type parameter of the multipart/report content is

"tracking-status".

AAllllmmaann [[PPaaggee 33]]

IInntteerrnneett DDrraafftt MMeessssaaggee//TTrraacckkiinngg--SSttaattuuss JJuullyy XXXXXX,, 22000000

(b) The first component of the multipart/report contains a human-

readable explanation of the MTSN, as described in [XXX].

type message/tracking-status, as defined in this document.

(d) If the original message or a portion of the message is to be

returned to the sender, it appears as the third component of

the multipart/report.

33..11.. TThhee mmeessssaaggee//ttrraacckkiinngg--ssttaattuuss ccoonntteenntt--ttyyppee

The message/tracking-status content-type is defined as fol-

lows:

MIME type name: message
MIME subtype name: tracking-status
Optional parameters: none
Encoding considerations: "7bit" encoding is sufficient and
MUST be used to maintain readability
when views by non-MIME mail readers.
Security considerations: discussed in section XXX of this memo.

The message/tracking-status report type for use in the multi-

part/report is "tracking-status".

The body of a message/tracking-status is modeled after RFC

1894, "An Extensible Message Format for Delivery Status Notifi-

cations". The body of a message/tracking-status consists of one

or more "fields" formatted to according to the ABNF of RFC 822

headers "fields" (see [XXX]). The per-message fields apear

first, followed by a blank line. Following the per-message

fields are one or more groups of per-recipient fields. Each

AAllllmmaann [[PPaaggee 44]]

IInntteerrnneett DDrraafftt MMeessssaaggee//TTrraacckkiinngg--SSttaattuuss JJuullyy XXXXXX,, 22000000

group of per-recipient fields is preceded by a blank line.

Using the ABNF of RFC 822, the syntax of the message/tracking-

status content is as follows:

tracking-status-content =
per-message-fields 1*( CRLF per-recipient-fields )

The per-message fields are described in section XXX. The per-

recipient fields are described in section XXX.

33..11..11.. GGeenneerraall ccoonnvveennttiioonnss ffoorr MMTTSSNN ffiieellddss

Section 2.1.1 of RFC 1894 (General conventions for DSN

fields) is included herein by reference. Notably, the defi-

nition of xtext is identical to that of RFC 1894.

33..11..22.. **--ttyyppee ssuubbffiieellddss

Section 2.1.2 of RFC 1894 (*-type subfields) is included

herein by reference. Notably, the definitions of address-

type, diagnostic-type, and MTA-name type are identical to

that of RFC 1894.

33..11..33.. LLeexxiiccaall ttookkeennss iimmppoorrtteedd ffrroomm RRFFCC 882222

The following lexical tokens, defined in [XXX], are used

in the ABNF grammar for MTSNs: atom, CHAR, comment, CR, CRLF,

DIGIT, LF, linear-white-space, SPACE, text. The date-time

lexical token is defined in [XXX].

AAllllmmaann [[PPaaggee 55]]

IInntteerrnneett DDrraafftt MMeessssaaggee//TTrraacckkiinngg--SSttaattuuss JJuullyy XXXXXX,, 22000000

33..22.. PPeerr--MMeessssaaggee MMTTSSNN FFiieellddss

Some fields of an MTSN apply to all of the addresses in a

single envelope. These fields may appear at most once in any

MTSN. These fields are used to correlate the MTSN with the

original message transaction and to provide additional informa-

tion which may be useful to gateways.

per-message-fields =
[ original-envelope-id-field CRLF ]
reporting-mta-field CRLF
[ arrival-date CRLF ]
*( extension-field CRLF )

33..22..11.. TThhee OOrriiggiinnaall--EEnnvveellooppee--IIdd ffiieelldd

The optional Original-Envelope-Id field is defined as in

section 2.2.1 of RFC 1894.

33..22..22.. TThhee RReeppoorrttiinngg--MMTTAA ffiieelldd

The Reporting-MTA field is defined as in section 2.2.2

of RFC 1894.

33..22..33.. TThhee AArrrriivvaall--DDaattee ffiieelldd

The Arrival-Date field is defined as in section 2.2.5 of

RFC 1894.

33..33.. PPeerr--RReecciippiieenntt MMTTSSNN ffiieellddss

An MTSN contains information about attempts to deliver a

message to one or more recipients. The delivery information for

AAllllmmaann [[PPaaggee 66]]

IInntteerrnneett DDrraafftt MMeessssaaggee//TTrraacckkiinngg--SSttaattuuss JJuullyy XXXXXX,, 22000000

any particular recipient is contained in a group of contiguous

per-recipient fields. Each group of per-recipient fields is

preceded by a blank line.

The syntax for the group of per-recipient fields is as fol-

lows:

per-recipient-fields =
[ original-recipient-field CRLF ]
final-recipient-field CRLF
action-field CRLF
status-field CRLF
[ remote-mta-field CRLF ]
[ last-attempt-date-field CRLF ]
[ will-retry-until-field CRLF ]
*( extension field CRLF )

33..33..11.. OOrriiggiinnaall--RReecciippiieenntt ffiieelldd

Section 2.3.1 XXX

33..33..22.. FFiinnaall--RReecciippiieenntt ffiieelldd

2.3.2 XXX

33..33..33.. AAccttiioonn ffiieelldd

The Action field indicates the action performed by the

Reporting-MTA as a result of its attempt to delivery the mes-

sage to this recipient address. This field MUST be present

for each recipient named in the MTSN. The syntax is as

defined in section 2.3.3 of RFC 1894. XXX Do we want to have

a "waiting for pickup" action?

AAllllmmaann [[PPaaggee 77]]

IInntteerrnneett DDrraafftt MMeessssaaggee//TTrraacckkiinngg--SSttaattuuss JJuullyy XXXXXX,, 22000000

33..33..44.. SSttaattuuss ffiieelldd The Status field is defined as in RFC

1894 section 2.3.4. A new code is added to RFC 1893,

"Enhanced Mail System Status Codes",

X.1.9 Message relayed to non-compliant mailer"

The mailbox address specified was valid, but the mes-

sage has been relayed to a system that does not speak

this protocol; no further information can be pro-

vided.

33..33..55.. RReemmoottee--MMTTAA ffiieelldd

Reference 2.3.5 XXX

33..33..66.. LLaasstt--AAtttteemmpptt--DDaattee ffiieelldd

Reference 2.3.7 XXX

33..33..77.. WWiillll--RReettrryy--UUnnttiill ffiieelldd Reference 2.3.8 XXX

33..44.. EExxtteennssiioonn ffiieellddss

Reference 2.4 XXX

33..55.. DDiiffffeerreenncceess ffrroomm RRFFCC 11889944

AAllllmmaann [[PPaaggee 88]]

IInntteerrnneett DDrraafftt MMeessssaaggee//TTrraacckkiinngg--SSttaattuuss JJuullyy XXXXXX,, 22000000

Original-Envelope-Id keep
Reporting-MTA keep
DSN-Gateway relevant?
Received-From-MTA keep?
Arrival-Date keep

Original-Recipient keep?
Final-Recipient keep
Action expand: need "queued". Is "expanded" relevant?
Status expand: need "relayed"
Remote-MTA keep
Diagnostic-Code drop
Last-Attempt keep
Will-Retry-Until keep

44.. SSeeccuurriittyy IIssssuueess

XXX To be completed.

AAllllmmaann [[PPaaggee 99]]