Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!hellgate.utah.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!VENERA.ISI.EDU!braden
From: braden@VENERA.ISI.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  Host requirements and SMTP
Message-ID: <9001051949.AA13352@braden.isi.edu>
Date: 5 Jan 90 19:49:54 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 100

Julian,

Thanks for your comments.

	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
	   
According to the intent of the HR WG, this would NOT satisfy the requirement
for implementation.  To implement the command, your code must include the
necessary algorithms and data structures which, if enabled by a particular
site administrator, would actually perform the intended function.
Note that the HR RFCs generally specify what must be present in the code, 
regardless of how particular sites choose to configure their systems.

	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.
	
Except as specifically mentioned in the HR RFC, all parts of RFC-821
are required.  Sending HELO is part of the SMTP protocol (see Section
3.5and all the examples of RFC-821); although the WG never discussed this
point (discussion would have been gratuitous), I think I can state with
certainty that sending HELO is required.

	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.
		
The limitations of HELO validation and IP addresses for hard-core 
authentication are very well known.  However, there is a lot of experience
in which HELO parameters have been useful for diagnosing mail delivery
problems.

	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.

The requirement in Section 5.2.8 to include the IP source address in the
Received: line is intended to do exactly that.  It was felt that both
pieces of information are useful for diagnosis.

	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. 
	
Some argued for this, but the WG decided that this should be left to
a future revision.  Many (but not all) WG members felt that the intent of the
Received: line is to provide trace information for humans, so that a
precise syntax is not a very important.  Here's a suggestion: put the domain
literal after the host domain name, with one or more blanks separating the two.

    Otherwise things like the RFC-822 ->
	X.400 gateways that try and preserve trace are going to have problems
	parsing these lines.

Gateways are specifically prohibited from modifying modifying Received:
lines! (Section 5.3.7 (B)).  So they don't need to, and should not try,
to parse these lines.

	Section 5.2.14
	New date format is good - but is this going to break existing systems
	and implementations I wonder?

The WG felt that we have a choice of breaking things gradually over the
next 10 years or all at once on 12/31/99, and preferred the former.  One
could argue that, I suppose.

 	Section 5.2.17 
	Urgghhhhh! This is awful. Making this a MUST is horrible. Domain
	literals should be stamped out. 
	
The WG felt that domain literals are an important escape mechanism for
users when the DNS is screwed up: a user-helpful feature.  Implementation does
not seem to me to be that big a deal compared with the overall 821/822
implementation job.

Again, we appreciate your comments, and they will be saved for the lucky
people who get to revise the HR RFC.

Bob Braden