I am curious about what network operators are doing with outbound SMTP traffic. In the past few weeks we have ran into over 10 providers, mostly local providers, which block outbound SMTP and require the users to go THOUGH their mail servers even though those servers are not responsible for the domains in question! I know other mail servers are blocking non-reversible mail, however, is this common? And more importantly, is this an acceptable practice? Most of our smaller ISPs that we support; we allow any outbound SMTP connection, however we do watch residential users for 5+ outbound SMTP connections at the same time. But if the ISP has their own mail servers, and users wish to relay though them, we basically tell them to use their mail server that they contract with. What is the best practice? ----------------------------------------------------------- Dennis Burgess, Mikrotik Certified Trainer Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 <tel:314-735-0270> Website: http://www.linktechs.net <http://www.linktechs.net/> LIVE On-Line Mikrotik Training <http://www.onlinemikrotiktraining.com/> - Author of "Learn RouterOS" <http://routerosbook.com/>
On Oct 24, 2011, at 9:29 PM, Dennis Burgess wrote:
I am curious about what network operators are doing with outbound SMTP traffic. In the past few weeks we have ran into over 10 providers, mostly local providers, which block outbound SMTP and require the users to go THOUGH their mail servers even though those servers are not responsible for the domains in question! I know other mail servers are blocking non-reversible mail, however, is this common? And more importantly, is this an acceptable practice?
It's both unacceptable in my opinion and common. There are even those misguided souls that will tell you it is best practice, though general agreement, even among them seems to be that only 25/tcp should be blocked and that 465 and 587 should not be blocked.
Most of our smaller ISPs that we support; we allow any outbound SMTP connection, however we do watch residential users for 5+ outbound SMTP connections at the same time. But if the ISP has their own mail
servers, and users wish to relay though them, we basically tell them to use their mail server that they contract with. What is the best practice?
Best practice is to do what works and block as much SPAM as possible without destroying the internet in the process. There are those who argue that blocking 25/tcp does not destroy the internet. By and large, they are the same ones who believe NAT was good for us. Owen
On Oct 24, 2011, at 9:29 PM, Dennis Burgess wrote:
I am curious about what network operators are doing with outbound
SMTP
traffic. In the past few weeks we have ran into over 10 providers, mostly local providers, which block outbound SMTP and require the users to go THOUGH their mail servers even though those servers are not responsible for the domains in question! I know other mail servers are blocking non-reversible mail, however, is this common? And more importantly, is this an acceptable practice?
It's both unacceptable in my opinion and common. There are even those misguided souls that will tell you it is best practice, though general agreement, even among them seems to be that only 25/tcp should be blocked and that 465 and 587 should not be blocked.
[dmb] I would agree, for residential customers, if they use the "ISP" domain, then yes they should relay though the ISPs mail server. For business customers and other residential customers that do NOT use the ISP domain, then I think they should use their own mail server that they already pay for.
Most of our smaller ISPs that we support; we allow any outbound SMTP connection, however we do watch residential users for 5+ outbound
SMTP
connections at the same time. But if the ISP has their own mail
servers, and users wish to relay though them, we basically tell them to use their mail server that they contract with. What is the best practice?
Best practice is to do what works and block as much SPAM as possible without destroying the internet in the process. There are those who argue that blocking 25/tcp does not destroy the internet. By and large, they are the same ones who believe NAT was good for us.
Owen
[dmb] Lots of smaller ISPs out there run thousands of customers though NAT and I can see the need to properly "monitor" the SPAM activity on those IPs, not saying that is right, but I do see the point, in this event. But for ISPs that are handing out publics, I don't see how blocking outbound Port 25 helps, other than makes more support calls for the end users. Keep in mind that, ATT DSL and the local cable co here in STL, both block outbound port 25, but a simple phone call or e-mail to their support and they will remove the block.
Owen DeLong <owen@delong.com> writes:
It's both unacceptable in my opinion and common. There are even those misguided souls that will tell you it is best practice, though general agreement, even among them seems to be that only 25/tcp should be blocked and that 465 and 587 should not be blocked.
It is definitely considered best practice in some areas. See e.g. http://translate.google.com/translate?hl=en&u=http://ikt-norge.no/wp-content/uploads/2010/10/bransjenorm-SPAM.pdf (couldn't find an english original, but the google translation looks OK) The document is signed by all major ISPs in Norway as well as the Norwegian research and education network operator, so it must be considered a local "best practice" whether you like it or not. Note that only port 25/tcp is blocked and that some of the ISPs offer a per-subscriber optout. Eh, this was the Northern Aurope NOG, wasn't it? Bjørn
I'm curious how a traveller is supposed to get SMTP relay service when, well, travelling. I am not really sure if I want a VPN for sending a simple email. And I can understand (although I am not convinced that doing so is such a great idea) blocking 25/tcp outgoing, as most botnets will try that method of delivery. However, I do believe that outgoing 465 SHOULD always be allowed. regards Carlos On Tue, Oct 25, 2011 at 10:43 AM, Bjørn Mork <bjorn@mork.no> wrote:
Owen DeLong <owen@delong.com> writes:
It's both unacceptable in my opinion and common. There are even those misguided souls that will tell you it is best practice, though general agreement, even among them seems to be that only 25/tcp should be blocked and that 465 and 587 should not be blocked.
It is definitely considered best practice in some areas. See e.g. http://translate.google.com/translate?hl=en&u=http://ikt-norge.no/wp-content/uploads/2010/10/bransjenorm-SPAM.pdf (couldn't find an english original, but the google translation looks OK)
The document is signed by all major ISPs in Norway as well as the Norwegian research and education network operator, so it must be considered a local "best practice" whether you like it or not.
Note that only port 25/tcp is blocked and that some of the ISPs offer a per-subscriber optout.
Eh, this was the Northern Aurope NOG, wasn't it?
Bjørn
-- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =========================
I'm curious how a traveller is supposed to get SMTP relay service when, well, travelling. I am not really sure if I want a VPN for sending a simple email.
And I can understand (although I am not convinced that doing so is such a great idea) blocking 25/tcp outgoing, as most botnets will try that method of delivery. However, I do believe that outgoing 465 SHOULD always be allowed.
regards
Carlos
[dmb] This is the exact question, why, do you NEED a SMTP Relay on ANY network. Your domain has a mail server out on the net that if you authenticate to, I am sure will relay your mail, and the reverse DNS and SPF records would match then as well. Why does the local internet provide NEED to relay though their server, regardless of the port.
On Tue, Oct 25, 2011 at 10:43 AM, Bjørn Mork <bjorn@mork.no> wrote:
Owen DeLong <owen@delong.com> writes:
It's both unacceptable in my opinion and common. There are even those misguided souls that will tell you it is best practice, though general agreement, even among them seems to be that only 25/tcp should be blocked and that 465 and 587 should not be blocked.
It is definitely considered best practice in some areas. See e.g. http://translate.google.com/translate?hl=en&u=http://ikt-norge.no/wp-c ontent/uploads/2010/10/bransjenorm-SPAM.pdf (couldn't find an english original, but the google translation looks OK)
The document is signed by all major ISPs in Norway as well as the Norwegian research and education network operator, so it must be considered a local "best practice" whether you like it or not.
Note that only port 25/tcp is blocked and that some of the ISPs offer a per-subscriber optout.
Eh, this was the Northern Aurope NOG, wasn't it?
Bjørn
-- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =========================
On Tue, Oct 25, 2011 at 10:57, Dennis Burgess <dmburgess@linktechs.net>wrote:
[dmb] This is the exact question, why, do you NEED a SMTP Relay on ANY network. Your domain has a mail server out on the net that if you authenticate to, I am sure will relay your mail, and the reverse DNS and SPF records would match then as well. Why does the local internet provide NEED to relay though their server, regardless of the port.
Not every domain actually has a mail server that allows remote authentication/relay. People hosting small vanity domains with cheap hosting providers might not. Maybe people using small ISPs with less-than-top-notch staff. Heck, maybe there's just a short-term issue with the mail server, and you still want/need to send something out right now, so you use your ISP's mail system. David Smith MVN.net
My point exactly, I am perfectly happy authenticating and relaying through either my MX at the office or with Google's SMTP server. But I just can't do that if SMTPoSSL ports are blocked by some lazy net admin. And I definitely hate it when I have to "pay" (in terms of delay and overhead) the price of a VPN in order to just send a couple of emails. cheers Carlos On Tue, Oct 25, 2011 at 1:57 PM, Dennis Burgess <dmburgess@linktechs.net> wrote:
I'm curious how a traveller is supposed to get SMTP relay service when, well, travelling. I am not really sure if I want a VPN for sending a simple email.
And I can understand (although I am not convinced that doing so is such a great idea) blocking 25/tcp outgoing, as most botnets will try that method of delivery. However, I do believe that outgoing 465 SHOULD always be allowed.
regards
Carlos
[dmb] This is the exact question, why, do you NEED a SMTP Relay on ANY network. Your domain has a mail server out on the net that if you authenticate to, I am sure will relay your mail, and the reverse DNS and SPF records would match then as well. Why does the local internet provide NEED to relay though their server, regardless of the port.
On Tue, Oct 25, 2011 at 10:43 AM, Bjørn Mork <bjorn@mork.no> wrote:
Owen DeLong <owen@delong.com> writes:
It's both unacceptable in my opinion and common. There are even those misguided souls that will tell you it is best practice, though general agreement, even among them seems to be that only 25/tcp should be blocked and that 465 and 587 should not be blocked.
It is definitely considered best practice in some areas. See e.g. http://translate.google.com/translate?hl=en&u=http://ikt-norge.no/wp-c ontent/uploads/2010/10/bransjenorm-SPAM.pdf (couldn't find an english original, but the google translation looks OK)
The document is signed by all major ISPs in Norway as well as the Norwegian research and education network operator, so it must be considered a local "best practice" whether you like it or not.
Note that only port 25/tcp is blocked and that some of the ISPs offer a per-subscriber optout.
Eh, this was the Northern Aurope NOG, wasn't it?
Bjørn
-- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =========================
-- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =========================
Owen DeLong wrote:
It's both unacceptable in my opinion and common. There are even those misguided souls that will tell you it is best practice, though general agreement, even among them seems to be that only 25/tcp should be blocked and that 465 and 587 should not be blocked.
From my consumer POV. If you get a static IP with your provider, whether it is home internet or co-location, there should not be anything blocked. You're paying extra for the static IP in the case of home internet and the least you can expect is no blocking. Otherwise what's the point? You can always block/cancel later in case of abuse obviously. Of course this (and the below) does not apply in case of dynamically assigned IPs to a pool of home internet users.
Best practice is to do what works and block as much SPAM as possible without destroying the internet in the process. There are those who argue that blocking 25/tcp does not destroy the internet. By and large, they are the same ones who believe NAT was good for us.
There shouldn't be any spam filtering or blocking on a static IP at the ISP level. The ISP should limit itself to filtering at their own mail servers. Greetings, Jeroen -- Earthquake Magnitude: 3.6 Date: Tuesday, October 25, 2011 18:20:24 UTC Location: Arizona Latitude: 34.8137; Longitude: -112.5391 Depth: 5.00 km
On our retail footprint we block outbound traffic from customers with dynamic IPs towards port 25, our support tells them to use their ISP's port 587 server.... That being said, since all of our home users have 50 mbit/sec or greater upload speeds we are pretty paranoid about the amount of spam that could be originated. We don't block anything on static assignments. Honestly, even as a very geeky user, I probably would not have noticed the block and I can confirm that it is massively important to lowering our spam footprint as a network. I asked our support people, and none of them had ever really had an issue with this policy in terms of keeping customers. I agree with Ricky's current comment on this thread, blocking is unfortunately necessary on the modern consumer portions of the internet. Thanks, John van Oppen -----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Monday, October 24, 2011 9:37 PM To: Dennis Burgess Cc: nanog@nanog.org Subject: Re: Outgoing SMTP Servers On Oct 24, 2011, at 9:29 PM, Dennis Burgess wrote:
I am curious about what network operators are doing with outbound SMTP traffic. In the past few weeks we have ran into over 10 providers, mostly local providers, which block outbound SMTP and require the users to go THOUGH their mail servers even though those servers are not responsible for the domains in question! I know other mail servers are blocking non-reversible mail, however, is this common? And more importantly, is this an acceptable practice?
It's both unacceptable in my opinion and common. There are even those misguided souls that will tell you it is best practice, though general agreement, even among them seems to be that only 25/tcp should be blocked and that 465 and 587 should not be blocked.
Most of our smaller ISPs that we support; we allow any outbound SMTP connection, however we do watch residential users for 5+ outbound SMTP connections at the same time. But if the ISP has their own mail
servers, and users wish to relay though them, we basically tell them to use their mail server that they contract with. What is the best practice?
Best practice is to do what works and block as much SPAM as possible without destroying the internet in the process. There are those who argue that blocking 25/tcp does not destroy the internet. By and large, they are the same ones who believe NAT was good for us. Owen
On our retail footprint we block outbound traffic from customers with dynamic IPs towards port 25, our support tells them to use their ISP's port 587 server.... That being said, since all of our home users have 50 mbit/sec or greater upload speeds we are pretty paranoid about the amount of spam that could be originated.
We don't block anything on static assignments. Honestly, even as a very geeky user, I probably would not have noticed the block and I can confirm that it is massively important to lowering our spam footprint as a network.
I asked our support people, and none of them had ever really had an issue with this policy in terms of keeping customers. I agree with Ricky's current comment on this thread, blocking is unfortunately necessary on the modern consumer portions of the internet.
Exactly. Just like not having wide open SMTP relays became "unfortunately necessary" over a dozen years ago. It's just the way it is and there is a solution for it.
On Oct 24, 2011, at 10:27 PM, Mikael Abrahamsson wrote:
On Mon, 24 Oct 2011, Dennis Burgess wrote:
I am curious about what network operators are doing with outbound SMTP traffic.
Block all TCP/25 and require users to use submit with authentication on TCP/587.
If they are using someone else's mail server for outbound, how, exactly do you control whether or not they use AUTH in the process? Further, if you make them use AUTH somehow, but, you don't force TLS, then, you are doing more harm than good IMHO. Owen
Blocking port/25 is a common practice (!= best practice) for home users/consumers because it makes life a bit simpler in educating the end user. ripe-409 gives some what glimpse of best-practice, not sure how many implements it that way. Regards, Aftab A. Siddiqui On Tue, Oct 25, 2011 at 2:35 PM, Owen DeLong <owen@delong.com> wrote:
On Oct 24, 2011, at 10:27 PM, Mikael Abrahamsson wrote:
On Mon, 24 Oct 2011, Dennis Burgess wrote:
I am curious about what network operators are doing with outbound SMTP traffic.
Block all TCP/25 and require users to use submit with authentication on TCP/587.
If they are using someone else's mail server for outbound, how, exactly do you control whether or not they use AUTH in the process?
Further, if you make them use AUTH somehow, but, you don't force TLS, then, you are doing more harm than good IMHO.
Owen
On Tue, Oct 25, 2011 at 2:51 AM, Aftab Siddiqui <aftab.siddiqui@gmail.com>wrote:
Blocking port/25 is a common practice (!= best practice) for home users/consumers because it makes life a bit simpler in educating the end user.
MAAWG have considered this a best practice for residential/dynamic IPs since 2005 - http://www.uceprotect.net/downloads/MAAWGPort25English.pdf The FTC and numerous other government agreed the same year - http://www.ftc.gov/bcp/edu/microsites/spam/zombie/letter_english.pdf (The URL in the pdf no longer works - it's not http://www.ftc.gov/bcp/edu/microsites/spam/zombie/) Anyone not yet past the denial stage on this one needs to get themselves a copy of RFC 5068 and start reading. Scott.
On 10/26/2011 10:57 PM, Scott Howard wrote:
On Tue, Oct 25, 2011 at 2:51 AM, Aftab Siddiqui <aftab.siddiqui@gmail.com>wrote:
Blocking port/25 is a common practice (!= best practice) for home users/consumers because it makes life a bit simpler in educating the end user.
And it's not just 25. I'm on Charter, and they're blocking 135-139, 445, and 1434 too. Give Netalyzr a shot from your ISP. Jeff
On Tue, 25 Oct 2011 02:35:31 PDT, Owen DeLong said:
If they are using someone else's mail server for outbound, how, exactly do you control whether or not they use AUTH in the process?
1) You don't even really *care* if they do or not, because... 2) if some other site is running with an un-AUTHed open port 587, the miscreants will find it and abuse it just like any other open mail relay. The community will deal with it quick enough so you don't have to. And at that point, it's the open mail relay's IP that ends up on the block lists, not your mail relay's IP. Other people running open port 587s tends to be quite self-correcting.
On Oct 25, 2011, at 3:29 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Tue, 25 Oct 2011 02:35:31 PDT, Owen DeLong said:
If they are using someone else's mail server for outbound, how, exactly do you control whether or not they use AUTH in the process?
1) You don't even really *care* if they do or not, because...
2) if some other site is running with an un-AUTHed open port 587, the miscreants will find it and abuse it just like any other open mail relay. The community will deal with it quick enough so you don't have to. And at that point, it's the open mail relay's IP that ends up on the block lists, not your mail relay's IP.
But that applies to port 25 also, so, I'm not understanding the difference.
Other people running open port 587s tends to be quite self-correcting.
At this point, so do open port 25s. Owen
On 10/25/2011 11:17 AM, Owen DeLong wrote:
But that applies to port 25 also, so, I'm not understanding the difference.
Other people running open port 587s tends to be quite self-correcting.
At this point, so do open port 25s.
The differences is in intentions from the user. All SMTP servers are supposed to accept incoming email to their domain on port 25, if they get a connection from a random IP they can check spf, dkim and dns blacklists but that's all they can do to see the reputation of the sender. Blocking port 25 is an ISP based list of who is allowed to send SMTP. Port 587 is supposed to only be used for MUA-MTA communications. If mx.hello.com gets a 587 connection from anyone and they say "mail from: <anyone other than hello.com>" the server can drop that as wrong. Yes it's nasty and dumb, but it works better than spf, DKIM and other technology right now. Maybe spf could be extended into reverse zones and who they're permitted to send mail for (too many ISP's don't let even business users update reverse records), maybe spf or a protocol like it will become required in the future so you know who can be trusted when they connect, or reputation or greylisting will take off, except for having to store reputation about all IP's and all /64s so the database isn't easily maintained. I think spf with dkim (with caveats worked out) would be the best solution but anything that requires a flag day with SMTP basically isn't gonna happen.
Owen
Robert
On Tue, Oct 25, 2011 at 12:29 AM, Dennis Burgess <dmburgess@linktechs.net> wrote:
I am curious about what network operators are doing with outbound SMTP traffic. In the past few weeks we have ran into over 10 providers, mostly local providers, which block outbound SMTP and require the users to go THOUGH their mail servers even though those servers are not responsible for the domains in question! I know other mail servers are blocking non-reversible mail, however, is this common? And more importantly, is this an acceptable practice?
Hi Dennis, Blocking outbound TCP SYN packets on port 25 from non-servers is considered a BEST PRACTICE to avoid being the source of snowshoe and botnet spam. Blocking it from legitimate mail servers... does not make sense. The SMTP submission port (TCP 587) is authenticated and should generally not be blocked. 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 10/25/2011 8:13 AM, William Herrin wrote:
Blocking outbound TCP SYN packets on port 25 from non-servers is considered a BEST PRACTICE ... The SMTP submission port (TCP 587) is authenticated and should generally not be blocked.
Email Submission Operations: Access and Accountability Requirements <http://www.ietf.org/rfc/rfc5068.txt> IETF BCP It does not explicitly support blocking outbound port 25, since that's controversial, but it /does/ require permitting outbound port 587. d/
Regards, Bill Herrin
-- Dave Crocker Brandenburg InternetWorking bbiw.net
On Oct 24, 2011, at 11:13 PM, William Herrin wrote:
On Tue, Oct 25, 2011 at 12:29 AM, Dennis Burgess <dmburgess@linktechs.net> wrote:
I am curious about what network operators are doing with outbound SMTP traffic. In the past few weeks we have ran into over 10 providers, mostly local providers, which block outbound SMTP and require the users to go THOUGH their mail servers even though those servers are not responsible for the domains in question! I know other mail servers are blocking non-reversible mail, however, is this common? And more importantly, is this an acceptable practice?
Hi Dennis,
Blocking outbound TCP SYN packets on port 25 from non-servers is considered a BEST PRACTICE to avoid being the source of snowshoe and botnet spam. Blocking it from legitimate mail servers... does not make sense.
The SMTP submission port (TCP 587) is authenticated and should generally not be blocked.
Interesting... Most people I know run the same policy on 25 and 587 these days... to-local-domain, no auth needed. relay, auth needed. auth required == TLS required. Anything else on either port seems not best practice to me. Due to the absurd things I've seen done in the world, I actually run that policy on 5 ports: 25, 587 as you would expect. 465 SSL rather than STARTTLS, but, otherwise identical 80 because it works when nothing else does. 443 because sometimes Deep Packet Inspection is a PITA. Of course, using 80 and 443 requires the use of additional IP address resources for those servers rather than being able to also run a web server on the same address, but, this is the consequence of replacing an internet with 64K ports with filters that force the entire internet to operate all services on TCP/80. With this combination, I have not encountered a hotel, airport lounge, or other poorly run environment from which I cannot send mail through my home server from my laptop/ipad/iphone/etc. Owen
On 2011-10-25 11:49 , Owen DeLong wrote: [..]
With this combination, I have not encountered a hotel, airport lounge, or other poorly run environment from which I cannot send mail through my home server from my laptop/ipad/iphone/etc.
Ever heard of this magical thing called a VPN? :) Indeed, that bypasses all those crappy local networks; and yes don't worry your iToy also has more than ample VPN abilities. Set up once and never have to bother about special configurations or getting around stupid filters. Greets, Jeroen
On Oct 25, 2011, at 3:04 AM, Jeroen Massar wrote:
On 2011-10-25 11:49 , Owen DeLong wrote: [..]
With this combination, I have not encountered a hotel, airport lounge, or other poorly run environment from which I cannot send mail through my home server from my laptop/ipad/iphone/etc.
Ever heard of this magical thing called a VPN? :)
Sure, but, why deal with the overhead? Who wants to have to login to a VPN every time just to quickly retrieve or send some email?
Indeed, that bypasses all those crappy local networks; and yes don't worry your iToy also has more than ample VPN abilities.
Some do, some don't, and not all networks are any friendlier to VPNs than they are to port 25.
Set up once and never have to bother about special configurations or getting around stupid filters.
Except where you have to or where there are so many layers of NAT that even VPNs don't work, or... I set up the 5 ports once and don't need any special configurations to get around stupid filters, stuff just works now. Owen
On 2011-10-25 12:20 , Owen DeLong wrote:
On Oct 25, 2011, at 3:04 AM, Jeroen Massar wrote:
On 2011-10-25 11:49 , Owen DeLong wrote: [..]
With this combination, I have not encountered a hotel, airport lounge, or other poorly run environment from which I cannot send mail through my home server from my laptop/ipad/iphone/etc.
Ever heard of this magical thing called a VPN? :)
Sure, but, why deal with the overhead? Who wants to have to login to a VPN every time just to quickly retrieve or send some email?
On that iToy of yours it is just a flick of a switch, presto.
Indeed, that bypasses all those crappy local networks; and yes don't worry your iToy also has more than ample VPN abilities.
Some do, some don't, and not all networks are any friendlier to VPNs than they are to port 25.
And the final solution then tends to be setting up a VPN on port 443... Which only wastes one IP address, not several for different services.
Set up once and never have to bother about special configurations or getting around stupid filters.
Except where you have to or where there are so many layers of NAT that even VPNs don't work, or...
Unless this 'NAT' is actually a firewall doing DPI on the packets, I can't see any reason why a VPN which just uses TCP over port 443 can't work in that situation. Greets, Jeroen
On Oct 25, 2011, at 4:15 AM, Jeroen Massar wrote:
On 2011-10-25 12:20 , Owen DeLong wrote:
On Oct 25, 2011, at 3:04 AM, Jeroen Massar wrote:
On 2011-10-25 11:49 , Owen DeLong wrote: [..]
With this combination, I have not encountered a hotel, airport lounge, or other poorly run environment from which I cannot send mail through my home server from my laptop/ipad/iphone/etc.
Ever heard of this magical thing called a VPN? :)
Sure, but, why deal with the overhead? Who wants to have to login to a VPN every time just to quickly retrieve or send some email?
On that iToy of yours it is just a flick of a switch, presto.
On anything, a VPN is a diversion of your traffic through a tunnel with additional overhead for encryption and encapsulation headers.
Indeed, that bypasses all those crappy local networks; and yes don't worry your iToy also has more than ample VPN abilities.
Some do, some don't, and not all networks are any friendlier to VPNs than they are to port 25.
And the final solution then tends to be setting up a VPN on port 443... Which only wastes one IP address, not several for different services.
Meh, there are plenty of IP addresses. The shortage is limited to this legacy v4 stuff. When the hotel networks and such catch up to the modern internet, I can stop running these extra addresses on IPv4 and it won't matter.
Set up once and never have to bother about special configurations or getting around stupid filters.
Except where you have to or where there are so many layers of NAT that even VPNs don't work, or...
Unless this 'NAT' is actually a firewall doing DPI on the packets, I can't see any reason why a VPN which just uses TCP over port 443 can't work in that situation.
You would think, but, I have seen them break. OTOH, most of my VPNs are IPSEC, not SSL, so that's another issue. There would be significant additional overhead in setting up an SSL VPN. Admittedly, it's one-time overhead, but, again, I don't see a reason to bother. Owen
On Tue, 25 Oct 2011 07:15:00 -0400, Jeroen Massar <jeroen@unfix.org> wrote:
On that iToy of yours it is just a flick of a switch, presto.
Where "flick of a switch" is actually several steps... Settings -> Network -> VPN... there's your switch. Wait for it to connect Go back to mail, refresh... And one's VPN profile has to be setup in advance. Plus, it doesn't always work. I gather you've never been in a network where an IPSec VPN wouldn't connect. I've seen it too many times. (I've even seen ISPs where it didn't work. Apparently GRE isn't IP to them.) An SSL VPN will often get around that, but it's additional hardware/software/setup/licenses/etc. (For a Cisco ASA, it's an additional word in your vpn setup, and a license... base "demo" is only 2 connections.) It's *MUCH* easier to setup the mail server on ports 465 and 587, require auth and tls. Done right, it's 100% transparent to the traveling user. Works perfectly even in networks where a VPN doesn't and the idiot hotel intercepts port 25 (not blocks, redirects to *their* server.) --Ricky
From nanog-bounces+bonomi=mail.r-bonomi.com@nanog.org Tue Oct 25 14:53:32 2011 Subject: Re: Outgoing SMTP Servers From: Alex Harrowell <a.harrowell@gmail.com> Date: Tue, 25 Oct 2011 20:52:46 +0100 To: Ricky Beam <jfbeam@gmail.com>, Jeroen Massar <jeroen@unfix.org> Cc: nanog@nanog.org
Ricky Beam <jfbeam@gmail.com> wrote:
Works perfectly even in networks where a VPN doesn't and the idiot hotel intercepts port 25 (not blocks, redirects to *their* server.)
--Ricky
Why do they do that?
Because some "quarter-asswit"[1] sold them that it was a good idea -- maybe on the basis tht it was: "easy" to to rate-limit -- supposedly an anti-spam measure; "easy" to 'forward' all the patron traffic to a relay server of the hotel's choice, so that, -if- it is spam, the outside world sees it coming from an already segregated address-space; "easy" to implement a holding queue, so that if they _do_ detect spam, they can drop _all_ the spam messages, even those sent before the spam threshold was detected.; etc., etc., ad nauseum. [1] "half-assed half-wit", reduced to a single term.
On 25 October 2011 20:52, Alex Harrowell <a.harrowell@gmail.com> wrote:
Ricky Beam <jfbeam@gmail.com> wrote:
Works perfectly even in networks where a VPN doesn't and the idiot hotel intercepts port 25 (not blocks, redirects to *their* server.)
--Ricky
Why do they do that?
My home ISP run an open relay on port 25 with IP-based authentication, so I might configure my laptops email client to send email via smtp.myisp.com port 25 (many/most? residential ISPs have unauthenticated relays, even ISPs that tell you to use authentication often have another server next to it that doesn't need authentication for customer IP space) If the hotel simply blocks port 25 then my email is broken, if they allow it then my email is broken (as my ISP doesn't let the hotel relay through their mail servers), however if the hotel redirects 25 to their own open relays then in theory my email should work fine. They could always tell people "there is a relay at 10.0.0.25 so you can change your settings to use that", however by redirecting all port 25 traffic there they are effectively forcibly auto-configuring anyone who was already configured to send via an unauthenticated server on port 25. They are probably acting under the assumption that the only people using 25 are using it for unauthenticated access, I believe most servers that do use authentication tell users to use alternate ports so this is probably a reasonable assumption. Compared to straight blocking of port 25 it's probably better as long as the relay it is redirecting you to works properly so you don't have to try and diagnose issues - However considering the quality of the average hotel network I suspect most of them that are trying to do this probably have it set to redirect to a dead server anyway. - Mike
No no no no no. The problem with your theory below is that: 1. It is by far best for users to authenticate to send mail. 2. Your "solution" works only for unencrypted unauthenticated users that ignore the certificate presented by the mail server. Put another way, your mechanism rewards those doing the wrong thing while punishing those of us sending our email via encrypted and authenticated mechanisms. That's a very bad thing. Owen Sent from my iPhone On Oct 25, 2011, at 15:03, Mike Jones <mike@mikejones.in> wrote:
On 25 October 2011 20:52, Alex Harrowell <a.harrowell@gmail.com> wrote:
Ricky Beam <jfbeam@gmail.com> wrote:
Works perfectly even in networks where a VPN doesn't and the idiot hotel intercepts port 25 (not blocks, redirects to *their* server.)
--Ricky
Why do they do that?
My home ISP run an open relay on port 25 with IP-based authentication, so I might configure my laptops email client to send email via smtp.myisp.com port 25 (many/most? residential ISPs have unauthenticated relays, even ISPs that tell you to use authentication often have another server next to it that doesn't need authentication for customer IP space)
If the hotel simply blocks port 25 then my email is broken, if they allow it then my email is broken (as my ISP doesn't let the hotel relay through their mail servers), however if the hotel redirects 25 to their own open relays then in theory my email should work fine.
They could always tell people "there is a relay at 10.0.0.25 so you can change your settings to use that", however by redirecting all port 25 traffic there they are effectively forcibly auto-configuring anyone who was already configured to send via an unauthenticated server on port 25. They are probably acting under the assumption that the only people using 25 are using it for unauthenticated access, I believe most servers that do use authentication tell users to use alternate ports so this is probably a reasonable assumption.
Compared to straight blocking of port 25 it's probably better as long as the relay it is redirecting you to works properly so you don't have to try and diagnose issues - However considering the quality of the average hotel network I suspect most of them that are trying to do this probably have it set to redirect to a dead server anyway.
- Mike
On Tue, Oct 25, 2011 at 5:56 PM, Owen DeLong <owen@delong.com> wrote:
Put another way, your mechanism rewards those doing the wrong thing while punishing those of us sending our email via encrypted and authenticated mechanisms.
Owen, If you're doing the "right" thing, sending email via encrypted, authenticated mechanisms, then you're doing it TCP ports 587 or 443. Where Mike's mechanism obstructs you not at all. If you're still doing the wrong thing, trying to talk to remote SMTP servers on TCP port 25, why should his mechanisms not punish you? 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 Oct 25, 2011, at 3:16 PM, William Herrin wrote:
On Tue, Oct 25, 2011 at 5:56 PM, Owen DeLong <owen@delong.com> wrote:
Put another way, your mechanism rewards those doing the wrong thing while punishing those of us sending our email via encrypted and authenticated mechanisms.
Owen,
If you're doing the "right" thing, sending email via encrypted, authenticated mechanisms, then you're doing it TCP ports 587 or 443. Where Mike's mechanism obstructs you not at all.
Depends. Some hotel admins aren't so bright. That's the problem. Not everyone hears block outbound SMTP on port 25, they hear block outbound SMTP and stop listening. Boom, 25, 465, 587 all get turned off. Worse, if they redirect 25, then, it can still cause problems with many clients because they will try 25 first assuming that if it is broken it will fail. There''s nothing wrong with that approach IMHO. There's no reason one can't send email over 25 just as well as 587 as long as they're authenticating and doing it over an encrypted channel. My client generally tries in this order: 25, 587, 465, 443, 80. If people merely break things by blocking SMTP on one or more ports, then it works. If they do stupid pet tricks like redirecting all connections to other addresses to their own server, then it breaks horribly.
If you're still doing the wrong thing, trying to talk to remote SMTP servers on TCP port 25, why should his mechanisms not punish you?
It's not wrong to talk to them on port 25. It's wrong to allow unauthenticated remote users to send on your own port 25 for relay purposes. This is the problem... I don't buy your idea of what constitutes doing the wrong thing and neither do the developers of many email clients. Owen
On Tue, Oct 25, 2011 at 8:15 PM, Owen DeLong <owen@delong.com> wrote:
On Oct 25, 2011, at 3:16 PM, William Herrin wrote:
If you're doing the "right" thing, sending email via encrypted, authenticated mechanisms, then you're doing it TCP ports 587 or 443. Where Mike's mechanism obstructs you not at all.
Depends. Some hotel admins aren't so bright. That's the problem. Not everyone hears block outbound SMTP on port 25, they hear block outbound SMTP and stop listening. Boom, 25, 465, 587 all get turned off.
Sure. But that's not Mike's mechanism. It's ignorant hotel guy's mechanism. Don't penalize Mike because some other fool does something similar but wrong.
If you're still doing the wrong thing, trying to talk to remote SMTP servers on TCP port 25, why should his mechanisms not punish you?
It's not wrong to talk to them on port 25. It's wrong to allow unauthenticated remote users to send on your own port 25 for relay purposes.
Sure it is. Same way it's wrong to have an open relay or an unsecured proxy. It isn't 1995 any more. 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 Oct 25, 2011, at 9:33 PM, William Herrin wrote:
On Tue, Oct 25, 2011 at 8:15 PM, Owen DeLong <owen@delong.com> wrote:
On Oct 25, 2011, at 3:16 PM, William Herrin wrote:
If you're doing the "right" thing, sending email via encrypted, authenticated mechanisms, then you're doing it TCP ports 587 or 443. Where Mike's mechanism obstructs you not at all.
Depends. Some hotel admins aren't so bright. That's the problem. Not everyone hears block outbound SMTP on port 25, they hear block outbound SMTP and stop listening. Boom, 25, 465, 587 all get turned off.
Sure. But that's not Mike's mechanism. It's ignorant hotel guy's mechanism. Don't penalize Mike because some other fool does something similar but wrong.
Mike recommends a tactic that leads to idiot hotel admins doing bad things. You bet I'll criticize it for that. His mechanism breaks things anyway. I'll criticize it for that too.
If you're still doing the wrong thing, trying to talk to remote SMTP servers on TCP port 25, why should his mechanisms not punish you?
It's not wrong to talk to them on port 25. It's wrong to allow unauthenticated remote users to send on your own port 25 for relay purposes.
Sure it is. Same way it's wrong to have an open relay or an unsecured proxy. It isn't 1995 any more.
As I said, we can agree to disagree about what is wrong. I know your position. I still don't agree with it. Owen
On 26 October 2011 05:44, Owen DeLong <owen@delong.com> wrote:
Mike recommends a tactic that leads to idiot hotel admins doing bad things. You bet I'll criticize it for that.
His mechanism breaks things anyway. I'll criticize it for that too.
Just to clarify, I was merely pointing out a possible argument behind someone doing it that way. For a hotel wifi type network I would consider it a valid option that is arguably (to some) better than straight blocking for the average user, for other types of networks with more long term user bases I would be very surprised if there was any justification for redirecting as opposed to simply blocking. If someone were asking for my advice on deploying a network like that I would have to point out that the extra effort required to deploy/support it is unlikely to be worth it. Blocking port 25 is unlikely to cause much of a problem compared to a single incident with that SMTP server that your hotel now needs to maintain. In a perfect world we would all have as many static globally routed IP addresses as we want with nothing filtered, in the real world a residential ISP who gives their customers globally routable IPv4 addresses for each computer (ie. a CPE that supports multiple computers without NAT) with no filtering at all is probably going to have to hire more support staff to deal with it, even before people from this list start null routing their IP space for being a rogue ISP that clearly doesn't give a damn etc :) Perhaps our next try with IPv6 can be a perfect world where hosts are secure enough for open end to end connectivity and infected machines are rarely a problem? IPv6 enabled systems are more secure than a lot of the systems we have floating around on IPv4 networks, but I still think we're going to end up with port blocking becoming reasonably common on IPv6 as well once that starts getting widely deployed to residential users. - Mike
In a perfect world we would all have as many static globally routed IP addresses as we want with nothing filtered, in the real world a residential ISP who gives their customers globally routable IPv4 addresses for each computer (ie. a CPE that supports multiple computers without NAT) with no filtering at all is probably going to have to hire more support staff to deal with it, even before people from this list start null routing their IP space for being a rogue ISP that clearly doesn't give a damn etc :)
Agreed that we should get to the point where everyone can have thousands of static globally routed subsets as soon as possible. The technology already exists and I use it wherever it is available. I have 65,536 static globally routed subsets available in my network, though I do not currently use that many. The reason we don't all have that yet is merely delay and inaction by those who have not yet implemented current IP technologies.
Perhaps our next try with IPv6 can be a perfect world where hosts are secure enough for open end to end connectivity and infected machines are rarely a problem? IPv6 enabled systems are more secure than a lot of the systems we have floating around on IPv4 networks, but I still think we're going to end up with port blocking becoming reasonably common on IPv6 as well once that starts getting widely deployed to residential users.
Firewalls are perfectly valid and I have no general objection to filtering packets based on the policy set by a site. What I object to is having someone I pay to move my packets tell me that they won't move some of those packets because they feel it is some form of best practice to eliminate my perfectly valid packets in order to prevent someone else from committing some form of abuse on the same protocol. I object even more strenuously to someone who redirects my packets for their intended destination to some man in the middle attack destination of their choosing. Redirecting someones SMTP is a man I. The middle attack. It is every bit as evil as any other form of network abuse or hijacking. Owen
On Wed, Oct 26, 2011 at 19:24:23PM -0600, Owen DeLong wrote:
Firewalls are perfectly valid and I have no general objection to filtering packets based on the policy set by a site. What I object to is having someone I pay to move my packets tell me that they won't move some of those packets because they feel it is some form of best practice to eliminate my perfectly valid packets in order to prevent someone else from committing some form of abuse on the same protocol.
I object even more strenuously to someone who redirects my packets for their intended destination to some man in the middle attack destination of their choosing.
Would it be useful to slice this analysis into component parts, e.g. "Residential" (dynamic), "small" (single/handful, e.g. small business, colo, hosted web, VPS), and large (/24 and up), as what is defined as "moving packets" may be viewed significantly differently? For instance, what Residential customers are paying for seems to not necessarily be (strictly speaking) "just moving all of your packets", at least according to residential ToS' that I've read lately. -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York
On 25/10/2011 23:03, Mike Jones wrote:
On 25 October 2011 20:52, Alex Harrowell <a.harrowell@gmail.com> wrote:
Ricky Beam <jfbeam@gmail.com> wrote:
Works perfectly even in networks where a VPN doesn't and the idiot hotel intercepts port 25 (not blocks, redirects to *their* server.)
--Ricky
Why do they do that?
If the hotel simply blocks port 25 then my email is broken, if they allow it then my email is broken (as my ISP doesn't let the hotel relay through their mail servers), however if the hotel redirects 25 to their own open relays then in theory my email should work fine.
This only works if the MUA is configured to send to an un-AUTH'd relay normally. It normally fails spectacularly when the MUA tries to present AUTH that the relay doesn't understand or accept. I know of at least one large consumer ISP that does this across their network. Their argument was that it caused less of a support overhead when they implemented since no one had to change any settings (in theory). The reality is that the support overhead just transfers to the hosting/mail provider. "I send mail via your server and you are rejecting it." And then the hosting provider gets to explain how the IAP is in fact mangling their customers mail. Spam from mis-configured and compromised hosts is a big issue and on an access network. Even worse with dynamically allocated IPs. Users dial up and inherit blacklistings from previous customers and often entire prefixes will be listed by the RBL if the snoeshow effect is big enough. I dislike the idea of blocking port 25 (though it has been effective in dealing with major outbreaks.) We ended up building an new product that works as an appliance. All port 25 is piped through and the packets are passed on un-touched. Spamminess is scored and with some clever integration with RADIUS, the score is applied to a username. If the threshold is exceeded then the user is dynamically blocked or directed to a honeypot (depending on the requirements). And if the user redials then the block follows them. After deploying that our abuse desk went quiet ;-) -- Graham Beneke
On Tue, 25 Oct 2011 15:52:46 -0400, Alex Harrowell <a.harrowell@gmail.com> wrote:>
Why do they do that?
You'd have to ask them. Or more accurately, you'd need to ask their system integrator -- I've never seen an "in house" network run like that. (and for the record, they were charging for that shitty network access.) Bottom line: Blocking port 25 (smtp) is undesirable, but necessary for a modern consumer internet. (Translation: It f'ing works.) This is the ISP saying, "You aren't a mail *server*." MUA's (mail clients) should only be connecting to specified MSA's or MTA's (mail *servers*). They should never be connecting to random MTA's (presumably for direct delivery, which is the job of an MTA not MUA.) The only people who can effectively police this is the ISP. Individual mail server admins and RBL maintainers can only guess and be reactionary, which is often wrong, still lets spam through, and becomes stale rather quickly. --Ricky
In message <op.v3y8xvo6tfhldh@rbeam.xactional.com>, "Ricky Beam" writes:
On Tue, 25 Oct 2011 15:52:46 -0400, Alex Harrowell <a.harrowell@gmail.com> wrote:>
Why do they do that?
You'd have to ask them. Or more accurately, you'd need to ask their system integrator -- I've never seen an "in house" network run like that. (and for the record, they were charging for that shitty network access.)
Bottom line: Blocking port 25 (smtp) is undesirable, but necessary for a modern consumer internet. (Translation: It f'ing works.) This is the ISP saying, "You aren't a mail *server*."
MTA == Mail Transfer Agent. You don't have to be a *server* to be a MTA. Blocking SMTP also prevents your customers running encrypted mail sessions to prevent nosy ISP's and others looking at what they are sending. With DNSSEC now being deployed and DANE being standardised, running a SMTP session with STARTTLS is being a reality. Now most people don't care about this but you shouldn't have to get a business grade service just to have secure email sessions and if you want to run a SMTP server to do that you are not changing the amount of traffic going over the connection so why the hell should a ISP care. IMAP, POP, SMTP all have about the same overhead for inbound email.
MUA's (mail clients) should only be connecting to specified MSA's or MTA's (mail *servers*). They should never be connecting to random MTA's (presumably for direct delivery, which is the job of an MTA not MUA.) The only people who can effectively police this is the ISP.
Total utter BS.
Individual mail server admins and RBL maintainers can only guess and be reactionary, which is often wrong, still lets spam through, and becomes stale rather quickly.
--Ricky
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 26 Oct 2011, at 23:13, "Mark Andrews" <marka@isc.org> wrote:
In message <op.v3y8xvo6tfhldh@rbeam.xactional.com>, "Ricky Beam" writes:
On Tue, 25 Oct 2011 15:52:46 -0400, Alex Harrowell <a.harrowell@gmail.com> wrote:>
Why do they do that?
You'd have to ask them. Or more accurately, you'd need to ask their system integrator -- I've never seen an "in house" network run like that. (and for the record, they were charging for that shitty network access.)
Bottom line: Blocking port 25 (smtp) is undesirable, but necessary for a modern consumer internet. (Translation: It f'ing works.) This is the ISP saying, "You aren't a mail *server*."
MTA == Mail Transfer Agent. You don't have to be a *server* to be a MTA. Blocking SMTP also prevents your customers running encrypted mail sessions to prevent nosy ISP's and others looking at what they are sending. With DNSSEC now being deployed and DANE being standardised, running a SMTP session with STARTTLS is being a reality.
This is what I used to do. Any outgoing port 25 was sunk into a pool of SMTP proxies that I wrote. These proxies would look for signs of authentication and if they found them, the session would be proxied to the original destination SMTP server from the same IP address of the originating host. Anything else was proxied to the pool of Ironports which would rate limit and otherwise SPAM examine the mail. That way people using authenticated servers would be allowed through on the assumption that in all likelihood they were OK. Others who do not auth or are SPAM bots would be scrubbed and rate limited quite severely. Our own customers were encouraged to use our outbound SMTP hosts which would either authenticate them if external or just allow them if internal, but with the SPAM scrubbing and less severe rate limiting enabled, Customers who need a higher volume of outbound mail can call us and authenticate to the SMTP servers and we can set them a bespoke profile for rate limiting and message size etc etc. That worked rather well because people's email got out and SPAM was largely stopped. The Ironports were darn good boxes if a little pricey, -- Leigh Porter ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
On 27/10/11 11:11, Mark Andrews wrote:
In message <op.v3y8xvo6tfhldh@rbeam.xactional.com>, "Ricky Beam" writes:
On Tue, 25 Oct 2011 15:52:46 -0400, Alex Harrowell <a.harrowell@gmail.com> wrote:>
Why do they do that? You'd have to ask them. Or more accurately, you'd need to ask their system integrator -- I've never seen an "in house" network run like that. (and for the record, they were charging for that shitty network access.)
Bottom line: Blocking port 25 (smtp) is undesirable, but necessary for a modern consumer internet. (Translation: It f'ing works.) This is the ISP saying, "You aren't a mail *server*." MTA == Mail Transfer Agent. You don't have to be a *server* to be a MTA. Blocking SMTP also prevents your customers running encrypted mail sessions to prevent nosy ISP's and others looking at what they are sending. With DNSSEC now being deployed and DANE being standardised, running a SMTP session with STARTTLS is being a reality.
Perhaps i'm asking the obvious, but why is "Blocking SMTP" going to prevent customers running encrypted mail sessions? If SMTP = 25/TCP and encrypted mail sessions run on another port, they're not blocked?
Now most people don't care about this but you shouldn't have to get a business grade service just to have secure email sessions and if you want to run a SMTP server to do that you are not changing the amount of traffic going over the connection so why the hell should a ISP care. IMAP, POP, SMTP all have about the same overhead for inbound email. The majority of consumers will use the SMTP service their ISP provides and not look twice. Surely anyone wanting to use something different will either
a) run their own mail server, requiring a static IP address and simply requiring the ISP to flick a switch which says 'ok, you're not blocked for 25/TCP anymore' or b) use an alternative SMTP server on port != 25/TCP with their own authentication layer and responsibility thereof. Sometimes I feel like contributors to NANOG see themselves as typical users. IT Engineers are anything but typical when you compare to mom-and-pop-interwebs-user, and it's those very users who're likely to wind up with malware that'll be firing to random external SMTP servers via 25/TCP, delivering spam which is quite effectively blocked by a 25/TCP block. I've seen recently SMTP-AUTH sessions exploited (user/pass credentials borrowed) for spam purposes, but at least this is an order of magnitude more difficult for the spammer, and more easily tracked by the ISP than having to do IP/Time based records checks.
MUA's (mail clients) should only be connecting to specified MSA's or MTA's (mail *servers*). They should never be connecting to random MTA's (presumably for direct delivery, which is the job of an MTA not MUA.) The only people who can effectively police this is the ISP. Total utter BS.
Why? It's a reasonable position; end users in the generic sense are sending to whatever their client has set up for SMTP, fire-and-forget. Again, I feel like folks are taking their relatively complicated use-cases and treating them as the norm. Mark.
In message <4EA8A021.9000805@blakjak.net>, Mark Foster writes:
On 27/10/11 11:11, Mark Andrews wrote:
In message <op.v3y8xvo6tfhldh@rbeam.xactional.com>, "Ricky Beam" writes:
On Tue, 25 Oct 2011 15:52:46 -0400, Alex Harrowell <a.harrowell@gmail.com>
wrote:>
Why do they do that? You'd have to ask them. Or more accurately, you'd need to ask their system integrator -- I've never seen an "in house" network run like that.
(and for the record, they were charging for that shitty network access.)
Bottom line: Blocking port 25 (smtp) is undesirable, but necessary for a modern consumer internet. (Translation: It f'ing works.) This is the ISP saying, "You aren't a mail *server*." MTA == Mail Transfer Agent. You don't have to be a *server* to be a MTA. Blocking SMTP also prevents your customers running encrypted mail sessions to prevent nosy ISP's and others looking at what they are sending. With DNSSEC now being deployed and DANE being standardised, running a SMTP session with STARTTLS is being a reality.
Perhaps i'm asking the obvious, but why is "Blocking SMTP" going to prevent customers running encrypted mail sessions? If SMTP = 25/TCP and encrypted mail sessions run on another port, they're not blocked?
It's encrypted email direct to MX. With that I can know that the email has been delivered to their mail exchangers.
Now most people don't care about this but you shouldn't have to get a business grade service just to have secure email sessions and if you want to run a SMTP server to do that you are not changing the amount of traffic going over the connection so why the hell should a ISP care. IMAP, POP, SMTP all have about the same overhead for inbound email. The majority of consumers will use the SMTP service their ISP provides and not look twice. Surely anyone wanting to use something different will either
a) run their own mail server, requiring a static IP address and simply requiring the ISP to flick a switch which says 'ok, you're not blocked for 25/TCP anymore'
And lots of ISP's don't offer those knobs in the misguided view that individuals don't need them.
b) use an alternative SMTP server on port != 25/TCP with their own authentication layer and responsibility thereof.
Which is just a non-starter.
Sometimes I feel like contributors to NANOG see themselves as typical users. IT Engineers are anything but typical when you compare to mom-and-pop-interwebs-user, and it's those very users who're likely to wind up with malware that'll be firing to random external SMTP servers via 25/TCP, delivering spam which is quite effectively blocked by a 25/TCP block.
As I said, most don't need it but for the few that do it should be available and shouldn't require one to get a business service. It's like ISP's that won't deliver business grade services to homes. Just because someone doesn't meet you pre-conceptions of their need it doesn't mean that what they need is unreasonable.
I've seen recently SMTP-AUTH sessions exploited (user/pass credentials borrowed) for spam purposes, but at least this is an order of magnitude more difficult for the spammer, and more easily tracked by the ISP than having to do IP/Time based records checks.
MUA's (mail clients) should only be connecting to specified MSA's or MTA's (mail *servers*). They should never be connecting to random MTA's (presumably for direct delivery, which
is the job of an MTA not MUA.) The only people who can effectively police
this is the ISP. Total utter BS.
Why? It's a reasonable position; end users in the generic sense are sending to whatever their client has set up for SMTP, fire-and-forget. Again, I feel like folks are taking their relatively complicated use-cases and treating them as the norm.
It's ths whole attitude that end users are incapable on doing thing correctly. Most user are prefectly fine with having their mail go through a ISP's servers but there are exceptions and when people start say "only a ISP can do this" or "only business need this" by BS detector goes off because individuals do need to do the same sorts of things. Mark. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Mark Andrews <marka@isc.org> writes:
In message <4EA8A021.9000805@blakjak.net>, Mark Foster writes:
Why? It's a reasonable position; end users in the generic sense are sending to whatever their client has set up for SMTP, fire-and-forget. Again, I feel like folks are taking their relatively complicated use-cases and treating them as the norm.
It's ths whole attitude that end users are incapable on doing thing correctly. Most user are prefectly fine with having their mail go through a ISP's servers but there are exceptions and when people start say "only a ISP can do this" or "only business need this" by BS detector goes off because individuals do need to do the same sorts of things.
Yes. Moving behind the BS, it's most likely a well calculated difference between designing a product for 99% of the users or going for the full 100%. The problem is that some of the less technical ISP staff, who often are involved in product definitons or financial and marketing decisions, will think that 99% is "everyone" :-) FWIW, we've been running a 25/tcp filter by default for a few years now, offering a knob to turn it off from the start. The knob is one of very few settings the users are offered in their self-service web UI, along with "change my password", "upgrade my account" and similar. Disabling the filter is of course free of charge. And when initially enabling the filter, all users were informed about the possibility to turn it off. Current status is that approx 1% of our users have disabled the filter so far. I assume most of them did so because they actually need access to port 25/tcp, but some may have just turned it off to see what happened and forgot about it. Filters will rarely be enabled again when first disabled, as disabled filters naturally are unnoticable. This makes the number of users disabling any given filter service aggregate over time. Anyway, that's the number we see. YMMV Whether that 1% of users are important to you or not will probably depend on a lot of factors. But I believe it's safe to say that those users can be classified as "power users", who will have a much higher tendency to buy more expensive products and to discuss their their ISP experiences with other power users. This makes them a lot more valuable than the number itself would indicate. Bjørn
----- Original Message -----
From: "Mark Andrews" <marka@isc.org>
Now most people don't care about this but you shouldn't have to get a business grade service just to have secure email sessions and if you want to run a SMTP server to do that you are not changing the amount of traffic going over the connection so why the hell should a ISP care. IMAP, POP, SMTP all have about the same overhead for inbound email.
They shouldn't care. Such users (probably 1% or less, though we tend, due to nerdview, to forget that) are collateral damage to what they're *trying* to do, which is to block the 99% of the traffic with that profile, which is bot spam. This has nothing to do with bandwidth; that's a strawman. 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 http://photo.imageinc.us +1 727 647 1274
On Tue, Oct 25, 2011 at 5:49 AM, Owen DeLong <owen@delong.com> wrote:
On Oct 24, 2011, at 11:13 PM, William Herrin wrote:
Blocking outbound TCP SYN packets on port 25 from non-servers is considered a BEST PRACTICE to avoid being the source of snowshoe and botnet spam. Blocking it from legitimate mail servers... does not make sense.
The SMTP submission port (TCP 587) is authenticated and should generally not be blocked.
Interesting... Most people I know run the same policy on 25 and 587 these days...
Owen, Perhaps you misunderstand the issue. The issue is not relaying mail through someone else's mail server, it's delivering mail to a mailbox served by that mail server. 99.99 etc. percent of the time when that's done directly from a IP address that's supposed to be user PC it's some form of spam. Hence the best practice within the email community is to ask the networking community to block those packets outright. And its why residential ISPs who fail to tend to find their way into Spamcop, Spamhaus and others. Facilitating that sort of network filtering is precisely why authenticated SMTP relaying was assigned port 587 instead of leaving it on port 25. On Tue, Oct 25, 2011 at 11:28 AM, Carlos Martinez-Cagnazzo <carlosm3011@gmail.com> wrote:
I'm curious how a traveller is supposed to get SMTP relay service when, well, travelling. I am not really sure if I want a VPN for sending a simple email.
That's what the SMTP submission port (TCP 587) is intended for and it's why outbound 587 should not be blocked. In fact, blocking 587 can cause problems with folks who use the Sender Policy Framework to restrict the servers allowed to pass mail from a particular domain outward. 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 Oct 25, 2011, at 8:46 AM, William Herrin wrote:
On Tue, Oct 25, 2011 at 5:49 AM, Owen DeLong <owen@delong.com> wrote:
On Oct 24, 2011, at 11:13 PM, William Herrin wrote:
Blocking outbound TCP SYN packets on port 25 from non-servers is considered a BEST PRACTICE to avoid being the source of snowshoe and botnet spam. Blocking it from legitimate mail servers... does not make sense.
The SMTP submission port (TCP 587) is authenticated and should generally not be blocked.
Interesting... Most people I know run the same policy on 25 and 587 these days...
Owen,
Perhaps you misunderstand the issue. The issue is not relaying mail through someone else's mail server, it's delivering mail to a mailbox served by that mail server. 99.99 etc. percent of the time when that's done directly from a IP address that's supposed to be user PC it's some form of spam. Hence the best practice within the email community is to ask the networking community to block those packets outright. And its why residential ISPs who fail to tend to find their way into Spamcop, Spamhaus and others. Facilitating that sort of network filtering is precisely why authenticated SMTP relaying was assigned port 587 instead of leaving it on port 25.
Wouldn't the right place for that form of rejection to occur be at the mail server in question? Precluding users doing legitimate things just because there are users who do illegitimate things is damaging to the internet and I will continue to route around it. I reject lots of residential connections to my port 25 services every day. However, senders who authenticate legitimately or legitimate sources of email (and yes, some spam sources too) connect just fine.
On Tue, Oct 25, 2011 at 11:28 AM, Carlos Martinez-Cagnazzo <carlosm3011@gmail.com> wrote:
I'm curious how a traveller is supposed to get SMTP relay service when, well, travelling. I am not really sure if I want a VPN for sending a simple email.
That's what the SMTP submission port (TCP 587) is intended for and it's why outbound 587 should not be blocked. In fact, blocking 587 can cause problems with folks who use the Sender Policy Framework to restrict the servers allowed to pass mail from a particular domain outward.
So the spammers move to 587 and problem solved. Owen
We use Mailchannels to route all outbound mail through it, which does a decent job of keeping garbage off the Internet and SBLs/RBLs clean. It is dependent on PBR so there is overhead to manage it but the product runs on our own hardware. -Matt -----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Tuesday, October 25, 2011 10:56 AM To: William Herrin Cc: nanog@nanog.org Subject: Re: Outgoing SMTP Servers On Oct 25, 2011, at 8:46 AM, William Herrin wrote:
On Tue, Oct 25, 2011 at 5:49 AM, Owen DeLong <owen@delong.com> wrote:
On Oct 24, 2011, at 11:13 PM, William Herrin wrote:
Blocking outbound TCP SYN packets on port 25 from non-servers is considered a BEST PRACTICE to avoid being the source of snowshoe and botnet spam. Blocking it from legitimate mail servers... does not make sense.
The SMTP submission port (TCP 587) is authenticated and should generally not be blocked.
Interesting... Most people I know run the same policy on 25 and 587 these days...
Owen,
Perhaps you misunderstand the issue. The issue is not relaying mail through someone else's mail server, it's delivering mail to a mailbox served by that mail server. 99.99 etc. percent of the time when that's done directly from a IP address that's supposed to be user PC it's some form of spam. Hence the best practice within the email community is to ask the networking community to block those packets outright. And its why residential ISPs who fail to tend to find their way into Spamcop, Spamhaus and others. Facilitating that sort of network filtering is precisely why authenticated SMTP relaying was assigned port 587 instead of leaving it on port 25.
Wouldn't the right place for that form of rejection to occur be at the mail server in question? Precluding users doing legitimate things just because there are users who do illegitimate things is damaging to the internet and I will continue to route around it. I reject lots of residential connections to my port 25 services every day. However, senders who authenticate legitimately or legitimate sources of email (and yes, some spam sources too) connect just fine.
On Tue, Oct 25, 2011 at 11:28 AM, Carlos Martinez-Cagnazzo <carlosm3011@gmail.com> wrote:
I'm curious how a traveller is supposed to get SMTP relay service when, well, travelling. I am not really sure if I want a VPN for sending a simple email.
That's what the SMTP submission port (TCP 587) is intended for and it's why outbound 587 should not be blocked. In fact, blocking 587 can cause problems with folks who use the Sender Policy Framework to restrict the servers allowed to pass mail from a particular domain outward.
So the spammers move to 587 and problem solved. Owen
On Tue, 25 Oct 2011 12:55:58 -0400, Owen DeLong <owen@delong.com> wrote:
Wouldn't the right place for that form of rejection to occur be at the mail server in question?
In a perfect world, yes. When you find a perfect world, send us an invite.
I reject lots of residential connections...
The real issue here is *KNOWING* who is residential or not. Only the ISP knows for sure; and they rarely tell others. The various blocklists are merely guessing. Using a rDNS name is an even worse guess.
However, senders who authenticate legitimately or legitimate sources of email (and yes, some spam sources too) connect just fine.
Authenticated sources can be traced and shutoff. If a random cablemodem user has some bot spewing spam, the only way to cut off the spam is to either (gee) block outbound port 25, or turn their connection off entirely. As a responsible admin, I'll take the least disruptive path. (I'll even preemptively do so.) --Ricky
On 10/25/11 12:31 PM, Ricky Beam wrote:
On Tue, 25 Oct 2011 12:55:58 -0400, Owen DeLong <owen@delong.com> wrote:
Wouldn't the right place for that form of rejection to occur be at the mail server in question?
In a perfect world, yes. When you find a perfect world, send us an invite.
I reject lots of residential connections...
The real issue here is *KNOWING* who is residential or not. Only the ISP knows for sure; and they rarely tell others. The various blocklists are merely guessing. Using a rDNS name is an even worse guess.
Agreed. Don't expect a comprehensive list based upon rDNS containing specific host names with IPv6. That would represent a never ending process to collect.
However, senders who authenticate legitimately or legitimate sources of email (and yes, some spam sources too) connect just fine.
Authenticated sources can be traced and shutoff. If a random cablemodem user has some bot spewing spam, the only way to cut off the spam is to either (gee) block outbound port 25, or turn their connection off entirely. As a responsible admin, I'll take the least disruptive path. (I'll even preemptively do so.)
Blocking ports is not free, but don't expect all DSL providers to unblock port 25 unless it is for a business account. Price differentials help pay for port blocking. In a perfect world, all SMTP transactions would cryptographically authenticate managing domains for the MTA. With less effort and resources (than that needed to check block lists) IPv6 could continue to work through LSNs aimed at helping those refusing to offer IPv6 connectivity. Blocking at the prefix requires block list resources 65k times greater than what is currently needed for IPv4. IPv6 announcements seem likely to expand another 6 fold fairly soon as well. In comparison, cryptographic authentication would be more practical, but a hybrid Kerberos scheme supported by various third-party service providers could reduce the overhead. Is it time for AuthenticatedMTP? -Doug
On Tue, Oct 25, 2011 at 2:49 AM, Owen DeLong <owen@delong.com> wrote:
Interesting... Most people I know run the same policy on 25 and 587 these days...
to-local-domain, no auth needed. relay, auth needed.
auth required == TLS required.
Anything else on either port seems not best practice to me.
RFC 5068 covers the best practice, and it's not what you've got above. Allowing unauthenticated inbound mail on port 587 defeats the entire purpose of blocking port 25 - the front door is now closed to spammers, but you've left the back door open! (Security through obscurity saves you here in that spammers rarely use port 587 - yet). There isn't a single situations where you should be expecting an unauthenticated inbound message on the 'Submission' port (is, 587) As much as some ISPs still resist blocking port 25 for residential customers, it does have a major impact on the volume of spam leaving your network. I've worked with numerous ISPs as they have gone through the process of blocking port 25 outbound. In every case the number of end-user complaints has been low enough to be basically considered background noise, but the benefits have been significant - including one ISP who removed not only themselves but also their entire country from most of the 'Top 10 Spammers' list when they did it! Scott.
On Oct 26, 2011, at 8:07 PM, Scott Howard wrote:
On Tue, Oct 25, 2011 at 2:49 AM, Owen DeLong <owen@delong.com> wrote: Interesting... Most people I know run the same policy on 25 and 587 these days...
to-local-domain, no auth needed. relay, auth needed.
auth required == TLS required.
Anything else on either port seems not best practice to me.
RFC 5068 covers the best practice, and it's not what you've got above.
Allowing unauthenticated inbound mail on port 587 defeats the entire purpose of blocking port 25 - the front door is now closed to spammers, but you've left the back door open! (Security through obscurity saves you here in that spammers rarely use port 587 - yet). There isn't a single situations where you should be expecting an unauthenticated inbound message on the 'Submission' port (is, 587)
I still believe that that RFC is not correct. That blocking port 25 has too much collateral damage and is not a best practice. As such, you are correct, I am not following RFC 5068. A certain amount of spam does hit my system, but, the hosts that deliver it are identified and blocked reasonably quickly.
As much as some ISPs still resist blocking port 25 for residential customers, it does have a major impact on the volume of spam leaving your network. I've worked with numerous ISPs as they have gone through the process of blocking port 25 outbound. In every case the number of end-user complaints has been low enough to be basically considered background noise, but the benefits have been significant - including one ISP who removed not only themselves but also their entire country from most of the 'Top 10 Spammers' list when they did it!
Blocking outbound port 25 would not reduce the already infinitesimal volume of spam leaving my network in the least. It would, however, block a lot of legitimate traffic. No thanks. Owen
Owen DeLong <owen@delong.com> writes:
On Oct 26, 2011, at 8:07 PM, Scott Howard wrote:
As much as some ISPs still resist blocking port 25 for residential customers, it does have a major impact on the volume of spam leaving your network. I've worked with numerous ISPs as they have gone through the process of blocking port 25 outbound. In every case the number of end-user complaints has been low enough to be basically considered background noise, but the benefits have been significant - including one ISP who removed not only themselves but also their entire country from most of the 'Top 10 Spammers' list when they did it!
Blocking outbound port 25 would not reduce the already infinitesimal volume of spam leaving my network in the least. It would, however, block a lot of legitimate traffic.
No thanks.
I understand that. But you may want to say "Yes, please" to having port 25 blocked by default while having the ability to turn that filter off. As a residential user, the IP address you use to connect to MXs will inevitably be one carved out of a pool allocated to residential users. This is completely independent of whether you are using IPv4 or IPv6, or having static or dynamic addresses. You buy a residential product => you get a residential address. What that means to you, is that the filters running on all the MXs around the world will classify *you* based on the observed behaviour of all the residential customers of your ISP (among other factors of course, but that's not relevant for this discussion). If your ISP offers an open port 25 to everyone policy, then you may experience that your legitimate traffic drowns in a large volume of worm or virus initiated traffic, making a number of MXs drop your traffic with the rest of the bunch. If, on the other hand, your ISP block port 25 by default and let you disable the filter, then your traffic will probably account for a significant part of the traffic the MXs of the world see from that address pool. This increases the probability that they classify the pool as "friendly", and end up accepting your traffic. Most MXs will probably have a sane enough policy to make them accept your mail in either case. But some won't. And as I'm sure you are aware of: You can influence your local policy by choosing your ISP, but you can rarely influence the policies of the MXs you want to talk to. That's why you would want to say "yes, please" to the "filter by default but offer a disable knob" service. Bjørn
I find that large network providers have less issues with this issue. As a small regional provider, implementing a "sane" port 25 filter has saved us a lot of money and customer headaches over the years. Our costs would be much higher if we could not save labor hours by implementing this. Possibly making service costs even more prohibitive. Pre implementation of these filters we had lower customer satisfaction, and were contemplating hiring more people to handle the labor load, due to UCE issues. It is interesting that some people who fully understand that the Internet is composed of many networks run by people with different interests can say what is best for the Internet as a whole. How my organization (or yours or anybody else's) runs our network, is between us and our paying users. But this thread has been interesting to follow. :) - Brian J.
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Wednesday, October 26, 2011 11:42 PM To: Scott Howard Cc: nanog@nanog.org Subject: Re: Outgoing SMTP Servers
On Oct 26, 2011, at 8:07 PM, Scott Howard wrote:
On Tue, Oct 25, 2011 at 2:49 AM, Owen DeLong <owen@delong.com> wrote: Interesting... Most people I know run the same policy on 25 and 587 these days...
to-local-domain, no auth needed. relay, auth needed.
auth required == TLS required.
Anything else on either port seems not best practice to me.
RFC 5068 covers the best practice, and it's not what you've got above.
Allowing unauthenticated inbound mail on port 587 defeats the entire purpose of blocking port 25 - the front door is now closed to spammers, but you've left the back door open! (Security through obscurity saves you here in that spammers rarely use port 587 - yet). There isn't a single situations where you should be expecting an unauthenticated inbound message on the 'Submission' port (is, 587)
I still believe that that RFC is not correct. That blocking port 25 has too much collateral damage and is not a best practice.
As such, you are correct, I am not following RFC 5068. A certain amount of spam does hit my system, but, the hosts that deliver it are identified and blocked reasonably quickly.
As much as some ISPs still resist blocking port 25 for residential customers, it does have a major impact on the volume of spam leaving your network. I've worked with numerous ISPs as they have gone through the process of blocking port 25 outbound. In every case the number of end-user complaints has been low enough to be basically considered background noise, but the benefits have been significant - including one ISP who removed not only themselves but also their entire country from most of the 'Top 10 Spammers' list when they did it!
Blocking outbound port 25 would not reduce the already infinitesimal volume of spam leaving my network in the least. It would, however, block a lot of legitimate traffic.
No thanks.
Owen
On Thu, 27 Oct 2011 13:53:34 -0000, Brian Johnson said:
It is interesting that some people who fully understand that the Internet is composed of many networks run by people with different interests can say what is best for the Internet as a whole. How my organization (or yours or anybody else's) runs our network, is between us and our paying users.
The fact that a behavior is "best" for your network does in no way, shape, or form, say anything about what's best for the Internet as a whole. In fact, it's well-understood that there are entire classes of behaviors that are optimal for single actors, but fail when deployed widely. https://en.wikipedia.org/wiki/Tragedy_of_the_commons
On Thu, 27 Oct 2011 13:53:34 -0000, Brian Johnson said:
It is interesting that some people who fully understand that the Internet is composed of many networks run by people with different interests can say what is best for the Internet as a whole. How my organization (or yours or anybody else's) runs our network, is between us and our paying users.
That claim is true *ONLY* to the extent that 'how your organization runs your network' does _not_ have an adverse effect on other peoples networks. The fact of the matter is that you do not have a viable business without the collective 'tolerance'/'approval' of the rest of the world. You, and your organization, need them far more than they need you. _How_ you pro-actively ensure spam does not exit from your network IS your business. That you *do* do so _is_ within the action purveiw of the 'rest of the world'. "Doing so" requires that you _actively_ monitor the behavior of your customers and have 'ways and means' in place to (a) detect, and (b) _stop_ immediately upon detection, such abusive behavior by your customers. One of the 'easiest', and most _cost-effective_ ways of doing so *is* to force all outgoing mail from your customers through a 'choke point' for examination/filtering/blckcing. The simplest way of doing that, *without* running afoul of 'wiretapping' statutes. is to require, by policy and by blocking direct external access, that customer out-bound email traffic go through your servers, and doing the necessary 'inspection' there.
-----Original Message----- From: Robert Bonomi [mailto:bonomi@mail.r-bonomi.com] Sent: Thursday, October 27, 2011 12:50 PM To: nanog@nanog.org Subject: Re: Outgoing SMTP Servers
On Thu, 27 Oct 2011 13:53:34 -0000, Brian Johnson said:
It is interesting that some people who fully understand that the Internet is composed of many networks run by people with different interests can say what is best for the Internet as a whole. How my organization (or yours or anybody else's) runs our network, is between us and our paying users.
That claim is true *ONLY* to the extent that 'how your organization runs your network' does _not_ have an adverse effect on other peoples networks.
The fact of the matter is that you do not have a viable business without the collective 'tolerance'/'approval' of the rest of the world.
OK.
You, and your organization, need them far more than they need you.
Argumentative and unnecessary.
_How_ you pro-actively ensure spam does not exit from your network IS your business.
That you *do* do so _is_ within the action purveiw of the 'rest of the world'.
Judge me as you will. My customers will determine if I change this policy. Their judgment is all that matters in this circumstance as the external Internet community has the access that the Internet community needs relative to this instance.
"Doing so" requires that you _actively_ monitor the behavior of your customers and have 'ways and means' in place to (a) detect, and (b) _stop_ immediately upon detection, such abusive behavior by your customers.
One of the 'easiest', and most _cost-effective_ ways of doing so *is* to force all outgoing mail from your customers through a 'choke point' for examination/filtering/blckcing.
The simplest way of doing that, *without* running afoul of 'wiretapping' statutes. is to require, by policy and by blocking direct external access, that customer out-bound email traffic go through your servers, and doing the necessary 'inspection' there.
I think you support my position, but I could be convinced otherwise. :) Be careful with you punctuation. I got lost a few times there :) - Brian
On Thu, Oct 27, 2011 at 1:50 PM, Robert Bonomi <bonomi@mail.r-bonomi.com> wrote:
On Thu, 27 Oct 2011 13:53:34 -0000, Brian Johnson said:
As a small regional provider, implementing a "sane" port 25 filter has saved us a lot of money and customer headaches over the years.
It is interesting that some people who fully understand that the Internet is composed of many networks run by people with different interests can say what is best for the Internet as a whole. How my organization (or yours or anybody else's) runs our network, is between us and our paying users.
That claim is true *ONLY* to the extent that 'how your organization runs your network' does _not_ have an adverse effect on other peoples networks.
What I *prevent* from entering or leaving my network is *my business*, between me and my customers. What I allow to leave my network can become yours. As with all rules, there's at least one exception: the monopoly or duopoly vendor has an obligation to ensure that restrictions don't abuse his position in the market. Nevertheless, "Mr. Small Business, you shouldn't be blocking that packet, it's bad for the Internet," is not for you or anyone else to say. 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: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Thursday, October 27, 2011 10:24 AM To: Brian Johnson Cc: nanog@nanog.org Subject: Re: Outgoing SMTP Servers
On Thu, 27 Oct 2011 13:53:34 -0000, Brian Johnson said:
It is interesting that some people who fully understand that the Internet is composed of many networks run by people with different interests can say what is best for the Internet as a whole. How my organization (or yours or anybody else's) runs our network, is between us and our paying users.
The fact that a behavior is "best" for your network does in no way, shape, or form, say anything about what's best for the Internet as a whole. In fact, it's well-understood that there are entire classes of behaviors that are optimal for single actors, but fail when deployed widely.
So... I'm in complete agreement with your statement, but The Wikipedia reference is not pertinent (and a little sophomoric). :)
On Thu, 27 Oct 2011 18:17:22 -0000, Brian Johnson said:
So... I'm in complete agreement with your statement, but The Wikipedia reference is not pertinent.
So I point out the tragedy of the commons, you agree with it, but the Wikipedia reference that talks about the same exact thing isn't pertinent? How does that follow? :)
On 10/27/2011 05:38 PM, Valdis.Kletnieks@vt.edu wrote:
On Thu, 27 Oct 2011 18:17:22 -0000, Brian Johnson said:
So... I'm in complete agreement with your statement, but The Wikipedia reference is not pertinent.
So I point out the tragedy of the commons, you agree with it, but the Wikipedia reference that talks about the same exact thing isn't pertinent? How does that follow? :) Maybe he is concerned that the Wikipedia article gets into nit-picking about the ownership of the commons that isn't relevant to our problem, and also is rather long-winded. Hardin got into some things at the end of his paper that probably aren't either (but then, he was a population biologist and not an economist). BTW - that paper is a good read and not too long. The journal link (reference 1 in the wikipedia article) actually works openly (AAAS only blocks full access for a while...)
For our purpose, the ownership of the commons in question truly isn't relevant; the fundamental statement of the tragedy for us is that a "useful" resource that is incrementally free (or even cheap enough) to a large number of participants will get exploited and probably overused. I'm not aware of any solution to this problem with commons that doesn't involve a central authority :-( In feudal practice the landlord could do some enforcement; the spanish alcaldes were another good example of a semi-central solution to the commons problem (water rights in their origins, though their authority grew over time). Classic economics says that market pricing is the solution, but that tends to result in another kind of tragedy. -- Pete
On Thu, Oct 27, 2011 at 9:29 PM, Pete Carah <pete@altadena.net> wrote:
On 10/27/2011 05:38 PM, Valdis.Kletnieks@vt.edu wrote:
On Thu, 27 Oct 2011 18:17:22 -0000, Brian Johnson said:
So... I'm in complete agreement with your statement, but The Wikipedia reference is not pertinent.
For our purpose, the ownership of the commons in question truly isn't relevant;
Pete, For our purpose, describing the Internet as a commons fundamentally misunderstands its nature. A commons is jointly owned, either by a non-trivial number of private owners or by all citizens of a government. For example, I own a 3/11,000ths share of a private road network. Those roads are a commons. The Internet is not jointly owned. You do not own a one seven billionth share of the network in my basement and I do not a own one seven billionth of yours. Rather, the Internet is a cooperative effort of the sole owners of its distinct individual pieces. As the owner of the network in my basement, it is my privilege alone to decide how you may and may not use it. The same goes for the respective owners of every other piece of the Internet. Nor is the data transiting these networks a commons. The air over my land is a commons. I don't control it. If I pollute it or if I don't, it promptly travels over someone else's land. According to intellectual property law, the data transiting the Internet is owned by its originator. That ownership does not change as the packets move between my network and yours. The point is, at every step with the Internet there is always a specific owner whose property is either being used with his permission or abused against his wishes. At no point is it a commons. You must understand the Internet's nature before you can properly consider my responsibility for the instructions passed from or through my network which direct the action of computers in yours. 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 10/28/2011 5:44 AM, William Herrin wrote:
A commons is jointly owned, either by a non-trivial number of private owners or by all citizens of a government.
The practical use of the term is a bit broader: <http://en.wikipedia.org/wiki/Commons> As rule, the term gets applied to situations of fate-sharing when actions by some affect utility for many. You cited air pollution. The Internet can suffer comparable effects. Spam can reasonably be called pollution and it has a systemic effect on all users. For such an issue, it's reasonable and even helpful to view it as a commons. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
On Thu, Oct 27, 2011 at 11:59 PM, Dave CROCKER <dhc2@dcrocker.net> wrote:
On 10/28/2011 5:44 AM, William Herrin wrote:
A commons is jointly owned, either by a non-trivial number of private owners or by all citizens of a government.
The practical use of the term is a bit broader: <http://en.wikipedia.org/wiki/Commons>
As rule, the term gets applied to situations of fate-sharing when actions by some affect utility for many.
You cited air pollution. The Internet can suffer comparable effects.
Spam can reasonably be called pollution and it has a systemic effect on all users. For such an issue, it's reasonable and even helpful to view it as a commons.
Dave, I respectfully disagree. If you throw pollution into the air, it may eventually impact me or it may blow somewhere else. Mostly it'll blow somewhere else. But as lots of people throw pollution into the air, some non-trivial portion of that pollution will drift over me. This is the so-called tragedy. By contrast, if you send me spam email, you are directly abusing my computer. The linkage is not at all amorphous. You send to me. I receive from you. There is no "all world" or "local area" destination. If you send without some specific pointer in my direction, I won't receive it. Ever. Imagining spam as a tragedy of the commons disguises its true nature as a massive quantity of one-on-one abuses of individual owners' computers. Worse, it forgives the owners of the intermediate networks for shrugging their shoulders and turning a blind eye to the abusers. 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
Email as facility is a public good whether it constitutes a commons or not... If wasn't you wouldn't bother putting up a server that would accept unsolicited incoming connections on behalf of yourself and others, doing so is generically non-rival and non-excludable although not perfectly so in either case (what public good is). On 10/27/11 21:26 , William Herrin wrote:
On Thu, Oct 27, 2011 at 11:59 PM, Dave CROCKER <dhc2@dcrocker.net> wrote:
On 10/28/2011 5:44 AM, William Herrin wrote:
A commons is jointly owned, either by a non-trivial number of private owners or by all citizens of a government.
The practical use of the term is a bit broader: <http://en.wikipedia.org/wiki/Commons>
As rule, the term gets applied to situations of fate-sharing when actions by some affect utility for many.
You cited air pollution. The Internet can suffer comparable effects.
Spam can reasonably be called pollution and it has a systemic effect on all users. For such an issue, it's reasonable and even helpful to view it as a commons.
Dave,
I respectfully disagree.
If you throw pollution into the air, it may eventually impact me or it may blow somewhere else. Mostly it'll blow somewhere else. But as lots of people throw pollution into the air, some non-trivial portion of that pollution will drift over me. This is the so-called tragedy.
By contrast, if you send me spam email, you are directly abusing my computer. The linkage is not at all amorphous. You send to me. I receive from you. There is no "all world" or "local area" destination. If you send without some specific pointer in my direction, I won't receive it. Ever.
Imagining spam as a tragedy of the commons disguises its true nature as a massive quantity of one-on-one abuses of individual owners' computers. Worse, it forgives the owners of the intermediate networks for shrugging their shoulders and turning a blind eye to the abusers.
Regards, Bill Herrin
On Fri, Oct 28, 2011 at 1:34 AM, Joel jaeggli <joelja@bogus.com> wrote:
Email as facility is a public good whether it constitutes a commons or not... If wasn't you wouldn't bother putting up a server that would accept unsolicited incoming connections on behalf of yourself and others, doing so is generically non-rival and non-excludable although not perfectly so in either case (what public good is).
Interesting. I want to abstract and restate what I think you just said and ask you to correct my understanding: Making a service accessible to the public via the Internet implicitly grants some basic permission to that public to make use of the service, permission which can not be revoked solely by saying so. If that's the case, what is the common denominator? What is the standard of permission automatically granted by placing an email server on the internet, from which a particular operator may grant more permission but may not reasonably grant less? Put another way, what's the whitelist of activities for which we generally expect our vendor to ignore complaints, what's the blacklist of activities for which a vendor who fails to adequately redress complaints is misbehaving and what's left in the gray zone where behavior might be abusive but is not automatically so? 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
Girls, You are all pretty. End the thread. Seriously. -Hammer- "I was a normal American nerd" -Jack Herer On 10/28/2011 01:59 PM, William Herrin wrote:
On Fri, Oct 28, 2011 at 1:34 AM, Joel jaeggli<joelja@bogus.com> wrote:
Email as facility is a public good whether it constitutes a commons or not... If wasn't you wouldn't bother putting up a server that would accept unsolicited incoming connections on behalf of yourself and others, doing so is generically non-rival and non-excludable although not perfectly so in either case (what public good is).
Interesting. I want to abstract and restate what I think you just said and ask you to correct my understanding:
Making a service accessible to the public via the Internet implicitly grants some basic permission to that public to make use of the service, permission which can not be revoked solely by saying so.
If that's the case, what is the common denominator? What is the standard of permission automatically granted by placing an email server on the internet, from which a particular operator may grant more permission but may not reasonably grant less? Put another way, what's the whitelist of activities for which we generally expect our vendor to ignore complaints, what's the blacklist of activities for which a vendor who fails to adequately redress complaints is misbehaving and what's left in the gray zone where behavior might be abusive but is not automatically so?
Regards, Bill Herrin
----- Original Message -----
From: "William Herrin" <bill@herrin.us>
Interesting. I want to abstract and restate what I think you just said and ask you to correct my understanding:
Making a service accessible to the public via the Internet implicitly grants some basic permission to that public to make use of the service, permission which can not be revoked solely by saying so.
That's correct; did you think it wasn't? The offer is *in the presence of a standard service on a standard port*; if I put a SMTP receiver on tcp/25, you are, yes, implicitly permitted to try to use it to send me email. There *is no place* to put "saying permission is revoked", so where would someone look, even if their daemon wanted to look.
If that's the case, what is the common denominator? What is the standard of permission automatically granted by placing an email server on the internet, from which a particular operator may grant more permission but may not reasonably grant less? Put another way, what's the whitelist of activities for which we generally expect our vendor to ignore complaints, what's the blacklist of activities for which a vendor who fails to adequately redress complaints is misbehaving and what's left in the gray zone where behavior might be abusive but is not automatically so?
If there are specific things you want people not to do, *make it impossible for them to do those things* (ssh authentication, for example). Above that, I suppose that rate limiting failures is expected of a connecting client... 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 http://photo.imageinc.us +1 727 647 1274
Bill, Your misunderstanding of physical pollution pollutes your understanding of spam. But it turns out that you seem to misunderstand spam quite a bit, independently. On 10/27/2011 9:26 PM, William Herrin wrote:
If you throw pollution into the air, it may eventually impact me or it may blow somewhere else. Mostly it'll blow somewhere else. But as lots of people throw pollution into the air, some non-trivial portion of that pollution will drift over me. This is the so-called tragedy.
They used to be able to tell how recently someone moved to in Los Angeles by how corrupted their lungs were, from the /local/ pollution. Maybe it's still possible. Pollution tends to increase the occurrence of some diseases, thereby significantly increasing societal health costs. So the casual view of pollution going "somewhere else" is simply wrong. Still you do seem to understand that it affects some mass of folk.
By contrast, if you send me spam email, you are directly abusing my computer. The linkage is not at all amorphous. You send to me. I receive from you. There is no "all world" or "local area" destination. If you send without some specific pointer in my direction, I won't receive it. Ever.
Imagining spam as a tragedy of the commons disguises its true nature as a massive quantity of one-on-one abuses of individual owners' computers. Worse, it forgives the owners of the intermediate networks for shrugging their shoulders and turning a blind eye to the abusers.
Email travels over shared resources. Spam consumes roughly %95 percent of that shared path (comm lines and servers). Receiving operators must devote masses of resources to filter that firehose of mostly junk, in order to get everyone's mailboxes to remain at least somewhat useful. Since the spammers are well-organized and aggressive and often quite bright, they adapt their attacks to get round these filters, thereby creating an extremely unstable arms race. This means the entire situation is extremely unstable. When -- not if -- it breaks, mail becomes unusable. That will be a common suffering. The one-to-one cost or damage is probably also a reasonable perspective, but it's /incremental/ to the shared cost. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
On Oct 30, 2011, at 2:19 PM, Dave CROCKER wrote: <snip ridiculousness>
Email travels over shared resources. Spam consumes roughly %95 percent of that shared path (comm lines and servers). Receiving operators must devote masses of resources to filter that firehose of mostly junk, in order to get everyone's mailboxes to remain at least somewhat useful. Since the spammers are well-organized and aggressive and often quite bright, they adapt their attacks to get round these filters, thereby creating an extremely unstable arms race. This means the entire situation is extremely unstable. When -- not if -- it breaks, mail becomes unusable. That will be a common suffering.
The one-to-one cost or damage is probably also a reasonable perspective, but it's /incremental/ to the shared cost.
d/ --
Dave Crocker Brandenburg InternetWorking bbiw.net
So you support filtering end-user outbound SMTP sessions as this is a means to prevent misuse of the Commons*. Correct? - Brian * I do not think of the Internet as a commons, but Dave does. I will not comment on this as it is tangential to the thread.
On 10/30/2011 8:36 PM, Brian Johnson wrote:
So you support filtering end-user outbound SMTP sessions as this is a means to prevent misuse of the Commons*. Correct?
If it is acceptable to have the receiving SMTP server at one end of a connection do filtering -- and it is -- then why wouldn't it be acceptable to have filtering done at the source end of that SMTP connection? As soon as we step upstream this way, stepping up earlier still is merely a question of efficacy and efficiency. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Dave CROCKER wrote:
On 10/30/2011 8:36 PM, Brian Johnson wrote:
So you support filtering end-user outbound SMTP sessions as this is a means to prevent misuse of the Commons*. Correct?
If it is acceptable to have the receiving SMTP server at one end of a connection do filtering -- and it is -- then why wouldn't it be acceptable to have filtering done at the source end of that SMTP connection?
As soon as we step upstream this way, stepping up earlier still is merely a question of efficacy and efficiency.
I've often wondered the same thing as to what the resistance is to outbound filtering is. I can think of a few possibilities: 1) cost of filtering 2) false positives 3) really _not_ wanting to know about abuse Given the cost of incoming filtering, I'd think that outbound filtering would be down in the noise. On the other hand, getting support blowback for false positives seems plausible, but probably no worse than blowback from false positives incoming. So, #3 -- assuming my list is exhaustive which it probably isn't -- seems like a real possibility. Especially when you consider that it opens a can of worms of "now that we know we have a likely bot, what do we with it, and how much will that cost?" Mike
On 10/31/2011 11:48 AM, Michael Thomas wrote:
I've often wondered the same thing as to what the resistance is to outbound filtering is. I can think of a few possibilities:
1) cost of filtering 2) false positives 3) really _not_ wanting to know about abuse
On the other hand, you have 1) cost of tracking 2) support costs handling infections It's really an range from "easiest and cost effective" to "doing it right". I personally run hybrid. There are areas that are near impossible to track; this is especially true for wide area wireless/cellular/NAT areas. I always recommend my customers block tcp/25, even to the local smarthosts. Use 587 and authentication to support better tracking. It's a hack, though, as it doesn't stop other abuses and it won't fix the underlying root cause. In locations that support ease of tracking, using a mixture of feedback loops with proper support is usually the proper way. This allows notification and fixing of the root cause. In our case, we recommend quick suspensions to demonstrate to customer how seriously we take the problem, and then we point out that the sending of spam/scanning is only the easier to detect symptoms. It is unlikely we'll notice if they have a keylogger as well. Finally, when architecture allows it, dynamic profiles with ACL support allowing a default of tcp/25 blocked, and easy to find and click removal of an account from tcp/25 blocking, combined with ACL monitoring, flagging, and notification by support staff is probably the ultimate in ideal scenarios. Combined with a % of traffic mirrored into a tunnel to an IDS which monitors for things such as network scanning or known signatures outbound, it makes for a very effective mechanism to assist customers in protecting themselves. I'm personally curious how much traffic is necessary to mirror to properly detect problems. ie, can you get away with 1% or less (GE for each 100GE-200GE of traffic) or if you must cover as much as 10%+. My traffic load is small enough that it doesn't matter, but it's always nice to know how well something might scale. Jack
Sent from my iPad On Oct 31, 2011, at 1:30 PM, "Jack Bates" <jbates@brightok.net> wrote:
On 10/31/2011 11:48 AM, Michael Thomas wrote:
I've often wondered the same thing as to what the resistance is to outbound filtering is. I can think of a few possibilities:
1) cost of filtering 2) false positives 3) really _not_ wanting to know about abuse
On the other hand, you have
1) cost of tracking 2) support costs handling infections
It's really an range from "easiest and cost effective" to "doing it right". I personally run hybrid. There are areas that are near impossible to track; this is especially true for wide area wireless/cellular/NAT areas. I always recommend my customers block tcp/25, even to the local smarthosts. Use 587 and authentication to support better tracking. It's a hack, though, as it doesn't stop other abuses and it won't fix the underlying root cause.
Let me know when u can "fix" the root causes. The two I know of: 1. Bad actors 2. Clueless users
In locations that support ease of tracking, using a mixture of feedback loops with proper support is usually the proper way. This allows notification and fixing of the root cause. In our case, we recommend quick suspensions to demonstrate to customer how seriously we take the problem, and then we point out that the sending of spam/scanning is only the easier to detect symptoms. It is unlikely we'll notice if they have a keylogger as well.
Still not the real root cause, but close. ;) Largely in agreement otherwise. - Brian
On 10/31/2011 8:12 PM, Brian Johnson wrote:
Sent from my iPad
On Oct 31, 2011, at 1:30 PM, "Jack Bates"<jbates@brightok.net> wrote:
On 10/31/2011 11:48 AM, Michael Thomas wrote:
I've often wondered the same thing as to what the resistance is to outbound filtering is. I can think of a few possibilities:
1) cost of filtering 2) false positives 3) really _not_ wanting to know about abuse On the other hand, you have
1) cost of tracking 2) support costs handling infections
It's really an range from "easiest and cost effective" to "doing it right". I personally run hybrid. There are areas that are near impossible to track; this is especially true for wide area wireless/cellular/NAT areas. I always recommend my customers block tcp/25, even to the local smarthosts. Use 587 and authentication to support better tracking. It's a hack, though, as it doesn't stop other abuses and it won't fix the underlying root cause.
Let me know when u can "fix" the root causes. The two I know of: 1. Bad actors 2. Clueless users
While true, from a security viewpoint, the root cause is loss of control over the system involved. Spam, while perhaps the most visible and annoying to others is not my highest concern (We find the number of clueless users direct spamming is miniscule compared to hijacked systems). My concern is that the customer has lost control of their machine and could at that moment be unknowingly giving out critical information. -Jack
On: Mon, 31 Oct 2011 09:48:21 -0700, Michael Thomas <mike@mtcc.com> opined:
Dave CROCKER wrote:
On 10/30/2011 8:36 PM, Brian Johnson wrote:
So you support filtering end-user outbound SMTP sessions as this is a means to prevent misuse of the Commons*. Correct?
If it is acceptable to have the receiving SMTP server at one end of a connection do filtering -- and it is -- then why wouldn't it be acceptable to have filtering done at the source end of that SMTP connection?
As soon as we step upstream this way, stepping up earlier still is merely a question of efficacy and efficiency.
I've often wondered the same thing as to what the resistance is to outbound filtering is. I can think of a few possibilities:
1) cost of filtering 2) false positives 3) really _not_ wanting to know about abuse
Given the cost of incoming filtering, I'd think that outbound filtering would be down in the noise. On the other hand, getting support blowback for false positives seems plausible, but probably no worse than blowback from false positives incoming. So, #3 -- assuming my list is exhaustive which it probably isn't -- seems like a real possibility. Especially when you consider that it opens a can of worms of "now that > we know we have a likely bot, what do we with it, and how much will that cost?"
There is an at-least-somewhat-valid argument against outbound filtering. to wit, various receiving systems may have different policies on what is/ is-not 'acceptable' traffic. They have a better idea of what is acceptable to the recipients (their users), than the originating MTA operator does. An originating system cannot accomodate that diversity of opinions _without_ getting input from all prospective recipients. And it is, of course, 'not practical' for every email recipient to notify every email 'source' network as to what that recpient considers 'acceptable'. <wry grin> There are only a relative handful of things a _residential_ provider can use to "reliably" filter outgoing mail. A non-comprehensive list: 1) 'Greylisting' at the origin is as effective at stopping spam as it is at the destination. 2) Checks for certain kinds of standards violations that legitimate mail software does not make. 3) Check for certain kinds of 'lies' in headers -- things that *cannot* occur in legitimate email. 4) 'Rate-limiting' to detect/quarrantine abnormal traffic levels. 5) Tracking SMTP 'MAIL FROM:" and the "From:" (or 'Resent-From:', if present), and quarrantining on abnormal numbers of different putative origins. There's no point in checking source addresses against any DNSBL, for reasons that should be 'obvious'. <*GRIN*> Further, any sort of "content" filters prevent customers from _discussing_ scams in e-mail. There is a 'hard' problem in letting the source 'opt out' of such filtering, because an intentional 'bad guy' will request his outgoing mail not be monitored, as well as the person who has a 'legitimate' reason for sending messages that might trip mindless content filters. Statistical note: Out of the last roughly 6,000 pieces of spam seen here, circa 2,700 were caught by checks 2), and 3) above, and another circa 2,600 were in character-sets not supported here. Incidentally, spam volume, as seen here, is running a bit _under_ 2/3 of all email, down from a peak of over 95%.
Sent from my iPad On Oct 31, 2011, at 4:17 PM, "Robert Bonomi" <bonomi@mail.r-bonomi.com> <snip>
There is an at-least-somewhat-valid argument against outbound filtering. to wit, various receiving systems may have different policies on what is/ is-not 'acceptable' traffic. They have a better idea of what is acceptable to the recipients (their users), than the originating MTA operator does. An originating system cannot accomodate that diversity of opinions _without_ getting input from all prospective recipients.
And it is, of course, 'not practical' for every email recipient to notify every email 'source' network as to what that recpient considers 'acceptable'. <wry grin>
This is not plausible. It also has nothing to do with a network owner protecting his network from his own users.
There are only a relative handful of things a _residential_ provider can use to "reliably" filter outgoing mail. A non-comprehensive list: 1) 'Greylisting' at the origin is as effective at stopping spam as it is at the destination. 2) Checks for certain kinds of standards violations that legitimate mail software does not make. 3) Check for certain kinds of 'lies' in headers -- things that *cannot* occur in legitimate email. 4) 'Rate-limiting' to detect/quarrantine abnormal traffic levels. 5) Tracking SMTP 'MAIL FROM:" and the "From:" (or 'Resent-From:', if present), and quarrantining on abnormal numbers of different putative origins.
There's no point in checking source addresses against any DNSBL, for reasons that should be 'obvious'. <*GRIN*>
Further, any sort of "content" filters prevent customers from _discussing_ scams in e-mail.
There is a 'hard' problem in letting the source 'opt out' of such filtering, because an intentional 'bad guy' will request his outgoing mail not be monitored, as well as the person who has a 'legitimate' reason for sending messages that might trip mindless content filters.
Statistical note: Out of the last roughly 6,000 pieces of spam seen here, circa 2,700 were caught by checks 2), and 3) above, and another circa 2,600 were in character-sets not supported here. Incidentally, spam volume, as seen here, is running a bit _under_ 2/3 of all email, down from a peak of over 95%.
This misses the point of the thread which is not filtering. It is port 25 blocking. Statistically all of he problems exist on TCP port 25. This is why the filtering is largely effective. - Brian
The point to make here is: - if an ISP takes the path of blocking tcp/25, then they MUST communicate this appropiately to customers and other users - they also MUST provide alternatives: SMTP over SSL should be allowed (tcp/465), authenticated relay, but *something*. IMO blocking 25/tcp is a side-effect of the failure of the whole ISP system to decisively deal with spammers. It's easier to blind-block 25/tcp than to do proper investigations and to collaborate with law enforcement. I have tried to hand reports with *static* IP addresses, contract identifiers and even home, mobile and work phone numbers of known spammers in Uruguay (I happen to have my personal feud with one that sells dog food), only to be shelved by management on the fears of legal action. I have also trouble swallowing the argument of "blocking 25/tcp is great because it avoids us getting into black lists and reduces spam". Yes, sure, but that doesn't prove it's the right approach in the long run, as you are dealing with symptoms and not causes/sources. It's the same thing as having tons of aspirines each time you have a headache. Even if the pain subsides, you might still have other underlying conditions that in fact are being masqueraded by your "solution". So, as it is often the case in society, we all pay the price. On Mon, Oct 31, 2011 at 11:17 PM, Brian Johnson <bjohnson@drtel.com> wrote:
Sent from my iPad
On Oct 31, 2011, at 4:17 PM, "Robert Bonomi" <bonomi@mail.r-bonomi.com>
<snip>
There is an at-least-somewhat-valid argument against outbound filtering. to wit, various receiving systems may have different policies on what is/ is-not 'acceptable' traffic. They have a better idea of what is acceptable to the recipients (their users), than the originating MTA operator does. An originating system cannot accomodate that diversity of opinions _without_ getting input from all prospective recipients.
And it is, of course, 'not practical' for every email recipient to notify every email 'source' network as to what that recpient considers 'acceptable'. <wry grin>
This is not plausible. It also has nothing to do with a network owner protecting his network from his own users.
There are only a relative handful of things a _residential_ provider can use to "reliably" filter outgoing mail. A non-comprehensive list: 1) 'Greylisting' at the origin is as effective at stopping spam as it is at the destination. 2) Checks for certain kinds of standards violations that legitimate mail software does not make. 3) Check for certain kinds of 'lies' in headers -- things that *cannot* occur in legitimate email. 4) 'Rate-limiting' to detect/quarrantine abnormal traffic levels. 5) Tracking SMTP 'MAIL FROM:" and the "From:" (or 'Resent-From:', if present), and quarrantining on abnormal numbers of different putative origins.
There's no point in checking source addresses against any DNSBL, for reasons that should be 'obvious'. <*GRIN*>
Further, any sort of "content" filters prevent customers from _discussing_ scams in e-mail.
There is a 'hard' problem in letting the source 'opt out' of such filtering, because an intentional 'bad guy' will request his outgoing mail not be monitored, as well as the person who has a 'legitimate' reason for sending messages that might trip mindless content filters.
Statistical note: Out of the last roughly 6,000 pieces of spam seen here, circa 2,700 were caught by checks 2), and 3) above, and another circa 2,600 were in character-sets not supported here. Incidentally, spam volume, as seen here, is running a bit _under_ 2/3 of all email, down from a peak of over 95%.
This misses the point of the thread which is not filtering. It is port 25 blocking. Statistically all of he problems exist on TCP port 25. This is why the filtering is largely effective.
- Brian
-- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =========================
Dave CROCKER [mailto:dhc2@dcrocker.net] said on Sunday, 30 October, 2011 22:41
On 10/30/2011 8:36 PM, Brian Johnson wrote:
So you support filtering end-user outbound SMTP sessions as this is a means to prevent misuse of the Commons*. Correct?
If it is acceptable to have the receiving SMTP server at one end of a connection do filtering -- and it is -- then why wouldn't it be acceptable to have filtering done at the source end of that SMTP connection?
As soon as we step upstream this way, stepping up earlier still is merely a question of efficacy and efficiency.
Actually, if it is my network I have the absolute right to control what comes in and what goes out. If I am a commercial entity and my paying customers like this, then I will make lots of money. If they don't, I will go out of business. Thus for self-interest and survival end-user-networks do not restrict outbound excessively but block inbound with various policies that strike a balance between paying customers going elsewhere and paying customers leaving for less controlled environments, while still making a profit and staying in business. Hence, we end up with the situation that we have. It won't change without either (a) every operator deciding to do the same thing for their own collective best interest (such as blocking outbound TCP/25); or, (b) external fascist forces. And the bit-movers really don't care, since all they do is move bits...and more bits means more money.
On Thu, 27 Oct 2011 23:44:16 EDT, William Herrin said:
For our purpose, describing the Internet as a commons fundamentally misunderstands its nature.
You *do* realize that for all your nice "Thei Internet Is Not A Commons" ranting, the basic problem is that some people (we'll call them spammers) *do* think that (a) it's a commons (or at least the exact ownership of a given chunk is irrelevant), and (b) they're allowed to graze their sheep upon it.
The Internet is not jointly owned. You do not own a one seven billionth share of the network in my basement and I do not a own one seven billionth of yours. Rather, the Internet is a cooperative effort of the sole owners of its distinct individual pieces.
That's correct, as far as it goes. However, what *is* a commons is the *value* of the cooperative effort - see Metcalf's Law. You turn off or disconnect your share of the Internet, my share of the *value* of the Internet drops slightly.
Nor is the data transiting these networks a commons. The air over my land is a commons. I don't control it. If I pollute it or if I don't, it promptly travels over someone else's land.
If you choose to pollute the air heavily, the value of the air drops for everybody. If you choose to pollute the Net heavily, the value of the Net drops for everybody.
The point is, at every step with the Internet there is always a specific owner whose property is either being used with his permission or abused against his wishes. At no point is it a commons.
Try working the same example but using a stream flowing across your property instead, that feeds into the reservior the municipal water supply draws from. Yes, you own your section of the stream, and the guy next door owns his section, and so on. So the stream is not a commons - but the quality of the water in it *is*. (Yes, weak analogy, the downstream people have no say in it. Pretend for the sake of argument that everybody involved lives next to a stream that feeds the reservior that everybody drinks from - that's actually a pretty good match to the Internet topology).
Comments in-line
-----Original Message----- From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Friday, October 28, 2011 10:42 AM To: William Herrin Cc: nanog@nanog.org; Pete Carah Subject: Re: Outgoing SMTP Servers
On Thu, 27 Oct 2011 23:44:16 EDT, William Herrin said:
For our purpose, describing the Internet as a commons fundamentally misunderstands its nature.
You *do* realize that for all your nice "Thei Internet Is Not A Commons" ranting, the basic problem is that some people (we'll call them spammers) *do* think that (a) it's a commons (or at least the exact ownership of a given chunk is irrelevant), and (b) they're allowed to graze their sheep upon it.
So we should treat the Internet with respect to bad actors differently than others. STRIKE 1!
The Internet is not jointly owned. You do not own a one seven billionth share of the network in my basement and I do not a own one seven billionth of yours. Rather, the Internet is a cooperative effort of the sole owners of its distinct individual pieces.
That's correct, as far as it goes. However, what *is* a commons is the *value* of the cooperative effort - see Metcalf's Law. You turn off or disconnect your share of the Internet, my share of the *value* of the Internet drops slightly.
So bad actors destroying the value created by a cooperative of good actors is not bad? STRIKE 2!
Nor is the data transiting these networks a commons. The air over my land is a commons. I don't control it. If I pollute it or if I don't, it promptly travels over someone else's land.
If you choose to pollute the air heavily, the value of the air drops for everybody. If you choose to pollute the Net heavily, the value of the Net drops for everybody.
STRIKE 3! Oops got ahead of myself. I'm attempting to prevent the pollution but I may capture a little good water (almost nothing) along the way. To say that this is a way of "bad acting" and causes a loss of value to the Internet as a whole is pure folly.
The point is, at every step with the Internet there is always a specific owner whose property is either being used with his permission or abused against his wishes. At no point is it a commons.
Try working the same example but using a stream flowing across your property instead, that feeds into the reservior the municipal water supply draws from. Yes, you own your section of the stream, and the guy next door owns his section, and so on. So the stream is not a commons - but the quality of the water in it *is*. (Yes, weak analogy, the downstream people have no say in it. Pretend for the sake of argument that everybody involved lives next to a stream that feeds the reservior that everybody drinks from - that's actually a pretty good match to the Internet topology).
Actually if there were 4 strikes... STRIKE 4! Since I only transit destination packets, this analogy does not apply in any significant way. In fact this would only apply to transit providers filtering between peers or other transit connections. In my experience this is used at the customer connection to the transit or peering connection to protect the Internet from the clueless or compromised. - Brian BTW... what a great game last night! :)
On Fri, Oct 28, 2011 at 11:41 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 27 Oct 2011 23:44:16 EDT, William Herrin said:
For our purpose, describing the Internet as a commons fundamentally misunderstands its nature.
You *do* realize that for all your nice "Thei Internet Is Not A Commons" ranting, the basic problem is that some people (we'll call them spammers) *do* think that (a) it's a commons (or at least the exact ownership of a given chunk is irrelevant), and (b) they're allowed to graze their sheep upon it.
Squatters, trespassers and thieves always manage to find self-serving justifications for their behavior. The theory that it's OK to take from the faceless owner is not a new one, nor is it particularly related to the concept of a commons.
The point is, at every step with the Internet there is always a specific owner whose property is either being used with his permission or abused against his wishes. At no point is it a commons.
Try working the same example but using a stream flowing across your property instead, that feeds into the reservior the municipal water supply draws from. Yes, you own your section of the stream, and the guy next door owns his section, and so on. So the stream is not a commons - but the quality of the water in it *is*.
You've picked an interesting analogy for the flow of data on the Internet. If I dam up the stream on my side inducing my upstream neighbor's property to flood, I can be sued and I *will* lose the lawsuit. My action has willfully and directly damaged his property. Same if I divert all the water and dry out my downstream neighbor's lake. In more populous areas this sort of issue becomes sufficiently contentious that the government simply takes the stream, defining it as a "stormwater easement" and at that point, a regulated commons. My house is sandwiched between a stormwater easement under the back yard and a sanitary sewer easement under the front. I know far more about the legal issues around moving water than I ever wanted to. Like the fact that an areaway drain built in the 50's was typically attached to the sanitary sewer in full compliance with the building code, but the current building code forbids it and a judge will throw the book at you even though post-ex-facto normally applies to old construction. 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 28 October 2011 16:41, <Valdis.Kletnieks@vt.edu> wrote:
You *do* realize that for all your nice "Thei Internet Is Not A Commons" ranting, the basic problem is that some people (we'll call them spammers) *do* think that (a) it's a commons (or at least the exact ownership of a given chunk is irrelevant), and (b) they're allowed to graze their sheep upon it.
If someone keeps putting their animals in my garden then some countries would permit me to shoot them and sue the owner for the cost of the bullets. Even those with more restrictive property rights laws would still permit me to throw them off of my land and sue the owner for any damage they caused me. On the Internet when people start shooting their sheep they think they are the victims and go to the dutch police, sorry i mean the police of whichever jurisdiction the hypothetical entity is from, complaining that they are being deprived of their right to abuse peoples gardens. - Mike
++1 - Brian Sent from my iPad On Oct 28, 2011, at 2:05 PM, "Mike Jones" <mike@mikejones.in> wrote:
On 28 October 2011 16:41, <Valdis.Kletnieks@vt.edu> wrote:
You *do* realize that for all your nice "Thei Internet Is Not A Commons" ranting, the basic problem is that some people (we'll call them spammers) *do* think that (a) it's a commons (or at least the exact ownership of a given chunk is irrelevant), and (b) they're allowed to graze their sheep upon it.
If someone keeps putting their animals in my garden then some countries would permit me to shoot them and sue the owner for the cost of the bullets. Even those with more restrictive property rights laws would still permit me to throw them off of my land and sue the owner for any damage they caused me.
On the Internet when people start shooting their sheep they think they are the victims and go to the dutch police, sorry i mean the police of whichever jurisdiction the hypothetical entity is from, complaining that they are being deprived of their right to abuse peoples gardens.
- Mike
The alternative to centralization is enclosure: segmentation and private ownership of portions of the formerly common resource. Since the internet is already thus enclosed, with each portion completely owned by one autonomous agent or another, the problem at hand is not a commons problem at all but merely one of negotiation and market force. Internet Death Penalties, blacklists, and unilateral de-peering and blackholing are exactly the sorts of responses an economist would expect to see to a rogue actor in the network community, precise analogs of various types of economic ostracism going back to the merchant consortia of the middle ages. -Gabriel -----Original Message----- From: Pete Carah [mailto:pete@altadena.net] Sent: Thursday, October 27, 2011 9:29 PM To: nanog@nanog.org Subject: Re: Outgoing SMTP Servers Maybe he is concerned that the Wikipedia article gets into nit-picking about the ownership of the commons that isn't relevant to our problem, and also is rather long-winded. Hardin got into some things at the end of his paper that probably aren't either (but then, he was a population biologist and not an economist). BTW - that paper is a good read and not too long. The journal link (reference 1 in the wikipedia article) actually works openly (AAAS only blocks full access for a while...) For our purpose, the ownership of the commons in question truly isn't relevant; the fundamental statement of the tragedy for us is that a "useful" resource that is incrementally free (or even cheap enough) to a large number of participants will get exploited and probably overused. I'm not aware of any solution to this problem with commons that doesn't involve a central authority :-( In feudal practice the landlord could do some enforcement; the spanish alcaldes were another good example of a semi-central solution to the commons problem (water rights in their origins, though their authority grew over time). Classic economics says that market pricing is the solution, but that tends to result in another kind of tragedy. -- Pete On 10/27/2011 05:38 PM, Valdis.Kletnieks@vt.edu wrote:
On Thu, 27 Oct 2011 18:17:22 -0000, Brian Johnson said:
So... I'm in complete agreement with your statement, but The Wikipedia reference is not pertinent.
So I point out the tragedy of the commons, you agree with it, but the Wikipedia reference that talks about the same exact thing isn't pertinent? How does that follow? :)
----- Original Message -----
From: "Valdis Kletnieks" <Valdis.Kletnieks@vt.edu>
On Thu, 27 Oct 2011 18:17:22 -0000, Brian Johnson said:
So... I'm in complete agreement with your statement, but The Wikipedia reference is not pertinent.
So I point out the tragedy of the commons, you agree with it, but the Wikipedia reference that talks about the same exact thing isn't pertinent? How does that follow? :)
http://xkcd.com/958/ 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 http://photo.imageinc.us +1 727 647 1274
This sadly is very common. It is getting more common by the day it seems but this practice has started almost a decade ago. An easy work around is to use a custom port as they seem to just block port 25 as a bad port but leave just about everything else open including 2525 which seems to be a common secondary smtp port for hosting companies.
On 25 Oct 2011, at 09:34, "Tim" <timphp@progressivemarketingnetwork.com> wrote:
This sadly is very common. It is getting more common by the day it seems but this practice has started almost a decade ago.
An easy work around is to use a custom port as they seem to just block port 25 as a bad port but leave just about everything else open including 2525 which seems to be a common secondary smtp port for hosting companies.
I use port 80 which has not failed me so far ;-) -- Leigh ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
I didn't see anyone address this from the service provider abuse department perspective. I think larger ISP's got sick and tired of dealing with abuse reports or having their IP space blocked because of their own (infected) residential users sending out spam. The solution for them was to block the spam. The cheapest/easiest way to do this was to block TCP 25 between subs and the internet, thus starting a trend. If 587 becomes popular, spammers will move on and the same ISPs that blocked 25 will follow suit. A better solution would have been to prevent infection or remove infected machines from the network(strong abuse policies, monitoring, give out free antivirus software, etc). Unfortunately, several major players (ATT, for example) went down the road of limiting internet access. Now that they've had a taste, some of them feel they can block other ports or applications like p2p (Comcast), Netflix (usage based billing on Bell, ATT, others). Unfortunately, I don't see the trend reversing. I'm afraid that Internet freedoms are likely to continue to decline and an "Unlimited" Internet experience won't exist at the residential level in 5+ years. --Blake
Blake Hudson wrote:
If 587 becomes popular, spammers will move on and the same ISPs that blocked 25 will follow suit.
I don't see this happening as easily. Authenticated means an easier shutdown of an account, rather than some form of port block/etc.
A better solution would have been to prevent infection or remove infected machines from the network(strong abuse policies, monitoring, give out free antivirus software, etc).
We have 2/3 of that. Antivirus helps some, but has some side-effects on the helpdesk, if they're also the first response tier. I find it strange mentioning 'monitoring' alongside 'freedoms', though.
Unfortunately, I don't see the trend reversing. I'm afraid that Internet freedoms are likely to continue to decline and an "Unlimited" Internet experience won't exist at the residential level in 5+ years.
I'll agree with that.
Blake Hudson wrote:
If 587 becomes popular, spammers will move on and the same ISPs that blocked 25 will follow suit. I don't see this happening as easily. Authenticated means an easier shutdown of an account, rather than some form of port block/etc. An infected machine can just as easily send out mail on port 587 as it can using port 25. It's not hard for bot net hearders to come up with a
J wrote the following on 10/25/2011 9:25 PM: list of valid credentials stolen from email clients, via key loggers, or simply guessed through probability. I see it every day. I will shutdown a compromised account on my end, but that doesn't stop ATT's infected subscriber from spamming 100 other servers using 100 other stolen credentials. I may also send an abuse report to ATT if they have an infected machine trying to perform a dictionary attack or brute force logins against my port 587 SMTP server. ATT's going to deal with the abuse reports as cheaply as possible. If they receive enough, I have no doubt they'll repeat past mistakes.
On 26/10/2011 04:35, Blake Hudson wrote:
An infected machine can just as easily send out mail on port 587 as it can using port 25. It's not hard for bot net hearders to come up with a list of valid credentials stolen from email clients, via key loggers, or simply guessed through probability. I see it every day.
The difference is that it is the relay that accepts the spam on 587 that ends up on the blacklists. A mail server with a sysadmin that might care and probably sees business impact in not fixing the problem. As apposed to an end user that doesn't give a hoot. Compromised mail authentication details are quick and easy to take down. A server mis-configured as an open relay on 587 is a one time fix. End users infected with nasties are a support desk blackhole. Hours of time explaining to moms and pops how to download anti-virus and install it and configure it and run it... -- Graham Beneke
On 10/25/2011 10:19 PM, Blake Hudson wrote:
I didn't see anyone address this from the service provider abuse department perspective. I think larger ISP's got sick and tired of dealing with abuse reports or having their IP space blocked because of their own (infected) residential users sending out spam. The solution for them was to block the spam. The cheapest/easiest way to do this was to block TCP 25 between subs and the internet, thus starting a trend. If 587 becomes popular, spammers will move on and the same ISPs that blocked 25 will follow suit. Actually, it doesn't work that way because of what submission is designed to do. I just posted another email about it so I won't repeat it, but basically you should think of blocking port 25 as a list of who's authorized to send emails, not as a port we just killed for fun and we're waiting for the spammers next move.
A better solution would have been to prevent infection or remove infected machines from the network(strong abuse policies, monitoring, give out free antivirus software, etc). Unfortunately, several major players (ATT, for example) went down the road of limiting internet access. Now that they've had a taste, some of them feel they can block other ports or applications like p2p (Comcast), Netflix (usage based billing on Bell, ATT, others).
As an ISP, I liked seeing abuse complaints drop to near zero when we did this. We spent about a month fixing some people who don't use webmail (most regular customers don't use an MUA anymore) and had our share of third-party MTA's that refused to turn on submission (no idea why, these were usually business-class comp accounts so we moved them to a business pool and dropped their acls) but overall we probably had less than 100 calls from doing this and it made our lives easier. Now I know you said you wanted us to be preventative and to treat the problem, but that's just impractical. We got 5000 abuse emails a month for (at the time) ~20k customers. Were 1/4 of them spamming? No, but the ones that were spamming generated automated reports from everyone. None of them were ever legitimate spammers. They were all users who clicked on a funny puppy picture their mom sent, or some other thing that set their computer on fire and had it spitting out gobs of porno links to everyone it could find. So it wasn't a set of problem users, it was just a random sampling of everyone's not-so-PC-savvy relatives. So, lets say we wrote software to collate those reports and got it down to 30 legitimate people (if we're lucky). Do we block their IP's and wait for them to call in then send them to geek squad? Do we try to fix their infected PC over the phone? At this point, no matter what we do they're going to get sent to a tier 2 tech which means at least 2 phone calls and whatever revenue we might have gotten from them is gone for quite a while. We can have one guy tied up all day every day trying to process abuse issues or we can just shut down port 25 and the problem magically disappears. Is their laptop uninfected? No, but they can no longer infect any other customer in our network or anyone elses network, thus reducing global infections. We've made the world a better place and saved ourselves some money. Unfortunately, the first coffee shop they go to that doesn't block port 25 is going to be a new spam source but we can't save them all. It may be possible in the future we'll have a more convenient method to police PC's but the network access controls that exist right now aren't flexible enough to allow different networks to set different policies, so if it's a work laptop and they have a domain administrator then 802.1x might not be possible, and mandating they have firewall or anti-virus turned on (or a specific version/that it's updated, etc) might not be possible. Most customers rail against controls anyway. You don't want port 25 blocked so how would you feel if we mandated you install our ad-ware mcafee client and scanned your computer every 15 minutes? And when you think about it, if the big boys gave up and blocked port 25 and stopped offering free anti-virus and a backrub when you call in, how can we afford to compete with that?
Unfortunately, I don't see the trend reversing. I'm afraid that Internet freedoms are likely to continue to decline and an "Unlimited" Internet experience won't exist at the residential level in 5+ years.
I hope that you're exaggerating for effect, but you might be right. Small providers have trouble competing right now because of all the advantages the carriers have in the market. Some of the ways small providers can distinguish themselves is through support, or offering things a big player won't. So in some cases it's better to find a regional ISP and go with them because they may work with you, and they may be a little more lenient with some things. I don't think port 25 is worth making a stand on though, there are better battles to fight (rate limiting) that actually mean something to the customer experience.
--Blake
Robert
We provide service to about 1,000 public schools and libraries in the state of Maine. For those users, we block SMTP (port 25 only) traffic unless it goes through our smarthost for incoming mail, and our mail-relay for outgoing mail. Otherwise we would be constantly ending up on blacklists, as many of our users who attempt to run their own servers configure them to be open relays, or don't secure host systems and have them turn into botnets. To make it a little more desirable we do provide a web UI to manage mail domains, including letting them configure whether or not they want to filter spam and some controls to how sensitive that is (kind of like postini). Recently, we've been rolling out Linux-based CPE instead of routers; those provide them with a local firewall. We've designed the firewall to filter outgoing SMTP by default, but they can configure a list of IP addresses to bypass that. In this situation, they can run their mail server directly on their network without making use of smarthost or mail-relay, can manage exceptions, but still have a base-level of protection against spam bots by default. We have found that many of our users have come to prefer using our relay servers as when something isn't working we can provide them with logging information to help them track down the problem and they tend to spend less time responding to spam incidents. Whether or not this model could work commercially, I'm not sure... I think we end up doing a lot more hand-holding than the typical ISP given our audience. As for our mail servers, both smarhost and mail-relay hosts we have them point to actually point to several mail servers, and we do perform base level greylisting and subscribe to a few blacklists before mail is relayed or checked for spam and viruses. On Tue, Oct 25, 2011 at 12:29 AM, Dennis Burgess <dmburgess@linktechs.net> wrote:
I am curious about what network operators are doing with outbound SMTP traffic. In the past few weeks we have ran into over 10 providers, mostly local providers, which block outbound SMTP and require the users to go THOUGH their mail servers even though those servers are not responsible for the domains in question! I know other mail servers are blocking non-reversible mail, however, is this common? And more importantly, is this an acceptable practice?
Most of our smaller ISPs that we support; we allow any outbound SMTP connection, however we do watch residential users for 5+ outbound SMTP connections at the same time. But if the ISP has their own mail servers, and users wish to relay though them, we basically tell them to use their mail server that they contract with. What is the best practice?
----------------------------------------------------------- Dennis Burgess, Mikrotik Certified Trainer Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 <tel:314-735-0270> Website: http://www.linktechs.net <http://www.linktechs.net/> LIVE On-Line Mikrotik Training <http://www.onlinemikrotiktraining.com/> - Author of "Learn RouterOS" <http://routerosbook.com/>
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
participants (42)
-
-Hammer- -
Aftab Siddiqui -
Alex Harrowell -
Bjørn Mork -
Blake Hudson -
Brian Johnson -
Carlos Martinez-Cagnazzo -
Dave CROCKER -
David E. Smith -
Dennis Burgess -
Douglas Otis -
Graham Beneke -
Henry Yen -
J -
Jack Bates -
Jay Ashworth -
Jeff Kell -
Jeroen Massar -
Jeroen van Aart -
Joel jaeggli -
John van Oppen -
Keith Medcalf -
Leigh Porter -
Mark Andrews -
Mark Foster -
Matt McBride -
McCall, Gabriel -
Michael Thomas -
Mikael Abrahamsson -
Mike Jones -
Owen DeLong -
Pete Carah -
Randy Bush -
Ray Soucy -
Ricky Beam -
Robert Bonomi -
Robert Drake -
Scott Howard -
Tim -
up＠3.am -
Valdis.Kletnieks＠vt.edu -
William Herrin