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., "<[EMAIL PROTECTED]>", 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 <[EMAIL PROTECTED]> 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., "<[EMAIL PROTECTED]>", 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 "<[EMAIL PROTECTED]>" 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
