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
