Deny MX queries for dynamic IP pools

Sven Eschenberg sven at whgl.uni-frankfurt.de
Tue Feb 2 01:26:36 UTC 2010


There have been quite some posts since my first answer to Wael.
I just wanted to rephrase some stuff etc.

On Tue, February 2, 2010 00:43, Peter Dambier wrote:
> Noel Butler wrote:
>> Firstly, I feel this really belongs on mailops not bind list :)
>> secondly...
>>
>> On Mon, 2010-02-01 at 00:00 +0300, Wael Shaheen wrote:
>>
>>> Blocking port 25 is much worse IMHO because it forces users out of the
>>> service, by restricting their ability to use their own mail servers
>>> that can
>>> be hosted externally. I believe good mail administrators will force
>>> SMTPS
>
> Blocking DNS belongs here.
>
> I don't think blocking DNS is a good idea. You are blocking access to
> zones using strictly internal DNS that is not published but only AXFRed
> and you are blocking alternative DNS. In germany alternative DNS is a
> must as many ISPs are stumbling over their own feet when implementing or
> testing censoring. Maybe some of the DNS blackouts here have been DNSSEC
> as well.

Dear fellow pirate, the local situation in Germany might not be relevant
here for Wael, esp. if he works at some ISP and there are no plans to
manipulate DNS otherwise. Yet I do agree as I stated in my first post, I
don't think, filtering/blocking/modifying requests in any way whatsoever
is an appropriate approach to a non-technical problem (as I said before).
Let it be DNS or directly blocking port 25. Here we do block port 25
within our own network - to put it in short, if a customer thinks this
policiy is appropriate, let the customer deploy it, don't do the customers
job and don't give the customer options of taking legal actions because
you break the customers setups.

>
> Oh, how about DNSSEC?
>
> How do you handle signatures?
>
> And you are breaking dnsbl because dnsbl is DNS at an alternative
> address. So some of your clients might accidently drop all mail
> as spam and it takes long to find such a bug if somebody else
> does maintain the mailer.

That is indeed true, I did forget about those in my first post. That
brings me back to my first argument: Don'T use technical methods for a non
technical problem, there many good reasons not to do this.

>
>>
>> The bigger question is why are you not blocking, suspending, or
>> terminating the accounts of those who you know are spamming, be it
>> deliberate, or not (as the end result is the same)
>>
>> Cheers
>>
>>
>
> Cheers
> Peter and Karin
>
>
> --
> Peter and Karin Dambier
> Cesidian Root - Radice Cesidiana
> Rimbacher Strasse 16
> D-69509 Moerlenbach-Bonsweiher
> +49(6209)795-816 (Telekom)
> +49(6252)750-308 (VoIP: sipgate.de)
> mail: peter at peter-dambier.de
> http://www.peter-dambier.de/
> http://iason.site.voila.fr/
> https://sourceforge.net/projects/iason/
> ULA= fd80:4ce1:c66a::/48
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>

Now Andrew said it pretty catchy already, let me rephrase my thoughts: Why
do you want to use some technical approach like filtering/blocking, to
solve a social problem. You as an ISP should have an agreement/contract
with your customers. It's the right place, to enforce, that customers take
action against spam. If they do not comply, willingly or due to
incompetence, it is at your hand, to disconnect them and terminate the
agreement, if necessary. And of course you can take additional legal
action when needed. This is just plain simple social engineering and imho
the only valid solution.

Wael, you said something about mail hosts on dynamic IP Pools being
'illegal' - If it is under your jurisdictional system, well, you already
had the answer/solution, to all your problems, if not, work out an
appropriate contract.

Regards

-Sven






More information about the bind-users mailing list