John C Klensin wrote:
????????????????
More verbose, the sentence was in 2821:
Such a transaction consists of a series of commands to specify the
originator and destination of the mail and transmission of the
message content (including any headers or other structure) itself.
In -03 you cleaned up various "headers" resulting in:
Such a transaction consists of a series of commands to specify the
originator and destination of the mail and transmission of the
message content (including any lines in the header section or other
structure) itself.
Is that either "including (any lines in the header section) OR other
structure", or is it "including any lines IN (the header section or
other structure)" ? Or is the difference anyway irrelevant, assuming
that it's a difference at all ? Maybe saying "message content itself,
including any lines" etc. (no parentheses) would be better readable.
[BCP 14 keywords]
Been discussed before. On list as Issue 7.
Okay. Not that I've seen many supporters to keep the "private"
terms in 2821bis since 2005, but maybe they'll show up later. :-)
Those language tags in RFC 2231 are okay.
Mumble.
Just in case, I meant the tags in RFC 2231 chapter 5, not chapter 4.
- 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.
Yes, if "issue 23" is related to the proposal to add a 2.3.x section
explaining "command" and "verb" as terminology. The explanation in
2.4 is good enough, and section 2.4 follows immediately after 2.3.11.
| 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.
Certainly a part of THE issue, maybe form a set of issue numbers
belonging to THE issue, and we can defer it while discussing less
critical stuff.
At some point we'll need the "implementation and interoperability
report", it would be a waste of time to fix details in the long
EXPN and VRFY sections if they're later deprecated with pointers
to (2)821 for curious readers.
[EAI]
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.
When I wrote "option for 8BITMIME, duty for EAI" etc. the option
I had in mind was this:
| If such messages are transmitted in violation of this rule,
| receiving SMTP servers MAY clear the high-order bit or reject
| the message as invalid.
That's a "MAY [...] reject the message as invalid" in 2821bis-03,
not in EAI. This MAY and the SHOULD NOT is no contradiction, but
I think receivers should be free to reject whatever they don't
like, not only 8bit garbage outside of 8BITMIME. Stripping the
MSB is a peculiar recipe, I'd prefer if I never get the results.
| 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.
IMO it needs a justification why that's relevant if you keep it,
for a specific MUST NOT after a general SHOULD NOT it has to be
important. You can't enumerate and forbid all cases of dubious
reject decisions. Something might be special with the Resent-*
case, and I've just no idea what this could be.
[551 "MUST NOT assume"]
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.
I'm not sure about the general effects, but here no MUSTard is
probably clearer.
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.
[...]
In practice, unless something has changed recently, 551 has been
very little used for years... and 251 even less so.
The SPF FAIL logic in the case of "2821-forwarding to a 3rd party
implementing 4408" in esssence emulates a 551 by the forwarder,
that's the good case, "so that the sender can make another plan",
as you put it in RFC.ietf-eai-framework-05. It would start to get
messy if the next hop accepts and discards the FAIL, maybe because
it checks accepted mails behind its border (too late).
251 is not very interesting, from the sender's POV it worked, and
then a sender won't care why it worked, and if that's a permanent
or temporary forwarding. In theory it is still relevant, shorter
routes are always better wrt potential errors, they're also faster.
In practice we can ignore 251, but the wording in RFC 821 is good:
| The receiver takes responsibility for delivering the message.
And if it doesn't wish to take this responsibility (incl. bounces
in the RFC 821 reverse path design) it can pick 551:
| The receiver refuses to accept mail for this user, and the
| sender must either redirect the mail according to the information
| provided or return an error response to the originating user.
Roughly the same as "make another plan". And nobody could be
interested to accept mail from dubious sources. They'd get it
back in the case of any errors, it would sit in their queue
trying to reach the next hop or address of the <reverse-path>.
Forwarding was a serious service, and 551 a serious alternative.
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.
Yes, it's clearly a manifestation of THE issue. I can't tell at
the moment if issue 25 covers 551 and forwarding to 3rd parties.
- 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.
It's a bad example for readers. The poor owner of foo.com might
still wonder why his spam has such odd pattern with local parts
jsmith@ + hsmith@ + dweep@ In some places folks try desperately
to educate users that they shouldn't make up arbitrary domains,
addresses, phone numbers, IPs, etc. for examples.
- 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.
Some liked the idea, and IIRC nobody disliked it...
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.
...getting rid of cruft like source routes is necessary, they're
hopelessly broken since RFC 1123. It's impossible to revive them
as they were, it won't work as expected and as designed.
5.2.16 is a "sender rewriting system".
I think this is a substantive change.
Yes, a substantive change in 2821 compared with 1123 5.2.16. The
gateway needs to make sure that error reports reach the foreign
environment, but like a mailing list it's also interested in any
errors caused by its redistribution. The normal user (sender) on
the other side has no clue what a gateway is, or how SMTP works,
if the gateway somehow screwed up. If the gateway picks its own
fabrication of a From address also as MAIL FROM address it could
with a small plausible error "arrange" that error reports never
make it anywhere, and that would be a Bad Thing.
Frank