Re: BCP38 making it work, solving problems

[Steven Champeon <schampeo () hesketh com>]

on Wed, Oct 13, 2004 at 07:09:10AM +0530, Suresh Ramasubramanian wrote:
> alex () yuriev com [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 (62.59.213.129)
  by 0 with SMTP; 27 Aug 2004 21:20:16 -0000
Received: from thewordfactory.com (mail.thewordfactory.com [216.27.21.211])
    by dslam129-213-59-62.adsl.zonnet.nl (Postfix) with ESMTP id 0453B70AB1
    for <hermes510 () philonline com>; 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 ([203.177.71.7])
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 [24.135.29.42])
        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 [216.150.205.36]). 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 [216.86.139.44] (may be forged))
smtp03.adnc.com (smtp03.adnc.com [206.251.248.23])
cobble.phpwebhosting.com (cobble.phpwebhosting.com [64.65.61.211])
date.marketorder.com ([64.65.150.229]) (by way of postini)
exchgkom.TRI.NET (mail.tecolote.com [65.170.33.20])
DNS2.TCBINC.NET (DNS2.TCBINC.NET [64.124.116.30])
mail-in-01.netsonic.net (mail-in-01.netsonic.net [66.180.172.253])
ms1.tcnoc.com (ms1.tcnoc.com [63.150.10.30])
exchange3.corp.bcs-tx.com (ip204.bcs-tx.com [216.136.93.204] (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!