--- On Tue, 11/24/09, Tilman Schmidt <[email protected]> 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.
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list [email protected]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
