http://tools.ietf.org/rfcdiff?url2=http%3A%2F%2Ftools.ietf.org%2Fid%2Fdraft-klensin-rfc2821bis-03.txt&difftype=--hwdiff
Top down only the diffs from -02 or what I see:
- What was wrong with "obsoletes 2821" (now "obsoletes 821") ?
The complete list of RFCs obsoleted by 2821 is longer.
- appendix C (source routes) is still there.
| including any lines in the header section or other structure
* including any other structure like lines in the header section
Or maybe get rid of the "or other structure", it's hard to parse
the sentence after you've replaced the "headers".
- 2.3 Terminology: Please use the BCP 14 terminology like most
other RFCs.
| A MIME extension (RFC2047 [30]) defines an
* Two MIME extensions (RFC2047 [30] and RFC2231 [??]) define an
Those language tags in RFC 2231 are okay.
| EHLO command MUST BE
* EHLO command MUST be
| Recent work, RFC3463 [39], has specified
* RFC3463 [39] specifies
RFC 1893 is no recent work anymore, RFC 3463 is a draft standard.
| However, it MUST not be construed as authorization
* However, it MUST NOT be construed as authorization
I've a script to highlight "MUSTard". Maybe a future version of
the idnits offers an option -s "sofixit".
- 2.3.11: "command" + "verb", let's forget it, 2.4 is the next
section and explains what's what right at the begin.
| However, in practice, some servers do not perform recipient
| verification until after the message text is received. These
| servers SHOULD treat a failure for one or more recipients as
| a "subsequent failure" and return a mail message as discussed
| in Section 6 and, in particular, in Section 6.1.
No, that's precisely what they SHOULD NOT do, because it's net
abuse in the case of unverified reverse paths. It will get them
blacklisted, and after that they won't be able to report serious
problems. There should not be any "you SHOULD spam" in 2821bis.
| Server SMTP systems SHOULD NOT reject messages based on
| perceived defects in the RFC 822 or MIME (RFC2045 [21]) message
| header section or message body.
Rejecting broken mail objects is an option for 8BITMIME, a duty
for EAI, and a duty for 4409. This SHOULD NOT is utter dubious.
| In particular, they MUST NOT reject messages in which the
| numbers of Resent-fields do not match or Resent-to appears
| without Resent-from and/or Resent- date.
Delete this, please. Receivers can reject whatever they don't
like. The complete Resent-* concept is unnecessary in a world
using MIME. If some servers try to count Resent-* blocks they
are mad. But that's IMO a harmless madness, not a MUST NOT.
| if a 551 code is used, they MUST NOT assume that the client
| will actually update address information or even return that
| information to the user.
Please delete or "or even" etc., clients can and should return
the complete error reply to the user. I also don't see the
point in "MUST NOT", you could just say "cannot" also for 251,
it's a fact, not an order.
The 251/551 section in RFC 821 is IMO clearer, This needs more
discussion, it misses the point of taking the responsibility for
the mail. That's by definition not possible for an unverified
reverse path, and 551 is a very sound alternative to 250/251
for servers not wishing to get into any trouble with bounces.
550 is also okay, but unlike 551 not very helpful for both sides.
- 3.5: There are many at least potentially valid addresses in
this chapter, please add "TLD" .example everywhere, and maybe
replace foo.com by example.com
- 3.6: I guess you'll update that when appendix C is eliminated,
therefore I skip it for now.
| Gateways are, of course, subject to the same rules for handling
| source routes as those described for other SMTP systems in
| Section 3.3
3.3 also discusses source routes, but the main part is in 3.6 (?)
| The translation algorithm used to convert mail from the Internet
| protocols to another environment's protocol SHOULD ensure that
| error messages from the foreign mail environment are delivered
| to the return path from the SMTP envelope, not to the sender
| listed in the "From:" field (or other fields) of the message body.
Normally you write "reverse path", is it intentionally a "return
path" here, because you're talking about gateways ? For the part
about the "sender" I propose:
* not to an address in the "From:", "Sender:", or similar header
* fields of the message.
That should cover Sender:, Resent-From:, Resent-Sender:, Reply-To:.
IMO "message body" is misleading if you actually mean the complete
message (header and body), or here especially its header. Maybe
"mail object" or "message data" is better if "message" isn't clear.
| If the foreign environment has no equivalent concept, the gateway
| must select and use a best approximation, with the message
| originator's address as the default of last resort.
I think it should use the address of postmaster@ (or similar) at
the gateway, and not a random address in something it made up while
translating foreign addresses to Internet addresses as specified in
3.7.4. The gateway is responsible, and errors should be reported
via the gateway. It's the same RFC 1123 problem as for forwarders,
and the solution in 1123 5.2.16 keeps the responsibility where it
belongs, at the gateway. 5.2.16 is a "sender rewriting system".
| Note that the key difference between handling aliases (Section
| 3.9.1) and forwarding (this subsection) is the change to the
| backward-pointing address in this case.
That's a point where you could mention that this used to be no
key difference under RFC 821, because "in any case, the SMTP"
added "its own identifier to the reverse path". There might be
better places to explain that RFC 1123 broke the original SMTP
design in its quest to get rid of the source routes.
Okay, 3 chapters out of 17 (with appendices), enough for today.
One disadvantage of minor changes in a diff is that I start to
look at text I haven't read for years only because there's a
diff mark, and then I start to compare 821/1123 with 2821bis...
Frank