Alexey Murz Korepov wrote:
> > An easier solution is to select a suitable netmask when adding the
>> Greylist policy. Typically such server clusters are in a small
>> network range.
>> When adding a policy, it's the Track option - next to the pull-down
>> manu with only Sender IP, you can enter a mask length - and the popup
>> help suggests /24 is a sane value (which I'd agree with).
>>
>> Doing it your way means having to whitelist loads of outfits as you
>> get complaints - mail.ru are far from alone in using clusters of
>> outbound mail handlers.
>Yes, I can add those IP addresses to whitelists, but, as I see, they
>are from different subnets (94.100.xx.xx, 217.69.xx.xx, etc), and
>sometimes it changes (mail.ru adds new servers). So periodically I
>must monitor logs and updates this whitelist.
No, please re-read what I wrote because you do not need to do
ANYTHING AT ALL to maintain this. Whilst some large outfits may use
more than one netblock, they will not be using many. For most
outfits, they only use one or two, and so the problem really isn't a
problem.
What I suggested is that you configure greylisting to track by (eg)
IP Address & /24 netmask. You can use a larger netmask but then
greylisting can start to become slightly less effective.
I've just done a quick check :
a=1; while [ $a -lt 400 ]; do host f${a}.mail.ru; a=$(( $a + 1 ));
done | grep -v NXDOMAIN | cut -f4 -d" " | cut -f1-3 -d'.' | sort |
uniq -c
Looking at f<n>.mail.ru for values of n from 1 to 400, I get these
results (leaving off the last octet) :
2 194.186.55
1 194.67.23
2 194.67.57
165 217.69.128
71 217.69.129
12 217.69.138
1 94.100.177
2 94.100.178
1 94.100.182
236 of those prefixes are in the same /23 netblock, leaving only 7
other prefixes, which are themselves in only 6 /23 netblocks. Change
/23 to /20*, and the results are now that only 9 addresses aren't in
the one netblock.
* The prefix assigned to MailRU according to a whois lookup.
I think if you try it, just applying a greylist policy with /23 or
/20 as the netmask will work for you. There is no ongoing work to
maintain it, Policyd will just automatically whitelist a
sender-recipient-IP tuple using a /23 or /20 mask. The majority of
the mail probably comes from machines in the 217.69.128/23 netblock,
and greylisting will work effectively when re-delivery is attempted
by any other machine in the same block.
I use /24 and have not have any complaints related to this problem -
but then I guess my customers probably don't get a lot of mail from
mail.ru.
Alexey Murz Korepov wrote:
> > Reverse DNS names can be forged very easily.
>> All a spammer needs to do is add a PTR record for their IP like
>> hello.example.net. and suddenly all their mail will bypass your
>> greylisting.
>But we can do the back-resolve the received DNS name to IP and if they
>are equal, bypass greylisting. For example:
>$ host 217.69.129.105
>105.129.69.217.in-addr.arpa domain name pointer f64.mail.ru.
>$ host f64.mail.ru
>f64.mail.ru has address 217.69.129.105
>
>Spammers will can't bypass this check, isn't so?
But such a check **WILL** cause you many false positives. Until you
try it, you would not believe how many admins around the world are
incapable (or just don't give a s**t) of setting up their DNS !
Enforcing a correct reverse-forward double lookup will cause many
failures.
--
Simon Hobson
Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.
_______________________________________________
Users mailing list
[email protected]
http://lists.policyd.org/mailman/listinfo/users
