7Network Working Group R. Gellens
8Request for Comments: 4409 QUALCOMM
9Obsoletes: 2476 J. Klensin
10Category: Standards Track April 2006
13 Message Submission for Mail
17 This document specifies an Internet standards track protocol for the
18 Internet community, and requests discussion and suggestions for
19 improvements. Please refer to the current edition of the "Internet
20 Official Protocol Standards" (STD 1) for the standardization state
21 and status of this protocol. Distribution of this memo is unlimited.
25 Copyright (C) The Internet Society (2006).
29 This memo splits message submission from message relay, allowing each
30 service to operate according to its own rules (for security, policy,
31 etc.), and specifies what actions are to be taken by a submission
34 Message relay and final delivery are unaffected, and continue to use
37 When conforming to this document, message submission uses the
38 protocol specified here, normally over port 587.
40 This separation of function offers a number of benefits, including
41 the ability to apply specific security or policy requirements.
58Gellens & Klensin Standards Track [Page 1]
60RFC 4409 Message Submission for Mail April 2006
65 1. Introduction ....................................................3
66 2. Document Information ............................................4
67 2.1. Definitions of Terms Used in This Memo .....................4
68 2.2. Conventions Used in This Document ..........................5
69 3. Message Submission ..............................................5
70 3.1. Submission Identification ..................................5
71 3.2. Message Rejection and Bouncing .............................5
72 3.3. Authorized Submission ......................................6
73 4. Mandatory Actions ...............................................7
74 4.1. General Submission Rejection Code ..........................7
75 4.2. Ensure All Domains Are Fully-Qualified .....................7
76 4.3. Require Authentication .....................................8
77 5. Recommended Actions .............................................8
78 5.1. Enforce Address Syntax .....................................8
79 5.2. Log Errors .................................................8
80 6. Optional Actions ................................................9
81 6.1. Enforce Submission Rights ..................................9
82 6.2. Enforce Permissions ........................................9
83 6.3. Check Message Data .........................................9
84 6.4. Support for the Postmaster Address .........................9
85 7. Interaction with SMTP Extensions ...............................10
86 8. Message Modifications ..........................................11
87 8.1. Add 'Sender' ..............................................11
88 8.2. Add 'Date' ................................................11
89 8.3. Add 'Message-ID' ..........................................11
90 8.4. Transfer Encode ...........................................11
91 8.5. Sign the Message ..........................................11
92 8.6. Encrypt the Message .......................................12
93 8.7. Resolve Aliases ...........................................12
94 8.8. Header Rewriting ..........................................12
95 9. Security Considerations ........................................12
96 10. IANA Considerations ...........................................13
97 11. Acknowledgements ..............................................13
98 12. Normative References ..........................................14
99 13. Informative References ........................................14
114Gellens & Klensin Standards Track [Page 2]
116RFC 4409 Message Submission for Mail April 2006
121 SMTP was defined as a message *transfer* protocol, that is, a means
122 to route (if needed) and deliver finished (complete) messages.
124 Message Transfer Agents (MTAs) are not supposed to alter the message
125 text, except to add 'Received', 'Return-Path', and other header
126 fields as required by [SMTP-MTA].
128 However, SMTP is now also widely used as a message *submission*
129 protocol, that is, a means for Message User Agents (MUAs) to
130 introduce new messages into the MTA routing network. The process
131 that accepts message submissions from MUAs is termed a Message
132 Submission Agent (MSA).
134 In order to permit unconstrained communications, SMTP is not often
135 authenticated during message relay.
137 Authentication and authorization of initial submissions have become
138 increasingly important, driven by changes in security requirements
139 and rising expectations that submission servers take responsibility
140 for the message traffic they originate.
142 For example, due to the prevalence of machines that have worms,
143 viruses, or other malicious software that generate large amounts of
144 spam, many sites now prohibit outbound traffic on the standard SMTP
145 port (port 25), funneling all mail submissions through submission
148 In addition to authentication and authorization issues, messages
149 being submitted are in some cases finished (complete) messages, and
150 in other cases are unfinished (incomplete) in one or more aspects.
151 Unfinished messages may need to be completed to ensure they conform
152 to [MESSAGE-FORMAT], and later requirements. For example, the
153 message may lack a proper 'Date' header field, and domains might not
154 be fully qualified. In some cases, the MUA may be unable to generate
155 finished messages (e.g., it might not know its time zone). Even when
156 submitted messages are complete, local site policy may dictate that
157 the message text be examined or modified in some way, e.g., to
158 conceal local name or address spaces. Such completions or
159 modifications have been shown to cause harm when performed by
160 downstream MTAs -- that is, MTAs after the first-hop submission MTA
161 -- and are in general considered to be outside the province of
162 standardized MTA functionality.
164 Separating messages into submissions and transfers allows developers
165 and network administrators to more easily do the following:
170Gellens & Klensin Standards Track [Page 3]
172RFC 4409 Message Submission for Mail April 2006
175 * Implement security policies and guard against unauthorized mail
176 relaying or injection of unsolicited bulk mail
178 * Implement authenticated submission, including off-site submission
179 by authorized users such as travelers
181 * Separate the relevant software code differences, thereby making
182 each code base more straightforward and allowing for different
183 programs for relay and submission
185 * Detect configuration problems with a site's mail clients
187 * Provide a basis for adding enhanced submission services in the
190 This memo describes a low-cost, deterministic means for messages to
191 be identified as submissions, and specifies what actions are to be
192 taken by a submission server.
1942. Document Information
1962.1. Definitions of Terms Used in This Memo
198 Many of the concepts and terms used in this document are defined in
199 [SMTP-MTA]; familiarity with those documents is assumed here.
203 Containing or consisting of a domain that can be globally resolved
204 using the Domain Name Service; that is, not a local alias or partial
207 Message Submission Agent (MSA)
209 A process that conforms to this specification. An MSA acts as a
210 submission server to accept messages from MUAs, and either delivers
211 them or acts as an SMTP client to relay them to an MTA.
213 Message Transfer Agent (MTA)
215 A process that conforms to [SMTP-MTA]. An MTA acts as an SMTP server
216 to accept messages from an MSA or another MTA, and either delivers
217 them or acts as an SMTP client to relay them to another MTA.
226Gellens & Klensin Standards Track [Page 4]
228RFC 4409 Message Submission for Mail April 2006
231 Message User Agent (MUA)
233 A process that acts (often on behalf of a user and with a user
234 interface) to compose and submit new messages, and process delivered
237 For delivered messages, the receiving MUA may obtain and process the
238 message according to local conventions or, in what is commonly
239 referred to as a split-MUA model, Post Office Protocol [POP3] or IMAP
240 [IMAP4] is used to access delivered messages, whereas the protocol
241 defined here (or SMTP) is used to submit messages.
2432.2. Conventions Used in This Document
245 In examples, "C:" is used to indicate lines sent by the client, and
246 "S:" indicates those sent by the server. Line breaks within a
247 command example are for editorial purposes only.
249 Examples use the 'example.net' domain.
251 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
252 in this document are to be interpreted as defined in [KEYWORDS].
2563.1. Submission Identification
258 Port 587 is reserved for email message submission as specified in
259 this document. Messages received on this port are defined to be
260 submissions. The protocol used is ESMTP [SMTP-MTA, ESMTP], with
261 additional restrictions or allowances as specified here.
263 Although most email clients and servers can be configured to use port
264 587 instead of 25, there are cases where this is not possible or
265 convenient. A site MAY choose to use port 25 for message submission,
266 by designating some hosts to be MSAs and others to be MTAs.
2683.2. Message Rejection and Bouncing
270 MTAs and MSAs MAY implement message rejection rules that rely in part
271 on whether the message is a submission or a relay.
273 For example, some sites might configure their MTAs to reject all RCPT
274 commands for messages that do not reference local users, and
275 configure their MSA to reject all message submissions that do not
276 come from authorized users, with authorization based either on
277 authenticated identity or the submitting endpoint being within a
278 protected IP environment.
282Gellens & Klensin Standards Track [Page 5]
284RFC 4409 Message Submission for Mail April 2006
287 NOTE: It is better to reject a message than to risk sending one that
288 is damaged. This is especially true for problems that are
289 correctable by the MUA, for example, an invalid 'From' field.
291 If an MSA is not able to determine a return path to the submitting
292 user, from a valid MAIL FROM, a valid source IP address, or based on
293 authenticated identity, then the MSA SHOULD immediately reject the
294 message. A message can be immediately rejected by returning a 550
295 code to the MAIL command.
297 Note that a null return path, that is, MAIL FROM:<>, is permitted and
298 MUST NOT in itself be cause for rejecting a message. (MUAs need to
299 generate null return-path messages for a variety of reasons,
300 including disposition notifications.)
302 Except in the case where the MSA is unable to determine a valid
303 return path for the message being submitted, text in this
304 specification that instructs an MSA to issue a rejection code MAY be
305 complied with by accepting the message and subsequently generating a
306 bounce message. (That is, if the MSA is going to reject a message
307 for any reason except being unable to determine a return path, it can
308 optionally do an immediate rejection or accept the message and then
311 NOTE: In the normal case of message submission, immediately
312 rejecting the message is preferred, as it gives the user and MUA
313 direct feedback. To properly handle delayed bounces, the client MUA
314 needs to maintain a queue of messages it has submitted, and match
315 bounces to them. Note that many contemporary MUAs do not have this
3183.3. Authorized Submission
320 Numerous methods have been used to ensure that only authorized users
321 are able to submit messages. These methods include authenticated
322 SMTP, IP address restrictions, secure IP and other tunnels, and prior
325 Authenticated SMTP [SMTP-AUTH] has seen widespread deployment. It
326 allows the MSA to determine an authorization identity for the message
327 submission, one that is not tied to other protocols.
329 IP address restrictions are very widely implemented, but do not allow
330 for travelers and similar situations, and can be easily spoofed
331 unless all transport paths between the MUA and MSA are trustworthy.
338Gellens & Klensin Standards Track [Page 6]
340RFC 4409 Message Submission for Mail April 2006
343 Secure IP [IPSEC], and other encrypted and authenticated tunneling
344 techniques, can also be used and provide additional benefits of
345 protection against eavesdropping and traffic analysis.
347 Requiring a POP [POP3] authentication (from the same IP address)
348 within some amount of time (e.g., 20 minutes) prior to the start of a
349 message submission session has also been used, but this does impose
350 restrictions on clients as well as servers, which may cause
351 difficulties. Specifically, the client must do a POP authentication
352 before an SMTP submission session, and not all clients are capable
353 and configured for this. Also, the MSA must coordinate with the POP
354 server, which may be difficult. There is also a window during which
355 an unauthorized user can submit messages and appear to be a
356 previously authorized user. Since it is dependent on the MUA's IP
357 addresses, this technique is substantially as subject to IP address
358 spoofing as validation based on known IP addresses alone (see above).
362 An MSA MUST do all of the following:
3644.1. General Submission Rejection Code
366 Unless covered by a more precise response code, response code 554 is
367 to be used to reject a MAIL, RCPT, or DATA command that contains
3704.2. Ensure All Domains Are Fully-Qualified
372 The MSA MUST ensure that all domains in the SMTP envelope are fully-
375 If the MSA examines or alters the message text in any way, except to
376 add trace header fields [SMTP-MTA], it MUST ensure that all domains
377 in address header fields are fully-qualified.
379 Reply code 554 is to be used to reject a MAIL, RCPT, or DATA command
380 that contains improper domain references.
382 A frequent local convention is to accept single-level domains (e.g.,
383 'sales') and then to expand the reference by adding the remaining
384 portion of the domain name (e.g., to 'sales.example.net'). Local
385 conventions that permit single-level domains SHOULD reject, rather
386 than expand, incomplete multi-level domains (e.g., 'squeaky.sales'),
387 since such expansion is particularly risky.
394Gellens & Klensin Standards Track [Page 7]
396RFC 4409 Message Submission for Mail April 2006
3994.3. Require Authentication
401 The MSA MUST by default issue an error response to the MAIL command
402 if the session has not been authenticated using [SMTP-AUTH], unless
403 it has already independently established authentication or
404 authorization (such as being within a protected subnetwork).
406 Section 3.3 discusses authentication mechanisms.
408 Reply code 530 [SMTP-AUTH] is used for this purpose.
4105. Recommended Actions
412 The MSA SHOULD do all of the following:
4145.1. Enforce Address Syntax
416 An MSA SHOULD reject messages with illegal syntax in a sender or
417 recipient SMTP envelope address.
419 If the MSA examines or alters the message text in way, except to add
420 trace header fields, it SHOULD reject messages with illegal address
421 syntax in address header fields.
423 Reply code 501 is to be used to reject a MAIL or RCPT command that
424 contains a detectably improper address.
426 When addresses are resolved after submission of the message body,
427 reply code 554 (with a suitable enhanced status code from
428 [SMTP-CODES]) is used after end-of-data, if the message contains
429 invalid addresses in the header.
433 The MSA SHOULD log message errors, especially apparent
434 misconfigurations of client software.
436 It can be very helpful to notify the administrator when problems are
437 detected with local mail clients. This is another advantage of
438 distinguishing submission from relay: system administrators might be
439 interested in local configuration problems, but not in client
440 problems at other sites.
442 Note that it is important to impose limits on such logging to prevent
443 certain forms of denial of service (DoS) attacks.
450Gellens & Klensin Standards Track [Page 8]
452RFC 4409 Message Submission for Mail April 2006
457 The MSA MAY do any of the following:
4596.1. Enforce Submission Rights
461 The MSA MAY issue an error response to a MAIL command if the address
462 in MAIL FROM appears to have insufficient submission rights, or is
463 not authorized with the authentication used (if the session has been
466 Reply code 550 with an appropriate enhanced status code per
467 [SMTP-CODES], such as 5.7.1, is used for this purpose.
4696.2. Enforce Permissions
471 The MSA MAY issue an error response to a RCPT command if inconsistent
472 with the permissions given to the user (if the session has been
475 Reply code 550 with an appropriate enhanced status code per
476 [SMTP-CODES], such as 5.7.1, is used for this purpose.
4786.3. Check Message Data
480 The MSA MAY issue an error response to the DATA command or send a
481 failure result after end-of-data if the submitted message is
482 syntactically invalid, or seems inconsistent with permissions given
483 to the user (if known), or violates site policy in some way.
485 Reply code 554 is used for syntactic problems in the data. Reply
486 code 501 is used if the command itself is not syntactically valid.
487 Reply code 550 with an appropriate enhanced status code per
488 [SMTP-CODES] (such as 5.7.1) is used to reject based on the
489 submitting user. Reply code 550 with an appropriate enhanced status
490 code (such as 5.7.0) is used if the message violates site policy.
4926.4. Support for the Postmaster Address
494 If appropriate under local conditions and to facilitate conformance
495 with the "postmaster" requirements of [SMTP-MTA], the MSA MAY permit
496 a reduced degree of authentication for mail addressed to the
497 "postmaster" (or one of its alternate spelling forms, see
498 [SMTP-MTA]), in one or more domains, as compared to requirements
499 enforced for other addresses. Among other benefits, this provides an
500 address of last resort that can be used by authorized users to report
501 problems that otherwise prevent them from submitting mail.
506Gellens & Klensin Standards Track [Page 9]
508RFC 4409 Message Submission for Mail April 2006
5117. Interaction with SMTP Extensions
513 The following table lists the current standards-track and
514 Experimental SMTP extensions. Listed are the EHLO keyword, name, an
515 indication as to the use of the extension on the submit port, and a
518Keyword Name Submission Reference
519---------- -------------------------- ---------- ----------------
520PIPELINING Pipelining SHOULD [PIPELINING]
521ENHANCEDSTATUSCODES Enhanced Status Codes SHOULD [CODES-EXTENSION]
522ETRN Extended Turn MUST NOT [ETRN]
523 ... Extended Codes SHOULD [SMTP-CODES]
524DSN Delivery Status Notification SHOULD [DSN]
525SIZE Message size MAY [SIZE]
526 ... 521 reply code MUST NOT [521REPLY]
527CHECKPOINT Checkpoint/Restart MAY [CHECKPOINT]
528BINARYMIME Binary MIME MAY [CHUNKING]
529CHUNKING Chunking MAY [CHUNKING]
5308BITMIME Use 8-bit data SHOULD [8BITMIME]
531AUTH Authentication MUST [SMTP-AUTH]
532STARTTLS Start TLS MAY [Start-TLS]
533NO-SOLICITING Notification of no soliciting MAY [Msg-Track]
534MTRK Message Tracking MAY [Msg-Track]
536 Future SMTP extensions SHOULD explicitly specify if they are valid on
539 Some SMTP extensions are especially useful for message submission:
541 Extended Status Codes [SMTP-CODES] SHOULD be supported and used
542 according to [CODES-EXTENSION]. This permits the MSA to notify the
543 client of specific configuration or other problems in more detail
544 than the response codes listed in this memo. Because some rejections
545 are related to a site's security policy, care should be used not to
546 expose more detail to unauthenticated senders than is needed
548 [PIPELINING] SHOULD be supported by the MSA.
550 [SMTP-AUTH] allows the MSA to validate the authority and determine
551 the identity of the submitting user and MUST be supported by the MSA.
553 Any references to the DATA command in this memo also refer to any
554 substitutes for DATA, such as the BDAT command used with [CHUNKING].
562Gellens & Klensin Standards Track [Page 10]
564RFC 4409 Message Submission for Mail April 2006
5678. Message Modifications
569 Sites MAY modify submissions to ensure compliance with standards and
570 site policy. This section describes a number of such modifications
571 that are often considered useful.
573 NOTE: As a matter of guidance for local decisions to implement
574 message modification, a paramount rule is to limit such actions to
575 remedies for specific problems that have clear solutions. This is
576 especially true with address elements. For example, indiscriminately
577 appending a domain to an address or element that lacks one typically
578 results in more broken addresses. An unqualified address must be
579 verified to be a valid local part in the domain before the domain can
582 Any message forwarded or delivered by the MSA MUST conform to the
583 requirements of [SMTP-MTA] and [MESSAGE-FORMAT].
587 The MSA MAY add or replace the 'Sender' field, if the identity of the
588 sender is known and this is not given in the 'From' field.
590 The MSA MUST ensure that any address it places in a 'Sender' field is
591 in fact a valid mail address.
595 The MSA MAY add a 'Date' field to the submitted message, if it lacks
596 it, or correct the 'Date' field if it does not conform to
597 [MESSAGE-FORMAT] syntax.
601 The MSA SHOULD add or replace the 'Message-ID' field, if it lacks it,
602 or it is not valid syntax (as defined by [MESSAGE-FORMAT]). Note
603 that a number of clients still do not generate Message-ID fields.
607 The MSA MAY apply transfer encoding to the message according to MIME
608 conventions, if needed and not harmful to the MIME type.
612 The MSA MAY (digitally) sign or otherwise add authentication
613 information to the message.
618Gellens & Klensin Standards Track [Page 11]
620RFC 4409 Message Submission for Mail April 2006
6238.6. Encrypt the Message
625 The MSA MAY encrypt the message for transport to reflect
626 organizational policies.
628 NOTE: To be useful, the addition of a signature and/or encryption by
629 the MSA generally implies that the connection between the MUA and MSA
630 must itself be secured in some other way, for example, by operating
631 inside of a secure environment, by securing the submission connection
632 at the transport layer, or by using an [SMTP-AUTH] mechanism that
633 provides for session integrity.
637 The MSA MAY resolve aliases (CNAME records) for domain names, in the
638 SMTP envelope and optionally in address fields of the header, subject
641 NOTE: Unconditionally resolving aliases could be harmful. For
642 example, if www.example.net and ftp.example.net are both aliases for
643 mail.example.net, rewriting them could lose useful information.
647 The MSA MAY rewrite local parts and/or domains in the SMTP envelope,
648 and optionally in address fields of the header, according to local
649 policy. For example, a site may prefer to rewrite 'JRU' as
650 'J.Random.User' in order to hide login names, and/or to rewrite
651 'squeaky.sales.example.net' as 'zyx.example.net' to hide machine
652 names and make it easier to move users.
654 However, only addresses, local-parts, or domains which match specific
655 local MSA configuration settings should be altered. It would be very
656 dangerous for the MSA to apply data-independent rewriting rules, such
657 as always deleting the first element of a domain name. So, for
658 example, a rule that strips the left-most element of the domain, if
659 the complete domain matches '*.foo.example.net', would be acceptable.
661 The MSA MUST NOT rewrite a forward-pointing (destination) address in
662 a way that violates the constraints of [SMTP-MTA] on modifications of
6659. Security Considerations
667 Separation of submission and relay of messages allows a site to
668 implement different policies for the two types of services, including
669 requiring use of additional security mechanisms for one or both. It
670 can do this in a way which is simpler, both technically and
674Gellens & Klensin Standards Track [Page 12]
676RFC 4409 Message Submission for Mail April 2006
679 administratively. This increases the likelihood that policies will
680 be applied correctly.
682 Separation also can aid in tracking and preventing unsolicited bulk
685 For example, a site could configure its mail servers such that the
686 MSA requires authentication before accepting a message, and the MTA
687 rejects all RCPT commands for non-local users. This can be an
688 important element in a site's total email security policy.
690 If a site fails to require any form of authorization for message
691 submissions (see section 3.3 for discussion), it is allowing open use
692 of its resources and name; unsolicited bulk email can be injected
693 using its facilities.
695 Section 3 includes further discussion of issues with some
696 authentication methods.
698 Section 5.2 includes a cautionary note that unlimited logging can
699 enable certain forms of denial of service attacks.
70110. IANA Considerations
703 The registration for port 587 has been updated to refer to this memo
704 rather than RFC 2476.
708 Nathaniel Borenstein and Barry Leiba were instrumental in the
709 development of this update to RFC 2476.
711 The original memo (RFC 2476) was developed in part based on comments
712 and discussions which took place on and off the IETF-Submit mailing
713 list. The help of those who took the time to review that document
714 and make suggestions is appreciated, especially that of Dave Crocker,
715 Ned Freed, Keith Moore, John Myers, and Chris Newman.
717 Special thanks to Harald Alvestrand, who got this effort started.
730Gellens & Klensin Standards Track [Page 13]
732RFC 4409 Message Submission for Mail April 2006
73512. Normative References
737 [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E.,
738 and D. Crocker, "SMTP Service Extensions", STD 10,
739 RFC 1869, November 1995.
741 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
742 Requirement Levels", BCP 14, RFC 2119, March 1997.
744 [SMTP-MTA] Postel, J., "Simple Mail Transfer Protocol", STD
745 10, RFC 821, August 1982.
747 Partridge, C., "Mail routing and the domain
748 system", STD 10, RFC 974, January 1986.
750 Braden, R., "Requirements for Internet Hosts -
751 Application and Support", STD 3, RFC 1123, October
754 Klensin, J., "Simple Mail Transfer Protocol", RFC
75713. Informative References
759 [521REPLY] Durand, A. and F. Dupont, "SMTP 521 Reply Code",
760 RFC 1846, September 1995.
762 [8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E.,
763 and D. Crocker, "SMTP Service Extension for 8bit-
764 MIMEtransport", RFC 1652, July 1994.
766 [CHECKPOINT] Crocker, D., Freed, N., and A. Cargille, "SMTP
767 Service Extension for Checkpoint/Restart", RFC
768 1845, September 1995.
770 [CHUNKING] Vaudreuil, G., "SMTP Service Extensions for
771 Transmission of Large and Binary MIME Messages",
772 RFC 3030, December 2000.
774 [CODES-EXTENSION] Freed, N., "SMTP Service Extension for Returning
775 Enhanced Error Codes", RFC 2034, October 1996.
777 [DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP)
778 Service Extension for Delivery Status Notifications
779 (DSNs)", RFC 3461, January 2003.
781 [ETRN] De Winter, J., "SMTP Service Extension for Remote
782 Message Queue Starting", RFC 1985, August 1996.
786Gellens & Klensin Standards Track [Page 14]
788RFC 4409 Message Submission for Mail April 2006
791 [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
792 VERSION 4rev1", RFC 3501, March 2003.
794 [IPSEC] Kent, S. and R. Atkinson, "Security Architecture
795 for the Internet Protocol", RFC 2401, November
798 [MESSAGE-FORMAT] Crocker, D., "Standard for the format of ARPA
799 Internet text messages", STD 11, RFC 822, August
802 Braden, R., "Requirements for Internet Hosts -
803 Application and Support", STD 3, RFC 1123, October
806 Resnick, P., "Internet Message Format", RFC 2822,
809 [Msg-Track] Allman, E. and T. Hansen, "SMTP Service Extension
810 for Message Tracking", RFC 3885, September 2004.
812 [PIPELINING] Freed, N., "SMTP Service Extension for Command
813 Pipelining", STD 60, RFC 2920, September 2000.
815 [POP3] Myers, J. and M. Rose, "Post Office Protocol -
816 Version 3", STD 53, RFC 1939, May 1996.
818 [SIZE] Klensin, J., Freed, N., and K. Moore, "SMTP Service
819 Extension for Message Size Declaration", STD 10,
820 RFC 1870, November 1995.
822 [SMTP-AUTH] Myers, J., "SMTP Service Extension for
823 Authentication", RFC 2554, March 1999.
825 [SMTP-CODES] Vaudreuil, G., "Enhanced Mail System Status Codes",
826 RFC 3463, January 2003.
828 [Start-TLS] Hoffman, P., "SMTP Service Extension for Secure
829 SMTP over Transport Layer Security", RFC 3207,
842Gellens & Klensin Standards Track [Page 15]
844RFC 4409 Message Submission for Mail April 2006
850 QUALCOMM Incorporated
852 San Diego, CA 92121-2779
855 EMail: rg+ietf@qualcomm.com
859 1770 Massachusetts Ave, #322
863 EMail: john+ietf@jck.com
898Gellens & Klensin Standards Track [Page 16]
900RFC 4409 Message Submission for Mail April 2006
903Full Copyright Statement
905 Copyright (C) The Internet Society (2006).
907 This document is subject to the rights, licenses and restrictions
908 contained in BCP 78, and except as set forth therein, the authors
909 retain all their rights.
911 This document and the information contained herein are provided on an
912 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
913 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
914 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
915 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
916 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
917 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
921 The IETF takes no position regarding the validity or scope of any
922 Intellectual Property Rights or other rights that might be claimed to
923 pertain to the implementation or use of the technology described in
924 this document or the extent to which any license under such rights
925 might or might not be available; nor does it represent that it has
926 made any independent effort to identify any such rights. Information
927 on the procedures with respect to rights in RFC documents can be
928 found in BCP 78 and BCP 79.
930 Copies of IPR disclosures made to the IETF Secretariat and any
931 assurances of licenses to be made available, or the result of an
932 attempt made to obtain a general license or permission for the use of
933 such proprietary rights by implementers or users of this
934 specification can be obtained from the IETF on-line IPR repository at
935 http://www.ietf.org/ipr.
937 The IETF invites any interested party to bring to its attention any
938 copyrights, patents or patent applications, or other proprietary
939 rights that may cover technology that may be required to implement
940 this standard. Please address the information to the IETF at
945 Funding for the RFC Editor function is provided by the IETF
946 Administrative Support Activity (IASA).
954Gellens & Klensin Standards Track [Page 17]