ietf-asrg
[Top] [All Lists]

Re: [Asrg] Some data on the validity of MAIL FROM addresses

2003-05-26 17:24:41
On Sun, May 18, 2003 at 03:34:14AM -0400, Kee Hinckley wrote:
Vernon has regularly made the claim that a significant proportion of 
spam messages have valid MAIL FROM's.  That means that bounces will 
go the the spammer.  This has significant ramifications for C/R 
systems (especially auto-respond ones) since it means that should 
they have to, spammers could respond to challenges.

There would be an easy test method.
Modify the SMTP/Mail Server to send bounces not with an empty envelope
sender, but with a collector address. Also collect double bounces.
Then start counting. That way you will catch the bounces as they will
not be discarded by "store and forward" systems that have to accept what
will result in a double bounce.
By also recording the bounces you sent out and matching sender/dest
pairs the task would be rather trivial for people with e.g. spam traps.

I can't get my hands on a mailserver thats not in production and has
a large enough amount of mails for significant statistics.

As for the numbers:
From my experience /lot/ of sender addresses are faked. There is the
- keep username strategy
  abcdef(_at_)domain1 -> abcdef(_at_)domain2
                 -> abcdef(_at_)domain3
                 -> abcdef(_at_)domain4
                 [ ... ]
- 45jcz8fh(_at_)yahoo(_dot_)com strategy (I see this mostly with yahoo 
addresses)
    A customer got abused and they relayed 57653 spam mails.
    They mostly grouped it in 8 messages per sender account (about 8700 unique)
    They were formed:
        0leba(_dot_)tpbok(_at_)hotmail(_dot_)com
        07k7m(_dot_)ww9eq(_at_)hotmail(_dot_)com
        dcf99(_dot_)drafz(_at_)yahoo(_dot_)com
        lmx6i(_dot_)q8tge(_at_)hotmail(_dot_)com
        6n4ss(_dot_)2x6np(_at_)hotmail(_dot_)com
        7gauv(_dot_)9nc0n(_at_)yahoo(_dot_)com
        g5ikw(_dot_)qehld(_at_)hotmail(_dot_)com
    all 8700. And from all the bounces I had seen NONE of them was
    valid.
    I put the list up at
        http://www.lamer.de/download/spamsender.txt.gz
    in case anyone is interested. The format is  "nnn  address" where
    "nnn" is the number of times the address was used as sender address.
    (uniq -c)
- the - what I call them - "nolist" group.
  They use
      
OWNER-NOLIST-OFCDAILY*xxx**domain(_dot_)(_dot_)(_dot_)(_dot_)(_at_)MAIL2(_dot_)ASP-PLATFORM(_dot_)COM
      
OWNER-NOLIST-OFCDAILY*xxx**domain(_dot_)(_dot_)(_dot_)(_dot_)(_at_)MAIL1(_dot_)YOURMAILSOURCE(_dot_)COM
      ...
  The bounces go back and are accepted (ad least they were before I put
  filters in) but they are abviously not evaluated as I always see
  the same (not existing/blocked) recipient lists tried over and over
  for months. So I am rather sure there is a bit bucket SMTP daemon
  accepting the messages.
- about 10% of the spam we (ought to) receive has
     - no valid A or MX record for the sender domain
       (slighty wrong figures because of the big(_at_)boss(_dot_)com Sobig-A 
worm)
     - about 3-5% of the spam that bounces hangs in the queue (at least
       for a short time), because
         - A/MX -> 127.0.0.1 or 0.0.0.0
         - A/MX don't accept emails for 7 days period like
              sales(_at_)websalesjet(_dot_)net
              claire(_at_)t9enterprises(_dot_)com
              *(_at_)online-shop-exchange(_dot_)com
              *(_at_)gratefulgeorge(_dot_)us
              *(_at_)healthfirs(_dot_)org
          ...

I doubt Vernons theory from my daily experience, but no, I have no real
numbers (s.a.)

        \Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>