--On Friday, 27 April, 2007 03:57 +0200 Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
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.
Bug in my XML. I was trying to get it to list both. Fixed.
| 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.
Been discussed before. On list as Issue 7.
| A MIME extension (RFC2047 [30]) defines an
* Two MIME extensions (RFC2047 [30] and RFC2231 [??]) define an
Done. I hope others agree and this doesn't need an issue
number, etc.
Those language tags in RFC 2231 are okay.
Mumble.
| EHLO command MUST BE
* EHLO command MUST be
Done.
| Recent work, RFC3463 [39], has specified
* RFC3463 [39] specifies
Done
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
Done
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.
I am not sure I understand this comment unless it is a
suggestion that we give a negative answer to Issue 23 and move
on.
| 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.
Issue 25.
| 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 reverse order, Submission (4409) servers are not SMTP
servers, there are no final EAI specs and I don't think the
current ones contain a requirement to reject _broken_ mail
objects, and the 8BITMIME option is about valid objects that the
relevant servers decide to not downgrade. Those are not
defects and are not being rejected on that basis.
| 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.
Changes an explicit DRUMS decision... needs a stronger argument
than your sense of taste, IMO.
| 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.
Mechanical translation. And yet another reason to back out all
of the changes to insert SHOULD/MUST language.
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.
In practice, unless something has changed recently, 551 has been
very little used for years... and 251 even less so. And I don't
understand why you think this has anything to do with either
taking responsibilty for mail or unverified return paths...
unless this is another manifestation of Issue 25.
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
These particular examples have been used since 821. I am loathe
to start making changes unless there is very general concern
that it is worth the effort and risks.
- 3.6: I guess you'll update that when appendix C is
eliminated, therefore I skip it for now.
If appendix C is eliminated, yes. The experience with the
changes to SHOULD/MUST have turned me back into a minimalist
position, i.e., I now believe that, if this document is to be
finished any time soon, we have better stop talking about "nice"
fixes and start concentrating on only those changes that are
necessary.
| 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 ?
Yes, it was, but it is too subtle, so I've changed it to
"reverse path"
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.
Changed. I think "message" is clear since the previous
sentence, as revised, talks about "header lines".
| 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".
I think this is a substantive change.
| 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.
Send text, but my inclination is to not change this further,
especially to reflect the long-dead "copy own address into
reverse-path stuff".
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...
Yet another reason to back out the SHOULD/MUST changes and to
start getting minimalist about this work.
thanks,
john