RE: Why do so few mail providers support Port 587?
Hi Folks, It's time to take this thread to SPAM-L or some other spam oriented list. Thanks in advance, -M -- Martin Hannigan (c) 617-388-2663 VeriSign, Inc. (w) 703-948-7018 Network Engineer IV Operations Infrastructure [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of just me Sent: Friday, February 25, 2005 5:26 PM To: Frank Louwers Cc: nanog@merit.edu Subject: Re: Why do so few mail providers support Port 587? On Fri, 25 Feb 2005, Frank Louwers wrote: The trick is to config port 587 in such a way that it ONLY accepts smtp-auth mail, not regular smtp. That way, virii/spam junk won't be able to use that port. What are you, stupid? The spammers have drone armies of machines with completely compromised operating systems. What makes you think that their mail credentials will be hard to obtain? matt ghali [EMAIL PROTECTED]darwin The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
Re: Why do so few mail providers support Port 587?
[Note reply-to] On Fri, Feb 25, 2005 at 02:45:40PM -0500, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: On Fri, 25 Feb 2005 12:56:50 EST, [EMAIL PROTECTED] said: Sorry, I misread that. But I still fail to see how 587 changes that. [snip] Yes. Authenticated SMTP makes tracking down which of your users is doing the spamming easier. But you're assuming that SMTP AUTH isn't being used on port 25 already. You can do SMTP AUTH just as easily on [snip] You do not authenticate every transaction on 25, else you wouldn't be getting any smtp from the real world. The point is that you can trivially sort must be authenticated vs is unknown as opposed to inspecting messages on dunno if might be anything port. Reducing the problem space is always a Good Thing. The real funny thing is that o started to write back to the earlier incarnation of this thread. Pasted below because it still applies. I'd rephrase Sean's question as 'why do so few SMALL mail providers [...]'. Bluntly, if AOL/etc can do it with their customer base then the 'bad' laziness is the only reason not to do so, or to rgue against those who wish to do so. On Tue, Feb 15, 2005 at 09:00:11PM -0500, Sean Donelan wrote: [snip] Seans rhetorical subject line was answered quite adequately by the rampant ignorance in the knee-jerk responses of those who have obviously not read the RFC in its many years of availability, thought about the consequences, nor been down the road of implementation. Rather than armchair nattering, come to the discussion prepared or sit on the sidelines and observe. If you haven't done your homework, you are Not Tall Enough To Ride This Ride and go to the queue for the spinning teacups. The beauty of what we've all been building for all these years is it is all documented; given a brain and desire you can go from clueless to clueful purely through self-educating. If you are expecting to be spood-fed then please return to the flow charts and MOPs of vendor certifications. Questions regarding the spec, document, implementations thereof are useful and have popped up, but in general there's a really sad trend of uninformed chattering. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: Why do so few mail providers support Port 587?
Date: Thu, 24 Feb 2005 16:08:42 -0500 From: Nils Ketelsen [EMAIL PROTECTED] To: nanog@merit.edu Subject: Re: Why do so few mail providers support Port 587? On Tue, Feb 15, 2005 at 09:00:11PM -0500, Sean Donelan wrote: [ ... ] What can be done to encourage universities and other mail providers with large roaming user populations to support RFC2476/Port 587? Give a good reason. That is still the missing part. From a security stance (well - partly ;D) I always like to emphasize that in The Real World port 25 is for traffic between MTA's *and* submission of mails to the local MTA. So to reduce the chance of one of my users abusing an Open Relay and to enforce corporate e-mail policies, only port 25 towards our mailserver is open. Port 587 on the other hand is meant for submission by clients. The security implications of allowing my users to contact such a port are very very low. If someone won't secure his mailserver on port 587, that's something different, but substantially different than if it were insecure on port 25... Now if you turn that around, you see why we opted to support SMTP Auth on port 587 and have left our legacy mailhub running on port 25 ;) I have users roaming around the world - on company business. And my users also entertain the same kind of roaming users. Now, if I want to have my users be able to connect to my mailserver on port 587 from anywhere in the world, I should also allow guests over here to do the same to their mailserver on port 587. It works both ways after all ;) Nils Kind regards, JP Velders
Re: E1 - RJ45 pinout with ethernet crossover cable
In article [EMAIL PROTECTED], Miquel van Smoorenburg [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Sam Stickland [EMAIL PROTECTED] wrote: Quick question: If I have two E1 ports (RJ45), then will running a straight ethernet cable between the two ports have the same affect as plugging a ballan into each port and using a pair of coax (over a v. short distance). Likewise would using an ethernet crossover cable have the same affect as swapping the pairs round on one balland. Or are the pinouts different to ethernet? I tried googling but couldn't find anything (perhaps because I can't seem to spell ballan :/ ). The pinouts are different. It's easy to make your own E1 crosscable though. E1 uses pairs 4-5 and 3-6, just swap those. 4-5 3-6 3-6 4-5 I wrote this from memory, and I got it wrong. Sorry. It's not 4/5 and 3/6, but 1/2 and 4/5 (as others undoubtedly will point out). Mike.
Re: Internet Email Services Association ( wasRE: Why do so few mail providers support Port 587?)
On Fri, 25 Feb 2005 [EMAIL PROTECTED] wrote: I'll agree with you on one thing, though -- the whole business of port 587 is a bit silly overall...why can't the same authentication schemes being bandied about for 587 be applied to 25, thus negating the need for another port just for mail injection? Because that would require providers to act like professionals I don't see what the big deal is. mx.justthe.net, for instance, requires SMTP AUTH on port 587 for everyone and requires SMTP AUTH on port 25 for anyone attempting to relay mail outside my network. The biggest cost I can see, and it *is* a significant cost, is walking users through the process of configuring their MUAs to do the authentication. Configuring the servers, however, shouldn't be a huge problem, and you can mitigate the cost issue by only setting up 587 for people who need to have it set up. -- JustThe.net - Apple Valley, CA - http://JustThe.net/ - 888.480.4NET (4638) Steven J. Sobol, Geek In Charge / [EMAIL PROTECTED] / PGP: 0xE3AE35ED In case anyone was wondering, that big glowing globe above the Victor Valley is the sun. -Victorville _Daily Press_ on the unusually large amount of rain the Southland has gotten this winter (January 12th, 2005)
Re: AOL scomp
On Fri, Feb 25, 2005 at 01:34:21AM -0600, Robert Bonomi wrote: Because the recipient *expressly* requested that all mail which would reach my inbox on your system be sent to me at AOL (or any other somewhere else). I have three somewhat-overlapping responses to that -- and I'll try to stay focused on operational issues, since this is NANOG, not Spam-L. (But if you to delve further into this, I would suggest shifting the discussion there, as it's probably more appropriate.) 1. SMTP spam is not mail. Oh, it may *look* like mail, it may arrive on the same port, and it may use the same protocol, but it's not mail. It's abuse. There's no reason to forward it to anybody. There's no reason to even accept it in the first place. Heck, there's no reason to even _emit_ it in the first place. Which (not emitting it) is what everyone should be trying to do, but few are. It seems to have somehow escaped the notice of many that spam/abuse doesn't fall out of the sky: it comes from systems. Those systems are on networks. Those networks are run by people. Those people are personally responsible for the spam/abuse that their networks emit. It's thus their responsibility to make it stop. But their failure to properly discharge that responsibility is why we have a major problem, or actually, several major problems, instead of a minor annoyance. [ Let's have a moment of nostalgia for the time when allowing this to happen day after day would not happened because the plug would have been unceremoniously pulled after the first 24 hours. It's illuminating how quickly unsolvable problems are at least patched to an acceptable degree when connectivity is at stake. ] 2. Mail delivery requires permission of all of: - the network operator - the system operator - the mail subsystem operator - the end user (who of course are sometimes all the same person/people). For instance, the end user may grant permission for someone to send 500M video clips attached to mail messages, but if the mail subsystem operator has limited mail message sizes to 10M, then permission is denied and the mail message is turned away. As another example, if the end user has granted permission for 5000 messages/second, but the network operator has capped bandwidth at a level below that required to transmit those messages, permission will be denied. What I'm trying to say is that merely having the permission of the end user to send something isn't enough: one also has to have permission from the authorities involved in providing the service, and their permission may be conditional on certain requirements enforced by automated agents, e.g., you will only be given permission if your message is = 10M or you will only be given permission if your message does not contain a live virus. Or you will only be given permission if your message isn't spam, or you will only be given permission if your message isn't coming from a domain/system/network known to emit prodigious quantities of spam. I see no reason for any of those four people to grant permission to receive or forward spam *except* for those very few conducting research in the area (similarly for viruses), and those people aren't going to want it via a forwarder anyway. So while the end user on some remote system may have in fact said send me everything, including the spam (although this seems very unlikely) this does not constitute permission to do so, because that user isn't the only party involved, and their permission alone is insufficient. (logical AND required, not logical OR) And I doubt very much that the others will give their consent. 3. Dealing properly with forwarded spam which is rejected by the destination is tough: generating bounces will make the generator a spammer-by-proxy, and that's obviously unacceptable. A much better course of action is to try to reject as much spam as possible -- rather than accepting it, trying to forward it, and then bouncing it (thereby spamming innocent third parties, and self-nominating for inclusion in various blacklists). Bottom line: deliberately forwarding spam makes you a spammer. Don't do it. If a user, for some bizarre reason, insists: don't do it. Tell them to find an irresponsible, spam-supporting ISP to do it for them -- there are certainly plenty of those around to choose from. This means that every such message from the 'forwarding' system to the destination system is, BY DEFINITON, solicited. The mailbox owner has expressly and explicictly requested those messages be sent to him at the receiving system. This is a definition of solicited which is wholly at odds with that in common practice for the last few decades. By your definition, the victim of a mailbombing attack would have somehow solicited that abuse merely because they have a forwarding alias on your system. I'm not having any. UBE (the proper definition of SMTP spam) doesn't magically become not-UBE just because it gets
Re: AOL scomp
From [EMAIL PROTECTED] Sat Feb 26 13:42:19 2005 Date: Sat, 26 Feb 2005 10:27:40 -0500 From: Rich Kulawiec [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: AOL scomp On Fri, Feb 25, 2005 at 01:34:21AM -0600, Robert Bonomi wrote: Because the recipient *expressly* requested that all mail which would reach my inbox on your system be sent to me at AOL (or any other somewhere else). I have three somewhat-overlapping responses to that -- and I'll try to stay focused on operational issues, since this is NANOG, not Spam-L. (But if you to delve further into this, I would suggest shifting the discussion there, as it's probably more appropriate.) 1. SMTP spam is not mail. Spam -- it's about _consent_, not *content*. If I, the forwarding system operator have the _consent_ of the mailbox owner on the destination system to forward messages to him, they are *not* spam on _that_ system. This *is* a separaate issue as to whether or not they are spam _on_the_forwarding_system_. Yes, the forwarding system should do everything reasonable to suppress spam from (a) reaching the local inbox *or* (b) being forwarded, if the customer has requested mail forwarding. If the recipient has a problem with receiving the forwarded message, he should complain _to_the_FORWARDING_system_ about it. *NOT* to the destinaiton system. So while the end user on some remote system may have in fact said send me everything, including the spam (although this seems very unlikely) How about various 'spamtrap' mailboxes, auto-forwarded to a central location for further processing? evil grin This means that every such message from the 'forwarding' system to the destination system is, BY DEFINITON, solicited. The mailbox owner has expressly and explicictly requested those messages be sent to him at the receiving system. This is a definition of solicited which is wholly at odds with that in common practice for the last few decades. By your definition, the victim of a mailbombing attack would have somehow solicited that abuse merely because they have a forwarding alias on your system. NOT AT ALL. It *IS* 'unsolicited' on _my_ system. It is *not* unsolicited at the final destination system. Questions/complaints/help-requests should be sent *TO*ME*, not to the destination system. He's *MY* customer, too. I've got an incentive to 'make things right'. I'm not having any. UBE (the proper definition of SMTP spam) doesn't magically become not-UBE just because it gets forwarded by somebody. Suppose my user manually forwards a 'spam' message to an account of his on another system. And then _forgets_ that *he* did it. And reports it to *that* provider as spam coming from my system. Is this _my_ fault? IS spam originating from my system? Should I terminate this user for 'spamming'? It's still spam, and anyone sending/forwarding it is personally responsible for their choice to do so. It's about *consent*, not _content_. Want to try to deny that the recipient _consented_ to the forwarding from his other account? It is _not_ 'unsolicited' (the first word of UBE / UCE) on the destination system. It *may*well* be 'unsolicited' at the system where the customer has the forwarding mailbox. Complaints should be directed to *THAT* system operator, *not* the operator of the destination system. Note: I *agree* that anyone sending/forwarding it is personally responsible fortheri choice to do so. The person that *made* that choice -- to forward that message -- however, is _the_customer_; the 'owner' of mailbox on the 'forwarding' system, *and* the 'owner' of the mailbox on the destination system. If my customer (in his identity on the receiving system) reports my customer (in his identity on _my_ system) as sending spam, should I terminate him from my system? After all, he's identified _himself_ as the spammer. (Yes, I realize that it's not possible to achieve perfection, but that isn't an excuse for failure to keep trying, continuously. It's not difficult to block 90% of spam using simple, free measures that rely entirely on open-source software and freely-accessible data. There's thus no valid excuse for not doing at least that much -- today.) Yup. Keep it from getting to the point it 'would' get to his inbox, and it won't get forwarded, either. But, if it _does_ get through, the recipient should be complaining about it _to_me_, not to the operator of the destination system.
Re: Why do so few mail providers support Port 587?
Paul Vixie wrote: well, in sbc-dsl-land, port 25 and port 587 are blocked, but port 26 gets through. it seems bizarre that port 587 would ever be blocked I suspect that was some kind of temporary aberration. SBC started blocking port 25 in the last two months, and during that time I've helped at least a dozen of our customers using SBC DSL switch their mail program settings from port 25 to port 587, with no trouble -- it worked in every case. I bet it works if you try it again now (as you say, blocking port 587 makes no sense). -- Robert L Mathews
Re: Why do so few mail providers support Port 587?
(as you say, blocking port 587 makes no sense). Let me get this straight... it makes no sense to block a port that will allow unlimited relaying of all sorts of malware by only verifying an easily purchased or stolen username and password? If someone uses a big-ISP network to forward business impacting malware thorough your small-biz email server, using questionably gained 587 credentials, who is going to get sued? Is it safe enough for the big-ISP to say we just route whatever our customer de'jour sends? I am against port blocking as much as the next guy, I just see port 587 as a disaster waiting to happen. ISP provided email credentials are universally transmitted in plain text. If an (insert any ISP here) employee can be arrested for selling email addresses to spammers, what keeps them from collecting and selling 587 credentials? I understand that ISPs are trying to find a roaming solution for your customers. I just want you to find one that is *better* than simple port-587-auth-before-open-relay. For starters I would recommend that 587 access NOT be enabled by default for all users. Let it be by special request, and even then with some teeth involved. -Jim P.
Re: Why do so few mail providers support Port 587?
On Sat, 26 Feb 2005, Jim Popovitch wrote: I am against port blocking as much as the next guy, I just see port 587 as a disaster waiting to happen. ISP provided email credentials are universally transmitted in plain text. If an (insert any ISP here) employee can be arrested for selling email addresses to spammers, what keeps them from collecting and selling 587 credentials? If you limit port 587 sending to let's say 1000 email per day you probably cover 99.9% of all normal users, and you're very likely to catch the spammers abusing an account. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
SMTP Port Blocking: Success or Failure?
We are considering filtering outbound SMTP traffic from our ISP customers, except from our own mail servers, to help reduce the amount of spam originating from our network. How successful/unsucessful has implementing outbound SMTP filtering done in stopping or slowing down spam from your network? Also, if outbound SMTP filtering has not worked for you, are there any other things that you have implemented that have helped with spam traffic? Thanks, = TC -- Tom Claydon, IT/ATM Network Engineer Dobson Telephone Company http://www.dobsonteleco.com
Re: Why do so few mail providers support Port 587?
jm Date: Fri, 25 Feb 2005 15:13:04 -0800 (PST) jm From: just me jm Internal users: With AUTH - correlate message with authenticated user, jm then forbid mail transmission for them only. I'd rather do that than jm slog through RADIUS logs. But, hey, maybe if I had more free time... jm Increasing the detail of an audit trail doesnt mean anyone will jm automatically use the information in an effective manner. Fingerprints and DNA analysis are equally useless, I suppose. jm Without auth, most ISPs could correlate abuse behavior between MTA jm logs and RADIUS logs, if they cared. Most don't. SMTP AUTH won't jm change that. I guess it's probably fallacious to argue from the viewpoint of ISPs caring. Please pardon my Freudian slip. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
RE: Why do so few mail providers support Port 587?
SD Date: Sat, 26 Feb 2005 00:24:16 -0500 (EST) SD From: Sean Donelan SD Sigh, if even the network professionals have difficulty understanding SD how things work, what hope is there for the rest of the users. Funny you should say that. I frequently comment that the average service provider of today is less competent and more apathetic than the average end user of a decade ago. I'd absolutely _love_ to be proven wrong. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: SMTP Port Blocking: Success or Failure?
On Sat, 26 Feb 2005, Claydon, Tom wrote: We are considering filtering outbound SMTP traffic from our ISP customers, except from our own mail servers, to help reduce the amount of spam originating from our network. How successful/unsucessful has implementing outbound SMTP filtering done in stopping or slowing down spam from your network? If you mean on Dial customers this sort of thing has been very helpful, add (as the previous conversations on this have shown, outbound to the dial user filters permitting source port 25 from your mail complex alone as well.
