[Dshield] PDF Spam Wave

Cefiar cef at optus.net
Fri Aug 10 06:16:33 GMT 2007

On Tuesday 07 August 2007 19:55:35 jayjwa wrote:
> *this* PDF spam:
> 1. Spammer connects to large.email.provider (no http-to-smtp header),
> submits email w/PDF attachment spoofed as
> (random-made-up-user)@certain.domain
> 2. Spammer sends email to non-existing user,
> (random)@(random-but-real-domain). So now we have fake mail going to
> non-existing user.
> 3. All of the (random-but-real-domain)s now receive mail to the correct
> domain, but to a user that _does not exist_ or cannot receive mail for some
> other reason.
> 4. They reject this. How is this *not* correct behavior?
> 5. Now certain.domain gets this "bounce". Only it's not a real bounce
> because certain.domain _never sent anything or handled any mail_.
> 6. "Bounce" (remember, certain.domain did not send anything to begin with)
> is labeled to (random)@certain.domain. Obviously, (random) does not exist.
> What to do with mail to a user that does not exist? Do you see the cycle
> here?

...And unfortunately I've seen this for well over 7 years, and in many cases 
my own personal and work addresses have been the destinations. Then it 
migrated well over 5 years ago to a combination of random addresses, 
addresses pulled from address books and off mailing lists, and corrupted 
versions of the same. Ever seen mail aimed at a user called "rdomo"? Welcome 
to a corrupted "majordomo" email address. I've even got email directed at "r" 
and "o" on the same machine.

> To make matters worse, multiply the above by the 10,000 or so messages the
> spam run seemed to generate, and also the fact that some mailservers kept
> trying to re-deliver even after the transaction was 550'ed. The
> "certain.domain" happened to be one of my intranet hosts. The only sensible
> thing I could come up with that ended mail to no one looping around in
> circles was eating these fake bounces at the door, which it showed towards
> the bottom of my original post.

In many of the above cases (eg: "rdomo"), I simply created an alias and fed 
the mail directly into things like spamassassin's learning mode, especially 
when I was "sure" the address was bogus.

> Moreover, this spam operated more like an email virus, in that I don't
> think it would be wise to bounce them, but rather sink them. The only place
> all these spam could end would be in the mailbox of a postmaster, which
> seemed to me a pretty worthless spam run (as no end-users ever got any
> messages). Why someone would initiate such a spam run was one of the things
> I was hoping to find out. If it was Joe-Job, as someone suggested, then no,
> I have not seen alot directed at me (especially to a low-activity, intranet
> server) as I do not run a commercial, educational institute or ISP
> mailserver.

As mentioned above, I have seen this sort problem for the last 7 or so years, 
on various addresses (from commercial, educational, ISP and non-commercial) 
over that time. Spammers and virus writers are feeding off each others 
technical know-how, and abusing the system in any way they can get away with.

> ------------Reply to second post, tonni at hetnet.nl:
> ->I have a perfect pdf spam solution, I refuse all mail that isn't for my
> -> users, my 1550+ user site currently refuses far more mail than it is
> -> offered,
> In this case (#2), your perfect pdf spam solution would have contributed to
> the storm of bounces already in session...

It might, but the problem here is not that it's being rejected inline - it's 
that large.email.provider is not adequately filtering mail, no matter what 
the source. They're the source of the problem (they accept the mail in the 
first place), and they're the ones that should be the source of your ire.

Personally, I put everything through a spam filter. Whether the user is 
authenticated or not, whether they're from a trusted IP space or not, and 
even if it's from a local process on the machine running the mail server. I 
also enforce things like not allowing banned files no matter how they're 
injected into the system for the same reason. When it comes to things like 
this, I trust no one. It also makes things a lot easier by reducing the 
complexity of a setup, and therefore the number of different paths that need 
to be tested when things change to ensure correct operation.

 Stuart Young - aka Cefiar - cef at optus.net

More information about the list mailing list