RE: ingress SMTP
How do you alert mail server operators who are smarthosting their e-mail through you that their outbound messages contain spam? Frank -Original Message- From: Matthew Moyle-Croft [mailto:[EMAIL PROTECTED] Sent: Saturday, September 13, 2008 12:41 AM To: Bill Stewart Cc: nanog@nanog.org Subject: Re: ingress SMTP Hi Bill, Bill Stewart wrote: In some sense, anything positive you an accomplish by blocking Port 25 you can also accomplish by leaving the port open and advertising the IP address on one of the dynamic / home broadband / etc. block lists, which leaves recipients free to whitelist or blacklist your users. Except that this tends to lead to a worse situation for people like yourself who wish to run a mailserver - because ultimately you'll have to resort to using an ISP's forwarder anyway because there will be more spam from the IP ranges you're in leaving to the wide world, thus a worse reputation, and so more blocking. ie. by blocking outbound SMTP by default and getting customers to use our mail cluster their email is more likely to arrive and not be dropped as coming from a potential spam source. I've toned down my vehemence about the blocking issue a bit - there's enough zombieware out there that I don't object strongly to an ISP that has it blocked by default but makes it easy for humans to enable. That's what we do - by default most customers have a small ACL applied which protects them from traffic from various windows ports, ensures SMTP goes via our mail cluster etc. Having customers send mail out via us is actually better because we do spam checking and can alert customers to their machines being compromised etc (or at least customers can look at their status themselves). But, customers can easily turn the filtering off via the portal we have. We have no issues with customers running servers - most people don't, and those who do value the ability to do so. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: [EMAIL PROTECTED] Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: ingress SMTP
On Sat, Sep 13, 2008 at 11:38 PM, Frank Bulk [EMAIL PROTECTED] wrote: How do you alert mail server operators who are smarthosting their e-mail through you that their outbound messages contain spam? Frank If those are actual mailservers smarthosting and getting MX from you then you doubtless have quite a lot of reporting already set up. Have you seen what Messagelabs, MXLogic etc do? There's also feedback loops, ARF formatted, where users on those mailservers can report inbound spam to the filtering vendor. .. or was that a rhetorical question and am I missing something here? -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: ingress SMTP
How do you alert mail server operators who are smarthosting their e-mail through you that their outbound messages contain spam? You don't let them falsify their envelope or headers to contain fields utterly unrelated to your own infrastructure, for starters. They try it, their mail bounces. It's a very rare piece of spam that actually comes from who it says it comes from anymore. Do that before thinking about rate-limiting or any other fanciness, and you've likely licked 90% of the problem right there. A smarthost with a strong sense of self backed up by port-25 rules is exactly what I'm talking about, and if certain large providers ever *read* their abuse boxes they'd find the same advice from me in more than one instance followed by a clear example of why. _H*
Re: ingress SMTP
*Hobbit* wrote: How do you alert mail server operators who are smarthosting their e-mail through you that their outbound messages contain spam? You don't let them falsify their envelope or headers to contain fields utterly unrelated to your own infrastructure, for starters. They try it, their mail bounces. It's a very rare piece of spam that actually comes from who it says it comes from anymore. Are you suggesting that only ISP domains should be allowed through? (eg. [EMAIL PROTECTED]) If you're forcing people to use your mail servers as a smart host then you wouldn't be very popular ... MMC
RE: ingress SMTP
Apologies for not being more clear, because I see the responses going in tangents I hadn't expected. Most anti-spam products drop the connection or issue some kind of rejection message during the SMTP exchange. If the connection is dropped, the subscriber's MTA/MUA will likely try and try again until it reaches expiration time. For MS Exchange I think that's two or three days. For Outlook Express, that message just sits in the Outbox. If a rejection message was issued, hopefully the sender can interpret what the MUA is saying, or the MTA sends back an undeliverable. So, for service providers who require their subscribers to smarthost messages through their server, how are they letting the subscribers know in some kind of active way? Frank -Original Message- From: Suresh Ramasubramanian [mailto:[EMAIL PROTECTED] Sent: Saturday, September 13, 2008 8:39 PM To: Frank Bulk Cc: Matthew Moyle-Croft; nanog@nanog.org Subject: Re: ingress SMTP On Sat, Sep 13, 2008 at 11:38 PM, Frank Bulk [EMAIL PROTECTED] wrote: How do you alert mail server operators who are smarthosting their e-mail through you that their outbound messages contain spam? Frank If those are actual mailservers smarthosting and getting MX from you then you doubtless have quite a lot of reporting already set up. Have you seen what Messagelabs, MXLogic etc do? There's also feedback loops, ARF formatted, where users on those mailservers can report inbound spam to the filtering vendor. .. or was that a rhetorical question and am I missing something here? -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: ingress SMTP
Hi, Hobbit - we met back in the late 80s / early 90s at various New Jersey things such as Trenton Computer Fair, but you probably don't remember me; Tigger says hi as well... Be Liberal in what you accept, be conservative in what you send, and be really really clear in your error messages, except occasionally if you're lying to spammers. IMHO, selling somebody connectivity that blocks various ports isn't selling them Internet Service, it's selling them Walled Garden Couch-Potato Service. For many people that's ok, and if they're sending traffic on Port 25 it's only because some zombieware has taken over their PC, as opposed to because they're actually trying to send it. But the old PC on my desk upstairs has about 2500 times as much CPU and 500 times as much disk space as the Vaxen that I used to run email for a department of 30 people, and the network connection is about 300 times as fast, and there's no particular reason that it shouldn't have full end-to-end Internet presence like anybody's commercial mail server. That's different from 15 years ago when I only had dialup at home, because dialup wasn't really a full-time process, and sending mail was sufficiently unreliable that it made sense to run a dumb client at home that talked to a full-time smart host that knew how to queue messages and retry on failure. Blocking port 25 has become popular, not only with walled-garden connectivity services that are really scared of their customers running their own servers (e.g. most cable modem companies), but also with other ISPs that don't want to deal with the problems of having customers who are spamming (whether deliberate or zombified.) So anybody buying something lower-priced than a T1 typically needs to have a mail client or mail transfer agent that can use other ports, unless they want to trust their ISP's mail service or use webmail. And also obviously if you're running an outbound mail relay smarthost for your clients you need to accept mail from known people on the various authenticated ports in case they're stuck behind a randomly misbehaving ISP, and you should also support encrypted SMTP in general. In some sense, anything positive you an accomplish by blocking Port 25 you can also accomplish by leaving the port open and advertising the IP address on one of the dynamic / home broadband / etc. block lists, which leaves recipients free to whitelist or blacklist your users. And you can certainly provide better service to your customers by redirecting Port 25 connections to an SMTP server that returns 550 We block Port 25 - see www.example.net/faq/port25blocking or some similarly useful message as opposed to just dropping the packets. I've toned down my vehemence about the blocking issue a bit - there's enough zombieware out there that I don't object strongly to an ISP that has it blocked by default but makes it easy for humans to enable. -- Thanks; Bill Stewart Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: ingress SMTP
Blocking port 25 has become popular, not only with walled-garden connectivity services that are really scared of their customers running their own servers (e.g. most cable modem companies), but also with other ISPs that don't want to deal with the problems of having customers who are spamming (whether deliberate or zombified.) So anybody buying something lower-priced than a T1 typically needs to have a mail client or mail transfer agent that can use other ports, unless they want to trust their ISP's mail service or use webmail. What proportion of an ISP's customers genuinely need the ability to talk to external hosts on 25/tcp? I mean really? We're talking about home users who can use their home ISP SMTP service and it'll meet their needs. Agree that there should be a mechanism to opt out, but smart organisations will offer alternative, authenticated services to address any requirement for direct SMTP (except perhaps for situations where you actually intend to run a mail server at home.) In some sense, anything positive you an accomplish by blocking Port 25 you can also accomplish by leaving the port open and advertising the IP address on one of the dynamic / home broadband / etc. block lists, which leaves recipients free to whitelist or blacklist your users. And you can certainly provide better service to your customers by redirecting Port 25 connections to an SMTP server that returns 550 We block Port 25 - see www.example.net/faq/port25blocking or some similarly useful message as opposed to just dropping the packets. I concur with the latter, but then again, if it's well publicised and clear from the get-go that external pot 25 is not a service offered, it should be no big deal. I do disagree that advertising the IP on blocklists serves the same purpose, because it pushes responsibility to a third party (ala ISP is waving its hands in the air and saying 'it's not my problem, we're just a means of access to the cloud', and suddenly third party outfits get a whole bunch more clout than is necessary - and noise levels on the internet go up and/or junk volumes go up. (Wonder how much spam the port-25-blockers actually stop?) Would seem easier and a whole bunch more flexible for ISPs to manage their own turf, as it were, third party blocklists are a little on the ugly side. (False Positives are very hard to get dealt with, from experience.) I've toned down my vehemence about the blocking issue a bit - there's enough zombieware out there that I don't object strongly to an ISP that has it blocked by default but makes it easy for humans to enable. Fair enough. I think there's probably agreement on this point, but I would also make the point that the only legitimate reason to enable 25/tcp outbound to external hosts should be to run a mail server. SMTP-Auth for private use, for example, shouldn't be on 25. Mark.
Re: ingress SMTP
Hi Bill, Bill Stewart wrote: In some sense, anything positive you an accomplish by blocking Port 25 you can also accomplish by leaving the port open and advertising the IP address on one of the dynamic / home broadband / etc. block lists, which leaves recipients free to whitelist or blacklist your users. Except that this tends to lead to a worse situation for people like yourself who wish to run a mailserver - because ultimately you'll have to resort to using an ISP's forwarder anyway because there will be more spam from the IP ranges you're in leaving to the wide world, thus a worse reputation, and so more blocking. ie. by blocking outbound SMTP by default and getting customers to use our mail cluster their email is more likely to arrive and not be dropped as coming from a potential spam source. I've toned down my vehemence about the blocking issue a bit - there's enough zombieware out there that I don't object strongly to an ISP that has it blocked by default but makes it easy for humans to enable. That's what we do - by default most customers have a small ACL applied which protects them from traffic from various windows ports, ensures SMTP goes via our mail cluster etc. Having customers send mail out via us is actually better because we do spam checking and can alert customers to their machines being compromised etc (or at least customers can look at their status themselves). But, customers can easily turn the filtering off via the portal we have. We have no issues with customers running servers - most people don't, and those who do value the ability to do so. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: [EMAIL PROTECTED] Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: ingress SMTP
Joel Jaeggli [EMAIL PROTECTED] writes: Does anyone bother to run an MSA on 587 and *not* require authentication? All my normal relay or lack thereof and delivery rules are in place on my 587 port. Of course muas's and mtas will also do tls as well as authentication over port 25 where available. I don't sea any reason to preclude a host that would be allowed to relay via 25 to do so via 587... Congruent policy makes administration simpler. Counterpoint here: I do not allow relaying (only local delivery and maybe MX but I think I'm not doing secondary MX for anyone anymore) over port 25 and I do not allow authentication over port 25 either. Likewise, I do not allow unauthenticated local delivery on port 587, demand STARTTLS on port 587, and generally you have to auth to do anything. The extra effort required to set this up (exim recipes available) pays dividends by ensuring that people have their MUAs configured properly at home - otherwise they won't work at all - and helps avoid whiney long distance phone calls asking for help from some user who's off in Bonaire or something. -r
Re: ingress SMTP
Mark Foster [EMAIL PROTECTED] writes: On Fri, 5 Sep 2008, Mikael Abrahamsson wrote: We don't allow most of our residential customer base to speak SMTP TCP/25 to anywhere at all (and we have millions of them). Wish more ISPs would do the same. Probably fair enough, if you as an ISP can get away with enforcing this sort of policy then so much the better. However relaying through your own ISPs 25/tcp should surely then make it relatively easy for noise to be tracked down and nailed at the source - by ISPs? (Do abuse@ desks investigate spam these days?) As others have noted, intercepting 25 breaks SPF. It also gratuitously creates weird anomalous behaviour that is much harder for a reasonably clued person to debug than a simple blocked port, so it's more likely to buy you a help desk call (with a subtle problem that your level 1 folks probably can't get sorted anyway). Perhaps you aren't in a position where you have to care about the balance sheets, but keeping the load off the help desk is a wonderful thing to do in terms of cost control. Doing traffic analysis looking for noise is just extra work for your abuse people - when I was setting policy for this sort of thing we put a cap at 1000 discrete destinations per day per authenticated user (with a daily report of who'd busted it, and most days the report was 0) and only once ran into a problem where someone was legitimately trying to send mail to a bajillion people and called the help desk. -r
Re: ingress SMTP
I am completely convinced that abuse@ in most big providers is a black hole with an autoresponder hung off it, and nothing ever gets done with complaints. NO HUMAN ever sees them, and even if they did, most of the humans at these outfits wouldn't recognize a Received: header if it bit them in the ass. I invite and welcome anyone from the big boyz I named in the original question -- verizon, comcast, roadrunner, charter, bellsouth/SBC, and now Google -- *especially* Gmail, given that counterproductive privacy policy we noted -- to inform me otherwise. _H*
Re: ingress SMTP
Jay R. Ashworth wrote: On Wed, Sep 03, 2008 at 12:58:53PM -0400, Nicholas Suan wrote: On Sep 3, 2008, at 12:49 PM, Jay R. Ashworth wrote: You're forgetting that 587 *is authenticated, always*. I'm not sure how that makes much of a difference since the usual spam vector is malware that has (almost) complete control of the machine in the first place. Well, that depends on MUA design, of course, but it's just been pointed out to me that the RFC says MAY, not MUST. Oops. Does anyone bother to run an MSA on 587 and *not* require authentication? All my normal relay or lack thereof and delivery rules are in place on my 587 port. Of course muas's and mtas will also do tls as well as authentication over port 25 where available. I don't sea any reason to preclude a host that would be allowed to relay via 25 to do so via 587... Congruent policy makes administration simpler. Cheers, -- jra
Re: ingress SMTP
On Sep 3, 2008, at 6:52 PM, Tim Sanderson wrote: Anybody not wanting to use their ISP email would notice it. I see filtering 25 FROM the customer as something that is not likely to happen because of this. When a customer buys bandwidth, they want to be able to use it for whatever they choose. This would be just one more restriction giving competitive advantage to any ISP not doing the filtering. In my country, some ISPs block outbound SMTP for home users and they require those users to use the ISPs SMTP server for outgoing which happen to do antivirus and antispam filtering. They will unblock port 25 if you provide good and rational explanation why you need it open and that you understand that in case of problems you will be held responsible. Eugen.
Re: ingress SMTP
Eugeniu Patrascu wrote: On Sep 3, 2008, at 8:08 PM, Winders, Timothy A wrote: Yes, setting up a 587 submit server internally would be best, but man power is at a premium and it hasn't happened. I don't know what SMTP server you're using, but on Postfix you just need to uncomment one line in master.cf, do a reload and that's it. it takes less than a minute to do it on server. YMMV. Would that it were so easy :) You also have the more daunting task of hooking up your auth/aaa infrastructure with your MTA's, and all of the care and feeding that entails. Mike
Re: ingress SMTP
- Original Message - From: Michael Thomas [EMAIL PROTECTED] Date: Monday, September 8, 2008 7:31 am Subject: Re: ingress SMTP Would that it were so easy :) You also have the more daunting task of hooking up your auth/aaa infrastructure with your MTA's, and all of the care and feeding that entails. As a matter of interest, it took but a couple of person hours to sort this out at my last place of work, the largest time chunk in equation was the compiling of TLS and the various SASL modules into Postfix. The second from largest chunk of time was to get the script to get the information required from the various other back end mail servers on campus, including, but not limited to, Lotus Notes, M$ Exchange, and Sun/iPlanet messaging server and it's LDAP server. The only down side to the system was password changed took up to 15 minutes to get to the mail systems as there was no direct connection between the external gateways and the internal auth systems. Of course the above doesn't take into account the several weeks of political badgering and grandstanding that we endured to get the faculties to actually accept that that was the way it was going to be. They couldn't stand that there would only be incoming and outgoing mail via the central gateway. Such is life at Universities. Regards, M
RE: SMTP rate-limits [Was: Re: ingress SMTP]
Can anyone comment authoritatively on the percentage of spam that's from a leaky faucet compared to fire hose? The stuff I see in my customer base are all fire hoses at the rate of 2.5, sometimes 5 message connection attempts per second. (I bet an academic could study the rate of spam emissions from a certain IP to identify their upstream bandwidth). Frank -Original Message- From: Michael Thomas [mailto:[EMAIL PROTECTED] Sent: Friday, September 05, 2008 9:46 AM To: Paul Ferguson Cc: nanog@nanog.org Subject: Re: SMTP rate-limits [Was: Re: ingress SMTP] snip I thought that these bot nets were so massive that it is pretty easy for them to fly under the radar for quotas, rate limiting, etc. Not that all bot nets are created equal, and there aren't local hot spots for whatever reason, but putting on the brakes in a way that users wouldn't feel pain is simply not going to make any appreciable difference in the overall mal-rate. No? Mike
Re: ingress SMTP
On Friday 05 September 2008 00:33:54 Mark Foster wrote: *rest snipped* Is the above described limitation a common occurrance in the world-at-large? If the ISP blocks port 25, then the ISP is taking responsibility for delivering all email sent by a user, and they have to start applying rate limits. Otherwise if they send all email from their users, all they've done is take the spam, and mix it in with the legitimate email, making spam filtering harder. Locally one of the big ISP insists you register all sender addresses with them, so all the spam from them has legitimate sender credentials. The problem is that by blocking port 25, you are basically then switching users to arbitrary per ISP rules for how to send email. This is probably good for ISPs (provides some sort of lock-in) but bad for their users. Whilst the antispam folk think it is a godsend because their block lists are smaller, it is relatively easy to block spewing IP addresses, and hard to filter when good and bad email is combined. Which is why they hate Google hiding the source IP address. This will continue until the real issue is addressed, which is the security of end user systems.
Re: ingress SMTP
On Fri, 5 Sep 2008, Simon Waters wrote: If the ISP blocks port 25, then the ISP is taking responsibility for delivering all email sent by a user, and they have to start applying rate limits. MUAs should stop sending email via 25 and use 587 or equivalent instead. There is little actual reason why someone should be able to send TCP/25 SMTP email from a residential connection when most software support authenticated TCP/587 submits. We don't allow most of our residential customer base to speak SMTP TCP/25 to anywhere at all (and we have millions of them). Wish more ISPs would do the same. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
SMTP rate-limits [Was: Re: ingress SMTP]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Simon Waters [EMAIL PROTECTED] wrote: If the ISP blocks port 25, then the ISP is taking responsibility for delivering all email sent by a user, and they have to start applying rate limits. Otherwise if they send all email from their users, all they've done is take the spam, and mix it in with the legitimate email, making spam filtering harder. Okay, I can understand why an ISP might want to apply SMTP rate-limits, but to clarify, I'm assuming you meant that ISPs (if they do block tcp/25 outbound to anything other than their own MTAs) need to watch for excessive SMTP utilization, which might indicate a spammer-client (?). ...as opposed to arbitrary SMTP rate-limits. Yes? - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIwO90q1pz9mNUZTMRAneaAJwMgmIz99bPUYJ2HgUD6Zs1MOFXgQCgmsPY eUtV2bBKymWfxNwNOgWfp5w= =bdk+ -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: ingress SMTP
On Fri, 5 Sep 2008, Mikael Abrahamsson wrote: On Fri, 5 Sep 2008, Simon Waters wrote: If the ISP blocks port 25, then the ISP is taking responsibility for delivering all email sent by a user, and they have to start applying rate limits. MUAs should stop sending email via 25 and use 587 or equivalent instead. There is little actual reason why someone should be able to send TCP/25 SMTP email from a residential connection when most software support authenticated TCP/587 submits. We don't allow most of our residential customer base to speak SMTP TCP/25 to anywhere at all (and we have millions of them). Wish more ISPs would do the same. Probably fair enough, if you as an ISP can get away with enforcing this sort of policy then so much the better. However relaying through your own ISPs 25/tcp should surely then make it relatively easy for noise to be tracked down and nailed at the source - by ISPs? (Do abuse@ desks investigate spam these days?)
Re: SMTP rate-limits [Was: Re: ingress SMTP]
On Fri, 5 Sep 2008, Michael Thomas wrote: I thought that these bot nets were so massive that it is pretty easy for them to fly under the radar for quotas, rate limiting, etc. Not that all bot nets are created equal, and there aren't local hot spots for whatever reason, but putting on the brakes in a way that users wouldn't feel pain is simply not going to make any appreciable difference in the overall mal-rate. Right. In practice the rate of delivery failures is a more useful indication of spam than the overall email rate. Tony. -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ IRISH SEA: NORTHEASTERLY BACKING NORTHERLY 6 TO GALE 8, BUT CYCLONIC 5 IN SOUTH AT FIRST. MODERATE BECOMING ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
Re: ingress SMTP
On Fri, Sep 05, 2008 at 10:35:15AM +0200, Mikael Abrahamsson wrote: On Fri, 5 Sep 2008, Simon Waters wrote: If the ISP blocks port 25, then the ISP is taking responsibility for delivering all email sent by a user, and they have to start applying rate limits. MUAs should stop sending email via 25 and use 587 or equivalent instead. There is little actual reason why someone should be able to send TCP/25 SMTP email from a residential connection when most software support authenticated TCP/587 submits. Just FYI- the ISP has the same 220 email address limit even when I send thru port 587, authenticated. (its comcast) We don't allow most of our residential customer base to speak SMTP TCP/25 to anywhere at all (and we have millions of them). Wish more ISPs would do the same. -- Mikael Abrahamssonemail: [EMAIL PROTECTED] --
Re: ingress SMTP
re: intercepting port 25 calls and routing them to the ISP's own SMTP server. Consider an employee of chocolate.com working from home. he connects to Chocolate.com's SMTP server to send mail, but his ISP intercepts the connection and routes the email via its own. The email will then be sent by the ISP's SMTP server. In a context where SPF has been implemented, it means that the email will have been sent by an SMTP server that has not been authorized to send emails from chocolate.com and thus rejected by the recipient, and it is not clear how the rejection message would be handled. Also, the ISP might not only intercept the call, but then reject the email because it doesn't have a from from the ISP's domain. Secondly, and more importantly. If you are dealing with mass market ISPs who have clear no servers policies, then no customer would have legitimate need to run an SMTP server from home. However, there are smaller ISPs who do cater to SOHO /small businesses and those would have legitimate needs to run their own SMTP servers, and if the small ISP ends up using last mile from a large ISP, that large ISP would be negatively impacting the smaller ISP's customers. One option is to block port 25, but allow unblocking on an individual basis to those who have fixed IPs or make a good justification to their ISP that they need the port unblocked. In terms of mass-market people using email services from the outside of their ISP (hotmail, yahoo, gmail), then I guess port 587 would be the required way to get it done).
Re: ingress SMTP
On Wed, 3 Sep 2008, Jay R. Ashworth wrote: Well, that depends on MUA design, of course, but it's just been pointed out to me that the RFC says MAY, not MUST. Note that there are TWO relevant RFCs: RFC 4409 and RFC 5068. The latter says: 3.1. Best Practices for Submission Operation Submission Authentication: MSAs MUST perform authentication on the identity asserted during all mail transactions on the SUBMISSION port, even for a message having a RCPT TO address that would not cause the message to be relayed outside of the local administrative domain. Tony. -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ FISHER GERMAN BIGHT: SOUTHWESTERLY 5 TO 7, OCCASIONALLY GALE 8 IN GERMAN BIGHT, DECREASING 4 AT TIMES. ROUGH OR VERY ROUGH, BECOMING MODERATE LATER. SQUALLY SHOWERS. MODERATE OR GOOD.
Re: ingress SMTP
On Thu, 4 Sep 2008, Jean-François Mezei wrote: Consider an employee of chocolate.com working from home. he connects to Chocolate.com's SMTP server to send mail, but his ISP intercepts the connection and routes the email via its own. The email will then be sent by the ISP's SMTP server. A user that has this problem has failed to choose the right port number and set up SMTP authentication and TLS properly. Tony. -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ ROCKALL MALIN: MAINLY NORTHERLY 4 OR 5 INCREASING 5 TO 7, PERHAPS GALE 8 LATER IN ROCKALL. MODERATE OR ROUGH. SHOWERS. GOOD.
Re: ingress SMTP
On Wed, 3 Sep 2008, Keith Medcalf wrote: Why would the requirements for authentication be different depending on the port used to connect to the MTA? It's easier to configure the MTA if you make a distinction between server-to-server traffic and client-to-server traffic. In fact my systems distinguish three classes of traffic: MX, message submission, and smarthost. The MX service has lots of anti-spam features. You want to separate it from the others so that techniques like teergrubing don't make message submission painfully slow. You can also avoid interoperability problems with server-to-server TLS. You can limit the number of connections used by the MX service to that when it is being hammered by spammers, you can reserve some capacity so that message submission and outgoing relay still work. Having a message submission service that always requires TLS and authentication makes it easier for users to check their configuration. A mistake such as not turning on AUTH can be hidden when they test on their home network, only to be discovered later when they are roaming far from tech support. Separating your smarthost (outgoing relay service) from your MX can avoid some strange problems. Back in the dim and distant past before remote AUTHed message submission and before separate MX and smarthost, our roaming users who failed to change their smarthost setting would have working email when contacting colleagues but not anyone else, with a mysterious relaying is not permitted error instead of something clear and helpful. There's also some advantage to making it harder for spammers to work out the name of your smarthost: we once (years ago) had a problem with an open web proxy that spammers used as the first half of a two-stage open relay, the second half of which was the MX of the proxy's parent domain. We separate these functions by having separate names and IP addresses for each one. They are all just facets of the same MTA, so we don't have to maintainn lots of different configurations. Tony. -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ LUNDY FASTNET IRISH SEA: WESTERLY OR SOUTHWESTERLY 4 OR 5, BECOMING CYCLONIC OR NORTHEASTERLY 5 TO 7, PERHAPS GALE 8 LATER. ROUGH OR VERY ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
Re: ingress SMTP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Bonomi wrote: One small data-point -- on a personal vanity domain, approximately 2/3 of all the spam (circa 15k junk emails/month) was 'direct to inbound MX' transmissions. The vast majority of this is coming from end-user machines outside of North America. This confirms the limited data I have. I configure my edge firewall (pf) to drop anything to/from the Spamhaus DROP list, as well as sendmail to use their XBL. The DROP list seems like it blocks mostly MX lookups (nice to see the blocking of mail start so early in the process!), so it is hard to say how many SMTP connections never happen (remote server/bot does not know where to connect). The XBL list, which is mostly residential IPs around the world, seems to be the single most effective technique in blocking incoming traffic-- on port 25. Obviously, these connections are coming from ISPs that do *not* block egress TCP 25. Slightly off topic-- I found it quite easy to configure the DROP list to work with pf (or is that the other way around?). I would be happy to share the small Perl script that updates the pf table. When I configured the DROP list on a free public wireless system I maintain, I was amazed at how much egress traffic it blocked-- obviously rogue/bad/evil webservers, IRC hosts, etc. I wonder if anyone else is using it that way? ... alec - -- ` / Alec Berry \__ | Senior Partner and Director of Technology \ | PGP/GPG key 0xE8E9030F| | http://alec.restontech.com/#PGP | |---| | RestonTech, Ltd. | |http://www.restontech.com/ | | Phone: (703) 234-2914| \___/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIv+YdREO1P+jpAw8RAnWzAKDxOmneR6j6DBVyo5/CO1wRYngorQCgo9SJ sArBQqQStX7zIuYK3qo1El0= =C2FM -END PGP SIGNATURE-
Re: ingress SMTP
In article [EMAIL PROTECTED] you write: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Bonomi wrote: One small data-point -- on a personal vanity domain, approximately 2/3 of all the spam (circa 15k junk emails/month) was 'direct to inbound MX' transmissions. The vast majority of this is coming from end-user machines outside of North America. This confirms the limited data I have. I configure my edge firewall (pf) to drop anything to/from the Spamhaus DROP list, as well as sendmail to use their XBL. The DROP list seems like it blocks mostly MX lookups (nice to see the blocking of mail start so early in the process!), so it is hard to say how many SMTP connections never happen (remote server/bot does not know where to connect). The XBL list, which is mostly residential IPs around the world, seems to be the single most effective technique in blocking incoming traffic-- on port 25. Obviously, these connections are coming from ISPs that do *not* block egress TCP 25. You do realise that there a mail clients that check MX records *before* submitting email (or before on sending the email) so that typos get detected in the client before any email is sent from the client. But you would never see those false positives. I know they exist because I've experienced them because I work from home and even though I tunnel email out via the office servers I prefer the typos to be caught locally. I doubt this will change your mind but it might stop someone else from making a bad decision to do what you are doing. Mark Slightly off topic-- I found it quite easy to configure the DROP list to work with pf (or is that the other way around?). I would be happy to share the small Perl script that updates the pf table. When I configured the DROP list on a free public wireless system I maintain, I was amazed at how much egress traffic it blocked-- obviously rogue/bad/evil webservers, IRC hosts, etc. I wonder if anyone else is using it that way? ... alec - -- ` / Alec Berry \__ | Senior Partner and Director of Technology \ | PGP/GPG key 0xE8E9030F| | http://alec.restontech.com/#PGP | |---| | RestonTech, Ltd. | |http://www.restontech.com/ | | Phone: (703) 234-2914| \___/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIv+YdREO1P+jpAw8RAnWzAKDxOmneR6j6DBVyo5/CO1wRYngorQCgo9SJ sArBQqQStX7zIuYK3qo1El0= =C2FM -END PGP SIGNATURE-
Re: ingress SMTP
Well, that depends on MUA design, of course, but it's just been pointed out to me that the RFC says MAY, not MUST. (That was me.) Note that there are TWO relevant RFCs: RFC 4409 and RFC 5068. The latter says: 3.1. Best Practices for Submission Operation Thanks, Tony. I hadn't taken account of superceding RFCs, and quoted 2476 to Jay. 2476 permits authN without encouraging or requiring it, but 4409 both obsoletes 2476 and makes authN mandatory, so it's more even than a best practice. It's the law, to the extent that two sites involved in a dispute may or may not consider RFC to be law. But as I noted privately, sendmail for one enables MSP out of the box without authentication -- or did the last few times I set it up -- so there's certainly a significant base of systems that at least are running MSP on 587 without requiring authentication. In such cases, blocking ports is just whacking moles, whether you ticket and fine the moles for violating RFC or not. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: ingress SMTP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Andrews wrote: You do realise that there a mail clients that check MX records *before* submitting email (or before on sending the email) so that typos get detected in the client before any email is sent from the client. I think you are not familiar with the difference between the DROP list and the XBL. The DROP list is *not* an RBL! I do not allow any traffic at all to or from the DROP list-- including MX lookups. I can't think of any good reasons why I would. The XBL is used only to block mail transport-- it is configured in sendmail, not at the firewall. The scenario you lay out will still work: - - end user on a dial up that happens to be on the XBL (common) - - end user queries MX records, either directly or via their name server - - end user submits mail to their SMTP server (not on the XBL) - - SMTP server transports mail to my system Unless one of those systems mentioned above is a hijacked name server in Kyiv (and thus on the DROP list), everything will work. ... alec - -- ` / Alec Berry \__ | Senior Partner and Director of Technology \ | PGP/GPG key 0xE8E9030F| | http://alec.restontech.com/#PGP | |---| | RestonTech, Ltd. | |http://www.restontech.com/ | | Phone: (703) 234-2914| \___/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIv/dTREO1P+jpAw8RAqiyAKDJt7FbFvplXB1JTe+dKDOOSXUijQCdH/cZ 4m4o9vE5FS96huARs2Rq5yU= =Paen -END PGP SIGNATURE-
Re: ingress SMTP
On Thu, Sep 04, 2008 at 02:01:48PM +1200, Mark Foster wrote: So in terms of the OP, I don't see why joe-user on a dynamic-IP home connection should need the ability to use port 25 to talk to anywhere but their local ISP SMTP server on a normal basis[1]. Whats a normal basis? My Home ISP won't let me send to more than 200 (or so) email addresses per day. If I used my ISP's email system I would constantly be losing my email service due to hitting the limit. I do the field scheduling for my local town soccer league. [Never volunteer! :-) ] So when I send a few announcements out to coaches, referees and administrators, I hit that limit and get my email shutoff for two days or so. I eventually switched to MailHop at DynDNS (smtp auth) I would have used port 25 but our ISP has begun blocking outbound port 25 nationwide, due to large amount of outbound spam from their customers. :-) *rest snipped* Is the above described limitation a common occurrance in the world-at-large? I've not heard of ISPs doing number-of-recipients-per-day limitations. I've heard of them doing number-of-recipients-per-email limitations (thus limiting large cc/bcc lists) but not total number of emails. Who's to say that there arent legitimate reasons to email a large number of people - perhaps your customers?? Certainly if my own ISP did something like that, you're quite right, i'd have to find an alternative. (Or perhaps, an alternative ISP. ) (who set the limit at 200? Can you opt-out of the limit or have it upped?) Mark.
ingress SMTP
I've been blackholing NANOG mail for a while due to other things displacing the time I'd need to read it, so I might be a little out of touch on this, but I did grovel through some of the archives looking for any discussion on this before posting. Didn't find a really coherent answer yet. What I'm trying to get a feel for is this: what proportion of edge customers have a genuine NEED to send direct SMTP traffic to TCP 25 at arbitrary destinations? I'm thinking mostly of cable-modem and DSL/fiber swamps, dialup pools [do they even exist anymore?], and other clouds basically containing end-users rather than the more bidirectional business-class customers. The big providers -- comcast, verizon, RR, charter, bellsouth, etc -- seem to be some of the most significant sources of spam and malware attempts, mostly from compromised end-user machines, and it seems that simply denying *INGRESS* of TCP 25 traffic except to the given ISP's outbound relay servers would cut an awful lot of it off at the pass. Decent anti-header-spoofing configuration on said mailservers would take care of even more. I realize this might be a total hot-button but I'm not talking about filtering TOWARD customers, I'm talking about filtering FROM them, upstream -- possibly less often discussed. And only SMTP. Not censorship, just a simple technical policy that the vast majority of customers wouldn't even notice. I've got a paper out about this that was put together quite a while ago, in fact: http://www.usenix.org/publications/login/2005-10/openpdfs/hobbit.pdf I can weigh the decision to trust a PTR lookup, but most of the big players seem to have their inverse DNS automated fairly well which helps such little hacks work. But really, I'd like to see more done at the SOURCE of the problem, which should be as simple as two ACL lines dropped into some edge routers. What is preventing this from being an operational no-brainer, including making a few exceptions for customers that prove they know how to lock down their own mail infrastructure? And why do the largest players seem to have the least clue about it? _H*
Re: ingress SMTP
On Wed, Sep 3, 2008 at 8:46 PM, *Hobbit* [EMAIL PROTECTED] wrote: What I'm trying to get a feel for is this: what proportion of edge customers have a genuine NEED to send direct SMTP traffic to TCP 25 at arbitrary destinations? I'm thinking mostly of cable-modem and Not too many - they got themselves port 587 to submit outbound mail. Read the maawg managing port 25 document - and while you are at it read the walled garden doc too.. port 25 abuse is the least of your worries with cable/dsl cpe swamps http://www.maawg.org/port25 http://www.maawg.org/about/whitepapers/MAAWG_Walled_Garden_BP_2007-09.pdf --srs
RE: ingress SMTP
Anybody not wanting to use their ISP email would notice it. I see filtering 25 FROM the customer as something that is not likely to happen because of this. When a customer buys bandwidth, they want to be able to use it for whatever they choose. This would be just one more restriction giving competitive advantage to any ISP not doing the filtering. -- Tim Sanderson, network administrator [EMAIL PROTECTED] -Original Message- From: *Hobbit* [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 11:16 AM To: nanog@nanog.org Subject: ingress SMTP I've been blackholing NANOG mail for a while due to other things displacing the time I'd need to read it, so I might be a little out of touch on this, but I did grovel through some of the archives looking for any discussion on this before posting. Didn't find a really coherent answer yet. What I'm trying to get a feel for is this: what proportion of edge customers have a genuine NEED to send direct SMTP traffic to TCP 25 at arbitrary destinations? I'm thinking mostly of cable-modem and DSL/fiber swamps, dialup pools [do they even exist anymore?], and other clouds basically containing end-users rather than the more bidirectional business-class customers. The big providers -- comcast, verizon, RR, charter, bellsouth, etc -- seem to be some of the most significant sources of spam and malware attempts, mostly from compromised end-user machines, and it seems that simply denying *INGRESS* of TCP 25 traffic except to the given ISP's outbound relay servers would cut an awful lot of it off at the pass. Decent anti-header-spoofing configuration on said mailservers would take care of even more. I realize this might be a total hot-button but I'm not talking about filtering TOWARD customers, I'm talking about filtering FROM them, upstream -- possibly less often discussed. And only SMTP. Not censorship, just a simple technical policy that the vast majority of customers wouldn't even notice. I've got a paper out about this that was put together quite a while ago, in fact: http://www.usenix.org/publications/login/2005-10/openpdfs/hobbit.pdf I can weigh the decision to trust a PTR lookup, but most of the big players seem to have their inverse DNS automated fairly well which helps such little hacks work. But really, I'd like to see more done at the SOURCE of the problem, which should be as simple as two ACL lines dropped into some edge routers. What is preventing this from being an operational no-brainer, including making a few exceptions for customers that prove they know how to lock down their own mail infrastructure? And why do the largest players seem to have the least clue about it? _H*
Re: ingress SMTP
What is preventing this from being an operational no-brainer, including making a few exceptions for customers that prove they know how to lock down their own mail infrastructure? As a small player who operates a mail server used by many local businesses, this becomes a support issue for admins in our position. We operate an SMTP server of our own that the employees of these various companies use from work and at home. Everything works great until an ISP decides to block 25 outbound. Now our customer cannot reach our server, so they call us to complain that they can receive but not send e-mail. We, being somewhat intelligent, have a support process in place to walk the customer through the SMTP port change from 25 to one of our two alternate ports. The problem, however, is that the customer simply cannot understand why their e-mail worked one day and doesn't the next. In their eyes the system used to work, and now it doesn't, so that must mean that we broke it and that we don't know what we're doing. Your comment about exceptions for customers that prove they know how to lock down is not based in reality, frankly. Have you ever tried to have Joe Sixpack call BigISP support to ask for an exception to a port block on his consumer-class connection with a dynamic IP? That's a wall that I would not be willing to ask my customers to climb over. Now, having said all that, I do agree that big ISPs should do more to prevent spam from originating at their networks. A basic block of 25 isn't the solution, in my opinion. Unfortunately I don't know what is. Perhaps monitoring the number of outgoing connections on 25 and temporarily cutting off access if a threshold is reached? Set it high enough and the legitimate users won't notice, but low enough that it disrupts the spammers. Perhaps I'm talking out of my ass and don't have a clue. In any case, I don't believe a blanket block of 25 is the answer. -Justin Scott, GravityFree smime.p7s Description: S/MIME Cryptographic Signature
Re: ingress SMTP
On Wed, Sep 03, 2008 at 11:56:51AM -0400, Justin Scott wrote: As a small player who operates a mail server used by many local businesses, this becomes a support issue for admins in our position. We operate an SMTP server of our own that the employees of these various companies use from work and at home. Everything works great until an ISP decides to block 25 outbound. Now our customer cannot reach our server, so they call us to complain that they can receive but not send e-mail. We, being somewhat intelligent, have a support process in place to walk the customer through the SMTP port change from 25 to one of our two alternate ports. The problem, however, is that the customer simply cannot understand why their e-mail worked one day and doesn't the next. In their eyes the system used to work, and now it doesn't, so that must mean that we broke it and that we don't know what we're doing. I feel your pain, local compadre, but I'm on their side. Here's your script: Allowing unfiltered public access to port 25 is one of the things that increases everyone's spam load, and your ISP is trying to be a Good Neighbor in blocking access to anyone's servers but their own; many ISPs are moving towards this safer configuration. We're a good neighbor, as well, and support Mail Submission Protocol on port 587, and here's how you set it up -- and it will work from pretty much anywhere forever. Which is a safe thing to tell people because it is decidedly *not* best practice to block 587. Cheers, -- jra -- Jay R. Ashworth Baylink [EMAIL PROTECTED] Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin)
Re: ingress SMTP
Why don't you set the alternate ports up as the defaults when the customer signs up? Excellent question and unfortunately I don't have an answer. I will run that one by management as it is an obviously great idea now that you mention it. We use TLS on port 587 and SSL on 465, most mail clients default to these ports when you click the TLS or SSL box. Bonus-- we tell our clients that we only support encrypted access to their mail. They understand. We also support SSL access for SMTP and POP, so that could be a possibility as well. I appreciate the feedback on this from everyone. I'm still not 100% convinced that a blanket port block is the answer, but then again I'm not an ISP so my opinion shouldn't be on the top of the list of considerations either. I do have some things to think about for new customers though g. -Justin Scott, GravityFree smime.p7s Description: S/MIME Cryptographic Signature
Re: ingress SMTP
Jay R. Ashworth wrote: On Wed, Sep 03, 2008 at 11:56:51AM -0400, Justin Scott wrote: As a small player who operates a mail server used by many local businesses, this becomes a support issue for admins in our position. We operate an SMTP server of our own that the employees of these various companies use from work and at home. Everything works great until an ISP decides to block 25 outbound. Now our customer cannot reach our server, so they call us to complain that they can receive but not send e-mail. We, being somewhat intelligent, have a support process in place to walk the customer through the SMTP port change from 25 to one of our two alternate ports. The problem, however, is that the customer simply cannot understand why their e-mail worked one day and doesn't the next. In their eyes the system used to work, and now it doesn't, so that must mean that we broke it and that we don't know what we're doing. I feel your pain, local compadre, but I'm on their side. Here's your script: Allowing unfiltered public access to port 25 is one of the things that increases everyone's spam load, and your ISP is trying to be a Good Neighbor in blocking access to anyone's servers but their own; many ISPs are moving towards this safer configuration. We're a good neighbor, as well, and support Mail Submission Protocol on port 587, and here's how you set it up -- and it will work from pretty much anywhere forever. I think this all vastly underrates the agility of the bad guys. So lots of ISP's have blocked port 25. Has it made any appreciable difference? Not that I can tell. If you block port 25, they'll just use another port and a relay if necessary. But the thing that's really pernicious about this sort of policy is that it's a back door policy for ISP's to clamp down on all outgoing ports in the name of security. And it's almost plausible, except for the annoying problem that the net becomes secure and useless in one swell foop. That said, I heard a pretty amazing claim made by somebody while I was still at the big ol networking company that ISP's in general not only didn't know which of their customers computers were owned, but that they didn't want to know. Even putting aside the claim of blissful ignorance, port 25 blocking is nothing more than a Maginot Line for the larger problems of infected computers. If we really wanted to curb spam, why don't we just put them in the penalty box until they are remediated? Heck, that even stops lots of other attacks that have nothing to do with port 25 too. Mike
Re: ingress SMTP
Do you operate your mailserver on a residential cablemodem or adsl rather than a business account? No, we co-lo equipment at a professional facility that our customers on any type of connection need to have access to send mail through, regardless of whether their ISP blocks the standard ports or not. -Justin Scott, GravityFree smime.p7s Description: S/MIME Cryptographic Signature
Re: ingress SMTP
On Wed, Sep 03, 2008 at 09:40:20AM -0700, Michael Thomas wrote: Allowing unfiltered public access to port 25 is one of the things that increases everyone's spam load, and your ISP is trying to be a Good Neighbor in blocking access to anyone's servers but their own; many ISPs are moving towards this safer configuration. We're a good neighbor, as well, and support Mail Submission Protocol on port 587, and here's how you set it up -- and it will work from pretty much anywhere forever. I think this all vastly underrates the agility of the bad guys. So lots of ISP's have blocked port 25. Has it made any appreciable difference? Not that I can tell. If you block port 25, they'll just use another port and a relay if necessary. You're forgetting that 587 *is authenticated, always*. The issue here, though, was that of an Enhanced Mail Provider's clients being unable to get through blocks *set by their client's ISPs*. The EMP has no control over that except to switch said clients to MSP (which they really should have done to begin with, as someone else notes). Cheers, -- jra -- Jay R. Ashworth Baylink [EMAIL PROTECTED] Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin)
Re: ingress SMTP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Thomas wrote: I think this all vastly underrates the agility of the bad guys. So lots of ISP's have blocked port 25. Has it made any appreciable difference? Not that I can tell. If you block port 25, they'll just use another port and a relay if necessary. I'm pretty sure it has, although without aggregate stats from various ISPs it is hard to tell. Since mail transport is exclusively on port 25 (as opposed to mail submission), a bot cannot just hop to another port. But the thing that's really pernicious about this sort of policy is that it's a back door policy for ISP's to clamp down on all outgoing ports in the name of security. I don't think ISPs have anything to gain by randomly blocking ports. They may block a port that is often used for malicious behavior (135-139, 194, 445, 1433, 3306 come to mind) as a way to reduce their support calls-- but they would have to balance that with the risk of loosing customers. It's not as much a slippery slope as much as it is a tightrope act (yes-- I am metaphorically challenged). ... alec - -- ` / Alec Berry \__ | Senior Partner and Director of Technology \ | PGP/GPG key 0xE8E9030F| | http://alec.restontech.com/#PGP | |---| | RestonTech, Ltd. | |http://www.restontech.com/ | | Phone: (703) 234-2914| \___/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIvsINREO1P+jpAw8RAvKNAKC83NJgwv4EakAv/jw5biO79D/xEwCgldZ+ JHkb3LboeAD2GC77vcb06Y4= =nfVP -END PGP SIGNATURE-
Re: ingress SMTP
On Wed, Sep 3, 2008 at 10:18 PM, Justin Scott [EMAIL PROTECTED] wrote: Do you operate your mailserver on a residential cablemodem or adsl rather than a business account? No, we co-lo equipment at a professional facility that our customers on any type of connection need to have access to send mail through, regardless of whether their ISP blocks the standard ports or not. That's why you set your outbound MTA to listen - for auth'd outbound connections only - on port 587 Endless loop of dead horse beating .. ouch srs -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: ingress SMTP
Alec Berry wrote: Michael Thomas wrote: But the thing that's really pernicious about this sort of policy is that it's a back door policy for ISP's to clamp down on all outgoing ports in the name of security. I don't think ISPs have anything to gain by randomly blocking ports. They may block a port that is often used for malicious behavior (135-139, 194, 445, 1433, 3306 come to mind) as a way to reduce their support calls-- but they would have to balance that with the risk of loosing customers. It's not as much a slippery slope as much as it is a tightrope act (yes-- I am metaphorically challenged). I see nothing wrong with filtering commonly abused ports, provided that the ISP allows a user to opt out if they know enough to ask. When port 25 block was first instituted, several providers actually redirected connections to their own servers (with spam filters and/or rate limits) rather than blocking the port entirely. This seems like a good compromise for port 25 in particular, provided you have the tools available to implement and support it properly. I also agree with the comments about switching customers to 587. My former monopoly ISP only accepted mail on 25 and I had endless problems trying to send mail from airports, hotels, coffee shops, etc. while traveling. The same hotspots also tended to block port 22, so I couldn't even forward mail via my own server. However, my new monopoly ISP only accepts mail on 587, and I have yet to have a single problem with that from any hotspot I've used since the switch. Ditto for reading my mail via IMAPS/993, whereas I used to have occasional problems reading it via IMAP/143. S
Re: ingress SMTP
On 9/3/08 10:50 AM, Suresh Ramasubramanian [EMAIL PROTECTED] wrote: On Wed, Sep 3, 2008 at 8:46 PM, *Hobbit* [EMAIL PROTECTED] wrote: What I'm trying to get a feel for is this: what proportion of edge customers have a genuine NEED to send direct SMTP traffic to TCP 25 at arbitrary destinations? I'm thinking mostly of cable-modem and Not too many - they got themselves port 587 to submit outbound mail. Read the maawg managing port 25 document - and while you are at it read the walled garden doc too.. port 25 abuse is the least of your worries with cable/dsl cpe swamps http://www.maawg.org/port25 http://www.maawg.org/about/whitepapers/MAAWG_Walled_Garden_BP_2007-09.pdf --srs We have not setup a port 587 smtp submit server. Our smtp servers run only on port 25. We point our clients outbound email to these servers, which require authentication for relaying. We run into problems with ISPs and hotels which block outbound SMTP. They can't send email. We have to work with them to work with their ISPs to find out what SMTP server they can use for outgoing email. It's a big problem. Yes, setting up a 587 submit server internally would be best, but man power is at a premium and it hasn't happened. So, for us, having ISPs block port 25 is a problem. === Tim Tim Winders | Associate Dean of Information Technology | South Plains College
Re: ingress SMTP
On Wednesday 03 September 2008 18:07:22 Stephen Sprunk wrote: When port 25 block was first instituted, several providers actually redirected connections to their own servers (with spam filters and/or rate limits) rather than blocking the port entirely. This seems like a good compromise for port 25 in particular, provided you have the tools available to implement and support it properly. It generated some very confused support calls here, where folks said I sent email to your server, and we had to tell them no you didn't, you only thought you did. Please if you are going to block it block it clearly and transparently. On the other hand abuse by bots isn't restricted to SMTP, and I suspect ISPs would be better of long term having a way of spotting compromised/malicious hosts and dealing with them, than applying a sticky plaster to port 25. Indeed spewing on port 25 is probably a good sign you need to apply said system.
Re: ingress SMTP
On Sep 3, 2008, at 12:49 PM, Jay R. Ashworth wrote: On Wed, Sep 03, 2008 at 09:40:20AM -0700, Michael Thomas wrote: Allowing unfiltered public access to port 25 is one of the things that increases everyone's spam load, and your ISP is trying to be a Good Neighbor in blocking access to anyone's servers but their own; many ISPs are moving towards this safer configuration. We're a good neighbor, as well, and support Mail Submission Protocol on port 587, and here's how you set it up -- and it will work from pretty much anywhere forever. I think this all vastly underrates the agility of the bad guys. So lots of ISP's have blocked port 25. Has it made any appreciable difference? Not that I can tell. If you block port 25, they'll just use another port and a relay if necessary. You're forgetting that 587 *is authenticated, always*. I'm not sure how that makes much of a difference since the usual spam vector is malware that has (almost) complete control of the machine in the first place.
RE: ingress SMTP
Intercepting port 25 traffic of your customers (as an ISP), redirecting it to your own servers, and allowing the connection to complete sounds like a pretty slippery slope of badness to me. Sure, you should be using TLS anyway, but slurping up port 25 traffic begs the question of what is happening to the SMTP authentication credentials or the mail data that flows through said intercept. Blocking traffic versus intercepting it wholesale are very different ballgames. Now, obviously, whoever is providing your pipe has the technical ability to intercept your traffic. Actually doing this has proven widely unpopular (to place it nicely) when uncovered, even with the best of intentions. There is usually an implicit trust that your ISP won't be employing underhanded tactics like that in most people's minds, I think. I suspect that most people will call any interception of their outbound mail traffic underhanded, even for if done for a perceived good reason in the mind of said ISP. - S -Original Message- From: Stephen Sprunk [EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 12:09 To: Alec Berry [EMAIL PROTECTED] Cc: north American Noise and Off-topic Gripes [EMAIL PROTECTED] Subject: Re: ingress SMTP Alec Berry wrote: Michael Thomas wrote: But the thing that's really pernicious about this sort of policy is that it's a back door policy for ISP's to clamp down on all outgoing ports in the name of security. I don't think ISPs have anything to gain by randomly blocking ports. They may block a port that is often used for malicious behavior (135-139, 194, 445, 1433, 3306 come to mind) as a way to reduce their support calls-- but they would have to balance that with the risk of loosing customers. It's not as much a slippery slope as much as it is a tightrope act (yes-- I am metaphorically challenged). I see nothing wrong with filtering commonly abused ports, provided that the ISP allows a user to opt out if they know enough to ask. When port 25 block was first instituted, several providers actually redirected connections to their own servers (with spam filters and/or rate limits) rather than blocking the port entirely. This seems like a good compromise for port 25 in particular, provided you have the tools available to implement and support it properly. I also agree with the comments about switching customers to 587. My former monopoly ISP only accepted mail on 25 and I had endless problems trying to send mail from airports, hotels, coffee shops, etc. while traveling. The same hotspots also tended to block port 22, so I couldn't even forward mail via my own server. However, my new monopoly ISP only accepts mail on 587, and I have yet to have a single problem with that from any hotspot I've used since the switch. Ditto for reading my mail via IMAPS/993, whereas I used to have occasional problems reading it via IMAP/143. S
Re: ingress SMTP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Winders, Timothy A wrote: We have not setup a port 587 smtp submit server. Our smtp servers run only on port 25. Sorry to be harsh, but that's just not the right way to do things these days. At the very least, you can run stunnel to allow incoming mail submission on port 465 (SMTP + SSL). So, for us, having ISPs block port 25 is a problem. Read: for us, running a mail server is a problem ... alec - -- ` / Alec Berry \__ | Senior Partner and Director of Technology \ | PGP/GPG key 0xE8E9030F| | http://alec.restontech.com/#PGP | |---| | RestonTech, Ltd. | |http://www.restontech.com/ | | Phone: (703) 234-2914| \___/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIvs30REO1P+jpAw8RAtBUAJsFmxNfi9UGcDCfmkDs7Tni+iHuKwCgtKyg 01N7WA1sXhzuWsYD4ZG6go0= =66IU -END PGP SIGNATURE-
Re: ingress SMTP
On 9/3/08 12:48 PM, Alec Berry [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Winders, Timothy A wrote: We have not setup a port 587 smtp submit server. Our smtp servers run only on port 25. Sorry to be harsh, but that's just not the right way to do things these days. At the very least, you can run stunnel to allow incoming mail submission on port 465 (SMTP + SSL). So, for us, having ISPs block port 25 is a problem. Read: for us, running a mail server is a problem Not harsh at all. It's reality. We do have the option for SMTP/SSL/TLS over port 25. It is only required for an authenticated session. I agree, it's not the right way to do things. Running a mail server used to be much easier. Volunteers to help set things up the right way are always welcome. :-) Otherwise, it will happen eventually. :-( Tim Winders | Associate Dean of Information Technology | South Plains College
Re: ingress SMTP
I agree, it's not the right way to do things. Running a mail server used to be much easier. Volunteers to help set things up the right way are always welcome. :-) Supporting those clients who can't connect is cheaper or more accessible for you?
Re: ingress SMTP
On 9/3/08 12:59 PM, Jason Fesler [EMAIL PROTECTED] wrote: I agree, it's not the right way to do things. Running a mail server used to be much easier. Volunteers to help set things up the right way are always welcome. :-) Supporting those clients who can't connect is cheaper or more accessible for you? At this point, yes. We offer SSL/VPN connections back into the network which (so far) has always fixed the problem if the client is unable to work with their ISP to get smtp settings for their email program. It's a matter of resources and priorities. I'd also like to setup an automated provisioning server, but don't know how to do that. There are many projects in the wings. Registering students and making sure they can pay for classes always seems to bubble to the top, though. ;-) Of course, this is getting a bit off topic for NANOG, so I'll stop there. Tim Winders | Associate Dean of Information Technology | South Plains College
Re: ingress SMTP
Wow, lots of responses already. Thanks, good discussion. I should clarify a little, that it's not necessarily about blanket port blocking or denying random ports as threats are perceived, but where needed in a well thought-out manner and trying to take customer needs [stated or observed] into account first. And back it up with AUP verbiage. There must be plenty of places where it just makes sense, and others where it's borderline, iffy, or unmanageable. One has to start *someplace*. Oh, and don't get me started about abuse-desk competency, or even existence, especially in the big providers. I'll bet most of them can't even find the *rack* where the autoresponder machine is, let alone actually figure out why its disk has been full for six months. Related question, now that some discussion has started: why the F does Gmail refuse to put real, identifiable injection-path headers in mail they relay out? The current policy only protects spammer identities behind a meaningless 10.x and is completely at odds with what almost every other freemail provider does, which of course breaks any receiving-end model. Who's here from Google that I can chat with about this? _H*
Re: ingress SMTP
on Wed, Sep 03, 2008 at 05:15:41PM +, *Hobbit* wrote: Related question, now that some discussion has started: why the F does Gmail refuse to put real, identifiable injection-path headers in mail they relay out? The current policy only protects spammer identities behind a meaningless 10.x and is completely at odds with what almost every other freemail provider does, which of course breaks any receiving-end model. Who's here from Google that I can chat with about this? Dunno who's here from Google, but every time I've asked about this (as the basis for a discussion of why they do such a sucky job of blocking 419 scams, which we otherwise block by injection point analysis) I've been told that it's a privacy issue. I long suspected it was just a side effect of an inflexible network architecture, but have been assured that, no, it's the privacy issue. And yes, this is completely at odds with the fact that they *do* put injection point IP audit trail into mail they relay via SMTP. In the end, it's an idiotic policy, and I hope they wake up and fix it. In the meantime, I'm reporting every 419 scam I get from them. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)747-9073 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/
Re: ingress SMTP
On Wed, Sep 03, 2008 at 12:58:53PM -0400, Nicholas Suan wrote: On Sep 3, 2008, at 12:49 PM, Jay R. Ashworth wrote: You're forgetting that 587 *is authenticated, always*. I'm not sure how that makes much of a difference since the usual spam vector is malware that has (almost) complete control of the machine in the first place. Well, that depends on MUA design, of course, but it's just been pointed out to me that the RFC says MAY, not MUST. Oops. Does anyone bother to run an MSA on 587 and *not* require authentication? Cheers, -- jra -- Jay R. Ashworth Baylink [EMAIL PROTECTED] Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin)
Re: ingress SMTP
On 9/3/08 1:04 PM, Winders, Timothy A [EMAIL PROTECTED] wrote: On 9/3/08 12:59 PM, Jason Fesler [EMAIL PROTECTED] wrote: I agree, it's not the right way to do things. Running a mail server used to be much easier. Volunteers to help set things up the right way are always welcome. :-) Supporting those clients who can't connect is cheaper or more accessible for you? At this point, yes. We offer SSL/VPN connections back into the network which (so far) has always fixed the problem if the client is unable to work with their ISP to get smtp settings for their email program. It's a matter of resources and priorities. I'd also like to setup an automated provisioning server, but don't know how to do that. There are many projects in the wings. Registering students and making sure they can pay for classes always seems to bubble to the top, though. ;-) Of course, this is getting a bit off topic for NANOG, so I'll stop there. Tim Winders | Associate Dean of Information Technology | South Plains College This thread has inspired me to get off my duff and get it done. I now have a properly working MSA running on port 587 requiring authentication. A few updates to user documentation and we'll be setup and running. Thanks for the kick in the pants. :-) Tim Winders | Associate Dean of Information Technology | South Plains College
Re: ingress SMTP
On Wed, 03 Sep 2008 15:00:15 EDT, Jay R. Ashworth said: Does anyone bother to run an MSA on 587 and *not* require authentication? Presumably only sites that don't care if they end up in half the anti-spam blacklists on the planet. Based on the evidence I have, there's a depressingly large number of those sort of sites pgp0qwfyKGamw.pgp Description: PGP signature
Re: ingress SMTP
*Hobbit* wrote: What I'm trying to get a feel for is this: what proportion of edge customers have a genuine NEED to send direct SMTP traffic to TCP 25 at arbitrary destinations? Probably very few. The big providers -- comcast, verizon, RR, charter, bellsouth, etc -- seem to be some of the most significant sources of spam and malware attempts, mostly from compromised end-user machines, and it seems that simply denying *INGRESS* of TCP 25 traffic except to the given ISP's outbound relay servers would cut an awful lot of it off at the pass. I have SBC / ATT / Yahoo DSL in Southern California and they block outbound 25 to anything but Yahoo SMTP server farm, and they only allow SSL connectivity at that. I'm all for that personally. It was a minor effort to setup my [EMAIL PROTECTED] address to be allowed out (had to fill out a webform and click a verify link). Since most people use the address given to them by the provider and most likely use webmail this certainly won't affect them. To top it all off I can fill out another web form and specifically request unblocking of ports and relay out mail server wherever I want. So SBC has a policy of deny SMTP relaying by default, provide clear instructions to allow outbound relay via approved server farm if you don't want to be blocked request unblocking via a self service web form. Seems perfectly acceptable to me. Thoughts? -- Charles Wyble (818) 280 - 7059 http://charlesnw.blogspot.com CTO Known Element Enterprises / SoCal WiFI project
RE: ingress SMTP
I would like to point my customers to port 587, but that kind of configuration is still in its infancy. We ask our employees of our business customers to VPN into work and for everyone else to use our webmail. Frank -Original Message- From: Justin Scott [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 10:57 AM To: nanog@nanog.org Subject: Re: ingress SMTP What is preventing this from being an operational no-brainer, including making a few exceptions for customers that prove they know how to lock down their own mail infrastructure? As a small player who operates a mail server used by many local businesses, this becomes a support issue for admins in our position. We operate an SMTP server of our own that the employees of these various companies use from work and at home. Everything works great until an ISP decides to block 25 outbound. Now our customer cannot reach our server, so they call us to complain that they can receive but not send e-mail. We, being somewhat intelligent, have a support process in place to walk the customer through the SMTP port change from 25 to one of our two alternate ports. The problem, however, is that the customer simply cannot understand why their e-mail worked one day and doesn't the next. In their eyes the system used to work, and now it doesn't, so that must mean that we broke it and that we don't know what we're doing. Your comment about exceptions for customers that prove they know how to lock down is not based in reality, frankly. Have you ever tried to have Joe Sixpack call BigISP support to ask for an exception to a port block on his consumer-class connection with a dynamic IP? That's a wall that I would not be willing to ask my customers to climb over. Now, having said all that, I do agree that big ISPs should do more to prevent spam from originating at their networks. A basic block of 25 isn't the solution, in my opinion. Unfortunately I don't know what is. Perhaps monitoring the number of outgoing connections on 25 and temporarily cutting off access if a threshold is reached? Set it high enough and the legitimate users won't notice, but low enough that it disrupts the spammers. Perhaps I'm talking out of my ass and don't have a clue. In any case, I don't believe a blanket block of 25 is the answer. -Justin Scott, GravityFree
RE: ingress SMTP
Mediacom appears to require SSL to POP3 access: http://www.mchsi.com/help/read/publisher_02/2002-01-28.01 If you are off the Mediacom Online network you can still access your e-mail using your e-mail client. However, you will need to configure your e-mail program to connect to our secure e-mail server via SSL. Frank -Original Message- From: Jay R. Ashworth [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 11:07 AM To: nanog@nanog.org Subject: Re: ingress SMTP On Wed, Sep 03, 2008 at 11:52:48AM -0400, Tim Sanderson wrote: Anybody not wanting to use their ISP email would notice it. I see filtering 25 FROM the customer as something that is not likely to happen because of this. When a customer buys bandwidth, they want to be able to use it for whatever they choose. This would be just one more restriction giving competitive advantage to any ISP not doing the filtering. Just as long as consumer ISPs don't start filtering *110* inbound from the net... as ATT used to. I had a client move from dialup to cablemodem about 10 years ago... and it took us a *week* to get ATT to admit they didn't accept inbound POP pickups. Client (intemperately) had printed the att.com email address of lots of crap -- they had to keep the dialup for a long time, since att wouldn't forward either... Thank ghod I'm out of the jungle now... Cheers, -- jra -- Jay R. Ashworth Baylink [EMAIL PROTECTED] Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin)
Re: ingress SMTP
From [EMAIL PROTECTED] Wed Sep 3 11:58:37 2008 From: Alec Berry [EMAIL PROTECTED] Subject: Re: ingress SMTP Michael Thomas wrote: I think this all vastly underrates the agility of the bad guys. So lots of ISP's have blocked port 25. Has it made any appreciable difference? Not that I can tell. If you block port 25, they'll just use another port and a relay if necessary. I'm pretty sure it has, although without aggregate stats from various ISPs it is hard to tell. Since mail transport is exclusively on port 25 (as opposed to mail submission), a bot cannot just hop to another port. One small data-point -- on a personal vanity domain, approximately 2/3 of all the spam (circa 15k junk emails/month) was 'direct to inbound MX' transmissions. The vast majority of this is coming from end-user machines outside of North America. China, India Thailand, Brazil, Poland, CZ, and a couple of providers each in Germany and France, appear to be the most prevalent sources _I_ see. The message count would be a fair bit higher, but I have several overseas networks (4 in DE, 2 in TW, 1 in CZ) plus pieces of 2 domestic networks (*da.uu.net, *pub-ip.psi.net) blocked at the firewall. Also firewalled are a couple of dozen IP addresses that have -each- made over 10k attempts to _relay_ mail through me. I'm seeing a significant amount of 'Received' header forgery, apparently intended to fool dumb header parsers into believing the direct-to-MX transmission _did_ go through the server associated with the domain used in the 'from: , from , and Reply-to: lines. The good news is that only a _really_ dumb parser would be fooled by most of what I'm seeing. :)
Re: ingress SMTP
On Sep 3, 2008, at 4:36 PM, Frank Bulk wrote: I would like to point my customers to port 587, but that kind of configuration is still in its infancy. We're a small managed services provider, and we started doing authenticated SMTP with TLS on port 587 six years ago. It's at least in kindergarten :-) Once we explain the advantages, our customers love it since their email just works pretty much wherever they go. As a former manager for a small resnet, blocking port 25 outbound is A Good Thing. Cut abuse email down by a huge factor. --Chris
Re: ingress SMTP
At 12:48 PM 9/3/2008, you wrote: Do you operate your mailserver on a residential cablemodem or adsl rather than a business account? No, we co-lo equipment at a professional facility that our customers on any type of connection need to have access to send mail through, regardless of whether their ISP blocks the standard ports or not. -Justin Scott, GravityFree I've been running a similar operation for over a decade, offering email services, web services and collocation to businesses from the tiny to the multinational. We have, since the beginning, provided instructions on using port 587 and port 465 for email submission. This is not hard to explain, and it has never been a problem for our customers or their tech folks to accomplish. Our servers are in data centers, our customers are on DSL, cable or even dialup circuits. We assume port 25 will be blocked, and while it isn't always, starting with that assumption simplifies matters. We also encourage our customers to always use TLS or SSL for all exchanges with the mail servers. Because we have many users who are road warriors, they never know who their local access ISP will be. Getting them set up for 587 or 465 before they leave home has always kept folks out of trouble. And those few who don't heed our advice have had their email hijacked by hotel networks that consume traffic to any remote port 25 themselves in an attempt to help. So again, just get your customers configured right at the start, and there will be few support calls on the subject. This is just part of being a third-party supplier of email services in the current reality. Dan
Re: ingress SMTP
- Original Message - From: Jay R. Ashworth [EMAIL PROTECTED] Date: Thursday, September 4, 2008 5:00 am Subject: Re: ingress SMTP Does anyone bother to run an MSA on 587 and *not* require authentication? Many can be configured that way (example: Sun One/iPlanet mail server can). Whether they are or not depends on the admin. / M
Why not go after bots? (was: ingress SMTP)
Charles Wyble wrote: I have SBC / ATT / Yahoo DSL in Southern California and they block outbound 25 to anything but Yahoo SMTP server farm, and they only allow SSL connectivity at that. I'm all for that personally. That seems to be the convention wisdom, but the science experiment as it were in blocking port 25 doesn't seem to be correlated (must less causated) with any drop in the spam rate. Because so far as I've heard there isn't any such drop. Spammers and the rest are pretty resourceful. So I still haven't heard why there isn't any emphasis on going after the bots that are by far the biggest problem instead of erecting damage for them to route around. I can sort of understand why providers are leery of getting sucked into that battle, but it's got to cost them a fortune for every My internet is slow call they take. Mike
ingress SMTP
On Wed, Sep 03, 2008 at 12:58:53PM -0400, Nicholas Suan wrote: On Sep 3, 2008, at 12:49 PM, Jay R. Ashworth wrote: You're forgetting that 587 *is authenticated, always*. I'm not sure how that makes much of a difference since the usual spam vector is malware that has (almost) complete control of the machine in the first place. Well, that depends on MUA design, of course, but it's just been pointed out to me that the RFC says MAY, not MUST. Oops. Does anyone bother to run an MSA on 587 and *not* require authentication? Raises hand. Why would the requirements for authentication be different depending on the port used to connect to the MTA? No matter how a session comes into the MTA (port 25, 465, 587, anything else) and no matter whether it is encrypted or not, the requirement for authentication (which is always available and advertized), is based on a simple policy: - local delivery originating from a non-blacklisted or internal/customer address does not require authentication; - relay from internal/customer IP Addresses does not require authentication; - any connection from a blacklisted IP requires authentication or no mail will be accepted; - relay from external/non-customer IP Addresses requires authentication; Is there a valid reason why a different configuration is justified? As an aside, outbound port 25 traffic is also blocked except from the MTA.
Re: ingress SMTP
On Wed, Sep 03, 2008 at 12:58:53PM -0400, Nicholas Suan wrote: On Sep 3, 2008, at 12:49 PM, Jay R. Ashworth wrote: You're forgetting that 587 *is authenticated, always*. I'm not sure how that makes much of a difference since the usual spam vector is malware that has (almost) complete control of the machine in the first place. Well, that depends on MUA design, of course, but it's just been pointed out to me that the RFC says MAY, not MUST. Oops. Does anyone bother to run an MSA on 587 and *not* require authentication? Raises hand. Why would the requirements for authentication be different depending on the port used to connect to the MTA? No matter how a session comes into the MTA (port 25, 465, 587, anything else) and no matter whether it is encrypted or not, the requirement for authentication (which is always available and advertized), is based on a simple policy: - local delivery originating from a non-blacklisted or internal/customer address does not require authentication; - relay from internal/customer IP Addresses does not require authentication; - any connection from a blacklisted IP requires authentication or no mail will be accepted; - relay from external/non-customer IP Addresses requires authentication; Is there a valid reason why a different configuration is justified? As an aside, outbound port 25 traffic is also blocked except from the MTA. I'm glad someone finally posted the above. When I came 'up through the ranks' the policy could be explained simply, by separating POP3 and SMTP. The following is the users-perspective explanation I used to offer: - Mail from World to Client is checked via user/password check (POP3 in your mail client). Because its authenticated, it can be done from anywhere - subject to your ISPs policies on the subject. - Mail from Client to World is not authenticated (generally speaking) but what is checked is where you are. The rules: - Mail from ISP-IP to ISP-SMTP-SERVER is accepted regardless of destination. - Mail from anywhere else to ISP-SMTP-SERVER is accepted only if the destination is 'local' to the ISP. - There's no reason to do anything else as a general rule. Privately managed outbound mail solutions (such as a colo, or a corporate network, which subjects you to some other sort of validation before accepting your message) should be 'accountable' and in order to circumvent Port 25 blocking, should be found on other ports anyway. Port 25 traffic should be subject to the above. (I realise this doesnt account for SMTP-Auth. The reality today is that ISPs are blocking Port 25 to reduce spam from drones and that people should be prepared to work around this.) So in terms of the OP, I don't see why joe-user on a dynamic-IP home connection should need the ability to use port 25 to talk to anywhere but their local ISP SMTP server on a normal basis[1]. Theyre not doing MX lookups so theyre not going direct to remote MTAs[2]. Regardless of where they got the mail _from_, the outbound mail should be via SMTP to their local SMTP server.[3] If you separate inbound (pop3) and outbound (smtp) mail delivery in your thinking you can start to make sense of things (from a users perspective). This is always the tack i've taken when trying to educate users about why their email outbound doesn't work when theyre moving from ISP to ISP. (At which point you offer them your authenticated-another-way service, such as 587 with SMTP auth). [1] Customers with a specific need to do so should have the means to opt-out. I believe most of the ISPs in NZ who block 25-outbound from clients also offer this option. [2] Customers doing MX lookups are either drones or people with mail servers at home. The former are obviously the target of the block. The latter are likely going to be any one of: - Blocked by SORBS or similar as a dynamic IP - Running a mail server in breach of AUP - On a fixed IP and (theoretically) capable of securing their system and not being a drone or open mail relay (and being traceable via their ISP). [3] Note also [2]. Outbound mail is associated with your ISP and their SMTP service. Has nothing to do with inbound mail. Nothing. Nada. Zip. Or doesn't the rest of the world think like this? Mark. PS: It occurs to me that SPF has an influence here, if you're aggressively using it then you should also be offering alternatives to Port 25 SMTP. IMHO.
BCP blocking list for edge networks? (was: ingress SMTP)
Ok, mine is actualy even edgier than that; no transit at all, to paraphrase Steeley Dan. But does anyone have a pointer to a good set of ports to block in each direction through my Shorewall DNAT setup, preferably annotated? On reflection, that's actually only outbound; the necessity to set up inbound DNAT manually makes it a default-deny environment, which is one of the reasons that some people like NAT as a component of an edge firewall. Cheers, -- jra -- Jay R. Ashworth Baylink [EMAIL PROTECTED] Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin)
RE: ingress SMTP
iiNet a reasonably sized Aussie ISP has a web page (specifially part of the 'My Account' page) where you can, with a simple check box, choose to have commonly abused ports blocked *for outgoing connections* or not. That's great, and an excellent solution. Unfortunately many of the larger providers here in the United States are not as enlightened from my experience. Of course, YMMV. -Justin Scott
ingress SMTP
Hmm.. if it helps - here's a link to an archived discussion on the same issue earlier this year. http://www.mail-archive.com/[EMAIL PROTECTED]/msg52598.html -- Ang Kah Yik (bangky) -- http://blog.bangky.net
Re: ingress SMTP
you just found one? i think a few dozen over the last several years. surprised though, i thought this particular horse was finally dead after all the beatings it'd received. srs On Thu, Sep 4, 2008 at 8:13 AM, Ang Kah Yik [EMAIL PROTECTED] wrote: Hmm.. if it helps - here's a link to an archived discussion on the same issue earlier this year. http://www.mail-archive.com/[EMAIL PROTECTED]/msg52598.html
Re: ingress SMTP
Nah. There have been plenty. This just happened to be one of the recent ones. But as you've rightly pointed out, the dead horse magically revives itself every once in a while ;) On Thu, Sep 4, 2008 at 10:51 AM, Suresh Ramasubramanian [EMAIL PROTECTED] wrote: you just found one? i think a few dozen over the last several years. surprised though, i thought this particular horse was finally dead after all the beatings it'd received. srs On Thu, Sep 4, 2008 at 8:13 AM, Ang Kah Yik [EMAIL PROTECTED] wrote: Hmm.. if it helps - here's a link to an archived discussion on the same issue earlier this year. http://www.mail-archive.com/[EMAIL PROTECTED]/msg52598.html -- Ang Kah Yik
RE: Why not go after bots? (was: ingress SMTP)
If the service providers spent as much resources implementing systems that automatically erected a walled-garden for botted hosts as they have with bandwidth monitoring, our internet would look at lot cleaner. But apparently the money trail didn't lead them there. Frank -Original Message- From: Suresh Ramasubramanian [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 10:09 PM To: Michael Thomas Cc: nanog@nanog.org Subject: Re: Why not go after bots? (was: ingress SMTP) On Wed, Sep 3, 2008 at 5:12 AM, Michael Thomas [EMAIL PROTECTED] wrote: That seems to be the convention wisdom, but the science experiment as it were in blocking port 25 doesn't seem to be correlated (must less causated) with any drop in the spam rate. Because so far as I've heard there isn't any such drop. Spammers and the rest are pretty resourceful. Let's put it this way .. a lot of ISPs have already realized that which is why port 25 blocking or management is the basics. They do that and have done that for years (and various providers elsewhere still proudly claim hey, we do outbound port 25 blocking, we're great!!!). The real action is in walled gardens to automatically detect and isolate botted hosts till they're cleaned up Go talk to arbor, sandvine, perftech etc etc srs
RE: ingress SMTP
If you leave port 587 un-authenticated then spammers just need to move their spambots to try port 587 *and* you're never sure who sent the message. If you're going to have the customer click a few extra buttons to get to port 587, might as well get them to authenticate. Authenticating port 587 is not the silver bullet, but it buys you a little bit. Frank -Original Message- From: Keith Medcalf [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 7:34 PM To: nanog@nanog.org Subject: ingress SMTP On Wed, Sep 03, 2008 at 12:58:53PM -0400, Nicholas Suan wrote: On Sep 3, 2008, at 12:49 PM, Jay R. Ashworth wrote: You're forgetting that 587 *is authenticated, always*. I'm not sure how that makes much of a difference since the usual spam vector is malware that has (almost) complete control of the machine in the first place. Well, that depends on MUA design, of course, but it's just been pointed out to me that the RFC says MAY, not MUST. Oops. Does anyone bother to run an MSA on 587 and *not* require authentication? Raises hand. Why would the requirements for authentication be different depending on the port used to connect to the MTA? No matter how a session comes into the MTA (port 25, 465, 587, anything else) and no matter whether it is encrypted or not, the requirement for authentication (which is always available and advertized), is based on a simple policy: - local delivery originating from a non-blacklisted or internal/customer address does not require authentication; - relay from internal/customer IP Addresses does not require authentication; - any connection from a blacklisted IP requires authentication or no mail will be accepted; - relay from external/non-customer IP Addresses requires authentication; Is there a valid reason why a different configuration is justified? As an aside, outbound port 25 traffic is also blocked except from the MTA.
