draft-klensin-rfc2821bis-10.txt   klensin-changed.txt 
skipping to change at page 24, line 14 skipping to change at page 24, line 14
When a name that is the argument to VRFY could identify more than one When a name that is the argument to VRFY could identify more than one
mailbox, the server MAY either note the ambiguity or identify the mailbox, the server MAY either note the ambiguity or identify the
alternatives. In other words, any of the following are legitimate alternatives. In other words, any of the following are legitimate
responses to VRFY: responses to VRFY:
553 User ambiguous 553 User ambiguous
or or
553- Ambiguous; Possibilities are 553- Ambiguous; Possibilities are
553-Joe Smith <jsmith@foo.com> 553-Joe Smith <jsmith@foo.example.com>
553-Harry Smith <hsmith@foo.com> 553-Harry Smith <hsmith@foo.example.com>
553 Melvin Smith <dweep@foo.com> 553 Melvin Smith <dweep@foo.example.com>
or or
553-Ambiguous; Possibilities 553-Ambiguous; Possibilities
553- <jsmith@foo.com> 553- <jsmith@foo.example.com>
553- <hsmith@foo.com> 553- <hsmith@foo.example.com>
553 <dweep@foo.com> 553 <dweep@foo.example.com>
Under normal circumstances, a client receiving a 553 reply would be Under normal circumstances, a client receiving a 553 reply would be
expected to expose the result to the user. Use of exactly the forms expected to expose the result to the user. Use of exactly the forms
given, and the "user ambiguous" or "ambiguous" keywords, possibly given, and the "user ambiguous" or "ambiguous" keywords, possibly
supplemented by extended reply codes such as those described in supplemented by extended reply codes such as those described in
RFC3463 [37], will facilitate automated translation into other RFC3463 [37], will facilitate automated translation into other
languages as needed. Of course, a client that was highly automated languages as needed. Of course, a client that was highly automated
or that was operating in another language than English, might choose or that was operating in another language than English, might choose
to try to translate the response, to return some other indication to to try to translate the response, to return some other indication to
the user than the literal text of the reply, or to take some the user than the literal text of the reply, or to take some
skipping to change at page 25, line 25 skipping to change at page 25, line 25
functionality, SHOULD accept the "local-part@domain" form as a "user functionality, SHOULD accept the "local-part@domain" form as a "user
name"; hosts MAY also choose to recognize other strings as "user name"; hosts MAY also choose to recognize other strings as "user
names". names".
The case of expanding a mailbox list requires a multiline reply, such The case of expanding a mailbox list requires a multiline reply, such
as: as:
C: EXPN Example-People C: EXPN Example-People
S: 250-Jon Postel <Postel@isi.edu> S: 250-Jon Postel <Postel@isi.edu>
S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu> S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu>
S: 250 Sam Q. Smith <SQSmith@specific.generic.com> S: 250 Sam Q. Smith <SQSmith@specific.generic.example.com>
or or
C: EXPN Executive-Washroom-List C: EXPN Executive-Washroom-List
S: 550 Access Denied to You. S: 550 Access Denied to You.
The character string arguments of the VRFY and EXPN commands cannot The character string arguments of the VRFY and EXPN commands cannot
be further restricted due to the variety of implementations of the be further restricted due to the variety of implementations of the
user name and mailbox list concepts. On some systems it may be user name and mailbox list concepts. On some systems it may be
appropriate for the argument of the EXPN command to be a file name appropriate for the argument of the EXPN command to be a file name
skipping to change at page 36, line 29 skipping to change at page 36, line 29
Similarly, relay hosts SHOULD strip or ignore source routes, and Similarly, relay hosts SHOULD strip or ignore source routes, and
names MUST NOT be copied into the reverse-path. When mail reaches names MUST NOT be copied into the reverse-path. When mail reaches
its ultimate destination (the forward-path contains only a its ultimate destination (the forward-path contains only a
destination mailbox), the SMTP server inserts it into the destination destination mailbox), the SMTP server inserts it into the destination
mailbox in accordance with its host mail conventions. mailbox in accordance with its host mail conventions.
This command appends its forward-path argument to the forward-path This command appends its forward-path argument to the forward-path
buffer; it does not change the reverse-path buffer nor the mail data buffer; it does not change the reverse-path buffer nor the mail data
buffer. buffer.
For example, mail received at relay host xyz.com with envelope For example, mail received at relay host xyz.example.com with envelope
commands commands
MAIL FROM:<userx@y.foo.org> MAIL FROM:<userx@y.foo.example.org>
RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> RCPT TO:<@hosta.int,@jkl.example.org:userc@d.bar.example.org>
will normally be sent directly on to host d.bar.org with envelope will normally be sent directly on to host d.bar.example.org with envelope
commands commands
MAIL FROM:<userx@y.foo.org> MAIL FROM:<userx@y.foo.example.org>
RCPT TO:<userc@d.bar.org> RCPT TO:<userc@d.bar.example.org>
As provided in Appendix C, xyz.com MAY also choose to relay the As provided in Appendix C, xyz.example.com MAY also choose to relay the
message to hosta.int, using the envelope commands message to hosta.int, using the envelope commands
MAIL FROM:<userx@y.foo.org> MAIL FROM:<userx@y.foo.example.org>
RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> RCPT TO:<@hosta.int,@jkl.example.org:userc@d.bar.example.org>
or to jkl.org, using the envelope commands or to jkl.example.org, using the envelope commands
MAIL FROM:<userx@y.foo.org> MAIL FROM:<userx@y.foo.example.org>
RCPT TO:<@jkl.org:userc@d.bar.org> RCPT TO:<@jkl.example.org:userc@d.bar.example.org>
Attempting to use relaying this way is now strongly discouraged. Attempting to use relaying this way is now strongly discouraged.
Since hosts are not required to relay mail at all, xyz.com MAY also Since hosts are not required to relay mail at all, xyz.example.com MAY also
reject the message entirely when the RCPT command is received, using reject the message entirely when the RCPT command is received, using
a 550 code (since this is a "policy reason"). a 550 code (since this is a "policy reason").
If service extensions were negotiated, the RCPT command may also If service extensions were negotiated, the RCPT command may also
carry parameters associated with a particular service extension carry parameters associated with a particular service extension
offered by the server. The client MUST NOT transmit parameters other offered by the server. The client MUST NOT transmit parameters other
than those associated with a service extension offered by the server than those associated with a service extension offered by the server
in its EHLO response. in its EHLO response.
Syntax: Syntax:
skipping to change at page 55, line 8 skipping to change at page 55, line 8
fully-qualified primary domain name) of the server host as the first fully-qualified primary domain name) of the server host as the first
word following the reply code. Sometimes the host will have no word following the reply code. Sometimes the host will have no
meaningful name. See Section 4.1.3 for a discussion of alternatives meaningful name. See Section 4.1.3 for a discussion of alternatives
in these situations. in these situations.
For example, For example,
220 ISIF.USC.EDU Service ready 220 ISIF.USC.EDU Service ready
or or
220 mail.example.com SuperSMTP v 6.1.2 Service ready 220 mail.example.example.com SuperSMTP v 6.1.2 Service ready
or or
220 [10.0.0.1] Clueless host service ready 220 [10.0.0.1] Clueless host service ready
The table below lists alternative success and failure replies for The table below lists alternative success and failure replies for
each command. These SHOULD be strictly adhered to. A receiver MAY each command. These SHOULD be strictly adhered to. A receiver MAY
substitute text in the replies, but the meanings and actions implied substitute text in the replies, but the meanings and actions implied
by the code numbers and by the specific command reply sequence MUST by the code numbers and by the specific command reply sequence MUST
be preserved. be preserved.
skipping to change at page 84, line 43 skipping to change at page 84, line 43
[43] Fenton, J., "Analysis of Threats Motivating DomainKeys [43] Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", RFC 4686, September 2006. Identified Mail (DKIM)", RFC 4686, September 2006.
[44] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and [44] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and
M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures",
RFC 4871, May 2007. RFC 4871, May 2007.
[45] Internet Assigned Number Authority (IANA), "IANA Mail [45] Internet Assigned Number Authority (IANA), "IANA Mail
Parameters", 2007, Parameters", 2007,
<http://www.iana.org/assignments/mail-parameters>. <http://www.iana.example.org/assignments/mail-parameters>.
[46] Internet Assigned Number Authority (IANA), "Address Literal [46] Internet Assigned Number Authority (IANA), "Address Literal
Tags", 2007, Tags", 2007,
<http://www.iana.org/assignments/address-literal-tags>. <http://www.iana.org/assignments/address-literal-tags>.
Appendix A. TCP Transport Service Appendix A. TCP Transport Service
The TCP connection supports the transmission of 8-bit bytes. The The TCP connection supports the transmission of 8-bit bytes. The
SMTP data is 7-bit ASCII characters. Each character is transmitted SMTP data is 7-bit ASCII characters. Each character is transmitted
as an 8-bit byte with the high-order bit cleared to zero. Service as an 8-bit byte with the high-order bit cleared to zero. Service
skipping to change at page 87, line 39 skipping to change at page 87, line 39
entirely and simply use the domain as specified in the Mailbox. entirely and simply use the domain as specified in the Mailbox.
Appendix D. Scenarios Appendix D. Scenarios
This section presents complete scenarios of several types of SMTP This section presents complete scenarios of several types of SMTP
sessions. In the examples, "C:" indicates what is said by the SMTP sessions. In the examples, "C:" indicates what is said by the SMTP
client, and "S:" indicates what is said by the SMTP server. client, and "S:" indicates what is said by the SMTP server.
D.1. A Typical SMTP Transaction Scenario D.1. A Typical SMTP Transaction Scenario
This SMTP example shows mail sent by Smith at host bar.com, to Jones, This SMTP example shows mail sent by Smith at host bar.example.com, to Jones,
Green, and Brown at host foo.com. Here we assume that host bar.com Green, and Brown at host foo.example.com. Here we assume that host bar.example.com
contacts host foo.com directly. The mail is accepted for Jones and contacts host foo.example.com directly. The mail is accepted for Jones and
Brown. Green does not have a mailbox at host foo.com. Brown. Green does not have a mailbox at host foo.example.com.
S: 220 foo.com Simple Mail Transfer Service Ready S: 220 foo.example.com Simple Mail Transfer Service Ready
C: EHLO bar.com C: EHLO bar.example.com
S: 250-foo.com greets bar.com S: 250-foo.example.com greets bar.example.com
S: 250-8BITMIME S: 250-8BITMIME
S: 250-SIZE S: 250-SIZE
S: 250-DSN S: 250-DSN
S: 250 HELP S: 250 HELP
C: MAIL FROM:<Smith@bar.com> C: MAIL FROM:<Smith@bar.example.com>
S: 250 OK S: 250 OK
C: RCPT TO:<Jones@foo.com> C: RCPT TO:<Jones@foo.example.com>
S: 250 OK S: 250 OK
C: RCPT TO:<Green@foo.com> C: RCPT TO:<Green@foo.example.com>
S: 550 No such user here S: 550 No such user here
C: RCPT TO:<Brown@foo.com> C: RCPT TO:<Brown@foo.example.com>
S: 250 OK S: 250 OK
C: DATA C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF> S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Blah blah blah... C: Blah blah blah...
C: ...etc. etc. etc. C: ...etc. etc. etc.
C: . C: .
S: 250 OK S: 250 OK
C: QUIT C: QUIT
S: 221 foo.com Service closing transmission channel S: 221 foo.example.com Service closing transmission channel
D.2. Aborted SMTP Transaction Scenario D.2. Aborted SMTP Transaction Scenario
S: 220 foo.com Simple Mail Transfer Service Ready S: 220 foo.example.com Simple Mail Transfer Service Ready
C: EHLO bar.com C: EHLO bar.example.com
S: 250-foo.com greets bar.com S: 250-foo.example.com greets bar.example.com
S: 250-8BITMIME S: 250-8BITMIME
S: 250-SIZE S: 250-SIZE
S: 250-DSN S: 250-DSN
S: 250 HELP S: 250 HELP
C: MAIL FROM:<Smith@bar.com> C: MAIL FROM:<Smith@bar.example.com>
S: 250 OK S: 250 OK
C: RCPT TO:<Jones@foo.com> C: RCPT TO:<Jones@foo.example.com>
S: 250 OK S: 250 OK
C: RCPT TO:<Green@foo.com> C: RCPT TO:<Green@foo.example.com>
S: 550 No such user here S: 550 No such user here
C: RSET C: RSET
S: 250 OK S: 250 OK
C: QUIT C: QUIT
S: 221 foo.com Service closing transmission channel S: 221 foo.example.com Service closing transmission channel
D.3. Relayed Mail Scenario D.3. Relayed Mail Scenario
Step 1 -- Source Host to Relay Host Step 1 -- Source Host to Relay Host
The source host performs a DNS lookup on XYZ.COM (the destination The source host performs a DNS lookup on XYZ.EXAMPLE.COM (the destination
address) and finds DNS MX records specifying xyz.com as the best address) and finds DNS MX records specifying xyz.example.com as the best
preference and foo.com as a lower preference. It attempts to open a preference and foo.example.com as a lower preference. It attempts to open a
connection to xyz.com and fails. It then opens a connection to connection to xyz.example.com and fails. It then opens a connection to
foo.com, with the following dialogue: foo.example.com, with the following dialogue:
S: 220 foo.com Simple Mail Transfer Service Ready S: 220 foo.example.com Simple Mail Transfer Service Ready
C: EHLO bar.com C: EHLO bar.example.com
S: 250-foo.com greets bar.com S: 250-foo.example.com greets bar.example.com
S: 250-8BITMIME S: 250-8BITMIME
S: 250-SIZE S: 250-SIZE
S: 250-DSN S: 250-DSN
S: 250 HELP S: 250 HELP
C: MAIL FROM:<JQP@bar.com> C: MAIL FROM:<JQP@bar.example.com>
S: 250 OK S: 250 OK
C: RCPT TO:<Jones@XYZ.COM> C: RCPT TO:<Jones@XYZ.EXAMPLE.COM>
S: 250 OK S: 250 OK
C: DATA C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF> S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Date: Thu, 21 May 1998 05:33:29 -0700 C: Date: Thu, 21 May 1998 05:33:29 -0700
C: From: John Q. Public <JQP@bar.com> C: From: John Q. Public <JQP@bar.example.com>
C: Subject: The Next Meeting of the Board C: Subject: The Next Meeting of the Board
C: To: Jones@xyz.com C: To: Jones@xyz.example.com
C: C:
C: Bill: C: Bill:
C: The next meeting of the board of directors will be C: The next meeting of the board of directors will be
C: on Tuesday. C: on Tuesday.
C: John. C: John.
C: . C: .
S: 250 OK S: 250 OK
C: QUIT C: QUIT
S: 221 foo.com Service closing transmission channel S: 221 foo.example.com Service closing transmission channel
Step 2 -- Relay Host to Destination Host Step 2 -- Relay Host to Destination Host
foo.com, having received the message, now does a DNS lookup on foo.example.com, having received the message, now does a DNS lookup on
xyz.com. It finds the same set of MX records, but cannot use the one xyz.example.com. It finds the same set of MX records, but cannot use the one
that points to itself (or to any other host as a worse preference). that points to itself (or to any other host as a worse preference).
It tries to open a connection to xyz.com itself and succeeds. Then It tries to open a connection to xyz.example.com itself and succeeds. Then
we have: we have:
S: 220 xyz.com Simple Mail Transfer Service Ready S: 220 xyz.example.com Simple Mail Transfer Service Ready
C: EHLO foo.com C: EHLO foo.example.com
S: 250 xyz.com is on the air S: 250 xyz.example.com is on the air
C: MAIL FROM:<JQP@bar.com> C: MAIL FROM:<JQP@bar.example.com>
S: 250 OK S: 250 OK
C: RCPT TO:<Jones@XYZ.COM> C: RCPT TO:<Jones@XYZ.EXAMPLE.COM>
S: 250 OK S: 250 OK
C: DATA C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF> S: 354 Start mail input; end with <CRLF>.<CRLF>
C: 05:33:29 -0700 C: 05:33:29 -0700
C: Date: Thu, 21 May 1998 05:33:22 -0700 C: Date: Thu, 21 May 1998 05:33:22 -0700
C: From: John Q. Public <JQP@bar.com> C: From: John Q. Public <JQP@bar.example.com>
C: Subject: The Next Meeting of the Board C: Subject: The Next Meeting of the Board
C: To: Jones@xyz.com C: To: Jones@xyz.example.com
C: C:
C: Bill: C: Bill:
C: The next meeting of the board of directors will be C: The next meeting of the board of directors will be
C: on Tuesday. C: on Tuesday.
C: John. C: John.
C: . C: .
S: 250 OK S: 250 OK
C: QUIT C: QUIT
S: 221 foo.com Service closing transmission channel S: 221 foo.example.com Service closing transmission channel
D.4. Verifying and Sending Scenario D.4. Verifying and Sending Scenario
S: 220 foo.com Simple Mail Transfer Service Ready S: 220 foo.example.com Simple Mail Transfer Service Ready
C: EHLO bar.com C: EHLO bar.example.com
S: 250-foo.com greets bar.com S: 250-foo.example.com greets bar.example.com
S: 250-8BITMIME S: 250-8BITMIME
S: 250-SIZE S: 250-SIZE
S: 250-DSN S: 250-DSN
S: 250-VRFY S: 250-VRFY
S: 250 HELP S: 250 HELP
C: VRFY Crispin C: VRFY Crispin
S: 250 Mark Crispin <Admin.MRC@foo.com> S: 250 Mark Crispin <Admin.MRC@foo.example.com>
C: MAIL FROM:<EAK@bar.com> C: MAIL FROM:<EAK@bar.example.com>
S: 250 OK S: 250 OK
C: RCPT TO:<Admin.MRC@foo.com> C: RCPT TO:<Admin.MRC@foo.example.com>
S: 250 OK S: 250 OK
C: DATA C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF> S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Blah blah blah... C: Blah blah blah...
C: ...etc. etc. etc. C: ...etc. etc. etc.
C: . C: .
S: 250 OK S: 250 OK
C: QUIT C: QUIT
S: 221 foo.com Service closing transmission channel S: 221 foo.example.com Service closing transmission channel
Appendix E. Other Gateway Issues Appendix E. Other Gateway Issues
In general, gateways between the Internet and other mail systems In general, gateways between the Internet and other mail systems
SHOULD attempt to preserve any layering semantics across the SHOULD attempt to preserve any layering semantics across the
boundaries between the two mail systems involved. Gateway- boundaries between the two mail systems involved. Gateway-
translation approaches that attempt to take shortcuts by mapping translation approaches that attempt to take shortcuts by mapping
(such as mapping envelope information from one system to the message (such as mapping envelope information from one system to the message
header section or body of another) have generally proven to be header section or body of another) have generally proven to be
inadequate in important ways. Systems translating between inadequate in important ways. Systems translating between
 End of changes. 44 change blocks. 
72 lines changed or deleted 72 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/