SMTP relaying policies for Commercial ISP customers...?
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: 1) Residential (a few dynamic IP computers) 2) Broadband Commercial (Static IP and a few forwarded IP's, a dozen end user PC's) 3) 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. 1) 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. 2) 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. 3) 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 -- Daniel Ellis, CTO, PenTeleData (610)826-9293
On Fri, 13 Feb 2004, Dan Ellis wrote:
1) 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.
2) 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.
3) 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,...).
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 --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
on Fri, Feb 13, 2004 at 12:35:17PM -0500, Andy Dills wrote:
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.
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: ---------------------------------------------------------------------- WKS Q 12:12:54 (9351) to: schampeo@hesketh.com from: <aaauto1327@optonline.net> at 68.59.188.188 (pcp02265132pcs.batlfl01.tn.comcast.net) ---------------------------------------------------------------------- WKS Q 12:13:23 (9356) to: schampeo@hesketh.com from: <aaauto1327@optonline.net> at 81.9.232.163 (cmr-81-9-232-163.telecable.es) ---------------------------------------------------------------------- WKS Q 12:15:21 (9513) to: schampeo@hesketh.com from: <aaauto1327@optonline.net> at 200.55.72.231 (200-55-72-231.dsl.prima.net.ar) ---------------------------------------------------------------------- WKS Q 12:15:49 (9519) to: schampeo@hesketh.com from: <aaauto1327@optonline.net> at 142.169.46.107 (c142.169.46-107.clta.globetrotter.net) ---------------------------------------------------------------------- WKS Q 12:15:51 (9520) to: schampeo@hesketh.com from: <aaauto1327@optonline.net> at 142.165.147.216 (hsdbsk142-165-147-216.sasknet.sk.ca) ---------------------------------------------------------------------- WKS Q 12:15:56 (9521) to: schampeo@hesketh.com from: <aaauto1327@optonline.net> at 141.158.119.119 (pool-141-158-119-119.pitt.east.verizon.net) ---------------------------------------------------------------------- WKS Q 12:17:03 (9556) to: schampeo@hesketh.com from: <aaauto1327@optonline.net> at 81.59.87.42 (dslam42-87-59-81.dyndsl.zonnet.nl) ---------------------------------------------------------------------- WKS Q 12:17:05 (9560) to: schampeo@hesketh.com from: <aaauto1327@optonline.net> at 81.50.196.106 (AToulouse-206-1-6-106.w81-50.abo.wanadoo.fr) ---------------------------------------------------------------------- WKS Q 12:17:07 (9579) to: schampeo@hesketh.com from: <aaauto1327@optonline.net> at 24.98.85.82 (c-24-98-85-82.atl.client2.attbi.com) ---------------------------------------------------------------------- WKS Q 12:17:13 (9589) to: schampeo@hesketh.com from: <aaauto1327@optonline.net> at 80.236.74.213 (ip-213.net-80-236-74.issy.rev.numericable.fr) ---------------------------------------------------------------------- WKS Q 12:17:22 (9592) to: schampeo@hesketh.com from: <aaauto1327@optonline.net> at 80.167.186.245 (x1-6-00-0c-6e-28-c6-cd.k345.webspeed.dk) ---------------------------------------------------------------------- WKS Q 12:17:25 (9593) to: schampeo@hesketh.com from: <aaauto1327@optonline.net> at 80.138.216.95 (p508AD85F.dip.t-dialin.net) ---------------------------------------------------------------------- WKS Q 12:19:01 (9646) to: schampeo@hesketh.com from: <aaauto1327@optonline.net> at 62.163.223.124 (a223124.upc-a.chello.nl) ---------------------------------------------------------------------- WKS Q 12:19:05 (9647) to: schampeo@hesketh.com from: <aaauto1327@optonline.net> at 63.121.234.49 (63-121-234-49.res.nb.cable.sigecom.net) ---------------------------------------------------------------------- WKS Q 12:21:25 (9796) to: schampeo@hesketh.com from: <aaauto1327@optonline.net> at 24.15.14.27 (c-24-15-14-27.client.comcast.net) ---------------------------------------------------------------------- WKS Q 12:21:26 (9797) to: schampeo@hesketh.com from: <aaauto1327@optonline.net> at 83.117.87.199 (c537557c7.cable.wanadoo.nl) ---------------------------------------------------------------------- WKS Q 12:21:28 (9798) to: schampeo@hesketh.com from: <aaauto1327@optonline.net> at 83.117.88.137 (c53755889.cable.wanadoo.nl) ---------------------------------------------------------------------- WKS Q 12:21:29 (9799) to: schampeo@hesketh.com from: <aaauto1327@optonline.net> at 200.56.179.150 (customer-GDL-179-150.megared.net.mx) ---------------------------------------------------------------------- WKS Q 12:21:31 (9800) to: schampeo@hesketh.com from: <aaauto1327@optonline.net> at 24.151.149.112 (ip-wv-24-151-149-112.charterwv.net) ---------------------------------------------------------------------- WKS Q 12:21:32 (9801) to: schampeo@hesketh.com from: <aaauto1327@optonline.net> at 81.167.103.107 (dyn-81-167-103-107.ppp.tiscali.fr) ---------------------------------------------------------------------- (WKS) is just a marker for "Well known spammer". Anyway, I count 20 attempts, presumably from the same sender, all from different machines, all with generic rDNS indicative of broadband/dynamic/dialup service, in nine countries (US, ES, AR, CA, NL, FR, DK, DE, MX) and on nineteen different ISPs -- all within eight minutes of one another. Indeed, each attempt within each group of attempts came mere seconds apart, after the previous rejection. There is some serious communication going on between the controlling spammer and the hosts that make up his network of compromised hosts. (I posted this to spam-l earlier today, to demonstrate that any effort to block "some" hosts with generic rDNS will fail, as the spammers will simply try another host, in a different country, from another ISP, and therefore efforts on the part of a single ISP to limit out-of-band mail through rate-limiting or other such narrow-focus strategies will fail.) I strongly encourage any ISP here who has a policy of not blocking outbound port 25 (or redirecting to their own mail servers), or of refusing to assign non-generic rDNS to legitimate/sanctioned mail sources on statically-assigned IPs, to reconsider whether their actions are to a great extent responsible for the vast majority of spam sent today. Steve -- hesketh.com/inc. v: (919) 834-2552 f: (919) 834-2554 w: http://hesketh.com Book publishing is second only to furniture delivery in slowness. -b. schneier
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 -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network Engineer | 3542 Broken Yoke Dr. | Give me Linux | | babydr@baby-dragons.com | Billings , MT. 59105 | only on AXP | +------------------------------------------------------------------+
participants (4)
-
Andy Dills
-
Dan Ellis
-
Mr. James W. Laferriere
-
Steven Champeon