http://www.mail-archive.com/[email protected]/msg97598.html
Dev Wednesday, June 1, 2005, 12:58:09 PM, you wrote: MTS> That interface and features are EXACTLY what MTS> we should have in Imail bynow. Who's mail server MTS> software is that? MTS> Dev wrote: My bad for not being MTS> hyper-accurate with my MTS> terminology. MTS> True, "tarpitting" is the ability to trigger a MTS> "time-out" period against originating IP's that exceed MTS> a specified limit of bad recipients. MTS> Your criticism of resource usage with "slowdown" MTS> tarpitting is certainly valid. However, any decent MTS> tarpit implementation also allows you to change that by MTS> specifying "close connection", which I do. Note the MTS> screenshot of the new server's tarpit interface. See? MTS> No TCP sockets were harmed or wasted during the filming MTS> of this picture. :-) MTS> We finally abandoned Imail because, at the time, they MTS> didn't have even a rudimentary dictionary-attack MTS> solution, (not to mention the geriatric webmail.) MTS> Attacks simply chewed up CPU cycles as Imail chased MTS> it's own tail. MTS> Now, the new registry-enabled "hang up" in Imail 8.2 is MTS> a start--it's crude but effective. In the next version, MTS> I trust that Ipswitch will enhance it to be world-class MTS> and fully-featured! MTS> Dev MTS> Thursday, May 26, 2005, 10:01:52 AM, you wrote: MTS> My understanding of the definition of MTS> tarpitting is slowing down the MTS> delivery of messages to multiple MTS> recipients...If my understanding is MTS> correct see "delay between recipients" in MTS> the SMTP Advanced tab in IMail MTS> Admin. If not please enlighten me to the proper mening MTS> 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 To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
