That interface and features are EXACTLY what we should have in Imail by now. Who's mail server software is that?

Dev wrote:
My bad for not being hyper-accurate with my
terminology.

True, "tarpitting" is the ability to trigger a
"time-out" period against originating IP's that exceed
a specified limit of bad recipients.

Your criticism of resource usage with "slowdown"
tarpitting is certainly valid. However, any decent
tarpit implementation also allows you to change that by
specifying "close connection", which I do. Note the
screenshot of the new server's tarpit interface. See?
No TCP sockets were harmed or wasted during the filming
of this picture. :-)

We finally abandoned Imail because, at the time, they
didn't have even a rudimentary dictionary-attack
solution, (not to mention the geriatric webmail.)
Attacks simply chewed up CPU cycles as Imail chased
it's own tail.

Now, the new registry-enabled "hang up" in Imail 8.2 is
a start--it's crude but effective. In the next version,
I trust that Ipswitch will enhance it to be world-class
and fully-featured!


Dev


Thursday, May 26, 2005, 10:01:52 AM, you wrote:


  
My understanding of the definition of tarpitting is slowing down the
delivery of messages to multiple recipients...If my understanding is
correct see "delay between recipients" in the SMTP Advanced tab in IMail
Admin. If not please enlighten me to the proper mening
      

LC> SMTP tar-pitting means that the SMTP server
LC> artificially injects delays 
LC> into its side of the SMTP dialogue
LC> (specifically, before returning SMTP 
LC> response codes) with the SMTP client.  The
LC> delays can be 10's of seconds or 
LC> many minutes.

LC> tar-pitting is an attempt, by one MX, to
LC> "hurt" the millions of IPs that 
LC> abuse MXs by slowing the abusive IPs and
LC> "wasting" their tcp sockets and 
LC> SMTP sessions.

LC> In adverse effect, the most hurt is done to
LC> the MX machine server itself 
LC> since it must also waste a tcp socket and a
LC> SMTP session on the MX side for 
LC> eacd tarpitting action.  In this
LC> shoot-MX-in-foot battle, which side has 
LC> the most tcp/smtp resources to waste?  A
LC> single MX or the aggregate of 
LC> millions of abusvie IPs attacking it?

LC> I always recommend against tar-pitting in
LC> general.  And from the large 
LC> number of IMGate/Imail users have added IMGate
LC> because IMail SMTP server 
LC> was unstable and incapable of supporting
LC> high-volumes of simultaneous SMTP 
LC> connects, I strongly recommend against any
LC> tar-pitting by the Imail server.

LC> The great benefit of IMGate to IMail users is off-loading the
LC> DNS+SMTP-to-Internet dialogue from Imail to
LC> IMGate.  Tar-pitting goes 
LC> exactly in the opposite direction, loading up
LC> IMail SMTPD with more demands 
LC> for tcp/smtp resources, and insanely, with no
LC> noticeable advantage, and NO 
LC> pain for the attackers.

LC> Len

LC> _____________________________________________________________________
LC> http://IMGate.MEIway.com : free anti-spam
LC> gateway, runs on 1000's of sites



LC> To Unsubscribe:
LC> http://www.ipswitch.com/support/mailing-lists.html
LC> List Archive:
LC> http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
LC> Knowledge Base/FAQ:
LC> http://www.ipswitch.com/support/IMail/




Reply via email to