On 13 May 2011 15:10, Simon Hobson <[email protected]> wrote: > 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. Thank's, I find those networks and use /20 and /23 netmasks already, and all works normally. mail.ru uses not only f<n>.mail.ru, but some more variants: sender3.mail.ru fallback6.mail.ru mx2.mail.ru I also scan it with your script example and find new subnets and add it too.
But after some time they can add new subnets, and I need spend time to to periodically check this and update rules. So, now I do the checks only when users inform me about failure or slow delivering of some mail. So some good mail can be lost. > 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. I propose to use reverse-forward double lookup ONLY for servers that match the whitelist at first check, not for each smtp attempt. If we add this feature, I will can add *.mail.ru domain to whitelist and solve all problems without researching manually it IP subnets. And if user didn't use domain wildcards in whitelist, this feature didn't slow down the process and will not give any failures. So, with this feature I will can disable mail delaying via greylist from gmail.com too with adding *.google.com to wildcard, because google have many smtp servers too: mail-bw0-f43.google.com mail-bw0-f67.google.com mail-fx0-f43.google.com mail-gw0-f43.google.com mail-gx0-f171.google.com mail-gy0-f171.google.com mail-pv0-f171.google.com mail-pv0-f195.google.com mail-pw0-f43.google.com mail-px0-f171.google.com mail-px0-f195.google.com mail-vw0-f43.google.com mail-vx0-f171.google.com mail-ww0-f53.google.com mail-yw0-f43.google.com smtp-out.google.com -- Best regards, Alexey Murz Korepov. Email, Jabber: [email protected] _______________________________________________ Users mailing list [email protected] http://lists.policyd.org/mailman/listinfo/users
