Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!NNSC.NSF.NET!craig From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: re: Host requirements and SMTP Message-ID: <9001060126.AA11937@ucbvax.Berkeley.EDU> Date: 5 Jan 90 13:35:35 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 92 Julian: Let me see if I can answer some of your questions. > Section 5.2.3 > This seems nonsensical, saying essentially you MUST implement > VRFY and SHOULD implement the EXPN commands, but both of these MAY be > disabled. > 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"? Let me just clarify the text here. It says MUST implement and MAY provide the facility to allow users to turn them off. The reason was that, in general, EXPN and VRFY are useful tools for tracking problems in mail-lists expansions. However, EXPN and VRFY are also viewed by some members of the community as a violation of privacy (Why should someone be able to find out whether I'm on mailing list X? Or why should someone be able to find out who is on my personal mail-lists?). Furthermore, both commands are minor security risks -- since mailbox names often are the same as account names. So we state that it is reasonable for users to ask for mail software in which they can turn off EXPN and VRFY. > Section 5.2.5 I don't know what to say here. HELO is part of the protocol, so yes you ought to do it. That said, yes, it doesn't do much. > 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. Firstly the from field should contain > both a source host and a domain literal of the IP address. Good - but > how, the grammer gives exactly one FROM per received line in rfc-822 > in the format > from domain > similarly there is only one FOR address allowed - perhaps a new grammer > should have been given here. Otherwise things like the RFC-822 -> > X.400 gateways that try and preserve trace are going to have problems > parsing these lines. I believe you are right and we goofed here. > 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. > > > My ideal text for this section would have been "Domain literals are not > intended for address use, an Implementation MAY make use of them for > routing, and SHOULD NOT fail outright if one is detected. > Gee -- that's what we tried to do, only a bit more forcefully. Domain literals may show up, your mailer must not barf on them, and if the domain literal = your host, your mailer ought to accept it. In other words, God help us, should you get a domain literal, do the minimum rational thing -- don't fail, and swallow it if it is for you. > 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. > So if somewhere on the Internet I get an address allegedly from > > where hidden-host is not directly contactable I must throw away the > Internet-host route part when sending an error. The most likely reason > for having a route in the originator is because the hidden host does > not yet have an entry in the DNS or an MX record for its domain, so > in that case there is no way to get back without the route. This isn't what were saying. What we were saying is there is good reason in the envelope to track how the mail has proceeded -- the typical way to do this is source routes (@A,@B:user@C) where user@C is the originating system. Now there's no point in replying via all the intermediate hops -- and now that source routes are discouraged, it may not even fly. So just strip down to user@C. In the case you cite, I'd argue the gateway should have sent stuff out as user%hidden@host, which would then become @A,@B:user%hidden@host, and you'd reply to user%hidden@host. Craig