[Mimedefang] Sendmail::Milter

[-]

--- On Tue, 11/24/09, Tilman Schmidt <t.schmidt at phoenixsoftware.de> wrote:
> Am 2009-11-23 21:38 schrieb -:
> > I too limit connections to one, and one per 5
> minutes.  Should remotes violate that, they get two
> warnings (ICMP admin-prohibited), and if they're too eager,
> they fall into my TCP TARPIT.
> 
> I wonder. Do you have any data on how typical mail server software
> reacts to that sort of policy? What does, for example, a Sendmail or
> Exchange server in default configuration do if it tries to deliver two
> mails to a destination server, the first one succeeds, and the second
> one fails with "administratively prohibited"?

Which would only happen if they tried to open two separate TCP sessions within the 5 minute window.  Two messages in the queue should result in one session sending both messages, and if the second message arrives into their queue after the first had been transmitted and the session closed, they should be waiting one queue interval (usually set to 10-15 minutes) before sending the next.

I have the setting at 5 minutes because I figured that someone out there may have their queue interval set that low.  I installed the firewall rules because I had spammer-relays connecting, trying, failing, disconnecting, and connecting again usually within 15 seconds later to try again.

If by receiving the ICMP message, they NDR a message for "no route to host" (e.g.), that's not my problem.  They're misconfigured by being too eager to hammer my server with back-to-back connections.  I actually impose this rule across my entire subnet, not per host, in order to block spammer mail-server scanners which hit each IP by trying to connect to port 25 on each as quickly as possible.  I have observed such behavior in my mail logs.

I operate a low volume mail server (typically 10 or less legitimate mails received and less than 200 spam attempts per day).  I find usually that most only one or two IP addresses fall into this trap daily.  (Remember that connlimit and hashlimit are per-IP resources.)  Leaving my subnet alone for 3 hours resets the trap unless they accumulate 20 TCP SYNs (or 20 UDPs), in which case they fall into my permanent tarpit as an abuser.  They are "removed" from the "permanent" tarpit only on system reboot, kernel table overflow (LRU removal) of the tarpit list ("recent" function), or manual intervention.