11 messages in net.sourceforge.lists.courier-usersRe: [courier-users] sender verify cal...
FromSent OnAttachments
ScottJul 18, 2006 5:40 pm 
ScottJul 18, 2006 5:43 pm 
Sam VarshavchikJul 18, 2006 6:12 pm 
ScottJul 18, 2006 10:24 pm 
Sam VarshavchikJul 19, 2006 3:59 am 
ScottJul 19, 2006 12:26 pm 
Ben KennedyJul 19, 2006 1:08 pm 
Sebastian LechteJul 20, 2006 4:39 am 
Marcus IlgnerJul 20, 2006 6:24 am 
Jay LeeJul 20, 2006 7:00 am 
Marcus IlgnerJul 20, 2006 8:54 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [courier-users] sender verify callout vs. tarpitActions...
From:Jay Lee (jl@pbu.edu)
Date:Jul 20, 2006 7:00:03 am
List:net.sourceforge.lists.courier-users

Marcus Ilgner wrote:

could maybe someone point me to some documentation on the tarpit functionality in the Courier MTA?

I don't think there's much on the website... The mailing list archives and the C code (courier/module.esmtp/couriesmtpd.c around line 65 is a start) will have to suffice...

What options there are possibly to set,

There aren't any options to be set (though I'd love to have the ability to configure the timeout lengths and have a whitelist... hint, hint...).

You could play with the hard coded INIT_TEERGRUBE and MAX_TEERGRUBE definitions and recompile... Setting INIT_TEERGRUBE to 0 should effectively disable the tarpit. Bumping MAX_TEERGRUBE to high would likely result in ESMTP connections timing out (possibly from a legit connection that just has a bunch of old email addresses...)

how it determines the address to tarpit etc.

As I understand it, it's not based on address, it's based on the server response. For example, if I connect and start sending bad commands, I start getting tarpitted. If I send a rcpt to: and Courier responds that it's non-existant, I start getting tarpitted... The timeout length continues until it hits MAX_TEERGRUBE. These settings are per session as I understand, so that if the same IP connects later (or even at the same time), one connections bad behavior will not cause the other to be tarpitted.

Up to now the existence of that functionality was the only thing that I could find ;)

Yep, this does need a little more documentation. Especially since it can really break things like Backup MX servers (yes I know they're a bad idea nowadays anyways but that doesn't mean they're going away)...

Jay