Received: from balder-227.proper.com (localhost [127.0.0.1]) by
 balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0ND4eqd036115
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
 Fri, 23 Jan 2009 06:04:40 -0700 (MST) (envelope-from
 owner-ietf-smtp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com
 (8.14.2/8.13.5/Submit) id n0ND4e4l036114;
 Fri, 23 Jan 2009 06:04:40 -0700 (MST) (envelope-from
 owner-ietf-smtp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to
 owner-ietf-smtp@mail.imc.org using -f
Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by
 balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0ND4TQs036105 for
 <ietf-smtp@imc.org>;
 Fri, 23 Jan 2009 06:04:39 -0700 (MST) (envelope-from sm@resistor.net)
Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by
 ns1.qubic.net (8.14.4.Alpha0/8.14.4.Alpha0) with ESMTP id n0ND4FZb021721
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
 Fri, 23 Jan 2009 05:04:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail;
 t=1232715867; x=1232802267; bh=4jzbtPCusGxWMt+fYsYaLP9knQoi2lIoHMRDPgot83U=;
 h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type;
 b=VaYqIq2gKQ946gGKcUcLT+I3JN/8JQDxQ901HkR3zXn5vfjJ6mTq86Um8/GeHG4M7
 3VkbNHHXT5EDKjbGrZdoVvhepMR+BBUhUsWclHtumoUY14JAZrR4nDD9nA7N5BHvI3
 J1xGnIRK2bjTza6tlztdy4+cPm66qEHOqN6sAgP4=
DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns;
 b=haB5GB4782U8a1zW3b3Eth1LGSs6DQbIEv4bOZzl8/C1uIgKrhK3k/w7Gf0ZXg+y7
 D/H5MLH650GFI8BrJJQr2z0C1B+7nDPBQokFn65gXqRcLtne+oa5Lk9p9akAG6UrBS8
 GfnNqkI2c86uaGcmRB54TANETLdfXXQR9OyC6j4=
Message-Id: <6.2.5.6.2.20090123035813.03381598@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 23 Jan 2009 04:59:26 -0800
To: John C Klensin <john+smtp@jck.com>
From: SM <sm@resistor.net>
Subject: Re: RFC 5321bis / 2821ter
Cc: ietf-smtp@imc.org
In-Reply-To: <E5EF288BD222F5BA20C735BD@PST.JCK.COM>
References: <E5EF288BD222F5BA20C735BD@PST.JCK.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>

At 22:46 22-01-2009, John C Klensin wrote:
>However, I had a discussion early this week with someone
>interested in the slightly-fuzzy text about arguments to HELO
>and/or EHLO and their relationship to spam-fighting.  The
>discussion leads to a question, especially since 5321bis is our
>first opportunity to really do something significant.
>
>Question: Is it time to formally deprecate 821 and, in
>particular, the main feature that distinguishes it: the use of
>HELO by SMTP clients?  We would still need to require that SMTP
>servers accept it, but we would tell full-capability clients
>(including the client side of relays and gateways) that HELO is
>obsolete.  One corollary of this is that we'd be telling
>low-capability clients, particularly those that are part of MUA
>systems, that they should be talking to Submit ports, not SMTP
>ones.

RFC 2821 obsoletes RFC 821.  There is a reference to RFC 821 in RFC 
2821 and RFC 5321 for some features not in significant use 
today.  The service extension model has been around for over seven 
years and the major MTAs have implemented RFC 2821.  RFC 2821 
specifies that servers MUST support the EHLO command even if they do 
not implement any specific extensions and clients SHOULD 
preferentially utilize EHLO rather than HELO with a fallback to HELO.

I don't know how much work it would be to formally depreciate RFC 
821.  It seems the right time to look into it.  I still see traffic 
from SMTP clients which use HELO.  I don't have a strong view about 
whether HELO should be obsoleted or not.

Regards,
-sm 


