[Top] [All Lists]

Re: RFC 5321bis / 2821ter

2009-01-27 08:49:51

Hi John,

John C Klensin wrote:

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

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

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.


Hector Santos, CTO

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