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

Re: greylisting generates error email?

Expand Messages
  • Grant
    ... I think what happened is the postscreen deep protocol checks did such an excellent job of reducing spam on their own that I figured the increased chance of
    Message 1 of 28 , Aug 17, 2013
    • 0 Attachment
      >> Do you use that config on a commercial mail server? I don't mean to
      >> say that you shouldn't, I'm just wondering if you do. In a commercial
      >> environment, the penalty for a false positive is a customer unable to
      >> reach the company behind the server which just isn't tolerable
      >
      > there is *no way* to have never ever false positivies
      >
      > and without spam protection someone deletes your message
      > within the 500 spam mails each day as collateral damagae
      >
      > in case of a false positive: the sender get a bounce from his mailserver
      > in case of deleted: it was silently dropped
      >
      > chosse one.....

      I think what happened is the postscreen deep protocol checks did such
      an excellent job of reducing spam on their own that I figured the
      increased chance of rejecting legitimate mail by using one or more IP
      lists wasn't worth dropping the small amount of remaining spam.

      - Grant
    • LuKreme
      ... zen is, for all practical purposes, perfect. You will not get false positives as everyone in zen is either a confirmed spammer or in the PBL (policy block
      Message 2 of 28 , Aug 19, 2013
      • 0 Attachment
        On 16 Aug 2013, at 07:13 , Grant <emailgrant@...> wrote:

        >>>> Use a dns white list with a negative score in the
        >>>> postscreen_dnsbl_sites, and set a negative value for
        >>>> postscreen_dnsbl_whitelist_threshold. Simple example:
        >>>> # main.cf
        >>>> postscreen_dnsbl_sites = zen.spamhaus.org list.dnswl.org*-1
        >>>> postscreen_dnsbl_whitelist_threshold = -1
        >>>
        >>> I've added the following to main.cf:
        >>>
        >>> postscreen_dnsbl_sites = list.dnswl.org*-1
        >>> postscreen_dnsbl_whitelist_threshold = -1
        >>>
        >>> Thank you for your help!
        >>
        >> Yes, that should whitelist known good sites from deep inspection,
        >> certainly all the big mailers such as google, yahoo, comcast, etc.
        >>
        >> However, I wonder why you don't have any dns blacklists such as
        >> zen.spamhaus.org defined there. The ability of postscreen to reject
        >> known bad sites without using precious smtpd processes is one of its
        >> key features.
        >
        > I would just rather have a false negative than a false positive. I
        > get a pretty small amount of spam at this point so I don't think
        > reducing it further is worth increasing the chances of a false
        > positive.

        zen is, for all practical purposes, perfect. You will not get false positives as everyone in zen is either a confirmed spammer or in the PBL (policy block list). That is to say, no one in zen should be connecting to your mailserver to send mail, ever.

        <http://www.spamhaus.org/zen/>

        zen blocks these categories:

        SBL Direct UBE sources, spam operations & spam services
        CSS Direct snowshoe spam sources detected via automation
        CBL (3rd party exploits such as proxies, trojans, etc.)
        PBL End-user Non-MTA IP addresses set by ISP outbound mail policy

        SBL and CSS are confirmed spammers. CBL are confirmed exploited machines. PBL are IPs that the IP owner has classified as not allowed to send mail directly.

        Blocking all of those is perfectly safe.

        --
        If lawyers are disbarred and clergymen defrocked, doesn't it follow that
        electricians can be delighted, musicians denoted?
      • Grant
        ... Would anyone agree/disagree with this? If there is a consensus that this is true, I will add zen.spamhaus.org to postscreen_dnsbl_sites. - Grant
        Message 3 of 28 , Aug 19, 2013
        • 0 Attachment
          > zen is, for all practical purposes, perfect. You will not get false positives as everyone in zen is either a confirmed spammer or in the PBL (policy block list). That is to say, no one in zen should be connecting to your mailserver to send mail, ever.
          >
          > <http://www.spamhaus.org/zen/>
          >
          > zen blocks these categories:
          >
          > SBL Direct UBE sources, spam operations & spam services
          > CSS Direct snowshoe spam sources detected via automation
          > CBL (3rd party exploits such as proxies, trojans, etc.)
          > PBL End-user Non-MTA IP addresses set by ISP outbound mail policy
          >
          > SBL and CSS are confirmed spammers. CBL are confirmed exploited machines. PBL are IPs that the IP owner has classified as not allowed to send mail directly.
          >
          > Blocking all of those is perfectly safe.

          Would anyone agree/disagree with this? If there is a consensus that
          this is true, I will add zen.spamhaus.org to postscreen_dnsbl_sites.

          - Grant
        • Erwan David
          On Tue, Aug 20, 2013 at 05:58:44AM CEST, LuKreme said: . ... Perfectly safe is the categorizing process is itself perfect. ANd since
          Message 4 of 28 , Aug 20, 2013
          • 0 Attachment
            On Tue, Aug 20, 2013 at 05:58:44AM CEST, LuKreme <kremels@...> said:
            .
            >
            > <http://www.spamhaus.org/zen/>
            >
            > zen blocks these categories:
            >
            > SBL Direct UBE sources, spam operations & spam services
            > CSS Direct snowshoe spam sources detected via automation
            > CBL (3rd party exploits such as proxies, trojans, etc.)
            > PBL End-user Non-MTA IP addresses set by ISP outbound mail policy
            >
            > SBL and CSS are confirmed spammers. CBL are confirmed exploited machines. PBL are IPs that the IP owner has classified as not allowed to send mail directly.
            >
            > Blocking all of those is perfectly safe.

            Perfectly safe is the categorizing process is itself perfect.
            ANd since nothing is perfect, you'll always have false positive.
          • Grant
            ... Has anyone had a confirmed false positive with zen.spamhaus.org ? - Grant
            Message 5 of 28 , Aug 20, 2013
            • 0 Attachment
              >> <http://www.spamhaus.org/zen/>
              >>
              >> zen blocks these categories:
              >>
              >> SBL Direct UBE sources, spam operations & spam services
              >> CSS Direct snowshoe spam sources detected via automation
              >> CBL (3rd party exploits such as proxies, trojans, etc.)
              >> PBL End-user Non-MTA IP addresses set by ISP outbound mail policy
              >>
              >> SBL and CSS are confirmed spammers. CBL are confirmed exploited machines. PBL are IPs that the IP owner has classified as not allowed to send mail directly.
              >>
              >> Blocking all of those is perfectly safe.
              >
              > Perfectly safe is the categorizing process is itself perfect.
              > ANd since nothing is perfect, you'll always have false positive.

              Has anyone had a confirmed false positive with zen.spamhaus.org ?

              - Grant
            • Jose Borges Ferreira
              ... machines. PBL are IPs that the IP owner has classified as not allowed to send mail directly. ... +1
              Message 6 of 28 , Aug 20, 2013
              • 0 Attachment


                On Aug 20, 2013 8:03 AM, "Erwan David" <erwan@...> wrote:
                >
                > On Tue, Aug 20, 2013 at 05:58:44AM CEST, LuKreme <kremels@...> said:
                > .
                > >
                > > <http://www.spamhaus.org/zen/>
                > >
                > > zen blocks these categories:
                > >
                > > SBL Direct UBE sources, spam operations & spam services
                > > CSS Direct snowshoe spam sources detected via automation
                > > CBL (3rd party exploits such as proxies, trojans, etc.)
                > > PBL End-user Non-MTA IP addresses set by ISP outbound mail policy
                > >
                > > SBL and CSS are confirmed spammers. CBL are confirmed exploited machines. PBL are IPs that the IP owner has classified as not allowed to send mail directly.
                > >
                > > Blocking all of those is perfectly safe.
                >
                > Perfectly safe is the categorizing process is itself perfect.
                > ANd since nothing is perfect, you'll always have false positive.

                +1

              • Stan Hoeppner
                ... http://lmgtfy.com/?q=spamhaus+false+positive -- Stan
                Message 7 of 28 , Aug 20, 2013
                • 0 Attachment
                  On 8/20/2013 3:06 AM, Grant wrote:

                  > Has anyone had a confirmed false positive with zen.spamhaus.org ?

                  http://lmgtfy.com/?q=spamhaus+false+positive

                  --
                  Stan
                • /dev/rob0
                  Whilst this subject is of some interest to many or most Postfix users, it has departed from being fully on topic here. It would fit better on a list like SDLU:
                  Message 8 of 28 , Aug 20, 2013
                  • 0 Attachment
                    Whilst this subject is of some interest to many or most Postfix
                    users, it has departed from being fully on topic here. It would fit
                    better on a list like SDLU: <http://spammers.dontlike.us>

                    [Disclaimer: I am a list moderator at SDLU.)

                    On Sat, Aug 17, 2013 at 10:39:25AM -0700, Grant wrote:
                    > > [attribution of quotes reconstructed]
                    rob0:
                    > > On Sat, Aug 17, 2013 at 12:54:44AM -0700, Grant wrote:
                    > >> Do you mean there aren't any legitimate servers listed in
                    > >> zen.spamhaus.org?
                    > >
                    > > Zen is a composite list, and indeed it is intended to be safe
                    > > for widespread use.
                    > >
                    > > SBL (Spamhaus Block List) lists IP addresses which are known
                    > > to be under the control of spammers.
                    > >
                    > > XBL (Exploits Block List) lists IP addresses which are actively
                    > > spewing bot spam. Legitimate servers are occasionally listed in
                    > > XBL, because they meet that condition. Some short time after they
                    > > stop their abuse, they are delisted. Typically this is less than
                    > > a day.
                    > >
                    > > PBL (Policy Block List) lists IP addresses which, according to
                    > > the netblock owners, should not normally be sending legitimate
                    > > email. Exceptions can be made for hosts with custom PTR upon
                    > > request. Many colocation providers submit their networks for PBL,
                    > > but removal is easy.
                    > >
                    > >> When I switched servers a while back, the new IP
                    > >> I received was listed on several blacklists and it was a hassle
                    > >> to get them removed.
                    > >
                    > > Far better that you go through that step than the Internet be
                    > > exposed to more spam.
                    >
                    > I agree, but the fact is that not everyone will go through that
                    > step.

                    You didn't understand. Those who do NOT get delisted from Zen *will*
                    face widespread delivery problems. No hard facts exist (nor could
                    valid statistics be collected), and it would vary by that site's
                    chosen set of sites they wish to send mail to, but in general I bet
                    they're going to have delivery problems for >75% of their mail.

                    This is speaking from my own experience when moving a server to a
                    PBL-listed IP address. Before getting the removal approved, my logs
                    were clogged with rejections. It was embarrassing. When I discovered
                    the problem I rerouted mail through a nonlisted relayhost until
                    delisted.

                    I have also seen this at exploited sites where I have been called in
                    to do the cleanup.

                    Let them be lazy. If they want to participate in Internet mail,
                    they're going to take the time to get removed from PBL.

                    None of the anti-DNSBL zealots can dispute this fact. In fact, this
                    is one of the things they so despise about Spamhaus: they have been
                    granted "too much power" by many email administrators, large and
                    small.

                    (I apologise to the "anti-DNSBL zealots" for the name calling. I'm a
                    pro-DNSBL and pro-Spamhaus zealot myself. I accept the same label.
                    Spamhaus and other DNSBL services have all but eliminated my spam
                    problem. I am grateful for that.)

                    Why have we (TINW) given Spamhaus this power? Do they abuse it? What
                    would happen if they did?

                    Mail administrators support Spamhaus because they have been careful
                    and responsible in the exercise of that power. They make our job in
                    trying to keep the abuse out of users' mailboxes much easier. Also,
                    pre-DATA filtering is safer and more accurate than content-based
                    approaches.

                    There have indeed been suggestions of abuse of power by Spamhaus.
                    Many of these suggestions were put forth by spammers and spam
                    supporters (providers who are willing to sell service to spammers,
                    turning a blind eye or making excuses in response to abuse reports.)

                    I'd say those constitute the majority of complaints, in fact. But to
                    be fair, there are other complaints. One I am aware of is the
                    Austrian national NIC (dot-AT registry.) Austrian law is demonstrably
                    spam-friendly regarding domain registrations.

                    (I don't care about Austrian law. To a large extent I don't even care
                    about laws where I live and where my server is situated. Spam is
                    crime, and such crime is not excused by ignorant laws. Any valid law
                    which is going to require me to accept and handle spam will also
                    reimburse my costs in doing so. None of them do. So I block spam,
                    including some CAN-SPAM compliant hosts on my US-based server. The
                    You-Can-Spam law doesn't pay to accept spam.)

                    To answer my final question above, if Spamhaus went overboard and
                    became like a SORBS, blocking mail providers who have occasional
                    issues with spam, well, I'd relegate them to the same status I did
                    SORBS. I consider SORBS' opinion on a client useful, but not enough
                    to consider the mail to be spam and worthy of blocking.

                    I am sure that Spamhaus administrators know this. Thus they are
                    careful and responsible.

                    > > Here's my example postscreen configuration which is intended
                    > > to be safe and reasonable for most uses:
                    > > http://rob0.nodns4.us/postscreen.html
                    >
                    > Do you use that config on a commercial mail server? I don't mean
                    > to say that you shouldn't, I'm just wondering if you do. In a

                    Not much. The majority of traffic is from and to a free software
                    project. I have, however, set up mail services for SMBs using these
                    policies or similar. (But I am not involved in the day-to-day
                    management of those sites.) My only commercial users are individual
                    consultancies such as myself.

                    > commercial environment, the penalty for a false positive is a
                    > customer unable to reach the company behind the server which just
                    > isn't tolerable.

                    "Commercial" is an arbitrary distinction. Many commercial sites say
                    things like this: "Our userbase, our customers, and our suppliers are
                    all in the USA, so we will block everything coming from outside the
                    USA." It might even work for some of them. It certainly would NOT be
                    acceptable for a free software project, with contributors and users
                    from all over the world, including Russia, Nigeria, China, and Korea.

                    "False positive" is also an arbitrary concept. If a sending client
                    listed on Zen comes to me, I reject it. That is a positive, nothing
                    "false" about it.

                    Okay, that is splitting hairs. I know what you mean by "false
                    positive": you mean "non-spam which is rejected."

                    The sending client gives its user a DSN informing said user of the
                    rejection. They can contact me and provide the information therein.
                    It's in my log, and I can see it was a Zen-listed host. I can give
                    them the same URL that my rejection notice did[1] and advise them to
                    fix whatever problem caused the listing. (I can even offer to fix it
                    for them, if they want to hire me. ;) )

                    The whole point is this, again: the Zen-listed host is having these
                    problems ALL OVER. I'm surely not the only site that rejected their
                    mail. Far more effective for them, rather than complaining to me, is
                    to get off the Zen list.

                    If they're on SBL, stop spamming! I don't even want non-UBE from
                    known spammers. If they think they're not spamming, let them make
                    their case with the folks at Spamhaus, who, I can guarantee, would
                    love to talk to them about it.

                    If they're on XBL, stop the exploit! Their site is being actively
                    used for the benefit of a spammer. Fix that!

                    If they're on PBL, follow the removal procedure. If they can't get
                    removed, such as for lack of custom PTR, find real hosting where
                    they're allowed to run a mail server.



                    [1] That's only true of hosts which get through postscreen to smtpd.
                    Postscreen does not provide the DNSBL's TXT record.
                    --
                    http://rob0.nodns4.us/ -- system administration and consulting
                    Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
                  Your message has been successfully submitted and would be delivered to recipients shortly.