Re: Outgoing SMTP Servers
On 26 October 2011 05:44, Owen DeLong o...@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
Re: the route is not in our bgprouter
On Tue, Oct 25, 2011 at 9:49 PM, Deric Kwokderic.kwok2...@gmail.com wrote: Our upstream provider said that destination network is blocking our ip. Now my question is how we can know it you can't really, if they do things right. (Aside from just not getting there) Have you tried contacting the destination network. I assume you have a customer that wants to talk to their customer? Its in both your interests to see why things aren't working. If this network is blocking us, the traceroute should reach out our bgp router to go further nodes before that network, right presumably, unless the destination is a direct peer. 2nd question is how they block us to not allow the route to advertise from our upstream to our bgp router. probably they just don't accept your route... why do you think your route isn't propogated beyond your border(s)? What is your prefix that you're announcing? Is it from a new range an potentially bogon filtered somehwere? What is the destination you're trying to get to? What do you see in BGP looking glasses for that IP. They could be doing something stupid/evil like putting your AS in their path. ls it possible? Thank you so much On Tue, Oct 25, 2011 at 9:35 AM, Patrick Sumby patrick.su...@sohonet.co.uk wrote: If your provider has a looking glass then that is a good start to see if they have the route in their routing tables. http://www.traceroute.org/ is a good start for searching for a looking glass on their website. Have you checked to see if you're actually recieving the route? You may be getting the route but not installing it into your routing table for some reason (eg invalid next hop or a router from another provider is being prefered). Do you have prefix lists inbound from your provider that could be blocking a route? show ip route X.X.X.X and show ip bgp route X.X.X.X will give different information. If you've covered the above and not found the answer then try talking to your provider. Regards Patrick On 25/10/2011 13:26, Deric Kwok wrote: Hi When we try to reach to outside ip, this route doesn't have in our bgp router How can we check whether it doesn't advertise from our upstream to us? Any web site and tools can help? Thank you
Re: Outgoing SMTP Servers
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 dmburg...@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 bj...@mork.no wrote: Owen DeLong o...@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=enu=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 =
Re: Outgoing SMTP Servers
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
Re: Outgoing SMTP Servers
On 25 Oct 2011, at 09:34, Tim tim...@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 __
Re: Colocation providers and ACL requests
On Tue, Oct 25, 2011 at 9:21 PM, Keegan Holley keegan.hol...@sungard.com wrote: I'm assuming colo means hosting, and the OP misspoke. Most colo providers don't provide active network for colo (as in power and rack only) customers. Yes, hosting. I did indeed misspeak.
XSServer / Taking down a spam friendly provider
Hello I run a few Wordpress sites here and there, but I'm amazed at the amount of spam that comes from xsserver.eu's clients. Their abuse department is non-responsive: they do not even have auto responders to emails and the offending IP addresses keep spamming weeks after my email. I have CC'd my abuse complaints to Hurricane Electric, with no luck either, so I'm stuck Before somebody screams the path of least resistance of just install Akismet or (insert spam plugin here), that type of thinking just makes spam even worse because we just keep large, possibly stale, databases of IP addresses that may or may not be active spammers and does not address the issue. Does anyone have any recommendations of where to go next because I'm just limited to doing a whois on the IP address, emailing the abuse contact and tracerouting. Examples of the offending IPs are: 109.230.216.225 109.230.220.34 109.230.217.166 109.230.220.95 A prime offender is hellomotow.net, who provides SEO services with automated spamming tools. hellomotow.net has spammed me in the past from IP addresses like this so I believe XSServer is becoming the new McColo / AlphaRed / ThePlanet (back in the day, their abuse dept is very responsive now) I'm not asking for you to do the footwork for me, unless you want, but just needed some advice from folks more knowledgeable than myself. -- --C The dumber people think you are, the more surprised they're going to be when you kill them. - Sir William Clayton
Re: Outgoing SMTP Servers
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 dmburg...@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/
Re: Colocation providers and ACL requests
2011/10/25 Jay Ashworth j...@baylink.com - Original Message - From: Keegan Holley keegan.hol...@sungard.com I'm assuming colo means hosting, and the OP misspoke. Most colo providers don't provide active network for colo (as in power and rack only) customers. Most? I'm sure there are exceptions to that rule. It's better than YMMV.
Re: Colocation providers and ACL requests
- Original Message - From: Keegan Holley keegan.hol...@sungard.com - Original Message - From: Keegan Holley keegan.hol...@sungard.com I'm assuming colo means hosting, and the OP misspoke. Most colo providers don't provide active network for colo (as in power and rack only) customers. Most? I'm sure there are exceptions to that rule. It's better than YMMV. Perhaps I look at a different category of colo provider, then, but I'm accustomed to seeing it be well up into double-digit percentage of the ones I've ever looked at. Hosting, to me, means provider's hardware, not just local blended bandwidth. Cheers, -- jr 'so many things are just me' a -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: Facebook insecure by design
On Oct 24, 2011 7:55 AM, Robert Bonomi bon...@mail.r-bonomi.com wrote: You can even download it all and erase yourself if you want out. Don't count on it. You may 'disappear' from public view, but that does not necessarily mean the data is truely 'gone'. Specific example -- if you request a USENET posting to be removed, all they do is make it 'invisible' to the world. It is _not_ removed from the databases, or from inernal access/use. That is a very good point, and one of the things that is being tested now that Buzz is going into archive mode. Users are given the option of backing up their posts on Buzz, and then deleting their Buzz content. Many like myself will just leave it there. It is a year+ of history, and what I posted publicly can stay public. It is supposed to remove all your Buzz content from the service and I believe it includes the content shared only with certain individuals. It does not completely erase it, because I believe email copies of the posts and comments that people had sent to their Gmail accounts will remain with those users. Deleting a product like your Picasa web albums is permanent as far as I know, but I will definitely ask some people on the Picasa team. Deleting your search history and other Dashboard items is supposed to be permanent, but as you pointed out, we are taking Google's word for it. --steve
Re: Facebook insecure by design
From: steve pirk [egrep] st...@pirk.com Date: Wed, 26 Oct 2011 09:24:04 -0700 Subject: Re: Facebook insecure by design On Oct 24, 2011 7:55 AM, Robert Bonomi bon...@mail.r-bonomi.com wrote: You can even download it all and erase yourself if you want out. Don't count on it. You may 'disappear' from public view, but that does not necessarily mean the data is truely 'gone'. Specific example -- if you request a USENET posting to be removed, all they do is make it 'invisible' to the world. It is _not_ removed from the databases, or from inernal access/use. That is a very good point, and one of the things that is being tested now that Buzz is going into archive mode. Users are given the option of backing up their posts on Buzz, and then deleting their Buzz content. Many like myself will just leave it there. It is a year+ of history, and what I posted publicly can stay public. It is supposed to remove all your Buzz content from the service and I believe it includes the content shared only with certain individuals. It does not completely erase it, because I believe email copies of the posts and comments that people had sent to their Gmail accounts will remain with those users. Deleting a product like your Picasa web albums is permanent as far as I know, but I will definitely ask some people on the Picasa team. Deleting your search history and other Dashboard items is supposed to be permanent, but as you pointed out, we are taking Google's word for it. I _don't_ know, but I *strongly* suspect that things like search history _are_ kept -- although 'detached' from any identification of the original person. That kind of information is simply 'too valuable' -- for pattern recognition, say -- to entirely discard. I also suspect it remains as part of lots of aggregate demographics, etc. I wouldn't be surrised if they kept statistal data on 'who deletes what'. grin
Re: XSServer / Taking down a spam friendly provider
On Wed, Oct 26, 2011 at 10:12:33AM -0400, Chris wrote: Before somebody screams the path of least resistance of just install Akismet or (insert spam plugin here), that type of thinking just makes spam even worse because we just keep large, possibly stale, databases of IP addresses that may or may not be active spammers and does not address the issue. Does anyone have any recommendations Examples of the offending IPs are: 109.230.216.225 109.230.220.34 109.230.217.166 109.230.220.95 All four addresses are in the Spamhaus sbl-xbl list. It would take ~10 lines of python in your cgi program to work this out. Nicolai
Re: XSServer / Taking down a spam friendly provider
For folks who do not understand, I'm trying to McColo XSServer so their lack of response in regards to abuse is gone rather than the suggestions of scripting (guess you didn't read the full text of the email) or you pushing a product on me because you work for the ISP that the product is hosted on. Everybody remembers McColo going down and being dropped from uplinks in 2008 then all the spam disappeared, right? On Wed, Oct 26, 2011 at 10:12 AM, Chris cal...@gmail.com wrote: Hello I run a few Wordpress sites here and there, but I'm amazed at the amount of spam that comes from xsserver.eu's clients. Their abuse department is non-responsive: they do not even have auto responders to emails and the offending IP addresses keep spamming weeks after my email. I have CC'd my abuse complaints to Hurricane Electric, with no luck either, so I'm stuck Before somebody screams the path of least resistance of just install Akismet or (insert spam plugin here), that type of thinking just makes spam even worse because we just keep large, possibly stale, databases of IP addresses that may or may not be active spammers and does not address the issue. Does anyone have any recommendations of where to go next because I'm just limited to doing a whois on the IP address, emailing the abuse contact and tracerouting. Examples of the offending IPs are: 109.230.216.225 109.230.220.34 109.230.217.166 109.230.220.95 A prime offender is hellomotow.net, who provides SEO services with automated spamming tools. hellomotow.net has spammed me in the past from IP addresses like this so I believe XSServer is becoming the new McColo / AlphaRed / ThePlanet (back in the day, their abuse dept is very responsive now) I'm not asking for you to do the footwork for me, unless you want, but just needed some advice from folks more knowledgeable than myself. -- --C The dumber people think you are, the more surprised they're going to be when you kill them. - Sir William Clayton
Re: Outgoing SMTP Servers
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
RE: XSServer / Taking down a spam friendly provider
On Wed, Oct 26, 2011 at 10:12:33AM -0400, Chris wrote: Does anyone have any recommendations of where to go next because I'm just limited to doing a whois on the IP address, emailing the abuse contact and tracerouting. Chris, Can't help much - but can say we find ourselves in a similar boat. As a rule of thumb, we systematically block, log, and report *every* spam, virus brute force etc attempt we receive against any of our devices. In the past three years, only one company has ever responded to an abuse request (CampaignMonitor to name honour them), though there are definitely some other good guys out there (a large number of them on this list)! [We don't apply the above logic for spam sent to email destinations, for obvious reasons] G
Re: Outgoing SMTP Servers
On Tue, 25 Oct 2011 15:52:46 -0400, Alex Harrowell a.harrow...@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
RE: Outgoing SMTP Servers
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:o...@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
[NANOG-announce] NANOG54 (San Diego, Feb 5-8 2012): Call for Presentations and Registration Now Open!
All, After a fantastic meeting in Philadelphia we're getting ready to provide you with another content rich meeting at the Westin Gaslamp Quarter in San Diego. Registration is now open for the meeting, and you can take advantage of the Early Bird Registration Discount and save $75 by registering before December 5th, 2011. Please see http://www.nanog.org/meetings/nanog54/nanog54_registration.html for more details. --- The NANOG54 CFP is available at: http://www.nanog.org/meetings/nanog54/callforpresentations.html Please keep these key dates in mind: Presentation Abstracts and Draft Slides Due: December 5th, 2011 Final Slides Due: December 19th, 2011 The NANOG Program Committee intends on having a draft program published by December 20th, 2011 and the final agenda published by January 16, 2012. --- Thanks, -Dave Temkin (for the NANOG Program Committee) ___ NANOG-announce mailing list nanog-annou...@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce
Re: Outgoing SMTP Servers
In message op.v3y8xvo6tfh...@rbeam.xactional.com, Ricky Beam writes: On Tue, 25 Oct 2011 15:52:46 -0400, Alex Harrowell a.harrow...@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: ma...@isc.org
Re: XSServer / Taking down a spam friendly provider
On Wed, 26 Oct 2011 13:47:03 -0400 Chris cal...@gmail.com wrote: For folks who do not understand, I'm trying to McColo XSServer so their lack of response in regards to abuse is gone rather than the suggestions of scripting (guess you didn't read the full text of the email) or you pushing a product on me because you work for the ISP that the product is hosted on. Everybody remembers McColo going down and being dropped from uplinks in 2008 then all the spam disappeared, right? McColo and Atrivo were disconnected for much larger sins than spamming someone's wordpress blog. William
Re: Advice on BGP traffic engineering for classified traffic
Jack Bates wrote: I'm curious if anyone has a pointer on traffic manipulation for classified traffic. Basics, I have a really cheap transit connection that some customers are paying reduced rates to only use that connection (and not my other transits). Though I've considered support for cases where NSP peering disputes break out. While I can advertise their networks out the correct transit for return traffic, I still have to figure out how to handle egress traffic. I'm guessing the crux of it is policy routing based on source address, but I'm interested in ways to engineer it to easy management and scalability. I've considered the possibility of an l3vpn to interconnect customers that are not requiring full routes, and possibly some type of vpls tunnel terminated at the necessary router for customers who need full routes. Thoughts, pointers, suggestions? One simple way to do this is with two routers each with a different table. One for your expensive transit and one for your cheap transit. Each customer's vlan is on both routers with vrrp preference set to the desired router for non-bgp customers. expensive transit customers have the ability to failover to the cheap router. you may or not want to allow the reverse to occur. - Kevin
CACHEbox question
Anyone using a CACHEbox? I need to know if they can operate as a layer 2 bridge/proxy. Sent from my iPhone
Re: Outgoing SMTP Servers
On 26 Oct 2011, at 23:13, Mark Andrews ma...@isc.org wrote: In message op.v3y8xvo6tfh...@rbeam.xactional.com, Ricky Beam writes: On Tue, 25 Oct 2011 15:52:46 -0400, Alex Harrowell a.harrow...@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 __
RE: Outgoing SMTP Servers
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.
Re: Outgoing SMTP Servers
On 27/10/11 11:11, Mark Andrews wrote: In message op.v3y8xvo6tfh...@rbeam.xactional.com, Ricky Beam writes: On Tue, 25 Oct 2011 15:52:46 -0400, Alex Harrowell a.harrow...@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.
Re: XSServer / Taking down a spam friendly provider
McColo and Atrivo were disconnected for much larger sins than spamming someone's wordpress blog. Many of you do not understand the scope of just spamming a Wordpress blog. This is a huge business. Shady SEO companies are charging individuals at least $250 per month to use their spam tools of choice to spam forums and Wordpress blogs. I got one of the major players on the run right now because he cannot seem to keep his business page hosted with a company longer than a few weeks and I keep playing whack-a-mole with him. Guess what? Innocent people's websites are being deranked on Google for hiring these guys with their shady backlink services and their money is being taken. Yes I know they got what they deserved, but it's so obvious with these backlink guys using cheap virtual private servers for a month, getting shutdown and getting a new IP address that something needs to be done. XSServer could have simply amused me with a default auto reply to make it look like they are doing something. Will your host allow you to block IP ranges? Not the solution I was looking for because blocking IP ranges and using scripts / services / etc like Akismet or others is simply ignoring the problem, not solving it. For folks who say hosting companies are not helpful: Linode, Amazon, BurstNET, Ubiquity Servers and others are extremely responsive to abuse complaints. -- --C The dumber people think you are, the more surprised they're going to be when you kill them. - Sir William Clayton
Re: Outgoing SMTP Servers
In message 4ea8a021.9000...@blakjak.net, Mark Foster writes: On 27/10/11 11:11, Mark Andrews wrote: In message op.v3y8xvo6tfh...@rbeam.xactional.com, Ricky Beam writes: On Tue, 25 Oct 2011 15:52:46 -0400, Alex Harrowell a.harrow...@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: ma...@isc.org
Re: Outgoing SMTP Servers
- Original Message - From: Mark Andrews ma...@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 j...@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
Re: Outgoing SMTP Servers
On Tue, Oct 25, 2011 at 2:51 AM, Aftab Siddiqui aftab.siddi...@gmail.comwrote: 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.
Re: Outgoing SMTP Servers
On 10/26/2011 10:57 PM, Scott Howard wrote: On Tue, Oct 25, 2011 at 2:51 AM, Aftab Siddiqui aftab.siddi...@gmail.comwrote: 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
Re: Outgoing SMTP Servers
On Tue, Oct 25, 2011 at 2:49 AM, Owen DeLong o...@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.
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 o...@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
Re: XSServer / Taking down a spam friendly provider
On Wed, 26 Oct 2011 20:22:53 -0400 Chris cal...@gmail.com wrote: McColo and Atrivo were disconnected for much larger sins than spamming someone's wordpress blog. Many of you do not understand the scope of just spamming a Wordpress blog. I do understand the scope of shady SEO companies. This is a huge business. Shady SEO companies are charging individuals at least $250 per month to use their spam tools of choice to spam forums and Wordpress blogs. I got one of the major players on the run right now because he cannot seem to keep his business page hosted with a company longer than a few weeks and I keep playing whack-a-mole with him. McColo and Atrivo were not terminated because of spam. If you believe they are, then you are simply misinformed. Atrivo and McColo were terminated over their network being used extensively for botnet control centers. Really! Not spam! Guess what? Innocent people's websites are being deranked on Google for hiring these guys with their shady backlink services and their money is being taken. Bummer. Indeed, it sucks to be them. Newsflash: only morons hire SEO companies. Perhaps Google is just working on increasing relevance quality by penalizing them for being morons. I would say it is a brilliant strategy, myself. Yes I know they got what they deserved, but it's so obvious with these backlink guys using cheap virtual private servers for a month, getting shutdown and getting a new IP address that something needs to be done. Ok, and when they go to another budget VPS provider other than XSServer? I am just wondering if you have a strategy for that scenario. Will you come and whine on NANOG about that provider too? XSServer could have simply amused me with a default auto reply to make it look like they are doing something. Wow, thanks for the pro tip. You're telling me that if I just replace my ab...@systeminplace.net contact with an autoresponder that most people will just assume that we are doing something and I can go and spend all my time on hookers and booze instead of terminating spammers? Shit. Why didn't anyone tell me earlier? Will your host allow you to block IP ranges? Not the solution I was looking for because blocking IP ranges and using scripts / services / etc like Akismet or others is simply ignoring the problem, not solving it. For folks who say hosting companies are not helpful: Linode, Amazon, BurstNET, Ubiquity Servers and others are extremely responsive to abuse complaints. William
