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

273710Re: Spam Backscatter

Expand Messages
  • /dev/rob0
    Feb 1 5:40 PM
    • 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 [])

      (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 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[], 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

      > 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
    • Show all 14 messages in this topic