WDIFF

draft-gellens-submit-01.txt --> draft-gellens-submit-02.txt

view Side-By-Side changes

Internet Draft H. Alvestrand and R. Gellens, Authors

Expires 28 February 22 May 1997 R. Gellens, Editor
28 August,

22 November, 1996
draft-gellens-smtp-submit-01.txt

draft-gellens-submit-02.txt

SMTP Extension for Message Submission/Relay Submission and Relay

Status of this Memo:

This draft document is being circulated for comment.

Please send comments to the IETF SMTP mailing list,

<ietf-smtp@list.cren.net>. To subscribe, send a message containing

SUBSCRIBE IETF-SMTP to <listproc@listproc.net>.

The following text is required by the Internet-draft rules:

This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by

other documents at any time. It is not appropriate to use

Internet Drafts as reference material or to cite them other than

as a "working draft" or "work in progress."

To learn the current status of any Internet Draft, please check the

"1id-abstracts.txt" listing contained in the Internet Drafts

shadow directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),

munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or

ftp.isi.edu (US West Coast).

The file name of this version is draft-gellens-smtp-submit-01.txt draft-gellens-submit-02.txt

1. Introduction

SMTP was defined as a message *relay* protocol, that is, a means for

message transfer agents (MTAs) to route finished (complete)

messages. SMTP forbids MTAs from altering the message text, except

to add Received headers.

Alvestrand, Gellens Expires February May 1997 [Page 1]
Internet Draft Submit SMTP August Submission November 1996

to add Received headers.

However, SMTP is now also widely used as a message *submission*

protocol, that is, a means for message user agents (MUAs) to

introduce new messages into the MTA routing network. Regardless of

whether this is good or bad, it is far too late to change.

Messages being submitted are in some cases finished (complete)

messages, and in other cases are unfinished (incomplete) in some

aspect or other. Unfinished (incomplete) messages need to be

completed to ensure they conform to [RFC-822], [RFC-1123], and later

requirements. For example, the message may lack proper Date or

Message-ID headers, and domains might not be fully qualified. In

some cases, the MUA may be unable to generate finished (complete)

messages (for example, it might not know its time zone). Even when

submitted messages are finished (complete), local site policy may

dictate that the message text be modified in some ways. Such

completions or modifications violate the letter and spirit of SMTP

when used as a relay protocol.

This memo proposes a low cost, deterministic means for an MTA messages to be
informed how

identified as submissions or relays.

2. SUBMIT Servers

To distinguish relay SMTP from submission, port XXXX is being reserved as the

SMTP SUBMIT port. Messages received on this port are assumed to be

submissions, even though the protocol used (submission or relay mode).

2. is otherwise SMTP.

However, in lieu of using this port, it may in certain cases be preferred

to use the standard SMTP port (port 25) on a system dedicated for and

known to be a SUBMIT server. When this is done, the SUBMIT server MUST

NOT be listed as an MX record for any domain. Additionally, the SUBMIT

server SHOULD verify that it is not configured as a normal SMTP server;

when the MTA receives a mail message with a RCPT TO, it SHOULD query

the DNS to verify that its IP address is not listed in any MX record for

the domain specified in the RCPT TO command. If there are no MX records

for that domain, the MTA SHOULD verify that its IP address is not

listed in any A records for that domain. If either verification fails,

the RCPT TO SHOULD be rejected, unless the local-part is "Postmaster"

(case insensitive) and it knows where to forward postmaster mail.

3. SMTP Extension for Message Submission or Relay

The name of this extension [ESMTP] is "Message Mode". "Relay".

The EHLO keyword is MODE. RELAY.

One new optional parameter is defined for the MAIL FROM verb: MODE. It has
a required value, which must be either SUBMIT or RELAY.

If SUBMIT RELAY is used with the MAIL FROM command, the message is to be

treated as a submission. relay. If RELAY is used, appears in MAIL FROM for a message

received on the SUBMIT port, the message is to MUST NOT be treated as a relay.

In addition to supporting

Alvestrand, Gellens Expires May 1997 [Page 2]
Internet Draft SMTP Submission November 1996

submission; the MODE extension, an MTA MAY choose to
receive messages on an additional port, port X. If so, all messages
received using port X are to be treated can either treat it as submissions. This is for a relay or reject

the benefit of clients which do MAIL FROM command with 504. (Although 504 is not use EMSTP but which listed in RFC

821 as a valid failure response to MAIL FROM, it seems to make the

most sense, although cases can be
easily configured to use a port other than 25. made for 521 and 554).

If neither SUBMIT nor RELAY is was not used, and the message was received on the standard

SMTP port (port 25), the MTA may either unconditionally treat the message as a

relay, or use the guidelines in section 6 8 to determine if the message

is a submission or a relay.

Alvestrand, Gellens Expires February 1997 [Page 2]

Internet Draft Submit SMTP August 1996

4. Actions when RELAY Is Used

If the MAIL FROM line has the RELAY parameter, the MTA is being

informed that this message is being relayed, and therefore the

letter and spirit of SMTP MUST be followed. The MTA MUST not NOT

alter the text, except to add a Received header.

The MTA MAY choose to implement message rejection rules which rely
in part on whether the message is a submission or a relay. For
example, some sites might configure their MTA to reject all RCPT TOs
for messages being relayed which do not reference local users.

5. Actions when the Message Is a Submission

The following things MUST be done by an the MTA if the message is a

submission:

(1) Ensure all domains (in the envelope as well as the text)

are fully-qualified.

The following things MAY be done by an the MTA if the message is a

submission:

(1) Refuse the MAIL FROM command if the address in MAIL FROM is

not believed to have submission right at this MTA, rights, or is invalid.

Failure code 554 should be used for this purpose.

(2) Refuse the DATA command or send a failure result after

end-of-data if the submitted message is syntactically

invalid, or seems inconsistent with permissions given to

the user (if known). Result code 554 should be used.

(3) Add a 'Sender' field to the submitted message, if it knows the

identity of the sender is known and this is not given in

the 'From' field.

(4) Add a 'Date' field to the submitted message, if it lacks it.

(5) Correct the 'Date' field if it does not conform to [RFC-822]

syntax (as modified by [RFC-1123]).

(6) Add a 'Message-ID' field to the submitted message, if it

lacks it.

(7) Transfer encode the message according to MIME conventions,

if desirable and needed needed.

Alvestrand, Gellens Expires May 1997 [Page 3]
Internet Draft SMTP Submission November 1996

(8) Resolve aliases (CNAME records) for domain names, in the

envelope as well as the text, subject to local policy. For

Alvestrand, Gellens Expires February 1997 [Page 3]

Internet Draft Submit SMTP August 1996

example, if www.ab.com and ftp.ab.com are both aliases for

mail.ab.com, rewriting them could lose useful information.

(9) Rewrite local parts, parts and/or domains, according to local

policy. For example, a site may prefer to rewrite JRU 'JRU' as J.Random.User

'J.Random.User' in order to hide logon names.

(10) Add a 'Content-MD5' field names, and/or to the submitted message, if

rewrite 'squeeky.sales.xyz.com' as 'zyx'com' to hide machine

names and make it
lacks it. easier to move users.

If an the MTA treats a message as a submission (see also section 6) 8) and

modifies its text in any way as a result, it SHOULD document all

such alterations by one or more of the following:

(1) Add a comment to each added or altered field, of the form

"(added/corrected by MTA <domainname>)".

(2) Add a 'Comments' field which lists what alterations were

made, the reason why each was done, and the domain name of

the MTA.

6. Interaction with Other SMTP Extensions

The SMTP [AUTH] extension, if supported and used, may allow the MTA

to determine the identity of the submitting user.

7. Message Rejection

The MTA MAY choose to implement message rejection rules which rely

in part on whether the message is a submission or a relay. For

example, some sites might configure their MTA to reject all RCPT TOs

for messages being relayed which do not reference local users, and/or

to reject all message submissions which do not come from local users

(based on IP address and/or authenticated identity).

The MTA may be unable to comply with the requirements for relaying

a submitted message. For example, the domain names in the message

headers and/or envelope might be unqualified and either unknown or

ambiguous, preventing the MTA from qualifying them. If the MTA

is able to determine a return path to the submitting user (from a valid

MAIL FROM, or based on authenticated identify), the MTA may either

reject the message immediately, or accept it and issue a bounce. If

the MTA is not able to determine a return path to the submitting

user, it MUST immediately reject messages which it is unable to relay.

A message can be immediately rejected by returning 554 to the MAIL FROM

command or after receiving the final period.

Alvestrand, Gellens Expires May 1997 [Page 4]
Internet Draft SMTP Submission November 1996

8. Possible Other Cases for Treating Messages as Submissions

For backwards compatibility with older mailers and MTAs, the MTA MAY

consider the message a submission, and treat it as above, under some

combinations of the following circumstances:

(1) The message lacks any 'Received' fields.

(2) The message comes from a host known to the MTA as being a

"pure client", such as a PC.

(3) The message lacks a 'Date' field.

(4) The MTA knows that all of its messages are submissions. For

example, an MTA and all clients might be configured so that

all submissions go through the that MTA, and only submissions go

through that MTA.

Alvestrand, Gellens Expires February 1997 [Page 4]

Internet Draft Submit SMTP August 1996

9. Security Considerations

Security issues are not considered in this memo.

10. Acknowledgements

This updated draft has been revised in part based on comments and

discussions which took place on and off the IETF-SMTP mailing list.

11. References

[AUTH]

J. Myers, "Internet Draft: SMTP Authentication", Carnegie

Mellon, draft-myers-smtp-auth-02.txt, January draft-myers-smtp-auth-04.txt, November 1996, work in

progress.

[ESMTP]

Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,

"SMTP Service Extensions", RFC 1869, STD 10, United Nations

University, Innosoft International, Inc., Dover Beach Consulting,

Inc., Network Management Associates, Inc., The Branch Office,

November 1995

[RFC-822]

D. Crocker, "Standard for the format of ARPA Internet text

messages", RFC 822, STD 11, University of Delaware, 08/13/1982

[RFC-1123]

R. Braden, Editor, "Requirements for Internet Hosts --

Application and Support", RFC 1123, USC/Information Sciences

Alvestrand, Gellens Expires May 1997 [Page 5]
Internet Draft SMTP Submission November 1996

Institute, October 1989

[SMTP]

J. Postel, "Simple Mail Transfer Protocol", RFC 821, STD 10,

Information Sciences Institute, 08/01/1982

12. Authors' Addresses

Harald Tveit Alvestrand +47 73 59 70 94

UNINETT Harald.T.Alvestrand@uninett.no

P.O.Box 6883 Elgeseter

N-7002 TRONDHEIM

NORWAY

Randall Gellens +1.714.380.6350

Alvestrand, Gellens Expires February 1997 [Page 5]

Internet Draft Submit SMTP August 1996

Unisys Corporation +1.714.380.5912 +1.619.651.5115

Qualcomm, Inc. +1.619.658.1560 (fax)
25725 Jeronimo Road Randy.Gellens@MV.Unisys.Com
Mail Stop 237
Mission Viejo,

6455 Lusk Blvd. Randy@Qualcomm.Com

San Diego, CA 92651 92121

U.S.A.

Alvestrand, Gellens Expires February May 1997 [Page 6]

----