SMTP authentication for broadband providers
Greetings, We're a medium sized regional MSO/broadband provider with 200k+ mailboxes, strongly considering enabling SMTP authentication on our customer-facing SMTP mail servers. We feel this is the next logical step to minimize our users UCE/virus impact (we already tarpit, virus scan, UCE scan, subscribe to RBL's, reject prior to SMTP close). I'm looking for comments on whether this is generally seen as a positive change or a waste of time (ie - will the next virus or worm gleam your SMTP username and password from Outlook Express and use it to replicate/SPAM)? Is anyone aware of any well known mail clients that do not support SMTP authentication (Unix, Windows or Mac)? Thanks in advance. --Dan -- Daniel Ellis, CTO, PenTeleData (610)826-9293 "The only way to predict the future is to invent it." --Alan Kay
On Tue, Feb 10, 2004 at 08:42:29PM -0500, Dan Ellis wrote:
I'm looking for comments on whether this is generally seen as a positive change or a waste of time (ie - will the next virus or worm gleam your SMTP username and password from Outlook Express and use it to replicate/SPAM)?
I've only seen one virus or worm so far that has done this (we are a hosting provider, so any users who use our mail servers are using SMTP authentication).
Is anyone aware of any well known mail clients that do not support SMTP authentication (Unix, Windows or Mac)?
Not many of the major ones. There are some differences in the authentication methods supported, however - many don't support methods other than LOGIN and / or PLAIN. There are also (surprise) some client-specific bugs with various mailers... Lookout Distress (version 4) for example, has some problems; see the "broken_sasl_auth_clients" config directive if you're using Postfix (google for that string to find out more information about this particular problem). -- "Since when is skepticism un-American? Dissent's not treason but they talk like it's the same..." (Sleater-Kinney - "Combat Rock")
We're a medium sized regional MSO/broadband provider with 200k+ mailboxes, strongly considering enabling SMTP authentication on our customer-facing SMTP mail servers.
We're relying exclusively on SMTP AUTH for SMTP relaying. The single biggest issue is that it requires ongoing user education. After a few weeks people forget what they did do get rid of the "Relaying denied" error message. It doesn't help that SMTP AUTH is not an option the "New Account Wizard" of Outlook and Outlook Express asks for. It has to be setup manually after. For "our" mail users it has been well received, ignoring the support calls. A big advantage is that roaming user no longer have to worry about who ip space they're on. That may change as networks install SMTP blocks. Adi
Adi, AL> We're relying exclusively on SMTP AUTH for SMTP relaying. what about port 25 blocking that is now done by many access providers? this makes it impossible for mobile users, coming from those providers, to access your server and do the auth. d/ -- Dave Crocker <dcrocker-at-brandenburg-dot-com> Brandenburg InternetWorking <www.brandenburg.com> Sunnyvale, CA USA <tel:+1.408.246.8253>
what about port 25 blocking that is now done by many access providers? this makes it impossible for mobile users, coming from those providers, to access your server and do the auth.
amb@cinephile:~$ fgrep submission /etc/services submission 587/tcp # submission amb@cinephile:~$ fgrep ssmtp /etc/services ssmtp 465/tcp smtps # SMTP over SSL Alex
On Wed, 11 Feb 2004 Valdis.Kletnieks@vt.edu wrote:
On Wed, 11 Feb 2004 11:15:20 PST, Dave Crocker said:
what about port 25 blocking that is now done by many access providers? this makes it impossible for mobile users, coming from those providers, to access your server and do the auth.
Port 587.
So is it time for ISPs to start blocking port 587 too? If the complaints are going back to the IP address anwyay, why shouldn't an ISP force it subscribers to go through the ISPs mail servers so it can control any messages sent by its subscribers?
On Wed, Feb 11, 2004 at 03:13:30PM -0500, Sean Donelan wrote:
On Wed, 11 Feb 2004 Valdis.Kletnieks@vt.edu wrote:
On Wed, 11 Feb 2004 11:15:20 PST, Dave Crocker said:
what about port 25 blocking that is now done by many access providers? this makes it impossible for mobile users, coming from those providers, to access your server and do the auth.
Port 587.
So is it time for ISPs to start blocking port 587 too?
If the complaints are going back to the IP address anwyay, why shouldn't an ISP force it subscribers to go through the ISPs mail servers so it can control any messages sent by its subscribers?
My understanding is that in most cases, providers are blocking port 25 outbound to prevent direct to MX spamming from their customers' machines - not to prevent customers from sending mail through other providers' mail servers. Unless they're specifically trying to force people to use their mail servers (which I don't think is usually the case), they don't need to block port 587. -- "Since when is skepticism un-American? Dissent's not treason but they talk like it's the same..." (Sleater-Kinney - "Combat Rock")
Will Yardley wrote:
My understanding is that in most cases, providers are blocking port 25 outbound to prevent direct to MX spamming from their customers' machines
If you do that, please put in a corresponding ACL to block port 25 inbound _and_ outbound. Otherwise, you just might get bitten by something like spoofed source routing, as several providers have found out in the past. srs
On Wed, 11 Feb 2004 15:13:30 EST, Sean Donelan said:
So is it time for ISPs to start blocking port 587 too?
RFC2476 says: 3.2. Message Rejection and Bouncing MTAs and MSAs MAY implement message rejection rules that rely in part on whether the message is a submission or a relay. For example, some sites might configure their MTA to reject all RCPT TOs for messages that do not reference local users, and configure their MSA to reject all message submissions that do not come from authorized users, based on IP address, or authenticated identity. Is there any indication that there are enough sites *NOT* doing some sort of authentication check on accepting messages on port 587 that it's worth the effort of blocking? Or should we just say "Submit mail via webmail, let's see the ISP block *THAT*"?
On Wed, 11 Feb 2004 Valdis.Kletnieks@vt.edu wrote:
Or should we just say "Submit mail via webmail, let's see the ISP block *THAT*"?
*THAT* has been suggested, and there are vendors trying to sell boxes to ISPs that would allow them to block mail submission via webmail (or wiretap mail submission via webmail depending on your NSA/FBI requirements). They are actually very nice boxes. If you were a conspiracy nut, you might think the reason why FBI and law enforcement take very little action against spammers is because the FBI likes spam. Spam is a useful tool to force ISPs to implement more tools in their network to identify and trace traffic for spam fighting. The same tools are readily adaptable. If we want a Fortune 1000 network, the vendors are more than willing to sell us all the boxes we need to implement it.
At 03:13 PM 2/11/2004, Sean Donelan wrote:
On Wed, 11 Feb 2004 Valdis.Kletnieks@vt.edu wrote:
On Wed, 11 Feb 2004 11:15:20 PST, Dave Crocker said:
what about port 25 blocking that is now done by many access providers? this makes it impossible for mobile users, coming from those providers, to access your server and do the auth.
Port 587.
So is it time for ISPs to start blocking port 587 too?
Why, to restrain trade? To forbid people from using AUTHENTICATED services of their mail provider of choice? Why shouldn't users be able to hire an Email service provider who might have a LOT more clue about how to run email services than the broadband vendor they happen to buy a circuit through? Please read the RFC 2476, the Standards Track document on the Submission protocol. Read especially section 3.3. While reading the document you will notice that at the time it did not require authentication (it's a MAY) but I think you'd find most deployment of Submission does use authentication of one sort or another.
If the complaints are going back to the IP address anwyay, why shouldn't an ISP force it subscribers to go through the ISPs mail servers so it can control any messages sent by its subscribers?
Are the complaints going back to the ISP? Or are they going to the email services provider who authenticated the user? (read the headers on emails and you'll see there is a notation regarding the authentication). People spent the time and effort to build a solution to the issue of port 25 being largely open and unauthenticated. That solution is the SUBMISSION protocol. Many companies heavily use this mechanism to offer premium services to end users.
On Wed, 11 Feb 2004, Daniel Senie wrote:
Why, to restrain trade? To forbid people from using AUTHENTICATED services of their mail provider of choice? Why shouldn't users be able to hire an Email service provider who might have a LOT more clue about how to run email services than the broadband vendor they happen to buy a circuit through?
Why should ISPs block port 25, 135, 445, or any of the other hundreds of ports people regularly say ISPs should block? I think some broadband vendors would be happy to provide the pipe, and not block any ports. Unfortunately a lot of very vocal people regular assert it is the *ISP's* responsibility and duty to monitor and control what its subscribers do on the network. If you are going to hold the ISP accountable, then expect the ISP to want to exert some control.
Are the complaints going back to the ISP? Or are they going to the email services provider who authenticated the user? (read the headers on emails and you'll see there is a notation regarding the authentication).
As anyone who has ever worked an abuse desk can tell you, the complaints go back to *EVERYONE* possibly related to (and sometimes not related to) any aspect of whatever the complaintant doesn't like.
People spent the time and effort to build a solution to the issue of port 25 being largely open and unauthenticated. That solution is the SUBMISSION protocol. Many companies heavily use this mechanism to offer premium services to end users.
And I applaud your effort. But does it really answer the question of who is responsible for handling abuse of the service? If ISP's are not responsible for abuse using port 573, they probably don't care. If the activists are going to continue to attack ISPs anyway, then expect the ISP to want to respond by implementing controls regardless of what port is used. The AOL model of subscriber control is very tempting. What reasons does an ISP have for not controlling what their subscribers can do.
--On 11 February 2004 16:30 -0500 Sean Donelan <sean@donelan.com> wrote:
And I applaud your effort. But does it really answer the question of who is responsible for handling abuse of the service? If ISP's are not responsible for abuse using port 573, they probably don't care.
I think you are missing the point. I have lots of people abusing my port 25. They can abuse this due to the nature of the (current unadorned) SMTP protocol as I have to leave it open and unauthenticated in order to receive mail to users served by my server. I can quite see why their DSL provider wants to block their connecting to my port 25, and (incidentally) other customers of theirs get caught in the collateral damage. On the other hand, I have noone even trying to abuse port 587 (sic) i.e. submission. Even if people tried, they'd find they needed authentication on that port (even to send to my local users). As I am doing nothing beyond a dumb RFC implementation, and assuming other mail hosts are no dumber, ISPs thus won't get abuse complaints for port 587 attacks in the same way they get port 25 complaints. Of course they'll get *some* port 587 complaints, just like they get some port 80 complaints. But blocking port 25 blocks access to a well known poorly authenticated service. Blocking port 587 doesn't (or rather wouldn't). If there were a whole pile of people accepting unauthenticated connections on port 587, life would be different. But there aren't & it isn't. Alex
On Wed, 11 Feb 2004, Alex Bligh wrote:
I think you are missing the point. I have lots of people abusing my port 25. They can abuse this due to the nature of the (current unadorned) SMTP protocol as I have to leave it open and unauthenticated in order to receive mail to users served by my server.
The bulk of the abuse (some people estimate 2/3's) is due to compromised computers. The owner of the computer doesn't know it is doing it. Unfortunately, once the computer is compromised any information on that computer is also compromised, including any SMTP authorization information. SMTP Auth is not the silver bullet to solve the spam problem. As it becomes more widely deployed, it will become less effective. It only appears to work now because SMTP AUTH is still a bit of a niche. Nevertheless SMTP AUTH is already being abused, and I expect complaints about users using plain smtp and smtp auth to eventually be equal. Right now SMTP AUTH is a bit more useful because the mailer can directly identify the compromised subscriber. But I expect this to also be short-lived. Eventually the compromised computers will start passing authentication information. But it seems like people latch on to the "shiny new thing." I think MUA-to-MTA authentication for submission as well as collection is a good thing. Its been developed several times already, and maybe this time it has the right features to catch on. But it will not solve either spam nor abuse.
--On 11 February 2004 19:45 -0500 Sean Donelan <sean@donelan.com> wrote:
The bulk of the abuse (some people estimate 2/3's) is due to compromised computers. The owner of the computer doesn't know it is doing it. Unfortunately, once the computer is compromised any information on that computer is also compromised, including any SMTP authorization information.
SMTP Auth is not the silver bullet to solve the spam problem. ... Right now SMTP AUTH is a bit more useful because the mailer can directly identify the compromised subscriber. But I expect this to also be short-lived. Eventually the compromised computers will start passing authentication information.
Sure it's not a silver bullet. I think we ran out of silver bullets years ago. But it gives you a lot more useful information that the IP address (not much use with NAT etc.). As someone spake earlier who appeared to have actually done it, you can then rate-limit by individual users, disable individual users etc. - that's *far* harder on non-authenticated dynamic SMTP. Once someone has comprimised a machine & stolen authentication tokens you are (arguably) fighting a different battle anyway. A comprimised machine could HTTP post spam to hotmail/yahoo etc. if it wanted to - the problem is then protocol independent. My original point was that port 25 blocking by ISPs does not stop mobile users using SMTP AUTH, and the reasons for ISPs blocking port 25 are not likely to be extended to smtps / submission. Not that the latter two protocols would solve all spam tomorrow. Alex
Folks, SD> SMTP Auth is not the silver bullet to solve the spam problem. As it SD> becomes more widely deployed, it will become less effective. It only SD> appears to work now because SMTP AUTH is still a bit of a niche. The problem is that this puts it into the category of being an arms race response. It keeps the game escalating. There are real costs for pursuing each interim step that provides only a partial benefit. Costs in effort. Costs in public expectations that quickly get frustrated. And so far, none of these partial steps has reduced the global amount of spam. It is well and good for the technical community to argue that we are shepherding spammers into tighters circles where will (finally) be able to control them. The only problem is that they are returning the favor. We have zero success engineering the behavior of abusers of the net, so why does anyone think our shepherding efforts have any chance of succeeding? To attack spam, we need to attack it at its core, not at some secondary or tertiary side-effect, with a mechanism that also hurt legitimate users. So, what, exactly, _is_ that core? Unless and until there is broad community consensus that answers that question in concrete and practical terms, then all our efforts are losing and stop-gap. d/ -- Dave Crocker <dcrocker-at-brandenburg-dot-com> Brandenburg InternetWorking <www.brandenburg.com> Sunnyvale, CA USA <tel:+1.408.246.8253>
On Wed, Feb 11, 2004 at 03:13:30PM -0500, Sean Donelan wrote:
On Wed, 11 Feb 2004 Valdis.Kletnieks@vt.edu wrote:
On Wed, 11 Feb 2004 11:15:20 PST, Dave Crocker said:
what about port 25 blocking that is now done by many access providers? this makes it impossible for mobile users, coming from those providers, to access your server and do the auth.
Port 587.
So is it time for ISPs to start blocking port 587 too?
If the complaints are going back to the IP address anwyay, why shouldn't an ISP force it subscribers to go through the ISPs mail servers so it can control any messages sent by its subscribers?
Because, maybe, I don't think it is a good idea for someone else to CONTROL any messages I might send. Who will control the controllers? -- -=[L]=-
Is anyone aware of any well known mail clients that do not support SMTP authentication (Unix, Windows or Mac)?
I'm not an ISP, but I know some users here who have wireless Internet on their mobile phones have complained in the past they can't send e-mail if you have SMTP AUTH only (as opposed to POP before SMTP). Not sure if it'd be an issue for you, but it's something I ran into. My basic response was "tough" :) -- Jason McCormick jason@devrandom.org GPG Key: http://www.devrandom.org/gpgkey.php GPG Fingerprint: 66C5 2B15 3E34 2B5E 5321 6147 303A DCE6 0A74 A19C
participants (12)
-
Adi Linden -
Alex Bligh -
Dan Ellis -
Daniel Senie -
Dave Crocker -
Dave Crocker -
Jason McCormick -
Lou Katz -
Sean Donelan -
Suresh Ramasubramanian -
Valdis.Kletnieks＠vt.edu -
Will Yardley