Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!computer-science.nottingham.ac.UK!j.onions From: j.onions@computer-science.nottingham.ac.UK (Julian Onions) Newsgroups: comp.protocols.tcp-ip Subject: Host requirements and SMTP Message-ID: <24861.631484091@cs.nott.ac.uk> Date: 4 Jan 90 20:14:51 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 97 I have just been upgrading an SMTP server/client to attempt to conform to the HOST REQUIREMENTS RFC. Most of the stuff is fairly sensible and lays down good practice. I have some comments on this generally though and wondered if anyone else has attempted to conform to this specification as yet? Anyway, maybe someone can answer these questions or shed some light... 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"? Section 5.2.5 A question/comment - is HELO really required? I know of one implementation that doesn't send HELO messages (MH) and the HR makes it clear that you should mostly ignore the HELO stuff anyway. The discussion about resolution of the HELO parameter is not that essential anyway, to my mind what is more important is that you can discover where the SMTP connection is coming from. I.e. if you can't resolve the IP address back to a domain name then you probably should not accept the mail because a) you don't know who is sending you the message really, so your chances of getting it back are limited if things blow up. b) You don't know who is really sending the message - from a security point of view. IP addresses can be forged but this is better than nothing - certainly better than implicitly believing the HELO. Therefore I would argue all the authentication should have been done before it gets to the HELO stage. A future HR should perhaps note that you should attempt to discover where the message is coming from. 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. Section 5.2.14 New date format is good - but is this going to break existing systems and implementations I wonder? 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. Next thing we'll need to recognise our own ethernet addresses in mail messages. So to be conformant you HAVE to be able to discover all your current IP addresses and to match on them. Does this really have to be a MUST? How many current systems can accept this syntax? I think this will be my biggest stumbling block to conformance. 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. Instead if domain literals are not supported, the affected addresses may be returned with a failure notice. Domain literals are only intended for tracing purposes." Domain literals together with source routing should be dropped. 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. I think these are the main things that hit me when trying to conform to the HR. I would welcome comments. Julian.