On Saturday, July 07, 2012 23:59:39, Janne Snabb wrote:
> On 07/08/2012 06:06 AM, Chris Knadle wrote:
...
> The list of countries at the top does not vary too much... I have no bad
> feelings about throwing in a couple of "delay = 30s" to collectively
> punish mail senders from the worst countries and to see if they timeout
> faster than they ought to.
The shortest timeout is 2 minutes (most are 5), so this seems like it should
be okay. Bypassing greylisting based on country of origin sounds mildly
interesting -- I'll give that some thought.
In terms of greylisting, I'm currently using a base "delay = 5s", with a multiplier for the
number of times the sender tries to send to the same recipient during the same connection. I've
been considering upping the base delay time because occasionally I get up to 20 successive
sending attempts. [It's not causing me any trouble, though.]
acl_check_rcpt:
warn
condition = ${if >{$acl_c1}{0} {yes}{no}}
log_message = $acl_c1 greylist failures; delaying ${eval:$acl_c1*5} seconds
delay = ${eval:$acl_c1*5}s
defer
message = $sender_host_address is not yet authorized to deliver \
mail from <$sender_address> to <$local_part@$domain>. \
Please try later.
set acl_c1 = ${eval:$acl_c1+1}
log_message = greylisted. ($acl_c1 attempts)
!senders = :
!hosts = : +relay_from_hosts : \
${if exists {/etc/greylistd/whitelist-hosts}\
{/etc/greylistd/whitelist-hosts}{}} : \
${if exists {/var/lib/greylistd/whitelist-hosts}\
{/var/lib/greylistd/whitelist-hosts}{}}
!authenticated = *
!acl = acl_local_deny_exceptions
domains = +local_domains : +relay_to_domains
condition = ${readsocket{/var/run/greylistd/socket}\
{--grey \
$sender_host_address \
$sender_address \
$local_part@$domain}\
{5s}{}{false}}
> > Scoring or blocking based on OS sounds dangerous, but you probably meant
> > this more as an example of one thing that is possible to do with it. p0f
> > also sounds interesting from an informational logging perspective, for
> > starters. The readme mentions it's possible for it to "detect illegal
> > network hookups".
>
> I give "Windows XP" a penalty on some mail servers, but do not outright
> reject anything based on this.
>
> The only significant legitimate mail source that I see identified as
> Windows XP are some of Microsoft's outgoing servers.
If Microsoft is still using Windows XP I find that a bit humorous, because
they're been simultaneously asking everyone else to upgrade.
I also found it interesting that you still get email from servers still
running Linux 2.4 and 2.2 -- that's just weird.
...
> > Also sounds to me like it would be convenient to build these two Exim
> > 'addons' into Debian packages, which would make them easier to install on
> > Debian-based distros. Let me know if someone is already working on this,
> > otherwise I might give it a shot as a way of checking these out. [I've
> > built a few Debian packages and gotten them to work, although I haven't
> > submitted any to try to get them into Debian proper yet for different
> > reasons.]
>
> I am not aware of any packaging efforts so far. Feel free to package
> them if you like. I appreciate it.
> However there is one obstacle: Debian has the old p0f version 2 whereas
> this dlfunc only works with the new p0f version 3.
Ah. Thanks for pointing this out, as I would have missed that. I found the
upstream source; when I saw that p0f is hosted at coredump.cx, it made me do
a double-take. ;-)
I also just created a bug report in the Debian BTS for p0f because what is
packaged now is v2.0.8 from 2006 (even in Sid), and upstream has marked these
old versions as "do not use". The wnpp report doesn't show the p0f up for
adoption, not orphaned, no RFH (Request For Help), so this package should
still be actively maintained.
Anyway if/when I have anything else of interest on this I'll send it to you
offlist.
-- Chris
--
Chris Knadle
Chris.Knadle@???
