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
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).
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
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" 
Adi,
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/
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
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.
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*"?
*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.
> > 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.
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.
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
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.
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
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
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?
Folks,
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.
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/