On Sun, 21 Apr 2002, Devin Carraway wrote: > On Sat, Apr 20, 2002 at 08:29:12PM -0700, Ask Bjoern Hansen wrote: > > Do you have other patches that we should put in? :-) > > No patch, but a coworker recently told me that MTAs should now be > considering an opening HELO as optional -- if the sender wants to lunge > right in with a RCPT, it's permissible. I can't find an RFC confirming > as much, but it does seem to be done that way by exim and sendmail.
hmn, the rfc (2821) doesn't say it's optional, "4.1.4 Order of Commands There are restrictions on the order in which these commands may be used. A session that will contain mail transactions MUST first be initialized by the use of the EHLO command. An SMTP server SHOULD accept commands for non-mail transactions (e.g., VRFY or EXPN) without this initialization." > A tangentially related issue I noticed is that of direct-to-MX spammers > conducting blind transmissions -- they write helo/rcpt/mail/data and the > contents of the mail without regard to the error values returned, thus > incurring a stream of 500 errors (and putting the spam in my maillog, > since I leave tracing enabled.) > > Still trying to think of a good response to that one. The nearest > approximation I can think of is to presume the spammer hasn't doctored > or reimplemented their own TCP stack, cramp the TCP receive window size > down, and if the sending host ignores a 553 on DATA in ESMTP, or on > anything in SMTP mode, close or cork the socket. It might avoid > transmission of some packets, or it might be a total waste of effort. Since we don't claim to support pipelining (rfc 2920) anyway, you could do a hack to flush the input buffer when there's an SMTP failure. That should ruin their session pretty efficiently. :-) - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
