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 <[email protected]> FUNET: Finnish Academic and Research Network Network Information/Software Archival Service
