2010/1/7 <open...@noid.net>: > In the absence of any feedback, I would say that I have two feature > requests for spamd (Bob, are you out there?): > > 1) Detect '500 5.5.1 Command unrecognized' loops, and when found, > start to gap response times with an increasing delay. > > 2) When a client does not wait for spamd's 220 opening message to > complete before sending, greytrap that client.
I'll take a look at both. -Bob > > Thanks for your consideration. > > - Tor > > > On Sat, Jan 02, 2010 at 03:15:03PM -0800, open...@noid.net wrote: >> Hello, >> >> I've got spamd working well (it's very cool!)... >> >> Sometimes I see in pftop a state entry that shows spamd has a very old >> connection that is actively still passing traffic (lasts for hours)... >> >> I was able to capture one of these as it began (using tcpdump). >> Here's what the trace shows (in distilled SMTP): >> >> send: 220 my >> recv: EHLO bogon.domain.com\r\n >> send: host.domain.net ESMTP MTA; Mon Dec 28 07:55:59 2009\r\n >> send: 250 Hello, spam sender. Pleased to be wasting your time.\r\n >> recv: HELO bogon.domain.com\r\n >> send: 500 5.5.1 Command unrecognized\r\n >> recv: \r\n >> send: 500 5.5.1 Command unrecognized\r\n >> recv: \r\n >> send: 500 5.5.1 Command unrecognized\r\n >> recv: \r\n >> >> ... etc, approximately two 5.5.1 errors per second >> >> This client sends it's EHLO before waiting for spamd to complete >> sending it's 220 opening message. I try to show that above using an >> indentation on the third line (the second send line). In fact, spamd >> is doing it's normal trick of stuttering out the 220 opening message >> one char per packet... >> >> I think spamd's state table is correct in not allowing the SMTP >> session to reset upon receiving the subsequent HELO. My questions >> are as follows: >> >> Should spamd start to reduce bandwidth for a session by extending >> reply times after some trigger like too many errors sent or too much >> time spent...? >> >> When a client sends it's EHLO (or anything at all) before waiting for >> the server's 220 opening message to complete, is that not grounds for >> immediate greytrapping? I do not think spamd enforces that at the >> moment. This would be similar to sendmail's FEATURE(`greet_pause') in >> that there would be a penalty for such misbehavior... >> >> Thanks for your consideration. >> >> - Tor
