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.
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
