Deny MX queries for dynamic IP pools

Wael Shaheen wael.shahin at gmail.com
Mon Feb 8 11:46:09 UTC 2010


Dear All,

Thank you for the valuable comments to this post.

Sincerely,
Wael

On 2/2/10 4:26 AM, "Sven Eschenberg" <sven at whgl.uni-frankfurt.de> wrote:

> 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
> 
> 
> 
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users





More information about the bind-users mailing list