ietf-smtp
[Top] [All Lists]

Re: clarification re 2821, s4.1.4

2002-08-17 17:47:46

--On Saturday, 17 August, 2002 16:08 -0500 "Eric A. Hall"
<ehall(_at_)ehsco(_dot_)com> wrote:

...
Are there valid reasons why an operator should not simply
discard any lookup which results in a negative answer?
Absolutely. There are also valid reasons for an operator
within a specific network to do so. A closed server might want
to reject any connection which cannot be validated through
multiple means (including the EHLO identifier, the subsequent
address lookup, and a tierterary comparison to an X.509
subject), and a failure of any of these could be considered
valid for that site. Most of us are just looking for something
in between, such as refusing sessions from site claiming to be
me but which I know are not me. Asking me to detail all of
these is arbitrary to the point of seeming artificial.

Eric, I don't disagree with this.  2821 doesn't disagree with
this -- all it says is that "if you make the test, and it fails,
don't reject the message for that reason".  I even agree that
asking you to detail all of the motivations for refusing a
message would be arbitrary and artificial... and a terribly bad
idea at that.   But that is _exactly_ the problem with what you
are suggesting: it is arbitrary, artificial, and a bad idea to
single out the particular case that you are concerned about and
put text into 2821bis whose intent is to say "if you are unhappy
after looking at the identifier, whether you continue with the
SMTP session or not, and what else you might do, is up to you".
Similar text could be inserted, with at least equal
justification, with every SMTP command.  

E.g., suppose a delivery address in a RCPT command doesn't exist
on my system.  The language that is now present says that I
either generate a 5yz code in response to the RCPT command or I
accept it, and return an error message later.  But, if it does
exist, am I _required_ to accept the mail?  Of course not, and I
don't need to tell the sender why, either, although there are
some behaviors I'm strongly discouraged from exhibiting (like
closing the connection without warning).  That is what section
7.7 is all about.  Could we add prose to 4.1.4 that parallels
the text you propose for the EHLO argument case?  Of course we
could, but it doesn't strike me as either necessary or wise.

     john