I don't have an opinion on this either, mostly because I don't know enough.
In the interest of learning, how does EHLO help fight spam over HELO? I
thought it just allowed for extensions...?
John C Klensin wrote:
Just as an update, I've got a first draft of this about ready to
go, modulo the IETF Trust figuring out a way for me to post it.
So far, it differs from 5321 only in that some changes suggested
after Last Call (by individuals and the IESG) have been
incorporated and there is an experiment in creating an index to
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
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.