Hi John,
John C Klensin wrote:
Hi.
Question: Is it time to formally deprecate 821 and, in
particular, the main feature that distinguishes it: the use of
HELO by SMTP clients?
I don't see a problem with adding new semantics that effectively
deprecates HELO.
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.
Both established servers and client will continue to support HELO for
their customer public server operations. I don't see us removing HELO
support. Even future developers will come across a server where
delivery is a problem and arguing about what is right or wrong is a
waste of time for everyone.
But overall, I see the goal is to begin instilling stronger SMTP
compliancy protocol specification for future developers (servers and
clients) by minimizing, removing, rewording all currently remaining
ambiguous and relaxed SMTP previsions.
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.
You mean private vs public? and thus, private operations authorizes
receivers to enforce expected strong behaviors.
As long as SUBMIT requires authentication, does it not? I don't see
how we will ever get rid of the public port.
I think we should discuss the technical problem at hand like beginning
with questions like:
1) Why is helo still used?
- No need for extensions
- smaller session handshaking
- legacy software, good vs bad.
2) Where is it a problem when used?
- bypasses strong machine authentication extended methods
3) Why can't we allow servers to optionally enforce the same
syntax requirements as EHLO? Over a migration period?
4) Are there any reason technical migration policy strategies?
I ask this because if we think about it, there is really subtle
differences between EHLO and HELO and its mostly in its syntax and
strong vs weak enforcement EHLO overs HELO.
Anyway, I don't think the angle of SPAM fighting is the solution. The
solution has to be applied to all to close all loopholes. Any new
enforcement has to apply to the good guy as well.
I don't have a strong opinion (or even a weak one) about this
one way or the other, nor have I looked at how much I'd have to
change the document to implement it if it were wanted. But,
because this is the point at which we are proposing to really
obsolete Full Standard 821 with a Full Standard, it seems like
the right time to ask the question. Since RFC 1425 was
published sixteen years ago next month, it should not be
unreasonable to tell people they've had enough time to get used
to the idea of something besides HELO.
+1, but you do realize that business aren't going to give a hoot about
the new rules when there are delivery problems, even if rare and
remote. If some legacy server says "500 Command not understood", it
would be silly for the worlds most advanced and modern SMTP client to
not send the mail because the receiver is not supporting EHLO.
From an Spam/Security standpoint, the difficulty in maximizing new
technology effectiveness has been the requirement to continue to
support legacy clients. Its the Archille's Heel of all the current
work being done. The client does not have to comply by simply staying
put in legacy mode.
I would suggest a I-D would where we might introduce a "Migration
Protocol Extension" where servers have the option to reject HELO after
a certain period and warning was issued to the legacy client.
We might even wish to borrow old mail networking policies that worked
in the past to address continued legacy interoperability issues. Such
as only allowing legacy SMTP clients to move mail (operate) during
certain times of the day. In a way, it would be like a greylist
concept for HELO legacy clients.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com