ietf-smtp
[Top] [All Lists]

Re: clarification re 2821, s4.1.4

2002-08-17 17:37:39

In the interest of reducing the number of nearly-identical
responses, I'm going to respond to several messages together...


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

 An SMTP server MAY verify that the domain name parameter in
the EHLO  command actually corresponds to the IP address of
the client. If this  verification process is not performed, or
if this process does not  complete successfully, the server
SHOULD limit use of the identifier  to logging purposes only.
If the verification process completes  without error (either
in the positive or negative), the identifier  MAY be used for
other purposes, as the server operator sees fit.

Eric, I think this makes text that is arguably already too
convoluted even worse.   In addition, it complicates section
7.7, which requires logging of this information in a Received
field if the message isn't rejected outright.  And, again, the
current text does not imply _any_ limitations on the use of the
domain name parameter, but _only_ on the results of trying to
match up the name with an address or vice versa.

--On Sunday, 18 August, 2002 00:04 +0300 Matti Aarnio
<mea+ietf-smtp(_at_)nic(_dot_)funet(_dot_)fi> wrote:

On Sat, Aug 17, 2002 at 04:33:44PM -0400, Keith Moore wrote:
 An SMTP server MAY verify that the domain name parameter in
 the EHLO command actually corresponds to the IP address of
 the client. 

the last thing we need is to give people more excuses to
implement stupid policies.

Indeed.  I would say there something like this:

  The experience with various desktop MUA softwares since
early 1990es   shows that those generate all manners of
variously faulty HELO/EHLO   parameter data making usefullness
of the data testing highly   questionable.  Put the received
parameter data into the trace header   (see n.n.n) along with
literal IP address of the remote host.
 
(fill in the section number)

The section number is 4.4 in the existing RFC 2821 and this is
the first bullet.  It doesn't include the explanation -- in the
interest of not turning an 80-ish page document into a 200 page
one, few of those explanations are there.

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

...
The opportunity to be stupid comes in the text I added,
although I will point out that it is a MAY not a SHOULD.
Operators MAY be as dumb as they want to be.

Eric, section 7.7 of 2821, IMO, gives operators as much latitude
for intelligent (or stupid) filtering and other actions as they
could possibly need, without pointing out instances of
stupidity.  I have inserted a forward pointer to it into 4.1.4
of 2821bis on the theory that it can't be harmful (although note
my comment in an earlier message).  But I don't think that
filling up that document up with explicit endorsements of the
right to stupidity makes sense -- there are just too many
opportunities and the document is too long already.

Keith, the "you can do it, but don't reject on it" text is in
2821 because it was carried forward, with some rephrasing from
1123.  If I recall, the "use it only for logging" part was added
to make sure we were clear about what we were talking about
(although it obviously wasn't clear enough for Eric, who reads
into it all sorts of prohibitions that I don't see).  We could
just tear the whole business out, but the practice is (or was)
frequent enough, and seems dumb enough, that the warning/
restriction seems to be in order.

Now, by contrast, Abhijit suggested alternate text that, while
less convoluted, I think would get us into trouble:

--On Sunday, 18 August, 2002 01:45 +0530 Abhijit Menon-Sen
<ams(_at_)wiw(_dot_)org> wrote:

  However, the server MUST NOT refuse to accept a message
because of a   verification failure: this information is for
logging and tracing   only.

The difficulty is that rejecting on the basis of some _real_
verification failure strikes me as quite reasonable.  Part of
the point is that name(address(name-in-EHLO-argument)) isn't
good enough to be a "verification failure" -- it is just an
often-meaningless test.  Worse, if some test were used in
conjunction with real remote server authentication and failed,
one would almost certainly want to reject the message/
transaction.  So we would have to qualify this suggested
language to make it clear what was, and was not, a verification
failure.  I think that, by the time we got through with that,
we'd end up with text that was at least as convoluted as what is
there now, with little or no gain.

In response to a few other comments, I (for whatever my opinion
is worth), would favor a BCP document called "rational and
irrational things to do in an SMTP server to resist spammers" or
something to that effect.   As Ned and others have pointed out,
there are enough cases that such a document would be hard to
write, and it would get harder if one wanted to include only
techniques that the spammers couldn't work around once they
becamse part of a widely-circulated document.  But, if someone
wants to try...   You will all forgive me if I don't think
adding each and every one of those cases to 2821bis is a good
idea.

      john


<Prev in Thread] Current Thread [Next in Thread>