[Dshield] Extreme increase in spam attempts... any one else seeing similar event?

Jim McCullough jim.mccullough at gmail.com
Sat Aug 18 00:02:08 GMT 2007


Just as an afterthought, we previously discussed backscatter and to
prevent a repeat of the last thread with it.  I think this thread
should stay on its course and not go back down the MTA configuration
issue again.  No need to give headaches to the bandwidth challenged,
or cause anyone's blood pressure to rise.... as for me no heartburn
please, I just finished scarfing a large Pizza Hut cheese lovers with
double pepperoni and two orders of hot wings.



-- 
Jim McCullough

"Just because the standard provides a cliff in front of you, you are
not necessarily required to jump off it."

    Norman Diamond

On 8/17/07, WebMaster at commerco.net <WebMaster at commerco.net> wrote:
> I'd argue that, rather than calling it spam as Dotzero suggests, this
> kind of activity should rightly be termed and considered a direct and
> deliberate form attack upon a targeted network by the originating
> party of the spam, whom I contend, deliberately use these kinds of
> SPF "challenged" MTAs as their "bot" attackers.
>
> It cannot be viewed as anything else these day, given that the "joe
> job" could have been just as easily done with an attackers own "throw
> away" domain name(s).  Instead, they clearly and deliberately chose
> to directly attack another party's domain name(s).  I contend that
> this was a conscious and premeditated choice and decision by the
> attacker.  It seems more than difficult to come to any other conclusion.
>
> Back "in the day", MTAs used to be able to freely forward
> messages.  Very early commercially available MTAs did not even have a
> "switch" to shut that off (trust me on that, the only one I could
> find was on the system case, which did solve at least part of the
> problem - at least we were not sending any open relay mail, but we
> did have to go buy other MTA software rather quickly).
>
> Over time, the damage caused by such open relays became clear to the
> Internet community and much was done to reinforce how bad having one
> of those was to everyone else.  I think it should be made just as
> clear to operators of MTAs that do not respect the explicit (-all)
> assertion in SPF DNS records, that they are nothing short of a modern
> day version of the open relay operator of yesteryear.  Ultimately, I
> believe that through education to stop such behavior, we make it more
> obvious to administrators as to why the use of their SPF oblivious
> MTAs make them arguably culpable as co-conspirators with the
> attackers themselves.
>
> You don't wish to protect your domain's reputation with SPF?  Fine
> (perhaps really bad judgement on your part, but fine as there may
> well be some corner case reasons for your environment).  Just please
> respect the fact that I do care and stop attacking servers in my
> network from your own by amplifying the negative effects of some
> criminal network attacker who has made my network their target du jour.
>
> WebMaster at Commerco.Net
>
> At 02:57 PM 8/17/2007, Dotzero wrote:
> >On 8/17/07, Tony Earnshaw <tonni at hetnet.nl> wrote:
> > >
> > > That sort of thing is very often backscatter from joe jobs, i.e. a bot
> > > network sending out spam with the smtp 'MAIL FROM:' with one of your
> > > valid addresses and the receiving MTA bouncing it (as opposed to smtp
> > > refusing it).
> > >
> >
> >What's interesting to me are the number of MTAs that will still
> >backscatter on joe jobs even if the abused domain makes a strong
> >(-all) SPF assertion. I'd argue that this type of backscatter should
> >be considered spam as well.
> >_________________________________________
> >SANSFIRE 2007 July 25-August 2 in Washington, DC.  56 courses, SANS top
> >instructors, and a great tools and solutions expo. Register today!
> >http://www.sans.org/info/4651 (brochure code ISC)
>
>
> _________________________________________
> SANSFIRE 2007 July 25-August 2 in Washington, DC.  56 courses, SANS top
> instructors, and a great tools and solutions expo. Register today!
> http://www.sans.org/info/4651 (brochure code ISC)
>


More information about the list mailing list