North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: BCP38 making it work, solving problems
on Wed, Oct 13, 2004 at 07:09:10AM +0530, Suresh Ramasubramanian wrote: > > [email protected] [12/10/04 13:16 -0400]: > > > > > If I, and my little 7-man company, can afford to have me solve the > > > problem on our end, why the heck can't you do the same? > > > > You can do it because you are a 7-man company. So can I. However, companies > > the size of Sprint cannot do it. > > > > Most filtering that I've seen (email, router, whatever) that just works great > for a 7 man company will not work when you serve several million users, > that's a fact. A 7 man Web app development company with ~100 or so hosted POP mail accounts, FYI. Not that it matters. If I can write rules that block spam with forged headers, so can any damn body else. And I'm tired of getting the bounces from those who feel it's not possible. Some examples of headers from mail that other ISPs have felt compelled by their size to accept and then bounce back to me: Received: from dslam129-213-59-62.adsl.zonnet.nl (22.214.171.124) by 0 with SMTP; 27 Aug 2004 21:20:16 -0000 Received: from thewordfactory.com (mail.thewordfactory.com [126.96.36.199]) by dslam129-213-59-62.adsl.zonnet.nl (Postfix) with ESMTP id 0453B70AB1 for <[email protected]>; Fri, 27 Aug 2004 15:29:58 -0500 The second Received header is forged. The first is from a dynamic DSL line. The message was accepted by mail.philonline.com ([188.8.131.52]) and bounced back to me in a message that didn't even have a Message-ID header, letting me know they are so dumb they accept forged mail from dynamic IPs and only then analyze it to see if the user exists or if the forged sender should be notified. Received: from ip84-RND_DIGIT[2-3]-RND_DIGIT[2-3]-RND_DIGIT[2-3].4tvMsWC8okzw.customer.aviamail.zzn.com (50-RND_DIGIT[2-3]-RND_DIGIT[2-3]-RND_DIGIT[2-3].customer.aviamail.zzn.com [184.108.40.206]) by ezEG4GA1.aviamail.zzn.com (RND_DIGIT[1-3].RND_DIGIT[1-3].RND_DIGIT[1-3]/RND_DIGIT[1-3].RND_DIGIT[1-3].RND_DIGIT[1-3]) with SMTP id B3tc6UKcaTVY This was in a bounce from mail.cygentech.com (geoanalysis36.cust.viawest.net [220.127.116.11]). We've been seeing these headers for more than a year now, and blocking them almost as long. But these idiots can't see that backscattering them at me is rather stupid. Just a few of the others who've done this (accepted mail with completely bogus RNDizer headers from broken spamware): plesk4.merkury.com (216-86-139-44.tns.net [18.104.22.168] (may be forged)) smtp03.adnc.com (smtp03.adnc.com [22.214.171.124]) cobble.phpwebhosting.com (cobble.phpwebhosting.com [126.96.36.199]) date.marketorder.com ([188.8.131.52]) (by way of postini) exchgkom.TRI.NET (mail.tecolote.com [184.108.40.206]) DNS2.TCBINC.NET (DNS2.TCBINC.NET [220.127.116.11]) mail-in-01.netsonic.net (mail-in-01.netsonic.net [18.104.22.168]) ms1.tcnoc.com (ms1.tcnoc.com [22.214.171.124]) exchange3.corp.bcs-tx.com (ip204.bcs-tx.com [126.96.36.199] (may be forged)) [...etc...] My full list of backscatter hosts is ~17K entries long. And those are just the ones who've hit my servers. Never mind the charter/rr/att/hotmail/etc. hosts that are also listed - I'm not just talking about random Exchange boxes here - I'm talking about every major ISP with which I am familiar. Want to know if you're responsible for backscatter abuse? Just ask. As you know, Suresh, Outblaze does the same thing. Listed here as hosts we no longer accept null sender mail from: mta1-1.us4.outblaze.com BOUNCER spf0.us4.outblaze.com BOUNCER spf10.us4.outblaze.com BOUNCER spf1.us4.outblaze.com BOUNCER spf2.us4.outblaze.com BOUNCER spf4-1.us4.outblaze.com BOUNCER spf5-1.us4.outblaze.com BOUNCER spf7-17.us4.outblaze.com BOUNCER At least you've said you're moving towards fixing it. Thanks. > One false positive report per week from 7 users. How many per week - or per > day - when you have 40 million users, is a question that gets answered real > fast. I don't even want to go into the backscatter messages that show that: - the sender forged the IP/domain of the recipient into HELO/EHLO - the recipient accepts mail for unknown accounts - the relaying host forwarded Webmail from Nigeria without proper Received headers added for blocking purposes - you name the obvious spamsign Come on, there is so much obvious crud that should be checked that isn't being checked - we could reduce backscatter by a third or more simply by refusing during SMTP handshake messages from hosts that forge the receipient IP/hostname/domain in HELO, or to users that don't exist, or if virus filters were clueful enough to drop, rather than emit DSNs, for known virus-originated messages that always forge the sender. > A lot of the bad filtering (or lack of filtering, for that matter) decisions > I've seen at large network providers and ISPs is generally where they are > also unresponsive to their users and to the internet community that reports > stuff to them (quite a few places I could name where most role accounts seem > to funnel straight to /dev/null) I wish I could say that was where most of them were confined. But what I see is a widespread lack of clue and the will to do something to fix email. You see Dave Crocker on Farber's list, saying that most spam is perfectly well-formed email, and I wonder what planet he's smoking. At /least/ 30% of the mail we reject is simply riddled with spamsigns and violations of basic RFCs. And I'd say that the same is true of the mail we get as backscatter from clueless morons pretending to be large ISP mail admins. -- join us! http://hesketh.com/about/careers/web_designer.html join us! hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.html join us!