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

277660Re: SORBS and mailing lists

Expand Messages
  • /dev/rob0
    Jun 2, 2011
      On Thu, Jun 02, 2011 at 01:23:11PM +0200, Florian Effenberger wrote:
      > thanks for the fast replies. For me, the problem has been solved in
      > the meantime. SORBS indeed reacted quite fast (thanks again!). What


      > I am missing, though, is how to avoid that in the future. It is
      > most likely to happen that from time to time someone doesn't
      > manage how to get from the mailing lists they've subscribred to,
      > and then sends a spam complaint, rather than contacting us.

      DNSBLs such as SORBS are generally driven by spamtrap addresses, not
      complaints from humans. They have never-used email addresses, which
      when hit once or twice should not trigger a listing, but when the
      sending continues, listing occurs.

      The rationale behind that is that a spammer bot might have entered
      the trap address into a web form, and it's proper for that web form
      to send one confirmation mail. That's what NON-spammy bulk mailers
      do. Spammers just continue to send without the confirmation.

      You need to understand that anyone can decide to publish a DNSBL,
      listing on any arbitrary basis they might choose. And any mail
      operator can decide to use that DNSBL, then publishing his config in
      a HOWTO blog for the next hapless/clueless Googler. Of course it is
      quite possible for some DNSBLs to be trigger-happy: listing on a
      single spamtrap hit. Lists like that will list many legitimate list
      servers. If a receiver is foolish enough to rely on unreliable
      DNSBLs, there is nothing you can do about it.

      Email is a mess.

      > So, we can do as much as we can on our side, but if users make
      > errors, and miss talking to us, it will be hard to avoid it in
      > total, so if there is any best practice on this, that would be
      > indeed helpful.

      Best practice is to do what Mailman and majordomo and just about
      every known legitimate list server does: confirm addresses before
      adding the subscription.

      There's nothing more you can do beyond doing the right thing. My
      personal opinion is that it's wrong to work around the mistakes of
      incompetent mail admins. Those mistakes are exacerbating the spam

      > But this, as far as I understood, is off-topic, so I'll discuss
      > offlist. :)

      As Stan mentioned (thanks Stan), this would be welcome on SDLU:
      Offlist mail to this address is discarded unless
      "/dev/rob0" or "not-spam" is in Subject: header
    • Show all 7 messages in this topic