[Dshield] PDF Spam Wave

jayjwa jayjwa at atr2.ath.cx
Tue Aug 7 09:55:35 GMT 2007

Two replies, since they are short and on the same topic I've placed both here.

----------Reply #1 abuse at what4now.com:

-> > Someone relays his experience about the recent rise in PDF spam, replete
-> > with details, headers, etc. trying to create a well-documented incident
-> > report, and he gets flamed by several people.
-> I don't think anyone flamed anyone.

The first reply back to this, as I was the OP, began "what's your point?". 
After carefully explaining in great detail with (uneditted) logs, I felt this 
remark was unwarrented, at best (thank you Shaun for your reply). Originally I 
had begun to respond to it, then cancelled it as one more page on top of the 
three already posted was not going to sway this person.

-> The replies said normal spam and seen before and explained why he was 
-> getting the spam.  It was made clear the mis-configured email servers 
-> are the problem.

Yet this was not the case. From the responses, it appeared that someone read 
about 5-7 lines into my post, drew a conclusion, then the rest jumped onboard. 
These were correctly configured servers being used by spammers to do their 
dirty work in a manner that is not commonly seen.

To summerize, again, *normal* PDF spam:

1. spammer connects to large.email.provider (or similar mid-man) and logs in 
as throwaway at provider.domain

2. spammer sends email w/PDF attachment to bypass filters to  real, existing 
users (you, me, whoever)

3. Large provider sends out spammer's request, adding its own headers
on top of what usually shows up as a http-to-smtp web interface header

4. User gets email w/PDF attachment that bypassed spam filter, appearing
from spammers_thowaway at large.email.provider.

These are easy to report and get closed down, and one only need make a filter 
to stop the incoming PDF spam. This is what everone assumed was happening. 
Yes, we've seen this before. Yes, you should reject this. Not sure what 
"accept then bounce" is, I use Sendmail and it does not have an "accept then 
bounce" option.

*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?

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.

Aug  2 11:26:04 atr2 sm-mta[29328]: l72FOboD029325: done; delay=00:01:25, ntries=1
Aug  2 11:36:32 atr2 sm-mta[29329]: NOQUEUE: connect from mail.daisy.cz []
Aug  2 11:36:32 atr2 sm-mta[29329]: l72FaWcV029329: Milter (milter-regex): init
success to negotiate
Aug  2 11:36:32 atr2 sm-mta[29329]: l72FaWcV029329: Milter: connect to filters
Aug  2 11:36:36 atr2 sm-mta[29329]: l72FaWcV029329: milter=milter-regex, action=mail, discard
Aug  2 11:36:36 atr2 sm-mta[29329]: l72FaWcV029329: Milter: from=<>, discard
Aug  2 11:36:36 atr2 sm-mta[29329]: l72FaWcV029329: from=<>, size=2732, class=0, nrcpts=1, msgid=<20070801115500.DBD73BC057 at mail.daisy.cz>, proto=ESMTP, daemon=MTA, relay=mail.daisy.cz []
Aug  2 11:36:36 atr2 sm-mta[29329]: l72FaWcV029329: Milter accept: message
Aug  2 11:36:36 atr2 sm-mta[29329]: l72FaWcV029329: to=<Horst at vdrl.ath.cx>, delay=00:00:00, pri=32732, stat=discarded

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.

-> From the description of the problem I got the impression that his server may
-> have been configured wrong but no one blamed him directly.

If anyone's server was misconfigured, it was not mine, which sent nothing, no 
mail, and had no interaction with spammers nor "accepted then bounced" 
anything. A few mails were held initially to find out just what this was.

------------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...

-> we don't get any false positives, none of our users complains 
-> about lost or delayed mail.

...as you've (frequently) pointed out, yet I've often wondered about.

-> But I'm not going even to *begin* to explain how, to anyone (only to 
-> die-hard Postfix people, but they taught me how, anyway). Yet less when a 
-> novice yuks.

When I find such a novice, prehaps I'll pass on this post to him.

More information about the list mailing list