Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!ucbvax!GATEWAY.MITRE.ORG!barns From: barns@GATEWAY.MITRE.ORG Newsgroups: comp.protocols.tcp-ip Subject: Re: Host requirements and SMTP Message-ID: <9001051853.AA02262@arcturus.mitre.org> Date: 5 Jan 90 18:53:13 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 144 If I don't answer this, Rayan Zachariassen probably will, and I like my version better... (Rayan is a good sort really, but we did have a lot of interesting or tedious discussions during the editing of this part of HR.) Most of these issues involve unprovable propositions - I for one will concede that in advance. Herewith my recollections and comments: Section 5.2.3 So to conform I can simply implement both these by replying with 252 Cannot VRFY User and 550 Access Denied to you Just changing these from 500 Unknown of unimplemented command seems pretty worthless What benefit do you gain from making VRFY a MUST when its quite acceptable to always answer "can't"? A trivial answer to this is, "if you choose to implement something in the stupidest way you shouldn't be surprised if the product is worthless." The hoped-for result here was: Almost all SMTP implementations ought to be capable of doing real EXPN and VRFY service for some set of cases. Many will find it unduly costly or infeasible for some other set of cases. Finally, there may be security or policy reasons why it is desired not to make certain names visible in this way. This might be all of the names at a site or only a few. So the intent here is to tell the developer to produce the code with the ability to do the functions in the cases where it is technically reasonable, and let the user/purchaser decide what additional restrictions to apply. Section 5.2.5 A question/comment - is HELO really required? [...] As an abstract question, this has no provable answer. As a matter of protocol definition, it is required. People's sentiments vary, but the implication of what was ultimately specified is something like this: The HELO command is there so the server will have an identity assertion about the client process. It is not intended to be a real authentication procedure. Strong authentication, or even "halfway" authentication, takes more work and not everyone thinks the effort is justified. Some people (including me) feel that receipt of mail (in the normal workaday world - not talking about multilevel secure systems, electronic funds transfer or other specific needs) should not be conditioned on any type of authentication - you take anything that shows up at the door, and then assess its worth after you read it if you still care. Converting the IP address back to a host name requires sending more traffic and doing more overhead work. Opinions vary on whether it is worth it. There's also the practical problem that the IP-address part of the domain tree seems to have more screwups in it. HR dodges all of these concerns by saying "invert the IP address if you wish but don't throw away the mail because of anything that happens - instead tell the recipient and let the recipient decide". Section 5.2.8 Various things should be pushed into the Received line it notes, but I don't see how this can be done. [...] Most of the miscellaneous things were envisioned as syntactic comments, which are permitted by the RFC822 syntax rules. For example: Received: from ALLEGED.DOMAIN ([11.22.33.44]) by MY.DOMAIN [etc.] The question of the syntax of the FOR was brought up by Rayan Zachariassen during the editing (as I am sure we will be justly reminded). I suppose there was some feeling that in view of the attitude expressed in the second chunk of DISCUSSION in section 5.2.8 ("Received: lines are primarily intended for humans...") that it wasn't too important to make this concrete. Syntaxes discussed for the contents of the FOR included 1#mailbox, 1#route-addr, and 1#(addr-spec / route-addr) with the last given being the last one discussed (according to my files). I think that 1#mailbox covers the other cases, so if I wanted to parse it today, I'd use 1#mailbox until it broke. Section 5.2.14 New date format is good - but is this going to break existing systems and implementations I wonder? RFC733, the predecessor of 822, allowed four digit years. I thought it was strange that it was taken out in 822, but in those days I wasn't involved in the writing of these things. I know there was a feeling that 733 allowed an excessive number of date formats for no particular reason. I suppose "they" overreacted slightly when updating it (in 822). I hope and believe we are converging on sanity at least in this one area. Section 5.2.17 Urgghhhhh! This is awful. Making this a MUST is horrible. Domain literals should be stamped out. Parsing a domain literal is ok, getting the semantics right is yucky in the extreme, it should at the maximum have been a MAY [...] Having had misadventures with DNS, I'm a believer in this provision as an escape mechanism when the DNS misbehaves and you really need to talk to someone. Given this rule, hosts A and B can manage to talk despite any DNS screwups on C. I don't really understand why this is hard. True, it's one more thing to code. I don't see huge semantic problems at least when the domain literal is a dotted-decimal IP address, which is the only case actually addressed in HR (which is about *Internet* hosts). It is slightly ugly that one ought to cope with [11.22.33.44] and [011.022.033.044] being equivalent, but this can be handled by converting to the 32-bit number. The code may be a little disgusting, but it shouldn't have to be lovingly optimized since it shouldn't be used very often. If you were thinking that you have to canonicalize it (rewrite the header or some such), you don't - read section 5.2.2 closely; it legitimizes allowing domain literals to pass unaltered. Section 5.5.3 This says if you have a source route as the originator of the message then an error message SHOULD throw away the route. [...] The philosophy arrived at by a combination of discussion and decree was something like: We wish explicit source routes within the Internet had never been defined. Since this unfortunate decision was made and many people implemented it, we will put in enough requirements so that mail items using them won't be rejected by anyone as illegal, but we will do everything possible to keep any more such mail items from being created. Note that this doesn't refer to "%-hack" or the like. The left-hand-side is a local matter relative to the specified right-hand-side. (This is just about the only aspect of this touchy topic on which I tend to wax religious.) So, the "blessed" answer to the scenario you describe is for the original sender to use %-hacks or the like on the LHS with the cooperation of some Internet-registered domain, or perhaps use domain literals for a very short time, but eventually get MX's or full DNS connectivity. Incidentally, Jon Postel "decreed" years ago that it was always intended that all domain names appearing on the Internet, including those in source routes, are supposed to be Internet-registered names. Under that dictum, the case you describe as most common should never have been allowed to occur, with or without the HR RFCs. (As all sensible people know, the real world doesn't always follow the rules. The point is just that any variations were unsanctioned by the Powers That Be.) The topic of explicit mail source routes is exceedingly controversial and generated about 20-25% of the total volume of discussion that led to these RFCs. It has been like this for years. Groan. Bill Barns