On Fri, Jan 23, 2009 at 01:46:06AM -0500, John C Klensin wrote:
Hi.
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
syntax productions.
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.
Validating data present in HELO or EHLO parameter would be
neat, but it is invalid in so large a share of _valid_ message
transmits, that I have had to ignore it since forever.
On the integrated usage frequency of different modes, I do have
some statistical data collected over several years in persistent
accounters within the MTA. SNMP RRD sets are 5 years long, MTA
"SNMP" counters were last reset in July 2005.
These are publicly viewable (http://vger.kernel.org/z/), but
I shall hilight some things:
Incoming smtp:
SS.SMTPconnects 55507276
SS.SMTP_HELO 28982564
SS.SMTP_EHLO 25593458
SS.IncomingClientPipelines 19295332
Outgoing smtp:
TA-SMTP.SmtpEHLO 799439122
TA-SMTP.SmtpHELO 6839640
Some outbound systems were being sent with forced HELO mode, as
they were not receiving emails entirely successfully when sending
with EHLO greeting. Currently no target is being explicitely
routed like that.
A 5 year SNMP trend plot on outgoing HELOs show slight decrease and
simultaneous outgoing EHLO-plot shows similar increase.
http://vger.kernel.org/z/graphs/vger_SNMP_TA-SMTP_SmtpHELO-5year.png
http://vger.kernel.org/z/graphs/vger_SNMP_TA-SMTP_SmtpEHLO-5year.png
That is, more and more of outgoing traffic is sent without
need to decrade the mode.
On the incoming flows.. Incoming HELOs are increasing all the time
in 5 year plot.
Also incoming client pipelining flows are increasing.
That is, while my server does support PIPELINING -mode both
incoming and outgoing, it does also note which greeting it gets
on incoming flow, and reacts accordingly. Spammers are also
unable to handle basic multi-recipient processing rules, if
they see single non-ok response, then at least one widely deployed
spamware drops the connection.
My statistics gathering is not able to tell how much HELO-traffic
is valid non-pipelined flows. Neither, precisely, it is able to
tell of how much are pipelined HELO spam-flows. There is just
an obvious (to eyeball mark 1) correlation in between those two
in day period statistics.
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.
Yes please.
In particular the message submission via SMTP should be deprecated
in favour of authenticated SUBMIT port usage.
The issue there is that for travelling user having to submit thru
port 25 is increasingly being blocked outside ISP's own servers.
With wide-spread SUBMIT availability, travellers would be able to
send their emails thru their service provider's servers no matter
where they happen to be.
ISP:s and their users are still very much unaware of SUBMIT service,
and rarely serving it, or at least rarely documenting on how to use it.
Some may have SMTPS service, but no SUBMIT.
On the other hand, combination of SUBMIT and STARTTLS has had problems
in clients, in particular with the Outlook brand of things.
Those clients did start with SSL handshake on SUBMIT port,
if TLS was enabled and port number was anything but 25...
This could also enable stricter control on what constitutes of valid
format message, and what is not. Things like Message-ID: -header
are practically mandatory, but at least one widely deployed MTA
product does not write it on error messages it sends...
Some MUA programs create the Message-ID, others do not, and let
the MTA to add it. Most MTAs add it, some do not.
Some add it even if it is already present. (Serious troubles
resulted when I tried to enforce a rule of "there is exactly one
'Message-ID:' header in incoming email.")
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.
john
--
/Matti Aarnio <mea(_at_)nic(_dot_)funet(_dot_)fi>
FUNET: Finnish Academic and Research Network
Network Information/Software Archival Service
