INTERNET DRAFT
Advanced Integrators, LC B. Gingery
Category: Internet Draft November 2001
Expires: 20 June 2002
ESMTP Service Extension for Filtering Gateways
draft-bgingery-esmtp-adat-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to 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 distribute 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."
This document requests consideration for adoption as an
extension to internet standards after an appropriate com-
ment period, 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. Dis-
tribution of this memo is unlimited.
Comments may be addressed to the author, who also
requests copies of discussions about this proposed exten-
sion, including access to IETF/IESG workgroup discussions
of this extension.
<bgingery-adat-draft@gtcs.com>
and may be referred to as draft-bgingery-esmtp-
adat-00.txt
Abstract
This document describes a needed extenson to the STD-10
SMTP (Simple Mail Transport Protocol) service so that an
ESMTP server and client mqy delay specific recipient
acceptance until after content can be examined by the
filtering gateway. It adds one return code (355) and
three verbs (ADAT, DRCP and ERCP) to the ESMTP protocol
as defined in RFC2821. It affects state processing of
ESMTP negotiations. It diverges from some MUST NOT
activities required by RFC2821, to recognize an addition-
ally needed functionality which is being widely performed
in defiance of existing standards. As such, it helps
restore needed hardiness to the world wide SMTP delivery
systems. It overloads the 454 return code as well as
adding a 355 (send recipients).
Table of Contents
1. Introduction
1.1 Terminology
1.2 Applicability
2. Added Verbs and Return Codes
2.1 ADAT and 355 code
2.2 <CR><LF>.<CR><LF> end-of-data
2.3 DRCP
2.4 ERCP
2.5 RSET before ERCP
2.6 454 code
2.7 Recap of ADAT based verbs
3. Typical sessions
3.1 Successful Single Recipient
3.2 Unsuccessful Single Recipient
3.3 Protectively Filtered - Site Prohibited
3.4 Content-Filtered for Specified Recipients
4. Send/Response map
5. Domain indication of ADAT support
6. Source Route Filters and other Filters
7. Manditory Discliamers
8. Security Considerations
9. Author Contact
A. References
1. Introduction
STD-10 ESMTP [See also RFC-2821] servers and clients have
a variant conversation within their handling of messages.
While these are strictly defined within a given session,
there are widely varying support for both basic and
extended protocols and facilities. Current requirements
for filtering for individual sites and even recipients
reduces the benefits of pre-qualifying recipients before
passing the payload data for any given message. Prior to
implementation of this service extension, the only poten-
tials for content-based rejection of multi-recipient
deliveries includes breaking of some tracking and debug-
ging provisions of previous standards and extensions.
SEND, SAML and SOML recipient specifications are falling
out of favor, (See Section F.6 of RFC2821) so this pro-
vides an alternative traditional MAIL/RCPT transactions,
and makes no pretense of integrating with the active
delivery methods which are now deprecated, and largely
replaced by Instant Messaging protocols. Some gateways
may wish to accept this subset into instant messaging
client-server conversations, as an Instant-Message to E-
Mail (or E-Mail to Instant Message) filtering gateway.
Such functions are outside the definition of this docu-
ment, but it is strongly recommended that such addresses
be managed by addressee address rather than by protocol
extension.
Currently RFC2821 (April 2001) which is on a standards
track to replace RFC-821 as STD-10, section 4.4 forbids
relay servers from inspecting content. However, this is
routinely done in spam and virus filtering services, to
the confusion of the overall SMTP based world-wide mail
processing network. Because recipients are routinely
qualified by the receiving server BEFORE content is
checked, several adaptations are becoming common:
1. Ignore status indications, returning an acceptance
even for messages which will be discarded according to
delivery rules, as a site policy.
2. Report delivery status via secondary status E-
Mails, using the <> null administrative return
address. This results in a sometimes abused facility
when envelope sender addresses are forged.
3. Recipients are already provisionally pre-approved,
then the entire delivery fails, even if local rules on
the receiving end would allow delivery to SOME recipi-
ents.
4. Recipients are already provisionally pre-approved.
Then, after transfer of content, it is discovered that
local delivery is prohibited by local recipient rules
for some recipients. This lack of delivery is then
ignored (as in case 1 above) or reported using the
abusable null return address.
1.1 Terminology
The key words "MUST", "MUST NOT", REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be inter-
preted as described in RFC-2991.
1.2 Applicability
This extension has potential use both for clients and
servers operating in MCA (Mail Client Agent requesting
injection), MSA (Mail Submission Agent - receiving injec-
tions), and MTA (Mail Transport Agent - accepting for
transport and disposition) roles.
Use of the ADAT/DRCP/ERCP protocol extension by a client
indicates that it assumes responsibility for notifying
its clients (if any) of the delayed disposition of mes-
sages. Advertisement of the ADAT protocol extension by
servers indicates that they accept responsibility for any
forwarding (relaying) and conversion required for passing
messages to subsequent services, whether they are ESMTP
or not, and whether or not they accept this ADAT exten-
sion. In addition, dsn (Delivery Status Notification)
enhancements to the basic protocols become relevant in
any software which acts as a filter, even where confusion
has prevented its use in previous implementations.
Servers implementing this extension SHOULD also implement
dsn [RFC1891].
The ESMTP with ADAT processing design allows for exten-
sions to the basic SMTP model:
+----------+
+------+ | |
| User |<-->| |
+------+ | Client- |<---------+ Commands/Replies
+------+ | SMTP | | SMTP, ESMTP
| File |<-->| | | or ESMTP/ADAT
|System| | | v
+------+ +----------+ +----------+ Local
| Filtering| +-----------+
+----------+ | Gateway |<--->| File |
| Recipient| | | | System |
| Gateway | | | +-----------+
| or |<----| | +-----------+
| Mailbox | | |<--->| Other |
| Server | | | | Mail |
+----------+ | | | System |
+----------+ +-----------+
The filtering gateway may act as an SMTP/ESMTP client
with the Recipient Gateway, or have combined functional-
ity to translate to other (non-SMTP/non-ESMTP) mail sys-
tems, or even have local delivery agents to a local
filesystem.
2. Added Verbs and Return Codes
Three verbs, and two return codes provide precise back-
ward compatibility through non-interference, while also
looking forward to better delivery status reporting.
AADDAATT functionally replaces the normal DDAATTAA verb, hence
must not be pipelined. DDRRCCPP functionally replaces the
RRCCPPTT To: verb, and EERRCCPP provides a needed end-of-recipi-
ents indication. 355 (data received, send recipients)
and 454 (undeliverable but not my failure) add to the
existing ESMTP standards.
2.1 ADAT
The ADAT verb MAY be advertised in ESMTP command exten-
sion advertisements only after this definition had
received a period of public comment. In initial testing,
it MUST utilize the X- prefix, as defined in RFC2821.
Throughout the rest of this document read X-ADAT
whereever ADAT is used. The ADAT verb when sent by
client to server MAY include an intended number of recip-
ients. If the server is not prepared to accept that many
recipients it SHOULD return a 452 Too many recipients.
The 250-ADAT verb advertisement indicates that the
receiving server is willing to delay recipient processing
until after content is received. Use of the ADAT verb by
the connected client indicates that the recipient(s) for
an upcoming message content will be delayed until after
the receiving server has had an opportunity to receive
the data. In all other respects, the ADAT verb is iden-
tical to the traditional DATA verb [RFC2821 S 4.1.1.4].
The optional count parameter for ADAT may be omitted by
the client, and is advisory-only. The server MAY return a
553 or 453 with comparable d.s.n to indicate that it
will not accept data destined in one batch for that num-
ber of recipients.
A client MUST NOT send the ADAT verb to a server in a
basic SMTP connection which was initiated with a HELO
instead of EHLO. A client MUST NOT send the ADAT verb to
a server which has not advertised the capability and
acceptance in its 250- commandlist advertisment response
to the EHLO.
A client MUST NOT send the ADAT verb before a normal MAIL
verb has been accepted.
A server which advertises for ADAT MUST return a 503 Com-
mand Sequence error for any of the following conditions:
* ADAT before EHLO
* ADAT before MAIL for this transaction
* ADAT after RCPT unless RCPT was part of previous transaction
* ADAT after DRCP unless ERCP ended that transaction.
When a 553 (or 453) with x.5.3 d.s.n is returned, the
client MAY respecify with a subset of the intended recip-
ients, or MAY respecify omitting the recipient count
advisory. In the case of a 453 4.5.3, the client may
decide to put off sending the batch, as it will not know
whether or not that number of recipients may be accepted
at another less busy time.
2.2 <CR><LF>.<CR><LF> end-of-data
As in DATA verb based transfers, the server MAY flag
integrity errors, which the client MUST accept as an
indication of a failure of the transfer.
Server MAY indicate a 554 5.7.7 Message Integrity Failure
or server failure message at end-of-data. Client MUST
accept such indicators on a by recipient basis, as well
as at this point, and SHOULD issue an RSET if a 554 5.7.7
Integrity Failure is received at end-of-data.
Server MAY NOT return a 453 4.5.3 nor 5xx 5.5.3 at end-
of-data.
The x.6.x dsn codes have the same meaning following an
ADAT body transfer as they would following a DATA body
transfer.
2.3 DRCP
The DRCP (Delayed Recipient) verb functions in post-data
(ADAT) message negotiations in an identical function to
the RCPT TO functions in the traditional (DATA based)
message negotiations. It takes the same DSN optional
parameters, and may respond with the same error rejec-
tions. In places where DRCP are used in this document
read X-DRCP if X-ADAT was used in the session, unless
otherwise stated.
Clients using X-ADAT MUST use X-DRCP for specifying
recipients for the message. Clients using ADAT MUST use
DRCP for specifying recipients. Servers MAY accept ERCP
and X-ERCP interchangably, and during an iterem conver-
sion period, advertise both ADAT and X-ADAT.
Clients MUST NOT send DRCP before ADAT has been accepted
with a 354 return, the actual message has been sent, and
the <CR><LF>.<CR><LF> end-of-data has been accepted with
a 355 2.7.0 Provisionally Accepted message.
Once the 250 is returned for a DRCP Server MUST either
accept responsability for delivery of accepted recipi-
ents, or cancel all of them at the ERCP with a 4xx or 5xx
return.
After any recipient the server may return a 453 (with dsn
4.5.3) Too Many Recipients response, even if it has
ignored a pre-ADAT advisory. Client SHOULD requeue
recipints for which a 453 is returned. The server MAY
also return a 550 (with dsn 5.5.3). Client SHOULD NOT
requeue such recipients, and submission agents may choose
to RSET the entire batch and return the appropriate error
to the sender.
When data is converted for a given recipient, that d.s.n
SHOULD be used with the 250 acceptance code.
2.4 ERCP
The ERCP (End of Recipients) verb functions in post-data
(ADAT) message negotiations in much the same way that the
<CR><LF>.<CR><LF> is used in prequalified recipient pro-
cessing. In compliance with RFC2821, only the X-ERCP may
be used until the experimental period for this protocol
extension is completed.
Clients sending X-ADAT MUST use X-ERCP. Clients sending
ADAT MUST send ERCP. Servers MAY accept ERCP and X-ERCP
interchangeably.
Server MAY return a successful recipient count in the 250
response. This is recommended, but the tracking of recip-
ients to whom it is accepted and those for whom the mes-
sage is rejected is the responsibility of the client
choosing to utilize this protocol, and MUST be done dur-
ing the DRCP negotiation phase. The recipient count
reported by the server is the number of DRCP specifica-
tions accepted, and is MUST NOT be decresed because of
locally-discarded-by-rule and MUST NOT be increased for
alias nor list expansions.
The client MAY return administrative notifications for
mismatches between the accepted DRCP count and the ERCP
count (if any) which it receives. The client SHOULD send
the number of successful DRCP recipients it is logging as
a parameter to the ERCP command.
Client MUST NOT interpret a 250 return to the ERCP to be
anything other than an acknowledgement of the end of
recipients. Server MUST NOT return recipient-dependent
status that applies only to some DRCP specified recipi-
ents in response to the ERCP.
Server MUST NOT return a 452 response to the ERCP, and
SHOULD only return a 421 in case of catastrophic failure.
The server MUST return a 451 even when variations in fil-
ter processing causes an out-of-storage condition. Once
ADAT and DRCP are accepted, the server has accepted the
message for that delivery, unless the entire batch is
rejected.
2.5 RSET before ERCP
A RSET before ERCP resets the connection to the pre-EHLO
or post-EHLO state. This is ambiguous in other docu-
ments, so remains ambiguous here as well. A client send-
ing a RSET before ERCP MUST presume that the message
related to that ERCP has not been sent to any recipients
and a server receiving an RSET before ERCP MUST NOT
deliver the message to any DRCP specified recipients
except as follows: The server MAY perform administrative
or debugging activities including delivery of the message
for oversight purposes (e.g. Postmaster Copy function)
even if that recipient was a listed DRCP recipient. In
that case the server SHOULD flag the message as specially
delivered, to avoid confusion.
Because ADAT processing produces a significantly higher
server load for busy servers, at least potentially, the
client MUST be prepared to accept unexpected 421 returns,
but also refusal of connections or refusal of services,
if it does significant probing of services by sending
ADAT based E-Mails followed by RSET or repeated ADAT
based E-Mails where there are NO acceptible DRCP recipi-
ents.
2.6 The 454 "Not my fault" temporary failure code
Consistently, SMTP has been defined as seen by a human
client imitating a submission clientware program. Clas-
sically, there have been only three temporary error
codes, which despite extended DSN encodings still are
often misinterpreted by software.
450 - is interpreted as Mailbox Busy
451 - is interpreted as a server error in processing
452 - is interpreted as a temporary space problem on the server
But another situation exists which is beyond the control
of the server and potentially the client, but which may
be expected to be corrected without hands-on correction
at either client or server. To follow standard posi-
tional encoding, this should be 454 as a non- specific
transient error which may be further defined with a d.s.n
extended encoding. Examples:
454 4.4.3 Reverse lookup service unreachable
454 4.1.8 Cannot validate senders domain
454 4.1.4 Found both SRV and MX record for sender
454 4.4.2 Forward lookup on relay-to host failed
454 4.4.4 Unable to route to relay-to host
But this 454 code is for conditions beyond the control of
the service giving the response, not local failure. For
example:
450 4.4.0 Pass-thru destination unreachable
450 4.4.1 Destination host not answering
451 4.7.0 Manditory filtering facility unavailable
450 4.4.5 Delivery services congestion
452 4.5.3 Too many recipients for single delivery.
550 5.5.3 Exceeds site policy for single message recipient count.
Thus, the 454 indicates a temporary condition that is not
truly a server failure, but a failure of the supporting
infrastructure. Until this code is adopted into the
basic ESMTP protocol, it MAY be returned in response to
end-of-data <CR><LF>.<CR><LF> end of data to DRCP and
MUST NOT be returned in response to ERCP.
2.7 Recap of ADAT based verbs
AADDAATT (or X-ADAT) may have zero-to-one parameters. That
one parameter (if present) is an ASCII string represent-
ing an integer count advisory of the number of intended
recipients.
DDRRCCPP TTOO::<local@domain> with the RCPT TO: defined in
RFC2821. Any server performing this ADAT protocol exten-
sion MUST accept the same extensions to a DRCP which it
would accept in the equivalent RCPT verb.
EERRCCPP (or X-ERCP) may have zero-to-one parameters. That
one parameter (if present) is an ASCII string represent-
ing an integer count of the number of DRCP recipients
that the client believes has been accepted by the server.
If the count is provided and the server's count of
accepted recipients does not match that number, the
server MUST return a 554 response, usually with a 5.5.0
(or optionally 5.5.3) extended status code. This return
indicates aborted delivery to all recipients.
3. Typical sessions
The following are given as typical and atypical session
illustrations:
3.1 Successful Single Recipient
R: mail.example.com ESMTP adatFilter (0.1.0/0.1.0); Sun, 18 Nov 2001 16:15:01 -0700 (MST)
S: EHLO client.example.com
R: 250-mail.eample.com Hello client.example.com [192.168.0.1], Love Ya
R: 250-250-ENHANCEDSTATUSCODES
R: 250-EXPN
R: 250-VERB
R: 250-8BITMIME
R: 250-SIZE
R: 250-DSN
R: 250-ONEX
R: 250-XUSR
R: 250-X-ADAT
R: 250 HELP
S: MAIL FROM:<luser@client.example.com>
R: 250 2.1.0 <luser@client.example.com>... Sender ok
S: X-ADAT
R: 354 Enter mail, end with "." on a line by itself
S: Date: Sun, 18 Nov 2001 16:15:01 -0700 (MST)
S: From: Louis User <luser@client.example.com>
S: To: Joe Recip <jrecip@example.com>
S: Subject: Example Message
S:
S: This is a sample advanced-data transmission message.
S: .
R: 355 2.7.0 Provisionally Accepted. Specify Recipients.
S: X-DRCP TO:<jrecip@example.com>
R: 250 2.0.0 fAINFLR00446 Message accepted for delivery
S: X-ERCP
R: 250 2.2.0 Successfully accepted for delivery to 1 recipient(s).
S: QUIT
R: 221 2.0.0 mail.example.com closing connection
3.2 Unsuccessful Single Recipient
R: mail.example.com ESMTP adatFilter (0.1.0/0.1.0); Sun, 18 Nov 2001 16:15:01 -0700 (MST)
S: EHLO client.example.com
R: 250-mail.eample.com Hello client.example.com [192.168.0.1], Love Ya
R: 250-250-ENHANCEDSTATUSCODES
R: 250-EXPN
R: 250-VERB
R: 250-8BITMIME
R: 250-SIZE
R: 250-DSN
R: 250-ONEX
R: 250-XUSR
R: 250-X-ADAT
R: 250 HELP
S: MAIL FROM:<luser@client.example.com>
R: 250 2.1.0 <luser@client.example.com>... Sender ok
S: X-ADAT 1
R: 354 Enter mail, end with "." on a line by itself
S: Date: Sun, 18 Nov 2001 16:15:01 -0700 (MST)
S: From: Louis User <luser@client.example.com>
S: To: Joe Recip <jrecip@example.com>
S: Subject: Example Message Rejection
S: MIME-Version: 1.0
S: Content-Type: multipart/mixed; BOUNDARY="0-231256789123AB=#993"
S:
S: --0-231256789123AB=#993
S: Content-Type: TEXT/plain; CHARSET=US-ASCII
S:
S: This is a sample advanced-data transmission message with
S: prohibited content.
S:
S: --0-231256789123AB=#993--
S: .
R: 355 2.7.0 Provisionally Accepted. Specify Recipients.
S: X-DRCP TO:<jrecip@example.com>
R: 554 5.7.1 <jrecip@example.com> delivery rejected by filter
S: X-ERCP
R: 250 2.2.0 Successfully accepted for delivery to 0 recipient(s).
S: QUIT
R: 221 2.0.0 mail.example.com closing connection
3.3 Protectively Filtered - Site Prohibited
R: mail.example.com ESMTP adatFilter (0.1.0/0.1.0); Sun, 18 Nov 2001 16:15:01 -0700 (MST)
S: EHLO client.example.com
R: 250-mail.eample.com Hello client.example.com [192.168.0.1], Love Ya
R: 250-250-ENHANCEDSTATUSCODES
R: 250-EXPN
R: 250-VERB
R: 250-8BITMIME
R: 250-SIZE
R: 250-DSN
R: 250-ONEX
R: 250-XUSR
R: 250-X-ADAT
R: 250 HELP
S: MAIL FROM:<luser@client.example.com>
R: 250 2.1.0 <luser@client.example.com>... Sender ok
S: X-ADAT 1
R: 354 Enter mail, end with "." on a line by itself
S: From: Louis User <luser@client.example.com>
S: Subject: Example Message Rejection
S: X-MSMail-Priority: Normal
S: X-Priority: 3
S: X-Mailer: Microsoft Outlook Express 5.00.2919.6600
S: MIME-Version: 1.0
S: Content-Type: multipart/mixed;
S: boundary="----=_NextPart_000_00B7_010B9FBF.A7AFBF00"
S: Content-Transfer-Encoding: 7bit
S: Message-Id: <20010919045807.809B7280E6@lethal.example.com>
S: Date: Sun, 18 Nov 2001 16:15:01 -0700 (MST)
S: To: undisclosed-recipients:;
S:
S: This is a multi-part message in MIME format.
S:
S: ------=_NextPart_000_00B7_010B9FBF.A7AFBF00
S: Content-Type: text/plain; charset=ISO-8859-1
S: Content-Transfer-Encoding: 7bit
S:
S: The amount indicated in the invoice as per instructions contained
S: therein. Good will be forwarded immediately upon receipt of payment.
S: We thank you for your interest in our products and take this
S: opportunity to send our best regards.
S: ------=_NextPart_000_00B7_010B9FBF.A7AFBF00
S: Content-Type: application/octet-stream; name="CFGWIZ32.EXE"
S: Content-Transfer-Encoding: base64
S: Content-Disposition: attachment; filename="CFGWIZ32.EXE"
S:
S: TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQA ...
S: B0AGEAcgB0ACAAeQBvAHUAcgAgAHMAeQBzAHQAZQBtACAAYgBlAGYAbwA=
S:
S:
S: ------=_NextPart_000_00B7_010B9FBF.A7AFBF00--
S: .
R: 554 5.7.1 Prohibited content detected. Do not re-attempt delivery!
S: QUIT
R: 221 2.0.0 mail.example.com closing connection
3.4 Content-Filtered for Specified Recipients
R: mail.example.com ESMTP adatFilter (0.1.0/0.1.0); Sun, 18 Nov 2001 16:15:01 -0700 (MST)
S: EHLO client.example.com
R: 250-mail.eample.com Hello client.example.com [192.168.0.1], Love Ya
R: 250-250-ENHANCEDSTATUSCODES
R: 250-EXPN
R: 250-VERB
R: 250-8BITMIME
R: 250-SIZE
R: 250-DSN
R: 250-ONEX
R: 250-XUSR
R: 250-X-ADAT
R: 250 HELP
S: MAIL FROM:<luser@client.example.com>
R: 250 2.1.0 <luser@client.example.com>... Sender ok
S: X-ADAT 1
R: 354 Enter mail, end with "." on a line by itself
S: From: Louis User <luser@client.example.com>
S: Subject: Example Message Rejection
S: X-Priority: 1
S: MIME-Version: 1.0
S: Content-Type: text/html
S: Content-Transfer-Encoding: 7bit
S: Message-Id: <200104290024359.SM00856@spamdomain.example.com>
S:
S: <html>
S:
S: <head>
S: <meta http-equiv="Content-Type" content="text/html;
S: charset=windows-1252">
S: <meta name="GENERATOR" content="Microsoft FrontPage 4.0">
S: <meta name="ProgId" content="FrontPage.Editor.Document">
S: <title>SERVICIO DE ENVIO DE EMAIL Le ofrecemos realizar nosotros
S: el envio de lo que quiera promocionar</title>
S: <bgsound
S: src="http://www.genesis-midi.com/midis/genesis/invisibletouch.mid"
S: loop ="2">
S: </head>
S:
S: <body
S: background="http://www.geocities.com/~lollydolly/pic/flowerb1.jpg">
S: ...
S: </html>
S: .
R: 355 2.7.0 Provisionally Accepted. Specify Recipients.
S: X-DRCP TO:<jrecip@example.com>
R: 554 5.7.1 <jrecip@example.com> delivery rejected by filter
S: X-DRCP TO:<postmaster>
R: 250 2.0.0 <postmaster>... Ok
S: X-ERCP
R: 250 2.2.0 Successfully accepted for delivery to 1 recipient(s).
S: QUIT
R: 221 2.0.0 mail.example.com closing connection
4. Send/Response map
This section is intended as a reference extending section
4.3.2 of RFC2821.
CONNECTION ESTABLISHMENT
S: 220
F: 421
E: 554
EHLO or HELO
S: 250
E: 504, 550
MAIL
S: 250
E: 552, 451, 452, 550, 553, 503
ADAT
S: 354 -> data -> S: 355
F: 552, 554, 421, 451, 452, 454
E: 502, 552, 421, 451, 452, 454, 550, 553, 503
DRCP TO:
S: 250, 251
F: 550, 551, 552, 553, 450, 451, 452
E: 500, 501, 503, 504, 554, 421, 454
ERCP
S: 250
F: 500, 501, 554, 421
5. Domain indication of ADAT support
Documents and standards specifying Domain Name Service MX
records, and those specifying SRV (Service Provider) sup-
port in the Domain Name Service leave a gap for implemen-
tation of "non-standard" ports for additional service
provisions. Any RFC2821 compliant ESMTP server running
on the default MX port (25) or the "submission" service
port (587) MAY advertise ADAT support in its EHLO 250
response group. In addition a domain may advertise which
servers support ADAT by appending the ADAT verb to the
service name, with a dash (ASCII "-") in a SRV record,
such as "esmtp-adat" for public delivery, or "submission-
adat".
"Submission" ports on advertised addresses may be
expected to require STARTTLS with client certification,
or SMTP-AUTH [RFC2554] or similar extensions. Clients
intending to use ADAT with authorization MUST authorize
(and/or STARTTLS) before issuing any MAIL verbs which
will be used with an ADAT directive. The entire transac-
tion then procedes under that authorization (and likely
encrypted tunnel). Filtering gateways which communicate
with delivery services via SMTP would normally safeguard
that with the STARTTLS [RFC2487] extension, as well.
6. Source Route Filters and other Filters
A client accepting the invitaiton to use the
ADAT/DRCP/ERCP protocol accepts other restrictions upon
delivery imposed by the gateway filter. There may be no
information as to what other mailsystem the filter is a
gateway to. The output of the gateway may also be (for
example) STARTTLS based ESMTP to destination delivery
hosts.
RFC2821 extends RFC1123 source routing specification to
indicate that a server MAY ignore the routes. ADAT
servers should be presumed to ignore the routes.
RFC2821 lists #-literals (section F.4) as deprecated.
DRCP verb processors MUST reject all addressees specified
by an integer host number, just as RFC2821 specifies
rejection.
7. Manditory Disclaimers
The IETF takes no position regarding the validity or
scope of any intellectual property or other rights that
might be claimed to pertain to the implementation or use
of the technology described in this document or the
extent to which any license under such rights might or
might not be available; neither does it represent that it
has made any effort to identify any such rights. Infor-
mation on the IETF's procedures with respect to rights in
standards-track and standards-related documentation can
be found in BCP-11. Copies of claims of rights made
available for publication and any assurances of licenses
to be made available, or the result of an attempt made to
obtain a general license or permission for the use of
such proprietary rights by implementors or users of this
specification can be obtained from the IETF Secretariat
The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications,
or other proprietary rights which may cover technology
that may be required to practice this standard. Please
address the information to the IETF Executive Director.
Full license is granted to The Internet Society as if
this document were created as a work for hire for the
ISOC, except that such grant shall not deminish the right
of the original author to publish and distribute the
work.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on
or otherwise explain it or assist in its implmentation
may be prepared, copied, published and distributed, in
whole or in part, without restriction of any kind, pro-
vided that the above copyright notice and this paragraph
are included on all such copies and derivative works.
However, this document itself may not be modified in any
way, such as by removing the copyright notice or refer-
ences to the Internet Society or other Internet organiza-
tions, except as needed for the purpose of developing
Internet standards in which case the procedures for copy-
rights defined in the Internet Standards process must be
followed, or as required to translate it into languages
other than English.
The limited permissions to and through The Internet Soci-
ety granted above are perpetual and will not be revoked
by the Internet Society or its successors or assigns, nor
by the author.
This document and the information contained herein is
provided on an "AS IS" basis and the author and THE
INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE."
8. Security Considerations
Security issues are not fully discussed in this memo.
Mention of elevated security uses of the [E]SMTP protocol
is for consideration of interoperability. It is the
belief of the author that use as defined above in the
initial draft will have no security significant consider-
ations which are not already present in ESMTP negotia-
tions which do not utilize the ADAT/DRCP/ERCP extension,
but "delay checks" until end-of-data.
9. Author Contact
Comments may be addressed to
<bgingery-adat-draft@gtcs.com>
A. References
STD0060/RFC2920 SMTP Service Extension for Command Pipelining
STD0010/RFC0821 Simple Mail Transfer Protocol
RFC3030 SMTP Service Extensions for Transmission of Large
and Binary MIME Messages
RFC2852 Deliver By SMTP Service Extension
RFC2821 Simple Mail Transfer Protocol
RFC2645 On-Demand Mail Relay (ODMR) SMTP Wth Dynamic IP
RFC2554 SMTP Service Extension for Authentication
BCP0030 Anti-Spam Recommendations for SMTP MTAs
RFC2487 SMTP Service Extension for Secure SMTP over TLS
RFC2476 Message Submission
RFC2442 The Batch SMTP Media Type
RFC2197 SMTP Service Extension for Command Pipelining
RFC2034 SMTP Service Extension for Returning Enhanced
Error Codes
RFC2033 Local Mail Transfer Protocol
RFC1893 Enhanced Mail System Status Codes
RFC1891 SMTP Service Extension for Delivery Status Notifications
STD0010/RFC1870 SMTP Service Extension for Message Size Declaration
STD0010/RFC1869 SMTP Service Extensions
RFC1854 SMTP Service Extension for Command Pipelining
RFC1846 SMTP 521 Reply Code
RFC1845 SMTP Service Extension for Checkpoint/Restart
RFC1652 SMTP Service Extension for 8bit-MIMEtransport
RFC1405 Mapping between X.400(1984/1988) and Mail-11