Subject: [Asrg] Re: Spammers probing for whitelisted addresses?

From: Douglas Campbell <[email-masked]>
Date: Fri, 27 Jan 2006 22:43:41 -0800

Walt Dnes:

>  Checking my reject logs, I've noticed a new pattern the past couple of
>weeks...
>  - *ONE* IP address
>  - sends 15 or 50 delivery attempts, approximately 1 attempt 2 every
>    seconds
>  - the envelope-sender is a legitimate looking address @gmail.com or
>    gmx.de or one of several .ru domains
>
>  
>
I've noticed a similar pattern  -- a large number of attempts from the 
same bot to deliver mail to the same address, with the helo and rcpt 
from strings varying.  I  have no idea what they are trying to do 
because the retries are too close together to defeat greylisting [note 
that greylisting states that one heuristic for changing state is that 
the second e-mail arrive after a user-configured timeout].  Either the 
command machine has broken logic, or the spammers are hoping the timeout 
is set very low.

Daniel Feenberg:

>Of these only 874 (13%) had an existing RDNS that did not reek of dynamic
>assignment. That is, did not include the strings "dsl", "dynamic", "dial"
>or "pool" and did not have any all-digit components.
>
>  
>
I have one of the aforementioned addresses; my rDNS is 
h-69-3-215-47.lsanca54.covad.net.  Obviously, I would be averse to 
having the rule you state run a widely used blocklist, but each of us 
must run our installations as we see fit.  If I see my address widely 
blocked, I'd consider routing my mail through my ISP; the only reason I 
don't is that I'm running sendmail, it's full featured, and I don't see 
a good reason yet to take the extra hop via a remailer.  My ability to 
send you e-mail is a privilege, not a right, and you have the right to 
deny me that privilege. 

That said, such a rule tars the innocent along with the guilty. It's 
like a google search that is over-broad.  Think.  We can do better.

I've been following the discussion about SPF, and here's what I noticed 
in my particular case:
a) one of my domains is being used by spammers to generate fraudulent 
rcpt from addresses.  Hence, I get over 200 bounces per day to my 
mailserver which commonly services 10 real messages (both inbound and 
outbound) per day.  I mentioned in a previous post that spam appliances 
are also bouncing with "the spam you sent us was returned without 
delivery" type messages.
b) two days ago, I added an SPF record to my DNS for the affected 
domain.  The SPF record verified correct via port25.com.
c) the average number of  bounces has not decreased since I added the 
SPF record.  And the number of "the spam you sent us" messages from the 
appliances has not decreased either.

The bad part about this is that aol is still among the bouncers, and 
they are the ones hosting the spammer's portal pages!

My conclusion: most mailers, and, more sadly, most spam appliances, are 
ignoring SPF.  My own MTA (sendmail) has an SPF implementation available 
as a milter (with a whole bunch of caveats that it not be used in a 
production environment), and it is an option that does not ship with the 
distro.  Obviously SPF validation must be made part of the top MTA 
distributions and enabled by default for it to have an effect.  That 
they have not is a sign that the MTA vendors don't think much of SPF, 
or, for some reason, are not eager to embrace it.

I'm trying to figure out the politics of this. 

Cheers,
Douglas Campbell
postmaster, craniumpro.com

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 28 Jan 2006 16:03:02 +0100

Douglas Campbell wrote:

> b) two days ago, I added an SPF record to my DNS for the
> affected domain.  The SPF record verified correct via
> port25.com.
> c) the average number of bounces has not decreased since
> I added the SPF record.

Two days is a bit short.  In 2004 "my" spammer needed six
months to get the idea.  It was clearly one spammer, the
difference between zero and almost 1.000 bounces and other
backscatter is obvious.  For the first about 6 weeks I had
no FAIL, then it took me another six weeks to figure out
the "zone cut" stuff (never worked), and after that I guess
"my" spammer didn't know what the hell SPF FAIL is until he
tested the then new SA 3.

In 2005 he tried it again for two weeks.  I've reported all
back scatter via SpamCop, then it stopped.  Of course I'm
not sure that SPF FAIL had anything to do with it, spammy
didn't inform me about his strategy.

> The bad part about this is that aol is still among the
> bouncers, and they are the ones hosting the spammer's
> portal pages!

AFAIK AOL ignores SPF FAIL, they're only using SPF PASS for
white-listing.  As it is draft-hutzler-spamops is toothtless,
"reject at the MDA" is too little too late.  "Implement and
support 2476bis" is fine, but rather short for a BCP.  IIRC
it doesn't recommend 2476bis 6.1 "enforce submission rights".

> Obviously SPF validation must be made part of the top MTA
> distributions and enabled by default
                    ^^^^^^^^^^^^^^^^^^
That's a dangerous idea.  You must know what you're doing if
you enable it.  You can only use it at your border MTAs, you
have to white list them if they talk with each other (normal
MX priority scheme as explained in RfC 2821), and you have to
make up your mind about the weird 1123 5.3.6(a) forwarding to
you from third parties.  Ignore them, white list them, talk
with them, whatever you do, it's more than only "enabled by
default".  Mininmally you'd know why you use (or don't use)
trusted-forwarders.org.

> I'm trying to figure out the politics of this.

Have fun, it's an interesting story.  Technically it's more
on the simple side, but not as simple as "enabled by default".

                            Bye, Frank

SC's view:  <http://www.spamcop.net/fom-serve/cache/329.html>

---

From: Daniel Feenberg <[email-masked]>
Date: Sat, 28 Jan 2006 10:25:29 -0500 (EST)

> like a google search that is over-broad.  Think.  We can do better.

Yeh, I am aware that some static addresses have dynamic sounding names.
The strings of digits are the most commonly misleading sign, but they
account for about half the dynamic sounding addresses, which makes it hard
to leave them out. It would be possible in principle to maintain a list of
truely dynamic addresses, but it would be a continuous effort.

Right now I believe sendmail allows you to specify an alternate smarthost
that is used if there is no connection possible to the destination MTA. It
might be nice to let the alternate be used if the connection is rejected
by the MTA as a possible spamhost. That way you could send mail directly
to MTAs that accepted it, but divert mail to your ISPs smarthost for
destinations that required it. I don't think any MTA does anything
like this, though. It is a feature I would enable on our MTA, even though
we have never been on any DNSBL, as it would provide some insurance
against rejections should we land on one. 

Daniel Feenberg