Hello all,
At our ISP operation, we are seeing increasing levels of traffic in our
outgoing MTA's, presumably due to spammers abusing some of our subscribers'
accounts. In fact, we are seeing connections from IPs outside of our network
as many as ten times of that from inside IPs. Probably all of our customers
are travelling abroad and sending back a lot of postcards, but just in
case... 
So we are considering ways to further filter this traffic. We are evaluating
implementation of MSA through port 587. However, we never did this and would
like to know of others more knowledgeable of their experiences. The question
is what best practices and stories do you guys have to share in this regard.
Also please let me know if you need additional detail.
thanks in advance,
cl.
Depending on what level of pain you want to inflict on your roaming users:
1) Require them to smtp auth to your server when sending mail
2) Require them to use the local SMTP of the server they are connected to,
and do not allow remote relay at all.
3) Require them to send mail via a webmail interface when they are not on
your local network
I would not think that using port 587 is going to work in many cases, such
as from Hotel wireless networks.
We have had very good luck with using port 587 and requiring the users
to authenticate to send email from outside our network.
Inside customers, we have not changed to force port 587 and
authentication for email clients, but the topic has come up in
discussions. This won't of course, stop spammers if they are hijacking
the users local email client settings.
-Mike
Hello all,
At our ISP operation, we are seeing increasing levels of traffic in our
outgoing MTA's, presumably due to spammers abusing some of our subscribers'
accounts. In fact, we are seeing connections from IPs outside of our network
as many as ten times of that from inside IPs. Probably all of our customers
are travelling abroad and sending back a lot of postcards, but just in
case...
So we are considering ways to further filter this traffic. We are evaluating
implementation of MSA through port 587. However, we never did this and would
like to know of others more knowledgeable of their experiences. The question
is what best practices and stories do you guys have to share in this regard.
Also please let me know if you need additional detail.
Depending on what level of pain you want to inflict on your roaming users:
1) Require them to smtp auth to your server when sending mail
SMTP AUTH on port 587, preferably with SSL/TLS.
2) Require them to use the local SMTP of the server they are connected to,
and do not allow remote relay at all.
Good way to not have customers.
3) Require them to send mail via a webmail interface when they are not on
your local network
I would not think that using port 587 is going to work in many cases, such
as from Hotel wireless networks.
Port 587 connectivity has survived almost every public access and hotel access system I've ever tried. Port 25 is often blocked or hijacked.
Hello all,
Hello Claudio,
At our ISP operation, we are seeing increasing levels of traffic in our
outgoing MTA's, presumably due to spammers abusing some of our subscribers'
accounts. In fact, we are seeing connections from IPs outside of our network
as many as ten times of that from inside IPs. Probably all of our customers
are travelling abroad and sending back a lot of postcards, but just in
case...
I presume you use SMTP-authentication ? That way it's easy to see what users
are sending a lot of mail (or more then usual).
So we are considering ways to further filter this traffic. We are evaluating
implementation of MSA through port 587. However, we never did this and would
like to know of others more knowledgeable of their experiences. The question
is what best practices and stories do you guys have to share in this regard.
Also please let me know if you need additional detail.
We added SSL to our SMTP-service and tell our customers to use SSL (not TLS)
with authentication and have the mailserver listen on the TCP-ports which
the mailclients pick for that (of which their are a few if I'm not mistaken).
We've found having to tell clients port-numbers sounds complicated and technical,
but telling people to use encryption sounds like a good service and in most
cases it just works (we ask the name of the e-mail client before we give
them any settings). Also because port 25 is blocked in a lot of places,
when people travel with laptops.
The mailservers log the IP-adress and username from the authentication,
that will hopefully allow us to easily play whack-a-mole when confronted
with the problem you might be having.
We have had very good luck with using port 587 and requiring the users
to authenticate to send email from outside our network.
Inside customers, we have not changed to force port 587 and
authentication for email clients, but the topic has come up in
discussions. This won't of course, stop spammers if they are hijacking
the users local email client settings.
It does however help find the user more easily (if the mailserver logs the username),
you can even automate sending an email to them and block them from sending any further
email (with exception to support-staff for example).
Inside customers, we have not changed to force port 587 and
authentication for email clients, but the topic has come up in
discussions. This won't of course, stop spammers if they are hijacking
the users local email client settings.
How best would you stop spammers hijacking local users email clients
-Mike
A discussion on this topic is happening on spam-l at the moment; it's
probably worth your time to subscribe to that list and read it, doubly
so since it's not really appropriate for nanog.
---Rsk
Assuming that you by SSL refer to a "raw" SSL-wrapped SMTP connection and with TLS refer to STARTTLS as described in RFC 3207, I would recommend against using "raw" SSL-wrapped SMTP.
Although there are some email clients that do this (and they usually use the unregistered port 465 for this), setting this up with Message Submission for Mail (as described in RFC 4409) and STARTTLS will likely give your customers a more joyful experience thanks to reasonable defaults in most modern email clients.
  jakob
RFC 5068, Email Submission Operations: Access and Accountability Requirements, is a BCP. It specifies authenticated port 587 for email submission across the net.
As others have noted, it works well through a wide variety of access environments. I don't remember the last time I found it blocked. I use it over TLS, of course.
Blocking of outbound port 25 for all hosts not explicitly authorized has become common. The fact that 587 default to authenticated is the win.
d/
Consider also smtps port which should be treated like smtp port and not like submission port, or simply do not listen on smtps as TLS is available on smtp port via esmtp.
A lot of providers are now blocking smtp traffic from dynamic/residential IPs, and all clients support to enter submission port instead of smtp port. The advantage of this config, when you have a roaming user, they don't need to configure their email client depending on the network they are connecting to.
If you want to see the extend of the problem on your network just go to http://www.uceprotect.net/en/rblcheck.php and enter your AS/network and see how many of your clients are spamming due to mainly botnets.
Log and monitor all that you can. And watch for a large number of IPs
logging into an account over a day (over a set limit - even across
country - that takes into account "home - blackberry - airport lounge
- airport lounge in another country - hotel - RIPE meeting venue"
type scenarios).
And especially watch for and/or firewall off logins from areas from
where you see particularly high levels of smtp auth abuse / logins to
compromised accounts
--srs
If you have left port 25 open, this is a good place to start.
http://www.uceprotect.net/en/rblcheck.php
I suspect any decent IDS will tell you which machine has weird traffic. I suppose you can put rules based on the IDS result to redirect them to a special web page to tell them, they have to do something.
The main issue, it not to know which machines are hijacked, but to support these machines.
No. UCEProtect is certainly not a decent or any other kind of place to start.
The MAAWG BCPs have far more available than one of the worst
maintained blacklists that has ever been in existence.
If you want FAQs from blocklists - there is much that's available on
the spamhaus.org website