Loading ...
Sorry, an error occurred while loading the content.

Re: Spam Backscatter

Expand Messages
  • Ansgar Wiechers
    ... I wrote a backscatter filter based on smtpprox to handle this. http://www.planetcobalt.net/sdb/backscatter.shtml WFM, but AFAIK not tested outside low
    Message 1 of 14 , Feb 1, 2011
    • 0 Attachment
      On 2011-02-02 Simon wrote:
      > We are receiving what appears to be backscatter from spam that is
      > using a valid address in the Return Path. I have included an example
      > of the header info from one of the spam messages below. The ?From? and
      > ?To? addresses just seem to be random and are not related to us in any
      > way. Does anyone know to block this sort of backscatter?

      I wrote a backscatter filter based on smtpprox to handle this.

      http://www.planetcobalt.net/sdb/backscatter.shtml

      WFM, but AFAIK not tested outside low traffic environments.

      Regards
      Ansgar Wiechers
      --
      "Abstractions save us time working, but they don't save us time learning."
      --Joel Spolsky
    • Noel Jones
      ... The client 195.191.72.102 is listed in zen.spamhaus.org. I would start with using reject_rbl_client zen.spamhaus.org somewhere in your config. And then
      Message 2 of 14 , Feb 1, 2011
      • 0 Attachment
        On 2/1/2011 5:39 PM, Simon wrote:
        > We are using postfix with debian lenny...
        >
        >
        > We are receiving what appears to be backscatter from spam that
        > is using a valid address in the Return Path. I have included
        > an example of the header info from one of the spam messages
        > below. The “From” and “To” addresses just seem to be random
        > and are not related to us in any way. Does anyone know to
        > block this sort of backscatter?
        >
        >
        > Original message headers:
        >
        > Return-Path: <soa@*
        > <mailto:soa@...>*[ourdomain.actual.domain]**>
        > Received: from 195-191-72-102.optolan.net.ua
        > <http://195-191-72-102.optolan.net.ua> (unknown [195.191.72.102])


        The client 195.191.72.102 is listed in zen.spamhaus.org. I
        would start with using reject_rbl_client zen.spamhaus.org
        somewhere in your config.

        And then add the backscatter.org RBL as someone else suggested.
        http://www.backscatterer.org/?target=usage (see the postfix
        section)



        -- Noel Jones
      • Simon
        ... Hmm - thats interesting: our config allready as: smtpd_recipient_restrictions = ... reject_rbl_client zen.spamhaus.org, ... Do i need to setup sender
        Message 3 of 14 , Feb 1, 2011
        • 0 Attachment
          On Wed, Feb 2, 2011 at 1:29 PM, Noel Jones <njones@...> wrote:


          Return-Path: <soa@*
          <mailto:soa@...>*[ourdomain.actual.domain]**> <http://195-191-72-102.optolan.net.ua> (unknown [195.191.72.102])


          The client 195.191.72.102 is listed in zen.spamhaus.org.  I would start with using  reject_rbl_client zen.spamhaus.org somewhere in your config.

          And then add the backscatter.org RBL as someone else suggested.
          http://www.backscatterer.org/?target=usage  (see the postfix section)

          Hmm - thats interesting: our config allready as:

          smtpd_recipient_restrictions = 
              ...
              reject_rbl_client zen.spamhaus.org,
              ...

          Do i need to setup sender restrictions as well?


        • Noel Jones
          ... [Please post in plain text. Your mail would be easier to read without the html mangling] Does your maillog contain examples of other hosts being rejected
          Message 4 of 14 , Feb 1, 2011
          • 0 Attachment
            On 2/1/2011 6:39 PM, Simon wrote:
            >
            >
            > On Wed, Feb 2, 2011 at 1:29 PM, Noel Jones
            > <njones@... <mailto:njones@...>> wrote:
            >
            >
            >
            > Return-Path: <soa@*
            > <mailto:soa@...
            > <mailto:soa@...>>*[ourdomain.actual.domain]**>
            >
            > Received: from 195-191-72-102.optolan.net.ua
            > <http://195-191-72-102.optolan.net.ua>
            > <http://195-191-72-102.optolan.net.ua> (unknown
            > [195.191.72.102])
            >
            >
            >
            > The client 195.191.72.102 is listed in zen.spamhaus.org
            > <http://zen.spamhaus.org>. I would start with using
            > reject_rbl_client zen.spamhaus.org
            > <http://zen.spamhaus.org> somewhere in your config.
            >
            > And then add the backscatter.org <http://backscatter.org>
            > RBL as someone else suggested.
            > http://www.backscatterer.org/?target=usage (see the
            > postfix section)
            >
            >
            > Hmm - thats interesting: our config allready as:
            >
            > smtpd_recipient_restrictions =
            > ...
            > reject_rbl_client zen.spamhaus.org <http://zen.spamhaus.org>,
            > ...
            >
            > Do i need to setup sender restrictions as well?
            >
            >

            [Please post in plain text. Your mail would be easier to read
            without the html mangling]

            Does your maillog contain examples of other hosts being
            rejected by zen?
            # grep 'reject:.*zen.spamhaus' /path/to/maillog

            If yes, then everything is OK; likely that client simply
            wasn't yet listed when the mail arrived at your server.

            If you don't have any rejects from zen in your log, maybe your
            config is broken, or maybe zen doesn't answer your IP due to
            excessive queries.
            http://www.spamhaus.org/organization/dnsblusage.html

            If you need help with your config, show "postconf -n" output.


            -- Noel Jones
          • Simon
            ... Opps! Sorry! ... Yes we do have these rejections in the mail log, so that is good... here is the output of postfix -n if anyone can see anything basic we
            Message 5 of 14 , Feb 1, 2011
            • 0 Attachment
              On Wed, Feb 2, 2011 at 1:49 PM, Noel Jones <njones@...> wrote:
              >
              > [Please post in plain text.  Your mail would be easier to read without the html mangling]

              Opps! Sorry!

              > Does your maillog contain examples of other hosts being rejected by zen?
              > # grep 'reject:.*zen.spamhaus' /path/to/maillog
              >
              > If yes, then everything is OK; likely that client simply wasn't yet listed when the mail arrived at your server.
              >
              > If you don't have any rejects from zen in your log, maybe your config is broken, or maybe zen doesn't answer your IP due to excessive queries.
              > http://www.spamhaus.org/organization/dnsblusage.html
              >
              > If you need help with your config, show "postconf -n" output.

              Yes we do have these rejections in the mail log, so that is good...
              here is the output of postfix -n if anyone can see anything basic we
              are missing (about 60,000 emails in per day, approx 50k rejected):

              # postconf -n
              alias_database = hash:/etc/aliases
              alias_maps = hash:/etc/aliases
              append_dot_mydomain = no
              biff = no
              body_checks = regexp:/etc/postfix/body_checks
              config_directory = /etc/postfix
              content_filter = smtp-amavis:[127.0.0.1]:10024
              inet_interfaces = all
              mailbox_size_limit = 0
              maximal_backoff_time = 2000
              message_size_limit = 52428800
              mime_header_checks = regexp:/etc/postfix/mime_header_checks.regexp
              minimal_backoff_time = 500
              mydestination = mysql:/etc/postfix/mysql-transport.cf
              myhostname = mail-in1.ourdomain.com
              mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
              myorigin = /etc/mailname
              queue_run_delay = 500
              readme_directory = no
              recipient_delimiter = +
              relayhost =
              smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
              smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
              smtpd_data_restrictions = reject_unauth_pipelining, permit
              smtpd_recipient_restrictions = check_recipient_access
              hash:/etc/postfix/access, permit_mynetworks,
              reject_unauth_destination,
              reject_unknown_sender_domain,
              reject_unknown_recipient_domain,
              reject_invalid_hostname,
              reject_non_fqdn_sender,
              reject_non_fqdn_recipient,
              reject_rbl_client zen.spamhaus.org,
              check_policy_service inet:127.0.0.1:10031,
              permit
              smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
              smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
              smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
              smtpd_use_tls = yes
              transport_maps = mysql:/etc/postfix/mysql-transport.cf
              undisclosed_recipients_header =
              unknown_local_recipient_reject_code = 550
              virtual_alias_maps = mysql:/etc/postfix/mysql-aliases.cf
            • Benny Pedersen
              ... a ... job.com spam
              Message 6 of 14 , Feb 1, 2011
              • 0 Attachment
                On Wed, 2 Feb 2011 12:39:12 +1300, Simon <greminn@...> wrote:

                > We are receiving what appears to be backscatter from spam that is using
                a
                > valid address in the Return Path. I have included an example of the

                job.com spam
              • /dev/rob0
                ... (Snipped was the To: address @tenthfloor.org -- this domain is served by ns{1,2}.counselschambers.com.au as MX. The instant Received: header went on to
                Message 7 of 14 , Feb 1, 2011
                • 0 Attachment
                  On Tue, Feb 01, 2011 at 06:29:37PM -0600, Noel Jones wrote:
                  > On 2/1/2011 5:39 PM, Simon wrote:
                  > >We are receiving what appears to be backscatter from spam that
                  > >is using a valid address in the Return Path. I have included
                  > >an example of the header info from one of the spam messages
                  > >below. The “From” and “To” addresses just seem to be random
                  > >and are not related to us in any way. Does anyone know to
                  > >block this sort of backscatter?
                  > >
                  > >
                  > >Original message headers:
                  > >
                  > >Return-Path: <soa@*
                  > ><mailto:soa@...>*[ourdomain.actual.domain]**>
                  > >Received: from 195-191-72-102.optolan.net.ua
                  > ><http://195-191-72-102.optolan.net.ua> (unknown [195.191.72.102])

                  (Snipped was the To: address @... -- this domain is
                  served by ns{1,2}.counselschambers.com.au as MX. The instant
                  Received: header went on to mention that it was received at
                  smtp-0.counselschambers.com.au -- same IP as ns1.)

                  > The client 195.191.72.102 is listed in zen.spamhaus.org. I would
                  > start with using reject_rbl_client zen.spamhaus.org somewhere in
                  > your config.

                  While this may be so, the OP probably received this as backscatter
                  from smtp.counselschambers.com.au[218.185.94.178], which currently is
                  listed on the backscatterer.org DNSBL. We (the Internet as a whole)
                  would benefit if more backscattering sites used Zen and other spam
                  control techniques, but the issue at hand is to block it after it's
                  backscatterred.

                  > And then add the backscatter.org RBL as someone else suggested.
                  > http://www.backscatterer.org/?target=usage (see the postfix
                  > section)

                  [sort-of thread hijacking here, sorry]

                  I put this one in my postscreen_dnsbl_sites with a low weight, but
                  I'm not sure it will do much good there. I guess it should probably
                  be called from check_sender_access in smtpd restrictions.

                  That said, some manual log scanning has showed that it has pushed a
                  few results over my postscreen_dnsbl_threshold, and those did indeed
                  look spammy, so it probably won't hurt if left there.
                  --
                  Offlist mail to this address is discarded unless
                  "/dev/rob0" or "not-spam" is in Subject: header
                • Daniel Bromberg
                  ... This reminds me, if rather tangentially, of a recent type of pernicious spam I got that originated from a Yahoo web mail client and thus avoid detection
                  Message 8 of 14 , Feb 1, 2011
                  • 0 Attachment
                    On 2/1/2011 8:40 PM, /dev/rob0 wrote:
                    > While this may be so, the OP probably received this as backscatter
                    > from smtp.counselschambers.com.au[218.185.94.178], which currently is
                    > listed on the backscatterer.org DNSBL. We (the Internet as a whole)
                    > would benefit if more backscattering sites used Zen and other spam
                    > control techniques, but the issue at hand is to block it after it's
                    > backscatterred.
                    This reminds me, if rather tangentially, of a recent type of pernicious
                    spam I got that originated from a Yahoo web mail client and thus avoid
                    detection via any IP test. (I guess Yahoo's detection and accompanying
                    CAPTCHA gateway, which I discovered by role-playing the spammer, is
                    either inadequate or is somehow being avoided by the spammer.)

                    If we take the argument from UCEprotect.net literally, that the spammer
                    has accomplished his goal once he has delivered his "crap" to our server
                    whether or not SpamAssassin et al. classifies it correctly and socks it
                    away, then can we do better?

                    More of a general question, no clear technical answer expected. Any
                    insights?

                    -Daniel
                  • Stan Hoeppner
                    ... That doesn t look like backscatter. It s just spam. You should have been easily rejecting such crud: 10 dnsbls are listing that IP address as a spam
                    Message 9 of 14 , Feb 1, 2011
                    • 0 Attachment
                      Simon put forth on 2/1/2011 5:39 PM:

                      > We are receiving what appears to be backscatter from spam
                      ...

                      > Return-Path: <soa@* <soa@...>*[ourdomain.actual.domain]**>
                      > Received: from 195-191-72-102.optolan.net.ua (unknown [195.191.72.102])
                      > by smtp-0.counselschambers.com.au (Postfix) with ESMTP id
                      > 1D400396B7E
                      > for <soars@...>; Wed, 2 Feb 2011 08:28:43 +1100
                      > (EST)
                      > From: no-reply811@...
                      > To: <soars@...>
                      > Subject: Position opening in your area

                      That doesn't look like backscatter. It's just spam. You should have been
                      easily rejecting such crud: 10 dnsbls are listing that IP address as a spam source:

                      http://www.mxtoolbox.com/SuperTool.aspx?action=blacklist%3a195.191.72.102

                      You are apparently not using any dnsbls in your Postfix config (or the wrong
                      ones). At minimum you should be using Spamhaus ZEN. It is free of charge
                      unless you routinely do over 300,000 lookups a day.

                      It might be beneficial for you to send your postconf -n output so we can make
                      some anti spam configuration suggestions. This spam you're having a problem
                      with would likely not have made it past the normal spam filters of most people
                      on this list.

                      --
                      Stan
                    • Stan Hoeppner
                      ... So it looks like you got hit before it was listed (I should have read all the responses before my first reply). The parent /24 looks like part of a
                      Message 10 of 14 , Feb 1, 2011
                      • 0 Attachment
                        Stan Hoeppner put forth on 2/1/2011 11:21 PM:

                        > It might be beneficial for you to send your postconf -n output so we can make
                        > some anti spam configuration suggestions. This spam you're having a problem
                        > with would likely not have made it past the normal spam filters of most people
                        > on this list.

                        So it looks like you got hit before it was listed (I should have read all the
                        responses before my first reply).

                        The parent /24 looks like part of a broadband pool--all generic rDNS matching
                        one pattern. I've thus added the regex:

                        /^[0-9]{1,3}-[0-9]{1,3}-[0-9]{1,3}-[0-9]{1,3}\.optolan\.net\.ua$/

                        to http://www.hardwarefreak.com/fqrdns.pcre which will reject any client with
                        rDNS matching this pattern.

                        For those who don't already know, the file contains an additional 1600+ regexes
                        matching similar broadband/dynamic rDNS patterns and blocks much bot spam. FPs
                        will be extremely low, and will only include SOHO MTAs and "Linux weenies" (to
                        use Dave Crocker's term).

                        Usage instructions are comments at the top of the file. You may want to give
                        this a go Simon.

                        --
                        Stan
                      Your message has been successfully submitted and would be delivered to recipients shortly.