Re: Color vision for network techs
Tei: such applications exist, see http://dankaminsky.com/2010/12/15/dankam/ http://www.wpcentral.com/augmented-reality-app-windows-phone-ids-colors-real-world-video http://daily-steampunk.com/steampunk-blog/2012/05/27/augmented-reality-steampunk-and-learing-color-vacuum/ On Sep 3, 2012 5:07 AM, Tei oscar.vi...@gmail.com wrote: Standards can have bugs, and a standard that is not compatible with maybe 5% of the population is buggy. Almost any standard that start this is red and this is green is flawed this way. This mean any future standard created as to look into this type of stuff (and i18n and localization and others) to not create flawed buggy standards. Old standards can be updated ... (maybe include lines of the same color but different contrast), but we all know how hard is to update standards. If I where one of these dudes, I would download/create a app for my iphone that recolorice video to change colours to others I could tell the difference. -- -- ℱin del ℳensaje.
Blocking MX query
Hi All, I've read old archive about blocking SMTP port (TCP port 25). In my current situation we are mobile operator and use NAT for our subscribers and we have few spammers, a bit difficult to track it because mostly our subscribers are prepaid services. If we block TCP port 25, there might be good subscribers will not be able to send email. We are thinking to block MX queries on our DNS server, so only spammer that use their own SMTP server will got affected. All DNS queries from our subscribers already redirected to our DNS cache servers. But seem Bind don't have feature to block MX query. Any best practice to block MX query? Regards Ibrahim
Re: Blocking MX query
Feel free to block port 25. Most if not all mail providers offer email access on webmail and on an alternate smtp port (587) If you have NAT - the problem is that if you have spammers abusing your service (or abusing other services on port 25) providers will end up blocking your NAT gateway IP and then you have a problem. You will want to look at walled gardens or similar to block spamming / infected users. Please see the maawg best practice for walled gardens and port 25 management. On Tue, Sep 4, 2012 at 3:37 PM, Ibrahim ibrah...@gmail.com wrote: Hi All, I've read old archive about blocking SMTP port (TCP port 25). In my current situation we are mobile operator and use NAT for our subscribers and we have few spammers, a bit difficult to track it because mostly our subscribers are prepaid services. If we block TCP port 25, there might be good subscribers will not be able to send email. We are thinking to block MX queries on our DNS server, so only spammer that use their own SMTP server will got affected. All DNS queries from our subscribers already redirected to our DNS cache servers. But seem Bind don't have feature to block MX query. Any best practice to block MX query? Regards Ibrahim -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Blocking MX query
Are you saying that you only allow your subscribers to use your DNS Servers and block access to all other DNS Server? On 4 September 2012 11:07, Ibrahim ibrah...@gmail.com wrote: Hi All, I've read old archive about blocking SMTP port (TCP port 25). In my current situation we are mobile operator and use NAT for our subscribers and we have few spammers, a bit difficult to track it because mostly our subscribers are prepaid services. If we block TCP port 25, there might be good subscribers will not be able to send email. We are thinking to block MX queries on our DNS server, so only spammer that use their own SMTP server will got affected. All DNS queries from our subscribers already redirected to our DNS cache servers. But seem Bind don't have feature to block MX query. Any best practice to block MX query? Regards Ibrahim -- ??? BaconZombie LOAD *,8,1
Re: Blocking MX query
Not block, but we use DNS transparent proxy mechanism. We need to do this as our government request all ISP to block porn sites :-) Regards Ibrahim On Tue, Sep 4, 2012 at 5:13 PM, Bacon Zombie baconzom...@gmail.com wrote: Are you saying that you only allow your subscribers to use your DNS Servers and block access to all other DNS Server? On 4 September 2012 11:07, Ibrahim ibrah...@gmail.com wrote: Hi All, I've read old archive about blocking SMTP port (TCP port 25). In my current situation we are mobile operator and use NAT for our subscribers and we have few spammers, a bit difficult to track it because mostly our subscribers are prepaid services. If we block TCP port 25, there might be good subscribers will not be able to send email. We are thinking to block MX queries on our DNS server, so only spammer that use their own SMTP server will got affected. All DNS queries from our subscribers already redirected to our DNS cache servers. But seem Bind don't have feature to block MX query. Any best practice to block MX query? Regards Ibrahim -- ??? BaconZombie LOAD *,8,1
Re: Blocking MX query
On Tue, Sep 4, 2012 at 3:48 PM, Ibrahim ibrah...@gmail.com wrote: Not block, but we use DNS transparent proxy mechanism. We need to do this as our government request all ISP to block porn sites :-) Plenty of ways to work around that actually. This stops random people from accessing porn sites but you are not likely to see spammers or bots get deterred too much by this mechanism. Still it does come in useful as part of a larger walled garden strategy. -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Blocking MX query
Hi Suresh, We create special NAT that all destination use TCP port 25 will be NATed to one public IP address only. And this public IP address is registered on most of RBLs. But we are still receiving complaint about spammer from this public IP address :-) Regards Ibrahim On Tue, Sep 4, 2012 at 5:12 PM, Suresh Ramasubramanian ops.li...@gmail.comwrote: Feel free to block port 25. Most if not all mail providers offer email access on webmail and on an alternate smtp port (587) If you have NAT - the problem is that if you have spammers abusing your service (or abusing other services on port 25) providers will end up blocking your NAT gateway IP and then you have a problem. You will want to look at walled gardens or similar to block spamming / infected users. Please see the maawg best practice for walled gardens and port 25 management. On Tue, Sep 4, 2012 at 3:37 PM, Ibrahim ibrah...@gmail.com wrote: Hi All, I've read old archive about blocking SMTP port (TCP port 25). In my current situation we are mobile operator and use NAT for our subscribers and we have few spammers, a bit difficult to track it because mostly our subscribers are prepaid services. If we block TCP port 25, there might be good subscribers will not be able to send email. We are thinking to block MX queries on our DNS server, so only spammer that use their own SMTP server will got affected. All DNS queries from our subscribers already redirected to our DNS cache servers. But seem Bind don't have feature to block MX query. Any best practice to block MX query? Regards Ibrahim -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Blocking MX query
Sure you will get it - but there's also spam through various webmail services, spam through the outbounds of different ISPs etc that you won't prevent with your approach. On Tue, Sep 4, 2012 at 3:54 PM, Ibrahim ibrah...@gmail.com wrote: We create special NAT that all destination use TCP port 25 will be NATed to one public IP address only. And this public IP address is registered on most of RBLs. But we are still receiving complaint about spammer from this public IP address :-) -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Blocking MX query
Ibrahim ibrah...@gmail.com wrote: We are thinking to block MX queries on our DNS server, so only spammer that use their own SMTP server will got affected. [...] Any best practice to block MX query? Don't do this. It won't hinder spammers and it'll cause problems for legit users. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first.
Re: Blocking MX query
On Tue, Sep 4, 2012 at 6:07 AM, Ibrahim ibrah...@gmail.com wrote: I've read old archive about blocking SMTP port (TCP port 25). In my current situation we are mobile operator and use NAT for our subscribers and we have few spammers, a bit difficult to track it because mostly our subscribers are prepaid services. If we block TCP port 25, there might be good subscribers will not be able to send email. Hi, There are no good subscribers trying to send email direct to a remote port 25 from behind a NAT. The good subscribers are either using your local smart host or they're using TCP port 587 on their remote mail server. You may safely block outbound TCP with a destination of port 25 from behind your NAT without harming reasonable use of your network. We are thinking to block MX queries on our DNS server, so only spammer that use their own SMTP server will got affected. All DNS queries from our subscribers already redirected to our DNS cache servers. But seem Bind don't have feature to block MX query. Any best practice to block MX query? Best practice is: don't mess with the DNS. I don't know if any resolver software supports what you want to do here. If it does, I don't know what the repercussions are likely to be. I do know that historically, altering DNS results has proven problematic. For example, returning an A record for your search server in place of no-host responses wreaks all manner of havoc. I also doubt the efficacy of the method. Were this to become common practice, a spammer could trivially evade it by using his own DNS software or simply pumping out the address list along with pre-resolved IP addresses to deliver the mail to. For all I know, they already do. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Regarding smaller prefix for hijack protection
This seems like an opportune time to remind people about RPKI-based origin validation as a hijack mitigation: http://tools.ietf.org/html/draft-ietf-sidr-pfx-validate-08 http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_bgp/configuration/15-2s/irg-origin-as.pdf I haven't run the numbers, but it seems like doing RPKI-based origin validation is probably a lot cheaper than upgrading routers to store a fully deaggregated route table :) On Tue, Sep 4, 2012 at 12:29 PM, Aftab Siddiqui aftab.siddi...@gmail.com wrote: The thing to acknowledge is that you've realized it otherwise if you follow the CIDR report than you will find bunch of arrogant folks/SPs not willing to understand the dilemma they are causing through de-aggregation. Regards, Aftab A. Siddiqui On Tue, Sep 4, 2012 at 10:19 AM, Anurag Bhatia m...@anuragbhatia.com wrote: I didn't realized the routing table size problem with /24's. Stupid me. Thanks everyone for updates. Appreciate good answers.
Strange Reachability Issue
Hello all, I was wondering if anyone might be able to share their thoughts on a strange issue we're experiencing with NTT at the moment. We're AS48273 and are advertising a prefix 94.198.184.0/21 through AS 8190 (single upstream provider at the moment). We've been doing this for some years now, and all has been fine. The last few days we seem to have disappeared from NTT's worldwide routing tables, with the exception of Europe. If we use their looking glass to query any NTT european router we can see the prefix, being learned via AS 286 then AS 8190, as expected. If we look at any other router outside of europe, there is simply no entry for that prefix. Elsewhere in the world we seem to be fine, we're in every other network I've looked at and general reachability is fine. First step was to contact the NTT NOC, and they've confirmed that there's no Internal routing/config issue on their network, but that they cannot discuss their peering arrangements due to NDAs. We've also picked it up with KPN (AS 286), who have verified that the prefix is visible throughout their network (true), and that they are advertising it to NTT. One thing of note is that Global Crossing are learning our prefix from KPN as well, and the prefix is showing fine in their global tables. We seem to be caught in the classic finger pointing scenario, but I can't get my head around why the prefix is visible in NTT Europe, but not anywhere else, unless they have a config error somewhere on their network. We've checked a few of the routes from AS 8190 and they are in the NTT global tables just fine, and at least in Europe they seem to have the same community values etc. We're still following on with NTT, but can anyone offer some wisdom for new avenues to pursue? Thanks for your help, Bryn Sadler This message has been scanned for viruses by essensys mailcontrol
Re: Blocking MX query
On Tue, Sep 04, 2012 at 08:05:06AM -0400, William Herrin wrote: I also doubt the efficacy of the method. Were this to become common practice, a spammer could trivially evade it by using his own DNS software or simply pumping out the address list along with pre-resolved IP addresses to deliver the mail to. For all I know, they already do. You're precisely correct. They've been doing this for many years, (a) because it's efficient (b) because it evades detection by techniques that monitor MX query volume (c) because few MX's change often (d) because it scales beautifully across large botnets. ---rsk
RE: Strange Reachability Issue
I will bet that will bet that within 48 hours of you checking and posting this the problem will mysteriously go away. Ralph Brandt Mechanicsburg PA 17055 -Original Message- From: Bryn Sadler [mailto:bryn.sad...@essensys.co.uk] Sent: Tuesday, September 04, 2012 9:02 AM To: nanog@nanog.org Subject: Strange Reachability Issue Hello all, I was wondering if anyone might be able to share their thoughts on a strange issue we're experiencing with NTT at the moment. We're AS48273 and are advertising a prefix 94.198.184.0/21 through AS 8190 (single upstream provider at the moment). We've been doing this for some years now, and all has been fine. The last few days we seem to have disappeared from NTT's worldwide routing tables, with the exception of Europe. If we use their looking glass to query any NTT european router we can see the prefix, being learned via AS 286 then AS 8190, as expected. If we look at any other router outside of europe, there is simply no entry for that prefix. Elsewhere in the world we seem to be fine, we're in every other network I've looked at and general reachability is fine. First step was to contact the NTT NOC, and they've confirmed that there's no Internal routing/config issue on their network, but that they cannot discuss their peering arrangements due to NDAs. We've also picked it up with KPN (AS 286), who have verified that the prefix is visible throughout their network (true), and that they are advertising it to NTT. One thing of note is that Global Crossing are learning our prefix from KPN as well, and the prefix is showing fine in their global tables. We seem to be caught in the classic finger pointing scenario, but I can't get my head around why the prefix is visible in NTT Europe, but not anywhere else, unless they have a config error somewhere on their network. We've checked a few of the routes from AS 8190 and they are in the NTT global tables just fine, and at least in Europe they seem to have the same community values etc. We're still following on with NTT, but can anyone offer some wisdom for new avenues to pursue? Thanks for your help, Bryn Sadler This message has been scanned for viruses by essensys mailcontrol
Re: Strange Reachability Issue
I know a few folks from NTT have looked into this. If someone from KPN would get in touch with Bryn I'm sure the issue could be quickly resolved. - Jared On Sep 4, 2012, at 9:18 AM, Brandt, Ralph wrote: I will bet that will bet that within 48 hours of you checking and posting this the problem will mysteriously go away. Ralph Brandt Mechanicsburg PA 17055 -Original Message- From: Bryn Sadler [mailto:bryn.sad...@essensys.co.uk] Sent: Tuesday, September 04, 2012 9:02 AM To: nanog@nanog.org Subject: Strange Reachability Issue Hello all, I was wondering if anyone might be able to share their thoughts on a strange issue we're experiencing with NTT at the moment. We're AS48273 and are advertising a prefix 94.198.184.0/21 through AS 8190 (single upstream provider at the moment). We've been doing this for some years now, and all has been fine. The last few days we seem to have disappeared from NTT's worldwide routing tables, with the exception of Europe. If we use their looking glass to query any NTT european router we can see the prefix, being learned via AS 286 then AS 8190, as expected. If we look at any other router outside of europe, there is simply no entry for that prefix. Elsewhere in the world we seem to be fine, we're in every other network I've looked at and general reachability is fine. First step was to contact the NTT NOC, and they've confirmed that there's no Internal routing/config issue on their network, but that they cannot discuss their peering arrangements due to NDAs. We've also picked it up with KPN (AS 286), who have verified that the prefix is visible throughout their network (true), and that they are advertising it to NTT. One thing of note is that Global Crossing are learning our prefix from KPN as well, and the prefix is showing fine in their global tables. We seem to be caught in the classic finger pointing scenario, but I can't get my head around why the prefix is visible in NTT Europe, but not anywhere else, unless they have a config error somewhere on their network. We've checked a few of the routes from AS 8190 and they are in the NTT global tables just fine, and at least in Europe they seem to have the same community values etc. We're still following on with NTT, but can anyone offer some wisdom for new avenues to pursue? Thanks for your help, Bryn Sadler This message has been scanned for viruses by essensys mailcontrol
Re: Strange Reachability Issue
Many thanks to Jared for jumping on this so quickly off-list, it's much appreciated and hopefully we're getting towards a solution now. Bryn On 04/09/2012 15:12, Jared Mauch ja...@puck.nether.net wrote: I know a few folks from NTT have looked into this. If someone from KPN would get in touch with Bryn I'm sure the issue could be quickly resolved. - Jared On Sep 4, 2012, at 9:18 AM, Brandt, Ralph wrote: I will bet that will bet that within 48 hours of you checking and posting this the problem will mysteriously go away. Ralph Brandt Mechanicsburg PA 17055 -Original Message- From: Bryn Sadler [mailto:bryn.sad...@essensys.co.uk] Sent: Tuesday, September 04, 2012 9:02 AM To: nanog@nanog.org Subject: Strange Reachability Issue Hello all, I was wondering if anyone might be able to share their thoughts on a strange issue we're experiencing with NTT at the moment. We're AS48273 and are advertising a prefix 94.198.184.0/21 through AS 8190 (single upstream provider at the moment). We've been doing this for some years now, and all has been fine. The last few days we seem to have disappeared from NTT's worldwide routing tables, with the exception of Europe. If we use their looking glass to query any NTT european router we can see the prefix, being learned via AS 286 then AS 8190, as expected. If we look at any other router outside of europe, there is simply no entry for that prefix. Elsewhere in the world we seem to be fine, we're in every other network I've looked at and general reachability is fine. First step was to contact the NTT NOC, and they've confirmed that there's no Internal routing/config issue on their network, but that they cannot discuss their peering arrangements due to NDAs. We've also picked it up with KPN (AS 286), who have verified that the prefix is visible throughout their network (true), and that they are advertising it to NTT. One thing of note is that Global Crossing are learning our prefix from KPN as well, and the prefix is showing fine in their global tables. We seem to be caught in the classic finger pointing scenario, but I can't get my head around why the prefix is visible in NTT Europe, but not anywhere else, unless they have a config error somewhere on their network. We've checked a few of the routes from AS 8190 and they are in the NTT global tables just fine, and at least in Europe they seem to have the same community values etc. We're still following on with NTT, but can anyone offer some wisdom for new avenues to pursue? Thanks for your help, Bryn Sadler This message has been scanned for viruses by essensys mailcontrol
Re: Blocking MX query
- Original Message - From: William Herrin b...@herrin.us There are no good subscribers trying to send email direct to a remote port 25 from behind a NAT. Users, like myself, running Linux on home computers and laptops; our local sendmail-equivalents will in fact attempt direct delivery to remote SMTP MX servers, and we generally move around enough that setting a smarthost is semi-impractical, at least on laptops. I'm a bad subscriber, Bill? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Strange Reachability Issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On 09/04/2012 07:20 AM, Bryn Sadler wrote: Many thanks to Jared for jumping on this so quickly off-list, it's much appreciated and hopefully we're getting towards a solution now. Bryn - -- yup you are in good hands, sounds more like filtering related among peers. Use can use communities to test this theory. regards, /virendra On 04/09/2012 15:12, Jared Mauch ja...@puck.nether.net wrote: I know a few folks from NTT have looked into this. If someone from KPN would get in touch with Bryn I'm sure the issue could be quickly resolved. - Jared On Sep 4, 2012, at 9:18 AM, Brandt, Ralph wrote: I will bet that will bet that within 48 hours of you checking and posting this the problem will mysteriously go away. Ralph Brandt Mechanicsburg PA 17055 -Original Message- From: Bryn Sadler [mailto:bryn.sad...@essensys.co.uk] Sent: Tuesday, September 04, 2012 9:02 AM To: nanog@nanog.org Subject: Strange Reachability Issue Hello all, I was wondering if anyone might be able to share their thoughts on a strange issue we're experiencing with NTT at the moment. We're AS48273 and are advertising a prefix 94.198.184.0/21 through AS 8190 (single upstream provider at the moment). We've been doing this for some years now, and all has been fine. The last few days we seem to have disappeared from NTT's worldwide routing tables, with the exception of Europe. If we use their looking glass to query any NTT european router we can see the prefix, being learned via AS 286 then AS 8190, as expected. If we look at any other router outside of europe, there is simply no entry for that prefix. Elsewhere in the world we seem to be fine, we're in every other network I've looked at and general reachability is fine. First step was to contact the NTT NOC, and they've confirmed that there's no Internal routing/config issue on their network, but that they cannot discuss their peering arrangements due to NDAs. We've also picked it up with KPN (AS 286), who have verified that the prefix is visible throughout their network (true), and that they are advertising it to NTT. One thing of note is that Global Crossing are learning our prefix from KPN as well, and the prefix is showing fine in their global tables. We seem to be caught in the classic finger pointing scenario, but I can't get my head around why the prefix is visible in NTT Europe, but not anywhere else, unless they have a config error somewhere on their network. We've checked a few of the routes from AS 8190 and they are in the NTT global tables just fine, and at least in Europe they seem to have the same community values etc. We're still following on with NTT, but can anyone offer some wisdom for new avenues to pursue? Thanks for your help, Bryn Sadler This message has been scanned for viruses by essensys mailcontrol -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iF4EAREIAAYFAlBGGlMACgkQ3HuimOHfh+GpNgD+PMX5zFgMcCc7pzLr9e/yskNs RESv+rEeZKC2t1UfpCYA/0vPN8JlgiRLoRi+S/kkJwOEXMlzYMnHS7eGkOn0YU4j =PJwR -END PGP SIGNATURE-
Re: Blocking MX query
On Tue, Sep 4, 2012 at 7:44 AM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: William Herrin b...@herrin.us There are no good subscribers trying to send email direct to a remote port 25 from behind a NAT. Users, like myself, running Linux on home computers and laptops; our local sendmail-equivalents will in fact attempt direct delivery to remote SMTP MX servers, and we generally move around enough that setting a smarthost is semi-impractical, at least on laptops. OpenVPN, et al... nice for being able to not only relay via the home server, but also access SMB or even NFS shares and the like, which you'd also not want reachable from the outside.
Re: Blocking MX query
What sort of an mta do you run on your laptop that doesnt support smtp auth? On Tuesday, September 4, 2012, Jay Ashworth wrote: - Original Message - From: William Herrin b...@herrin.us javascript:; There are no good subscribers trying to send email direct to a remote port 25 from behind a NAT. Users, like myself, running Linux on home computers and laptops; our local sendmail-equivalents will in fact attempt direct delivery to remote SMTP MX servers, and we generally move around enough that setting a smarthost is semi-impractical, at least on laptops. I'm a bad subscriber, Bill? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com javascript:; Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Blocking MX query
- Original Message - From: Suresh Ramasubramanian ops.li...@gmail.com What sort of an mta do you run on your laptop that doesnt support smtp auth? SMTP Auth to *arbitrary remote domains' MX servers*? Am I missing something, or are you? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
The End-To-End Internet (was Re: Blocking MX query)
- Original Message - From: John Peach john-na...@johnpeach.com On Tue, 4 Sep 2012 11:57:38 -0400 (EDT) Jay Ashworth j...@baylink.com wrote: SMTP Auth to *arbitrary remote domains' MX servers*? Am I missing something, or are you? I run an MTA on my server and auth to that from laptops and other clients. Relaying allowed for authorised users. So, in other words, it's ok to rant and stomp our feet about the end-to-end architecture and how critical it is to support in order to diss NAT, but we're required to ignore it when discussing SMTP? I'm not sure I'm following, there. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Blocking MX query
Have your desktop MTA configured to relay through your smarthost with smtp auth? Howtos for doing this on sendmail, qmail, postfix etc are over a decade old now. On Sep 4, 2012 9:28 PM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Suresh Ramasubramanian ops.li...@gmail.com What sort of an mta do you run on your laptop that doesnt support smtp auth? SMTP Auth to *arbitrary remote domains' MX servers*? Am I missing something, or are you? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: The End-To-End Internet (was Re: Blocking MX query)
On 9/4/12 9:05 AM, Jay Ashworth wrote: - Original Message - From: John Peach john-na...@johnpeach.com On Tue, 4 Sep 2012 11:57:38 -0400 (EDT) Jay Ashworth j...@baylink.com wrote: SMTP Auth to *arbitrary remote domains' MX servers*? Am I missing something, or are you? I run an MTA on my server and auth to that from laptops and other clients. Relaying allowed for authorised users. So, in other words, it's ok to rant and stomp our feet about the end-to-end architecture and how critical it is to support in order to diss NAT, but we're required to ignore it when discussing SMTP? I'm not sure I'm following, there. Feelings on spam = this is why we can't have nice things ~Seth
Re: Blocking MX query
On 09/04/2012 05:05 AM, William Herrin wrote: There are no good subscribers trying to send email direct to a remote port 25 from behind a NAT. The good subscribers are either using your local smart host or they're using TCP port 587 on their remote mail server. You may safely block outbound TCP with a destination of port 25 from behind your NAT without harming reasonable use of your network. Would that were true going forward. Consider a world where your home is chock full of purpose built devices, most likely with an embedded web browser for configuration where you have a username/password for each. In the web world this works because there is a hidden assumption that you can use email for user/password reset/recovery and that it works well. When your boxen can't do that because email is blocked, what are you going to do? Reset to factory defaults? Every time I forget? And please lets not get another useless lecture on why the unwashed masses should be using password vaults. They won't. This hidden assumption of a reliable out of band mechanism for account recovery is going to come to the fore as v6 rolls out and ip is as gratuitously added to cheap devices as digital controls are now. Email is the glue that keeps the web world functioning. Until there's something else, it will continue to be needed and its role will expand in the home too. Mike
Re: Blocking MX query
On Tue, Sep 4, 2012 at 10:44 AM, Jay Ashworth j...@baylink.com wrote: There are no good subscribers trying to send email direct to a remote port 25 from behind a NAT. Users, like myself, running Linux on home computers and laptops; our local sendmail-equivalents will in fact attempt direct delivery to remote SMTP MX servers, and we generally move around enough that setting a smarthost is semi-impractical, at least on laptops. I'm a bad subscriber, Bill? Okay, fair enough. There are no good users *expecting* to send email direct to a remote port 25 from behind a NAT. There are some good users who occasionally run slightly sloppy configurations which might attempt spurious port 25 connections. Good to block port 25. Not good to knee-jerk ban users whose machines happen to poke the port once or twice. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Blocking MX query
- Original Message - From: William Herrin b...@herrin.us I'm a bad subscriber, Bill? Okay, fair enough. There are no good users *expecting* to send email direct to a remote port 25 from behind a NAT. There are some good users who occasionally run slightly sloppy configurations which might attempt spurious port 25 connections. I do, in fact, expect that. You're alleging that's a bad practice. Good to block port 25. Not good to knee-jerk ban users whose machines happen to poke the port once or twice. I wasn't even talking about banning or blocking me. I was, as you'll see in my other response, exercising the end-to-end architecture of the Internet, as members of this list regularly exhort that I should be able to. This is why we can't have nice things is not, actually, a sufficiently useful excuse for me to not agree with that principle. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: The End-To-End Internet (was Re: Blocking MX query)
- Original Message - From: Owen DeLong o...@delong.com I am confused... I don't understand your comment. It is regularly alleged, on this mailing list, that NAT is bad *because it violates the end-to-end principle of the Internet*, where each host is a full-fledged host, able to connect to any other host to perform transactions. We see it now alleged that the opposite is true: that a laptop, say, like mine, which runs Linux and postfix, and does not require a smarthost to deliver mail to a remote server *is a bad actor* *precisely because it does that* (in attempting to send mail directly to a domain's MX server) *from behind a NAT router*, and possibly different ones at different times. I find these conflicting reports very conflicting. Either the end-to-end principle *is* the Prime Directive... or it is *not*. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Blocking MX query
On Tue, Sep 4, 2012 at 12:59 PM, Michael Thomas m...@mtcc.com wrote: On 09/04/2012 05:05 AM, William Herrin wrote: There are no good subscribers trying to send email direct to a remote port 25 from behind a NAT. The good subscribers are either using your local smart host or they're using TCP port 587 on their remote mail server. You may safely block outbound TCP with a destination of port 25 from behind your NAT without harming reasonable use of your network. Would that were true going forward. Consider a world where your home is chock full of purpose built devices, most likely with an embedded web browser for configuration where you have a username/password for each. In the web world this works because there is a hidden assumption that you can use email for user/password reset/recovery and that it works well. Hi Mike, A. What device do you offer as an example of this? I haven't stumbled across one yet. Web sites yes. Physical home devices, no. What I *have* seen is devices that call out to a web server, you make an account on the remote web server to configure them and then all the normal rules about accounts on remote web servers apply. B. Bad hidden assumption. Expect it to fail as more than a few cable and DSL providers are blocking random port 25 outbound. Besides, some folks change email accounts like they change underwear. Relying on that email address still working a year from now is not smart. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Blocking MX query
On Tue, Sep 4, 2012 at 11:57 AM, Jay Ashworth j...@baylink.com wrote: What sort of an mta do you run on your laptop that doesnt support smtp auth? SMTP Auth to *arbitrary remote domains' MX servers*? Am I missing something, or are you? You are. You should be doing SMTP Auth to *your* email server on which you have an authorized account and then letting it relay your messages to the world. Okay, fair enough. There are no good users *expecting* to send email direct to a remote port 25 from behind a NAT. There are some good users who occasionally run slightly sloppy configurations which might attempt spurious port 25 connections. I do, in fact, expect that. You're alleging that's a bad practice. Yes, I am. Here's a few others. http://security.comcast.net/get-help/spam.aspx Port 25 Blocking Port 25 is conduit on a computer that spammers can take control of and use to send their spam - often without the user ever knowing his/her computer has been hijacked. Comcast works with our customers to block access to Port 25 and protect their PC. Comcast recommends that our customers establish a more secure email configuration on their PC - Port 587 - We have made it easy by creating a one-click fix that automatically configures your computers to this safer PC configuration. http://qwest.centurylink.com/internethelp/email-troubleshooting-port25.html CenturyLink filters port 25 to reduce the spread of email viruses and spam (unsolicited email). Filtering port 25 has become the industry standard to reduce the spread of email viruses and spam. These email viruses allow malicious software to control infected computers. These viruses direct the infected machines to send email viruses and spam through port 25. http://cbl.abuseat.org/nat.html The simplest and most effective way to stop this is to configure your NAT to prohibit connections to the Internet on port 25 except from real mail servers. Not only does this stop all of these viruses and spams dead in their tracks, the NAT logs will immediately tell you the LAN address of the infected machine. http://tools.ietf.org/html/rfc5068 A proactive technique used by some providers is to block all use of port 25 SMTP for mail that is being sent outbound, or to automatically redirect this traffic through a local SMTP proxy, except for hosts that are explicitly authorized. http://www.microsoft.com/security/sir/strategy/default.aspx#!section_2_4 Block access to port 25 from all hosts on your network other than those you explicitly authorize to perform SMTP relay functions. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Blocking MX query
On 09/04/2012 11:55 AM, William Herrin wrote: On Tue, Sep 4, 2012 at 12:59 PM, Michael Thomas m...@mtcc.com wrote: On 09/04/2012 05:05 AM, William Herrin wrote: There are no good subscribers trying to send email direct to a remote port 25 from behind a NAT. The good subscribers are either using your local smart host or they're using TCP port 587 on their remote mail server. You may safely block outbound TCP with a destination of port 25 from behind your NAT without harming reasonable use of your network. Would that were true going forward. Consider a world where your home is chock full of purpose built devices, most likely with an embedded web browser for configuration where you have a username/password for each. In the web world this works because there is a hidden assumption that you can use email for user/password reset/recovery and that it works well. Hi Mike, A. What device do you offer as an example of this? I haven't stumbled across one yet. Web sites yes. Physical home devices, no. What I *have* seen is devices that call out to a web server, you make an account on the remote web server to configure them and then all the normal rules about accounts on remote web servers apply. I want to buy hardware from people, not their ill-conceived cloud service that dies when there's no more business case for it and is probably evil anyway. B. Bad hidden assumption. Expect it to fail as more than a few cable and DSL providers are blocking random port 25 outbound. Besides, some folks change email accounts like they change underwear. Relying on that email address still working a year from now is not smart. I'm well aware of port 25 blocking. I'm saying your assumption that there is *never* any reason for a home originating port 25 traffic is a bad one. It's never been a good one, but the collateral damage was pretty low when NAT's are in the way. v6 will change that, and the collateral damage will rise. Unless you can come up with another ubiquitous out of band method for account recovery, expect the tension -- and help desk calls -- to increase. Mike
Re: The End-To-End Internet (was Re: Blocking MX query)
On Sep 4, 2012, at 14:22, Jay Ashworth wrote: I find these conflicting reports very conflicting. Either the end-to-end principle *is* the Prime Directive... or it is *not*. Just because something is of extremely high importance does not mean it still can't be overridden when there's good enough reason. In this case, in the majority of random computer on the internet IP blocks the ratio of spambots to legitimate mail senders is so far off balance that a whitelisting approach to allowing outbound port 25 traffic is not unreasonable. Unlike the bad kinds of NAT, this doesn't also indiscriminately block thousands of other uses, it exclusively affects email traffic in a way which is trivial for the legitimate user to work around while stopping the random infected hosts in their tracks. Many providers also block traffic on ports like 137 (NetBIOS) on consumer space for similar reasons, the malicious or unwanted uses vastly outweigh the legitimate ones. The reason bad NATs get dumped on is because there are better solutions both known and available on the market. If you have an idea for a way to allow your laptop to send messages directly while still stopping or minimizing the ability of the thousands of zombies sharing an ISP with you from doing the same the world would love to hear it. --- Sean Harlow s...@seanharlow.info
Re: Blocking MX query
- Original Message - From: William Herrin b...@herrin.us SMTP Auth to *arbitrary remote domains' MX servers*? Am I missing something, or are you? You are. You should be doing SMTP Auth to *your* email server on which you have an authorized account and then letting it relay your messages to the world. Ah; so then the End-To-End Principle is *not* The Prime Directive. Good; thanks. Can we stop flogging people with it who like DNAT, then? Cheers -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: The End-To-End Internet (was Re: Blocking MX query)
On Tue, Sep 4, 2012 at 2:22 PM, Jay Ashworth j...@baylink.com wrote: It is regularly alleged, on this mailing list, that NAT is bad *because it violates the end-to-end principle of the Internet*, where each host is a full-fledged host, able to connect to any other host to perform transactions. That's what firewalls *are for* Jay. They intentionally break end-to-end for communications classified by the network owner as undesirable. Whether a particular firewall employs NAT or not is largely beside the point here. Either way, the firewall is *supposed* to break some of the end to end communication paths. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: The End-To-End Internet (was Re: Blocking MX query)
On 9/4/2012 2:22 PM, Jay Ashworth wrote: - Original Message - From: Owen DeLong o...@delong.com I am confused... I don't understand your comment. It is regularly alleged, on this mailing list, that NAT is bad *because it violates the end-to-end principle of the Internet*, where each host is a full-fledged host, able to connect to any other host to perform transactions. We see it now alleged that the opposite is true: that a laptop, say, like mine, which runs Linux and postfix, and does not require a smarthost to deliver mail to a remote server *is a bad actor* *precisely because it does that* (in attempting to send mail directly to a domain's MX server) *from behind a NAT router*, and possibly different ones at different times. I find these conflicting reports very conflicting. Either the end-to-end principle *is* the Prime Directive... or it is *not*. The end-to-end design principle pushes application functions to endpoints instead of placing these functions in the network itself. This principle requires that endpoints be *capable* of creating connections to each other. Network system design must support these connections being initiated by either side - which is where NAT implementations usually fail. There is no requirement that all endpoints be *permitted* to connect to and use any service of any other endpoint. The end-to-end design principle does not require a complete lack of authentication or authorization. I can refuse connections to port 25 on my endpoint (mail server) from hosts that do not conform to my requirements (e.g. those that do not have forward-confirmed reverse DNS) without violating the end-to-end design principle in any way. Thus it is a false chain of conclusions to say that: - end-to-end is violated by restricting connections to/from certain hosts [therefore] - the end-to-end design principle is not important [therefore] - NAT is good ...which I believe is the argument that was being made? ... Ref - http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf Cheers, -- jra
Re: The End-To-End Internet (was Re: Blocking MX query)
- Original Message - From: William Herrin b...@herrin.us That's what firewalls *are for* Jay. They intentionally break end-to-end for communications classified by the network owner as undesirable. Whether a particular firewall employs NAT or not is largely beside the point here. Either way, the firewall is *supposed* to break some of the end to end communication paths. Correct, Bill. Hopefully, everyone else here who thinks DNAT is the anti-Christ heard the largely beside the point part of your assertion, with which I agree. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: The End-To-End Internet (was Re: Blocking MX query)
On 09/04/2012 01:07 PM, David Miller wrote: There is no requirement that all endpoints be *permitted* to connect to and use any service of any other endpoint. The end-to-end design principle does not require a complete lack of authentication or authorization. I can refuse connections to port 25 on my endpoint (mail server) from hosts that do not conform to my requirements (e.g. those that do not have forward-confirmed reverse DNS) without violating the end-to-end design principle in any way. The thing that has never set well with me with ISP blanket port 25 blocking is that the fate sharing is not correct. If I have a mail server and I refuse to take incoming connects from dynamic home IP blocks, the fate sharing is correct: I'm only hurting myself if there's collateral damage. When ISP's have blanket port 25, the two parties of the intended conversation never get a say: things just break mysteriously as far as both parties are concerned, but the ISP isn't hurt at all. So they have no incentive to drop their false positive rate. That's not good. Mike
RE: 91.201.64.0/22 hijacked?
It does not sound as though the original holders of the space know/care - if they are out of business, they probably don't care. If they are actively involved in it, then it's not a hijack. If they haven't updated their company name/website, then it's not a hijack, just poor record keeping. If you suspect the address space is abandoned, or hijacked, report it to RIPE. It may not get deallocated and reassinged until a few months after the bill stops getting paid. --Heather -Original Message- From: Jeroen van Aart [mailto:jer...@mompl.net] Sent: Friday, August 31, 2012 2:39 PM To: NANOG list Subject: 91.201.64.0/22 hijacked? The below email exchange may be of interest to some of you. The practical upshot is that it appears the 91.201.64.0/22 range was hijacked and should be included into the DROP list. As an interesting aside, quoting a friend: the original company (that performed dangerous waste utilization) may have been a shady thing in and of itself (..) what most companies calling themselves ecoservice (with variations) do is take money for safe utilisation of hazardous waste, and then dump it in some old quarry out in the remote (or not so remote) corner of a forest or other natural area (..) they always have criminal links and protection from corrupts officials (often co-owners) and security/law enforcement services From: Jeroen van Aart there is nothing but crap coming from 91.201.64.0/24. Amongst other things attempts to spam (through) wordpress sites. inetnum: 91.201.64.0 - 91.201.67.255 netname: Donekoserv descr: DonEkoService Ltd Don - name of the nearby large river. EkoService means ecological service. country: RU org: ORG-DS41-RIPE person: Haralevich Piotr address:novocherkassk, ul stremyannaya d.6 mnt-by: MNT-DONECO phone: +7495100 nic-hdl: HP2220-RIPE changed: ad...@donecoserv.ru 20101117 The company performed dangerous waste utilization: http://donekoservis.alloy.ru/contacts/ http://www.idbo.ru/view/72321/ But domains donecoserv.ru and donekoservis.ru don't exist anymore. traceroute 91.201.64.14 ... 11 router02.spbbm18.ru.edpnet.net (212.71.11.26) 65.979 ms 65.971 ms 66.182 ms 12 77.109.110.62.static.edpnet.net (77.109.110.62) 88.868 ms 47.809 ms 47.715ms 13 195.2.240.234 (195.2.240.234) 48.235 ms 48.546 ms 48.664 ms 14 ajursrv.parohod.biz (95.215.0.206) 47.957 ms 47.752 ms 47.606 ms 15 mail.rx-helps.com (91.201.64.14) 48.206 ms 48.302 ms 48.237 ms SPb (Sankt-Peterburg) is 1500 km from Novocherkassk. parohod.biz also is in Sankt-Peterburg, they offer SEO (which I consider fraud, spamming websites and search engines). Also, see http://support.clean-mx.de/clean-mx/viruses.php?email=ad...@donecoserv.ruresponse= http://www.spambotsecurity.com/forum/viewtopic.php?f=7t=795 http://unapprovedpharmacy.wordpress.com/2011/01/03/whois-www-canadianmedsshop-com/ | January 3, 2011 ... | inetnum: 91.201.64.0 91.201.67.255 | netname: Donekoserv | descr: DonEkoService Ltd | country: RU | org: ORG-DS41-RIPE ... | organisation: ORG-DS41-RIPE | org-name: DonEko Service | org-type: OTHER | address: novocherkassk, ul stremyannaya d.6 | e-mail: ad...@bulletproof-web.com Note bulletproof. Therefore, the 91.201.64.0/22 range was hijacked and should be included into the DROP list.
Re: The End-To-End Internet (was Re: Blocking MX query)
If you are sending direct SMTP on behalf of your domain from essentially random locations, how are we supposed to pick you out from spammers that do the same? Use your MX or SPF senders as your outbound mail agent, especially if they are properly configured with full DNS records so we can tell they are the correct machines to be sending on your behalf, or expect that you will get more mail bounced and lost than the average user because you are being unpredictable and unverifiable. On 09/04/2012 11:05 AM, Jay Ashworth wrote: - Original Message - From: John Peach john-na...@johnpeach.com On Tue, 4 Sep 2012 11:57:38 -0400 (EDT) Jay Ashworth j...@baylink.com wrote: SMTP Auth to *arbitrary remote domains' MX servers*? Am I missing something, or are you? I run an MTA on my server and auth to that from laptops and other clients. Relaying allowed for authorised users. So, in other words, it's ok to rant and stomp our feet about the end-to-end architecture and how critical it is to support in order to diss NAT, but we're required to ignore it when discussing SMTP? I'm not sure I'm following, there. Cheers, -- jra -- Daniel Taylor VP Operations Vocal Laboratories, Inc dtay...@vocalabs.com 952-941-6580x203
Re: The End-To-End Internet (was Re: Blocking MX query)
On 09/04/2012 09:34 AM, Daniel Taylor wrote: If you are sending direct SMTP on behalf of your domain from essentially random locations, how are we supposed to pick you out from spammers that do the same? Use DKIM. Mike
Research Project: Identifying DNSSEC Validators
Within Verisign Labs we have a project underway to quantify the number of DNSSEC-validating resolvers in use on the Internet. In particular, we want to identify recursive name servers which have configured the root zone trust anchor. We find this data a useful metric for DNSSEC adoption and especially helpful for informing discussions about key rollovers for the root zone. In order for our our measurements to be meaningful, we need to receive queries from a wide variety of recursive name servers. To achieve this goal we ask members of the DNS and networking communities to assist by adding the following single line of HTML code to your web pages: a href=http://prefetch.validatorsearch.verisignlabs.com;/a This HTML snippet should have no visible impact on a rendered page. Since nearly all web browsers now implement DNS prefetching, the code above results in a DNS query for the name shown and allows us to characterize the recursive name server that the query goes through. Please note that we are not interested in identifying individual users who have loaded the web page. The name above points to the localhost IP address (127.0.0.1) so even if someone does manage to click on it, that request does not reach us. For some preliminary results, please visit the project web page at http://validatorsearch.verisignlabs.com/ We look forward to presenting the full results at a future NANOG meeting. Duane W.
Re: Blocking MX query
Suresh Ramasubramanian wrote: Have your desktop MTA configured to relay through your smarthost with smtp auth? Howtos for doing this on sendmail, qmail, postfix etc are over a decade old now. What if, your home is also behind NAT or blocked port 25? Masataka Ohta
Re: Blocking MX query
Who cares about NAT when you say smtp auth rather than allowing relay for specific IPs? And if you mean your smarthost is a linux box in your home, it isn't impossible to get static IP broadband .. which is neither natted nor port 25 filtered. On Sep 5, 2012 6:01 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Suresh Ramasubramanian wrote: Have your desktop MTA configured to relay through your smarthost with smtp auth? Howtos for doing this on sendmail, qmail, postfix etc are over a decade old now. What if, your home is also behind NAT or blocked port 25? Masataka Ohta
Re: Blocking MX query
On 9/4/12, Rich Kulawiec r...@gsp.org wrote: You're precisely correct. They've been doing this for many years, (a) because it's efficient (b) because it evades detection by techniques that monitor MX query volume (c) because few MX's change often (d) because it scales beautifully across large botnets. One can begin to envision a spam avoidance scheme; where a mail server is assigned a random IP within an IPv6 prefix based on a EUI64/UUID. Two static MX records are published; each MX referencing short-lived records with a TTL of 60 seconds or less. One of those records points to the current IP address of the mail server, and one of those records point to the next one. A mail server binds to each address both previous and next and accepts port 25 connections for mail delivery. Every 60 seconds, the current address AAA record is changed to the IP listed in the next address AAA record; a new EUI64 is generated, and the next address record is populated with the new randomly generated IPV6 address. A mail server for the domain binds the new IP address and starts listening; and starts tarpitting any new port 25 connections from the previous address in 90 seconds. After 600 seconds, or when the IP is no longer in the most recent 5, an6 existing SMTP connections to the old server IP (from unacceptably slow senders/deliveries) are terminated, and the server removes the old IP from its interface. -- -JH
Re: Blocking MX query
MUA's can make MX queries to validate entered addresses before SMTP/SUBMISSION is even attempted. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Blocking MX query
On Wed, 05 Sep 2012 09:29:49 +0900, Masataka Ohta said: Suresh Ramasubramanian wrote: Have your desktop MTA configured to relay through your smarthost with smtp auth? Howtos for doing this on sendmail, qmail, postfix etc are over a decade old now. What if, your home is also behind NAT or blocked port 25? Weren't you the one who a few weeks ago was advocating more NAT rather than deploying IPv6? pgpMEkzRJ5Flv.pgp Description: PGP signature
Re: Blocking MX query
On Wed, Sep 5, 2012 at 6:38 AM, Mark Andrews ma...@isc.org wrote: MUA's can make MX queries to validate entered addresses before SMTP/SUBMISSION is even attempted. Sure but not on this guy's network as he's transparently proxying dns and blocking MX requests on his proxy Of course a bot can build up a rich cache of MX records from elsewhere and send from a botted 3g modem connected host on his network
Re: Blocking MX query
In message CAArzuost70Yq=KfXHXZSOV+ptg6apiDzm71=fhcs+ty_yo5...@mail.gmail.com, Suresh Ramasubramanian writes: On Wed, Sep 5, 2012 at 6:38 AM, Mark Andrews ma...@isc.org wrote: MUA's can make MX queries to validate entered addresses before SMTP/SUBMISSION is even attempted. Sure but not on this guy's network as he's transparently proxying dns and blocking MX requests on his proxy Well he was looking for software to block the queries. There is a whole mentality that homes don't need X which on closer examination just doesn't bear up to scrutany. This includes blocking SMTP or don't you think home users are entitled to have privacy when it comes to whom they email? STARTTLS from anywhere to anywhere is possible today and is not vulnerable to interception except in the MX's themselves. You can secure the MX records (and their absense) and secure the CERTs used by STARTTLS. Of course a bot can build up a rich cache of MX records from elsewhere and send from a botted 3g modem connected host on his network -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Blocking MX query
This is a bit of a slippery slope. There is broad agreement that SPs need to block port 25 outbound (and inbound) on dynamic IP space. And he did say he's in a country where he's obliged by law to filter out porn (and I guess anything else his country's government doesn't like). Where do blocking MX record lookups fit in between the porn blocking and the port 25 filtering? Rather closer to port 25 filtering I'd say, but your call. This is not a user privacy issue at all. Static IP broadband is entirely available if you should decide you want to run a mailserver at your home. And for people using outlook (or postfix) on their desktop to relay through a smarthost, MX lookups don't matter one way or the other. --srs On Wed, Sep 5, 2012 at 7:30 AM, Mark Andrews ma...@isc.org wrote: Well he was looking for software to block the queries. There is a whole mentality that homes don't need X which on closer examination just doesn't bear up to scrutany. This includes blocking SMTP or don't you think home users are entitled to have privacy when it comes to whom they email? STARTTLS from anywhere to anywhere is possible today and is not vulnerable to interception except in the MX's themselves. You can secure the MX records (and their absense) and secure the CERTs used by STARTTLS. -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Blocking MX query
On Sep 4, 2012, at 12:07 PM, William Herrin b...@herrin.us wrote: You are. You should be doing SMTP Auth to *your* email server on which you have an authorized account and then letting it relay your messages to the world. This is not the thread for this conversation per se. The practicality of general ISP 25 blocking is established for antispam purposes. So are power users running home domains. Different user profiles. Different circumstances. George William Herbert Sent from my iPhone
Re: Blocking MX query
All, thanks for the input and comment. In summary, I will block TCP port 25. My DNS loadbalancer (F5) can filter MX query and need license to do it. But given the information the botnet use address list with pre-resolved IP addresses then blocking MX query is not the answer :-) Thanks Regards Ibrahim On Wed, Sep 5, 2012 at 9:18 AM, George Herbert george.herb...@gmail.comwrote: On Sep 4, 2012, at 12:07 PM, William Herrin b...@herrin.us wrote: You are. You should be doing SMTP Auth to *your* email server on which you have an authorized account and then letting it relay your messages to the world. This is not the thread for this conversation per se. The practicality of general ISP 25 blocking is established for antispam purposes. So are power users running home domains. Different user profiles. Different circumstances. George William Herbert Sent from my iPhone
Re: Blocking MX query
On 9/4/12, Mark Andrews ma...@isc.org wrote: In message CAArzuost70Yq=KfXHXZSOV+ptg6apiDzm71=fhcs+ty_yo5...@mail.gmail.com, Suresh Ramasubramanian writes: STARTTLS from anywhere to anywhere is possible today and is not vulnerable to interception except in the MX's themselves. You can secure the MX records (and their absense) and secure the CERTs used by STARTTLS. You can also use SMTPS on port 465; or STARTTLS on port 587. Most MX servers don't support TLS or SSL, so it could be privacy neutral, and many MX server operators utilize dynamic host RBLs, even if STARTTLS connections are allowed. It is possible for end user to tunnel SMTP traffic over VPN, SSL, or SSH to a private submit server on a trusted network. Blocking initial outgoing TCP SYN for port 25 completely creates a predictable failure scenario. which is to be encouraged. ISPs very commonly block outgoing initial SYNs to that port. And ISPs also commonly block23, 135 - 139, 190, 389, 445, 1025, 1080, 1433 - 1434, 3380, 3389, 5060, 5070, 5631, 6667, 31337, 559. Some may block connections to all outgoing ports, except a small number. Those are all accepted practices, with increasing annoyance, and increasing predictable breakage, the more ports are messed with. Blocking few/no ports is desirable; and port 25 is so widely blocked, that MUAs should be set to 587 + authenticated submit in the first place. Tampering with the contents of packets, blocking application level traffic by creating fake application layer error messages, for example fake nxdomain/servfail response, or fake 550 rejected SMTP response, is to be strongly discouraged, because it causes unpredictable application failures. ISP routers aren't supposed to reject/accept packets based on application layer data. The exception would be you manage the end user computers, and dictate a very precise list of applications, so you can pick ones whose vendors list it as a supported thing, or you have gone through rigorous testing procedures. (Enterprise IDS units, that analyze packets and seek to block attacks by reacting to application content, are OK, for example) Of course a bot can build up a rich cache of MX records from elsewhere and send from a botted 3g modem connected host on his network Yes. It can also probe randomly for servers listening on port 25 based on A record lookup instead of MX, or by using Reverse DNS to find a domain, and then guess e-mail addresses. -- Mark Andrews, ISC -- -JH
Re: Blocking MX query
In message caaawwbxmxhs+8w2cv90b8x9xj0omvhtmwdy+wmycpw6giwf...@mail.gmail.com, Jimmy Hess writes: On 9/4/12, Mark Andrews ma...@isc.org wrote: In message CAArzuost70Yq=KfXHXZSOV+ptg6apiDzm71=fhcs+ty_yo5...@mail.gmail.com, Suresh Ramasubramanian writes: STARTTLS from anywhere to anywhere is possible today and is not vulnerable to interception except in the MX's themselves. You can secure the MX records (and their absense) and secure the CERTs used by STARTTLS. You can also use SMTPS on port 465; or STARTTLS on port 587. Most MX servers don't support TLS or SSL, so it could be privacy neutral, and many MX server operators utilize dynamic host RBLs, even if STARTTLS connections are allowed. It is possible for end user to tunnel SMTP traffic over VPN, SSL, or SSH to a private submit server on a trusted network. You missed the point. It *is* a privacy problem if my ISP can see the MAIL TO: u...@example.net. It is *unreasonable* to expect everyone to run their own submission server to avoid this privacy problem. Most MX's don't *currently* support STARTTLS because until recently it was difficult to prevent various MiM interception attacks and you had to pay for CERTs. Both of these reasons are in the process of going away. You can prevent MiM on MX records by using DNSSEC. You can generate and publish your own CERT records using DANE. Blocking initial outgoing TCP SYN for port 25 completely creates a predictable failure scenario. which is to be encouraged. Only if you don't care for user privacy. There is way to much data collection already. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Blocking MX query
valdis.kletni...@vt.edu wrote: Have your desktop MTA configured to relay through your smarthost with smtp auth? Howtos for doing this on sendmail, qmail, postfix etc are over a decade old now. What if, your home is also behind NAT or blocked port 25? Weren't you the one who a few weeks ago was advocating more NAT rather than deploying IPv6? NAT, here, means dumb NAT. With most, if not all, pseudo ISPs using NAT, you can't expect port forwarding services. While ISPs in the future should use not IPv6 but NAT with fixed IP addresses and sets of port numbers assigned to their customers, keeping the end to end transparency, it does not solve the problem of blocked port 25. Note that IPv6 do not solve the problem of blocked port 25, either. Masataka Ohta
Re: Blocking MX query
On Wed, Sep 5, 2012 at 9:10 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: While ISPs in the future should use not IPv6 but NAT with fixed IP addresses and sets of port numbers assigned to their customers, keeping the end to end transparency, it does not solve the problem of blocked port 25. Note that IPv6 do not solve the problem of blocked port 25, either. So - now with ipv6 you're going to see hi, my toto highly computerized toilet is trying to make outbound port 25 connections to gmail http://www.telecoms.com/48734/vodafone-and-ibm-team-up-on-connected-home-appliances/ -- Suresh Ramasubramanian (ops.li...@gmail.com)
