My apologies for another annoying SMTP thread.
So, while considering enabling SMTPAUTH for all our customers, I’m planning on placing firm policy on relaying. We’re a regional broadband ISP/MSO that also serves a significant number of educational and commercial cable/DSL connections as well as a large number of T1/T3/OC3/Ethernet customers.
That leaves with me needing to define how we will handle 3 situations:
-
Residential (a few dynamic IP computers)
-
Broadband Commercial (Static IP and a few forwarded IP’s, a dozen end user PC’s)
-
Dedicated commercial customers (t1/ds3/Ethernet/oc3)
HISTORY: Old school thought was that as long as you are on an ISP’s IP space, you can use them to relay. This made it easy for roamers as everyone would use the ISP’s mailserver for outbound, and their mailserver for inbound. Yes – there was always a fuzzy line for t1/ds3/oc3 customers because some ISP’s allowed their space to relay and some did not. I’m trying to determine what the “new school” thoughts are.
Below are my thoughts and concerns on each. I’m interested in hearing what others have implemented regarding policy, what the large NSP’s have implemented, and what your thoughts are.
-
Residential Policy: Enable SMTPAUTH and disallow relaying unless the customer has a valid username/password. If you’re not paying for a mailbox, you don’t get to relay outbound. This should not break anything except those residential accounts that should be commercial anyway.
-
Broadband commercial: This is the difficult one. These are the customers that aren’t big enough to rightfully run their own mailserver, but they are big enough to have roaming users on their networks (coffee shops, branch offices, hotels, SOHO….). They expect relaying service for either their mailserver or for all their various PC’s. At the same time, they don’t have many, if any mailboxes through the ISP. My thought is that they should ONLY be allowed to relay via SMTPAUTH by using a residential mailbox login/pass OR they need to purchase a commercial relay service (expensive because of the openness of it) for their IP space.
-
T1+ : These customers should not be allowed to relay unless they purchase (expensive) relay services for their IP space. Of course, they can always use a residential mailbox, but will have to use SMTPAUTH for it and will be restrained by the same policies residential mailboxes have (low tolerance tarpitting,…).
As always, thanks in advance.
–Dan
While the amount of effort you put into this so far is commendable, I
really think you're barking up the wrong tree.
At the end of the day, what have you done, besides annoy your customers
and increase the load on your support staff?
I don't really see what you're suggesting being anything other than a huge
effort, solving the wrong problem.
For any responsible ISP, the problem is the spam coming into your
mailservers, not leaving. As long as you quickly castrate the people who
do relay spam through you, you're not going to have an egress spam
problem.
Since you seem to have countless hours to invest in this problem, you'd be
better off writing a log parser to identify WHEN somebody is relaying spam
through you, so you can react.
Something else I've seen implemented is rate limiting. Keep track of the
number of messages sent by an IP over a variable amount of time and
implement thresholds.
I'd love to hear some of the conversations you have with your leased line
customers, when you tell them they have to pay for "(expensive) relay
services" to send mail through your mail server. How many times will they
laugh before hanging up on you? 
That's like the IRS trying to charge you for the forms...
And I'd also like to see the looks on your technical support staff's faces
when you tell them they need to assist your ENTIRE USER BASE in switching
to authenticated SMTP
And then you have to deal with the customers who have MTAs that don't
support authenticated SMTP...and on and on.
Whenever the solution is more expensive than the problem, you need to go
back to the drawing board.
Andy
I beg to differ (though you did qualify your statement with
"responsible", so maybe this critique doesn't apply). Yes, anyone
providing Internet services such as inbound mail has to deal with spam.
But to assume that all spam goes through your outbound mail servers is
simply not commensurate with the facts.
Since 1/1/04, we've rejected many email messages on our servers as
having originated from hosts with generic rDNS symptomatic of
dynamic/broadband/dialup/etc. IP assignment. Of those that were
rejected, here is a quick summary, showing the domain or ccTLD of the
originating host for those representing 20 or more attempts.
585 comcast.net 46 co.uk
402 rr.com 46 tiscali.nl
188 attbi.com 43 yahoo.com
175 pacbell.net 41 rogers.com
165 ameritech.net 40 mchsi.com
130 shawcable.net 38 cgocable.net
128 adelphia.net 36 snet.net
125 optonline.net 35 mindspring.com
106 wanadoo.fr 34 interbusiness.it
105 verizon.net 32 surfer.at
103 bellsouth.net 30 telus.net
89 charter.com 30 go2lnk.com
88 dsl-verizon.net 30 com.br
80 t-dialin.net 29 net.au
79 swbell.net 28 rima-tde.net
63 ne.jp 27 wideopenwest.com
61 videotron.ca 24 bbtt.de
58 net.il 22 nuvox.net
51 proxad.net 21 com.hk
48 com.tw 21 bbtec.net
48 a2000.nl 20 telia.com
20 charter-stl.com
These are not messages originating through known ISP mail servers, which
we have to a large extent "offwhitelisted" - meaning we don't reject,
but rather add a header to, such messages so that the header can be used
as part of a quarantine strategy. Any large ISP mailhost we've received
spam through (such as the freemail providers who are the greatest source
of Nigerian 419/lottery scams) is "offwhitelisted" and may be subject to
further blocking on a case by case basis, or to further filtering.
Some of the messages aggregated above may well have been virus or worm
delivery attempts; I haven't analyzed the day-to-day breakdown, but I'd
be surprised if MyDoom doesn't figure in to a large extent in the cases
documented above. But that is of no consequence; spam or virus messages
both constitute abuse by out-of-band, often compromised, hosts.
The problem of abusive mail originating from dynamic and otherwise
non-sanctioned sources is real; viruses such as SoBig are suspected of
being used in a vast net of compromised hosts, to evade other filtering
strategies.
Sobig.a and the Spam You Receive Today - LURHQ
http://www.lurhq.com/sobig.html
Sobig.e - Evolution of the Worm - LURHQ
http://www.lurhq.com/sobig-e.html
Sobig.f Examined - LURHQ
http://www.lurhq.com/sobig-f.html
In an eight-minute window on one of my servers yesterday, I saw the
following:
Hello All , Is anyone using this product in in production ?
I have a customer who is in a crunch for time & is unable to put
any sugnificant resources together to build one from scratch .
Please reply off list & I'll summarize . Tia , JimL