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
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 <ibrahim1@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.lists@gmail.com)
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.lists@gmail.com>wrote:
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.
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
On Tue, Sep 4, 2012 at 3:37 PM, Ibrahim <ibrahim1@gmail.com> wrote: 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.lists@gmail.com)
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 <ibrahim1@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.lists@gmail.com)
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 <ibrahim1@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
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 <baconzombie@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 <ibrahim1@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
On Tue, Sep 4, 2012 at 3:48 PM, Ibrahim <ibrahim1@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.lists@gmail.com)
Ibrahim <ibrahim1@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 <dot@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.
On Tue, Sep 4, 2012 at 6:07 AM, Ibrahim <ibrahim1@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 ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
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
On 9/4/12, Rich Kulawiec <rsk@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 AAAA records with a TTL of 60 seconds or less. One of those AAAA records points to the current IP address of the mail server, and one of those AAAA 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" AAAA 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
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: marka@isc.org
On Wed, Sep 5, 2012 at 6:38 AM, Mark Andrews <marka@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
In message <CAArzuost70Yq=KfXHXZSOV+ptg6apiDzm71=FhCS+Ty_yo5OAA@mail.gmail.com>, Suresh Ramasubramanian writes:
On Wed, Sep 5, 2012 at 6:38 AM, Mark Andrews <marka@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: marka@isc.org
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 <marka@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.lists@gmail.com)
On 9/4/12, Mark Andrews <marka@isc.org> wrote:
In message <CAArzuost70Yq=KfXHXZSOV+ptg6apiDzm71=FhCS+Ty_yo5OAA@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 block 23, 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
In message <CAAAwwbXMXhS+8w2CV90b8x9XJ0omvhTmWDY+WMyCPw6GiWfZMQ@mail.gmail.com>, Jimmy Hess writes:
On 9/4/12, Mark Andrews <marka@isc.org> wrote:
In message <CAArzuost70Yq=KfXHXZSOV+ptg6apiDzm71=FhCS+Ty_yo5OAA@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: <user@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: marka@isc.org
----- Original Message -----
From: "William Herrin" <bill@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 jra@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
On Tue, Sep 4, 2012 at 7:44 AM, Jay Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "William Herrin" <bill@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.
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" <bill@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 jra@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.lists@gmail.com)
----- Original Message -----
From: "Suresh Ramasubramanian" <ops.lists@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 jra@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
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" <jra@baylink.com> wrote:
----- Original Message -----
From: "Suresh Ramasubramanian" <ops.lists@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 jra@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
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" <mohta@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
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?
valdis.kletnieks@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
On Wed, Sep 5, 2012 at 9:10 AM, Masataka Ohta <mohta@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-app... -- Suresh Ramasubramanian (ops.lists@gmail.com)
On Sep 4, 2012, at 11:45 PM, Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
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-app...
-- Suresh Ramasubramanian (ops.lists@gmail.com)
Gives a new meaning to a sh*** connection. Or perhaps to flushing a mail queue... David Sent from a mobile device, please forgive autocorrection.
On Tue, Sep 4, 2012 at 11:57 AM, Jay Ashworth <jra@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 ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
----- Original Message -----
From: "William Herrin" <bill@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 jra@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
On Sep 4, 2012, at 12:07 PM, William Herrin <bill@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
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.herbert@gmail.com>wrote:
On Sep 4, 2012, at 12:07 PM, William Herrin <bill@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
On Tue, Sep 4, 2012 at 10:44 AM, Jay Ashworth <jra@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 ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
----- Original Message -----
From: "William Herrin" <bill@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 jra@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
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
On Tue, Sep 4, 2012 at 12:59 PM, Michael Thomas <mike@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 ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 09/04/2012 11:55 AM, William Herrin wrote:
On Tue, Sep 4, 2012 at 12:59 PM, Michael Thomas <mike@mtcc.com> 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
On 09/04/2012 05:05 AM, William Herrin wrote: 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
participants (15)
-
Bacon Zombie -
David Barak -
George Herbert -
Ibrahim -
Jay Ashworth -
Jimmy Hess -
Mark Andrews -
Masataka Ohta -
Michael Thomas -
Ray Wong -
Rich Kulawiec -
Suresh Ramasubramanian -
Tony Finch -
valdis.kletnieks＠vt.edu -
William Herrin