> Date: 2005-02-10 19:09 > From: Randall Gellens <randy@xxxxxxxxxxxx> > At 3:03 PM -0500 2/10/05, Bruce Lilly wrote: > > ÂThere are some differences between what the draft says and that > > Âdescription: > > Â1. the draft explicitly permits operation on port 25 > > Â2. the draft section 4.3 doesn't mention port. > > > > ÂSpecifically regarding the 4.3 MUST quoted above and the reply code, > > Âand the necessary two independent implementations required for > > Âadvancement to Draft Standard status, do the implementations supporting > > Âthe request to advance to Draft in fact unconditionally require > > Âauthorization (i.e. independent of whether port 25 or 587 is used, and > > Âregardless of administrative configuration other than specifying that the > > Âimplementation is to act as an MSA), and reply with code 530 (unspecified > > Âextended response code) if authorization is lacking? > > Both the draft and RFC 2476 allow submission to use 25 instead of > 587, but state that "normally" 587 is used, and allow 25 to be used > in order to accommodate implementations that are hard to configure. > Both say that port 587 is reserved for submission. ÂSo, 587 is the > normal case for submission, and 25 is an exceptional case. But as written, section 4.3 specifies that when acting as an MSA, authentication MUST (emphasis in original) be used, regardless of port. > Please see the implementation report for the details, but I believe > most implementations had various configuration options that allowed > them to require authentication or not. Again, "or not" is not allowed by the draft as written; implementations with an "or not" provision would fail to comply with the "MUST" (they would comply with a "SHOULD", however). Aside: based on my understanding of the implementation report, there are no two implementations which simultaneously comply with all of the draft (or 2476) provisions, failing the "two independent implementations" test for advancement to Draft Standard status. > > ÂOn another matter, admittedly unchanged since RFC 2476, there seem to > > Âbe some undesirable discrepancies between submission and non-submission > > ÂESMTP regarding extended response codes. ÂDraft section 3.4 states that > > Âextended status code 5.6.2 means "Bad domain or address", whereas > > ÂRFC 3463 assigns that code the semantics "Conversion required and > > Âprohibited" [RFC 3463 section 3.7]. ÂThe corresponding RFC 3463 > > Âextended response code for domain/address issues would be in the > > Â5.1.XXX range [RFC 3463 section 3.2]. ÂThe draft specifies (sect. 5.1) use > > Âof 5.6.2 with 554 for message header field address issues when an error > > Âis reported after DATA. ÂSMTP (RFC 2821) does not require examination > > Âof message header address field content except in the particular case > > Âof a gateway [RFC 2821 section 3.8]. ÂIf the intent is that MSAs are > > Âalways to be considered to be gateways, then the draft should explicitly > > Âsay so (the term "gateway" does not appear anywhere in the draft). > > Â[that would be a novel use of the term "gateway" in Internet mail; a > > Âgateway usually has one side in a non-SMTP environment] > > ÂConversely, if MSAs are not always to be considered as gateways, then > > Âreturning errors in response to message content is: > > Â1. explicitly counter to the SHOULD NOT of RFC 2821 section 3.4 (bottom of > > Â Â page 18) > > Â2. inappropriately associated with "conversion" semantics where no > > Â Â conversion is in fact required (indeed, other than adding trace fields, > > Â Â tinkering with message data by non-gateway SMTP receivers is disallowed > > Â Â [RFC 2821 section 2.3.8]). > > It is not the intent of either this draft or RFC 2476 to say that > MSAs are always gateways; rather, the intent in both is to recognize > the reality that organizations sometimes see a need to examine and > potentially modify messages submitted using their servers, and to > make a clear distinction between this case, and the > examination/modification of messages being relayed. Well, there's an unresolved incompatibility with RFC 2821. Following up on a disturbing sense of dÃja vu, I checked my records and found the following commentary on RFC 2476 -- I believe that the issues remain largely unaddressed by the draft: --------------------- Date: Sat, 17 Apr 2004 22:54:44 -0400 From: Bruce Lilly <blilly@xxxxxxxxx> Reply-To: blilly@xxxxxxxxx Organization: Bruce Lilly User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us MIME-Version: 1.0 To: John C Klensin <klensin@xxxxxxx>, Randy@xxxxxxxxxxxx Subject: Comments on RFC 2476 (Submission protocol) X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-UID: 407 X-Length: 3072 Hello, First, the reason that I'm sending this directly rather than to ietf-submit is that I'm not subscribed to that list and in a few hours I'll be on an airplane on a business trip, and I may be incommunicado for a week or so. By all means feel free to forward my comments to the list and/or to Chris Newman (whom I see has made some list contributions about a month ago; unfortunately the list archive on the IMC web sit only displays "Chris Newman <Chris.Newman@xxxxxxx>" and the corresponding mailto link is the useless "mailto:Chris.Newman@xxxxxxxxxxxxx";). Following are my comments, in the order as presented in the RFC: section 3.2, last NOTE: Of course the MSA, in order to "properly handle delayed bounces" will have to be able to accurately determine the source, which s probably only possible is some authentication mechanism is used. section 3.4 enhanced status codes: This is the biggest problem that I see: the basis is RFC 1893 (superseded by RFC 3463) status codes, which specifically address only issues related to hard errors in delivery. For example, there is no standardized extended status code to address the situation where an email address is not valid but a forwarding address is available. 3463 does address the situation where such a forwarding address is NOT available (5.1.6), but not the situation corresponding to SMTP response 251. 2.1.6 might be an appropriate extended status code, but RFC 3463 specifically states that X.1.6 " is only useful for permanent failures", i.e. 5.1.6. One might hope that some unified set of extended status codes might be developed that could be used for multiple protocols. Unfortunately, there seems to be an inconsistency even within the mail protocols. RFC 2476 lists extended status code 5.6.2 as "Bad domain or address", whereas RFC 3463 (and 1893) list that code as "Conversion required and prohibited". That is very confusing, since RFC 3463 provides a range of extended codes (x.1.0 through x.1.8) for address/domain errors. It is also notable that RFC 2476 (e.g. section 4.1) provides no extended status codes for transient failures or for success; only class 5 -- permanent failure. Another example of the extended status issue shows up in RFC 2476 section 5.1, which again addresses only permanent failures, not temporary failures (e.g. DNS transient failures). It also doesn't distinguish between syntax errors and address semantic errors. Best regards, Bruce Lilly ---------------------------------- _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf