[Dshield] PDF Spam Wave
freddie at parawebic.com
Fri Aug 10 14:20:08 GMT 2007
Domains are not blacklisted - IP addresses are blacklisted
-------- Original Nachricht --------
Von: Chuck Rothauser [mailto:chuckr at keywestkeys.com]
Gesendet: 10.08.2007 14:52:20
An: "General DShield Discussion List" <list at lists.dshield.org>;
Betreff: Re: [Dshield] PDF Spam Wave
Spammers find smtp mailrelays and use legitimate domains which
the legitimate domain to be black listed........no fun trying to
----- Original Message -----
Sent: Friday, August 10, 2007 2:16 AM
Subject: Re: [Dshield] PDF Spam Wave
> On Tuesday 07 August 2007 19:55:35 jayjwa wrote:
>> *this* PDF spam:
>> 1. Spammer connects to large.email.provider (no http-to-smtp
>> submits email w/PDF attachment spoofed as
>> 2. Spammer sends email to non-existing user,
>> (random)@(random-but-real-domain). So now we have fake mail
>> non-existing user.
>> 3. All of the (random-but-real-domain)s now receive mail to
>> domain, but to a user that _does not exist_ or cannot receive
>> other reason.
>> 4. They reject this. How is this *not* correct behavior?
>> 5. Now certain.domain gets this "bounce". Only it's not a
>> because certain.domain _never sent anything or handled any
>> 6. "Bounce" (remember, certain.domain did not send anything
>> is labeled to (random)@certain.domain. Obviously, (random)
>> What to do with mail to a user that does not exist? Do you
see the cycle
> ...And unfortunately I've seen this for well over 7 years, and
> my own personal and work addresses have been the destinations.
> migrated well over 5 years ago to a combination of random
> addresses pulled from address books and off mailing lists, and
> versions of the same. Ever seen mail aimed at a user called
> to a corrupted "majordomo" email address. I've even got email
> and "o" on the same machine.
>> To make matters worse, multiply the above by the 10,000 or so
>> spam run seemed to generate, and also the fact that some
>> trying to re-deliver even after the transaction was 550'ed.
>> "certain.domain" happened to be one of my intranet hosts. The
>> thing I could come up with that ended mail to no one looping
>> circles was eating these fake bounces at the door, which it
>> the bottom of my original post.
> In many of the above cases (eg: "rdomo"), I simply created an
> the mail directly into things like spamassassin's learning
> 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.
>> all these spam could end would be in the mailbox of a
>> 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
>> I was hoping to find out. If it was Joe-Job, as someone
>> I have not seen alot directed at me (especially to a
>> server) as I do not run a commercial, educational institute
> As mentioned above, I have seen this sort problem for the last
7 or so
> on various addresses (from commercial, educational, ISP and
> over that time. Spammers and virus writers are feeding off
> technical know-how, and abusing the system in any way they can
>> ------------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
>> the storm of bounces already in session...
> It might, but the problem here is not that it's being rejected
> that large.email.provider is not adequately filtering mail, no
> 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
> also enforce things like not allowing banned files no matter
> injected into the system for the same reason. When it comes to
> this, I trust no one. It also makes things a lot easier by
> complexity of a setup, and therefore the number of different
> to be tested when things change to ensure correct operation.
> Stuart Young - aka Cefiar - cef at optus.net
> SANSFIRE 2007 July 25-August 2 in Washington, DC. 56 courses,
> instructors, and a great tools and solutions expo. Register
> http://www.sans.org/info/4651 (brochure code ISC)
SANSFIRE 2007 July 25-August 2 in Washington, DC. 56 courses,
instructors, and a great tools and solutions expo. Register
http://www.sans.org/info/4651 (brochure code ISC)
More information about the list