Mark E. Mallett wrote:
Sorry that this is such a long comment on such a trivial thing.
It's correct, and better to fix this a.s.a.p. than to report it
as erratum later. Where "a.s.a.p." can be either AUTH48 or -09.
===
[3.1 3rd paragraph about initial 554]
I believe this is actually a way to reject a "session" and not
a "transaction". Since "transaction" (or "mail transaction")
is a specific term used in this document to refer to something
within a session, I think that it's not correct here.
OTOH 3.1 is "Session initiation", it's not exactly easy to be
confused about the topic... ;-) A 554 in the session initiation
in a certain *IS* a session, and it prohibits to reach a state
where a transaction could begin.
If you want to reject a session you can do that with TCP, just
don't accept the connection - depending on the IP, the phase of
the moon, or whatever.
===
[3.3
it's really more accurate to say "when a mail transaction is
not in progress" than "without a previous MAIL command" since
that's what's intended.
Okay. IMO it's again not exactly easy to be confused about the
topic of 3.3 "Mail Transactions". It's a rather long section,
folks could quote it out of context, and your wording is more
accurate - I'm not sure if it is clearer, quoted out of context
readers might not know what a "mail transaction" is.
there's similar text later in the section re the DATA command
That should be fine, it says "missing accepted RCPT TO => 554",
and "missing MAIL FROM => 503". Are you worried that this does
not mention SOML FROM and SAML FROM ?
"if there is no transaction open, or no RCPT commands have been
accepted," ...
Maybe, if you are optimistic that readers know what an "open
transaction" is, initiated by the most recent MAIL, SOML, SAML.
For hardcore nitpicking "open mail transaction" could eliminate
SEND, but I think 2821 + 2821bis intentionally ignore this cruft.
I also notice that there is nothing that explicitly says when
the processing of the DATA command ends a transaction, from the
server state point of view. There is the statement that the
end of mail indicator "confirms the mail transaction" but this
is not the same thing. My understanding has been that once a
DATA command has been OKed (with a 354 reply) and the subsequent
response to the data transfer has been sent (even from data
timeout), the server should then go into a state where no
transaction is in progress. But nothing in the text says that.
Sorry, I don't see the problem here. Or rather, I think that
rejecting individual RCPT TO post-DATA with bounces constitutes
"net abuse" for an unverified reverse path, but that is not what
you are talking about and addressed "elsewhere", among others in
an I-D about "selective reject".
After the final dot, or whatever does the trick for BDAT + BURL,
the server sends a reply, and after doing that the transaction
is finished from its POV. The client is supposed to wait for
this reply with a timeout. After that timeout the session is
supposed to be broken (= not only the transaction failed), and
that is discussed elsewhere.
one could believe that another DATA command could be issued
at this point, or that further RCPTs could be given, etc.
The first paragraph of section 3.3 ends with:
| Then a DATA command initiates transfer of the mail data and
| is terminated by the "end of mail" data indicator, which also
| confirms the transaction.
Do you want "unrevocably initiates the end of the transaction",
or similar ? Trying to figure out what you mean, IMHO it could
make sense to split section 3.3 into an intro (1st paragraph),
3.3.1 (MAIL FROM, 1st step), 3.3.2 (RCPT TO, 2nd step), and
3.3.3 (DATA, 3rd step).
===
| When normal (2yz or 551) responses are returned from a VRFY
| or EXPN request, the reply normally includes the mailbox
| name, i.e., "<local-part(_at_)domain>", where "domain" is a fully
| qualified domain name, MUST appear in the syntax.
[...]
I don't think that's even a sentence. By the time you get to
"MUST appear in the syntax", it's hard to know what exactly
must appear in the "syntax".
From my DEnglish POV it's a perfect sentence, but arguably it
could be split into two sentences. Somehow there MUST be a
<local-part(_at_)domain> construct in the reply - okay, maybe I get
it now, you are talking about "syntax" vs. "reply", and the
"normally" is unclear: There are no "normal responses" with
an "unnormal" (= without <Mailbox>) reply.
| When normal (2yz or 551) responses are returned from a VRFY
| or EXPN request, the reply MUST include the mailbox name,
| i.e., "<local-part(_at_)domain>", where "domain" is a fully
| qualified domain name.
Yes, that is better. John will anyway hate us for discussing
original 2821 text after the 2821bis Last Call, I would write:
| When normal (2yz or 551) responses are returned from a VRFY
| or EXPN request, the reply MUST include the <Mailbox> name
| with a "<local-part(_at_)domain>" construct, where <Domain> is a
| fully qualified domain name.
And anybody mumbling <address-literal> now deserves to be shot
without warning... ;-)
Not that anybody is really worrying about VRFY
My proposal that including VRFY and EXPN in a DS requires some
evidence that it is implemented and interoperable was widely
ignored. According to the IESG page nobody reported that they
bothered to implement 2821, obviously that can't be true. The
part I implemented (for a stupid client script) has no EXPN or
VRFY, but it insists on 8BITMIME for non-ASCII after EHLO.
=== [About 4.1.4]
Maybe, but it is a bit late in the procedure to start with any
"make a shorter draft" efforts. Inherited from RFC 2821 the
text is sometimes still convoluted, but IMO better, and in most
cases (not limited to 4.1.4) I think its "spirit" is clear.
Do you know practical interoperability issues wrt the end of
a transaction ?
===
| Greeting = ( "220 " (Domain / address-literal) [...]
[...]
should mention be made here of the '554' style greeting?
After deleting three attempted responses trying to justify
why it's okay as is, all running into contradictions: Yes,
it should mention 554, it's bad enough for an erratum.
===
| I: 354 -> data -> S: 250
| E: 552, 554, 451, 452
| E: 450, 550 (rejections for policy reasons)
| E: 503, 554
That is better. Are you sure that 504 and 554 are the only
alternatives for 354 ?
===
| If none do, then a bcc: header field with no
| additional information SHOULD be inserted as specified in [32].
I imagine this is under control, but I think [32] means [10].
I imagine this is NOT under control IFF [10] changes the rules ;-)
But I'm intentionally paranoid wrt IETF and RFC-editor procedures.
===
Appendix D.4 Verifying and Sending Scenario
[...]
the SEND FROM command in this example will be rejected
(particularly since it's not advertised in the EHLO response as
per F.6)
LOL. Another future erratum bites the dust. Thanks for a review
from scratch, I fear nobody else did this for some months / years.
Frank