DNS Tests not always getting done - SpamAssassin

This is a discussion on DNS Tests not always getting done - SpamAssassin ; Periodically I have seen spam come in my inbox and after reviewing the headers, I'd see that it didn't hit any of the DNS/URL BL checks. So I left SA running in debug mode for a while and saw some ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 28

Thread: DNS Tests not always getting done

  1. DNS Tests not always getting done

    Periodically I have seen spam come in my inbox and after reviewing the
    headers, I'd see that it didn't hit any of the DNS/URL BL checks. So I
    left SA running in debug mode for a while and saw some strange entries
    (sorry for the long post here). Fortunately, these don't happen too
    often, but I would like to know if there is anything I can do...
    1) ...to configure my setup more correctly. For instance, I believe
    spamhaus is now closed, correct? I see that same abort message in EVERY
    message. So, how should I disable the spamhaus check. Or, if it is
    still working, why is mine not?

    2) What can I do in procmail to check to make sure the DNS tests were
    completed? Maybe give each mail a second or third chance to get the DNS
    checks done. I'll probably have to pick one or two of them and call
    them vital, and run a check against them just to see if it was
    successful in testing the message, and if not, do it again. Something
    like that, perhaps???

    Skip

    Here are the logs:
    Went well
    [28851] dbg: async: escaping: lost or timed out requests or responses
    [28851] dbg: async: aborting after 22.349 s, past original deadline:
    DNSBL-A, dns:A:250.101.133.209.zen.spamhaus.org.
    [28851] dbg: async: aborting after 11.761 s, deadline shrunk: URI-A,
    A:ns2.eonline.com.
    [28851] dbg: async: aborting after 11.760 s, deadline shrunk: URI-A,
    A:ns.eonline.com.
    [28851] dbg: async: aborting after 11.761 s, deadline shrunk: URI-A,
    A:ns1.atdc1.eonline.com.
    [28851] dbg: async: aborted 4 remaining lookups
    [28851] dbg: async: timing: 10.577 . dns:A:250.101.133.209.iadb.isipp.com.
    [28851] dbg: async: timing: 10.577 .
    dns:A:250.101.133.209.sa-accredit.habeas.com.
    [28851] dbg: async: timing: 10.577 .
    dns:A:response.broadcaster.g4tv.com.dob.sibl.suppo rt-intelligence.net.
    [28851] dbg: async: timing: 10.578 .
    dns:TXT:250.101.133.209.sa-trusted.bondedsender.org.
    [28851] dbg: async: timing: 10.579 . dns:A:250.101.133.209.list.dnswl.org.
    [28851] dbg: async: timing: 10.579 .
    dns:A:response.broadcaster.g4tv.com.fulldom.rfc-ignorant.org.
    [28851] dbg: async: timing: 10.579 .
    dns:A:response.broadcaster.g4tv.com.bl.open-whois.org.
    [28851] dbg: async: timing: 10.580 . dns:TXT:250.101.133.209.list.dsbl.org.

    Not so well
    [11567] dbg: async: aborting after 24.824 s, past original deadline:
    DNSBL-A, dns:A:250.101.133.209.zen.spamhaus.org.
    [11567] dbg: async: aborting after 24.827 s, past original deadline:
    DNSBL-A, dns:A:response.broadcaster.g4tv.com.rhsbl.ahbl.org .
    [11567] dbg: async: aborting after 24.820 s, past original deadline:
    DNSBL-TXT, dns:TXT:250.101.133.209.sa-trusted.bondedsender.org.
    [11567] dbg: async: aborting after 24.833 s, past original deadline:
    URI-DNSBL, DNSBL:multi.uribl.com.:g4tv.com
    [11567] dbg: async: aborting after 24.826 s, past original deadline:
    DNSBL-A, dns:A:250.101.133.209.dob.sibl.support-intelligence.net.
    [11567] dbg: async: aborting after 24.823 s, past original deadline:
    DNSBL-A,
    dns:A:response.broadcaster.g4tv.com.dob.sibl.suppo rt-intelligence.net.
    [11567] dbg: async: aborting after 24.829 s, past original deadline:
    DNSBL-A, dns:A:250.101.133.209.plus.bondedsender.org.
    [11567] dbg: async: aborting after 24.833 s, past original deadline:
    URI-DNSBL, DNSBL:bl.open-whois.org.:g4tv.com
    [11567] dbg: async: aborting after 24.825 s, past original deadline:
    NO_DNS_FOR_FROM, DNSBL-MX, dns:MX:response.broadcaster.g4tv.com
    [11567] dbg: async: aborting after 24.832 s, past original deadline:
    URI-DNSBL, DNSBL:rhsbl.ahbl.org.:g4tv.com
    [11567] dbg: async: aborting after 24.822 s, past original deadline:
    DNSBL-A, dns:A:250.101.133.209.sa-accredit.habeas.com.
    [11567] dbg: async: aborting after 24.828 s, past original deadline:
    DNSBL-A, dns:A:250.101.133.209.combined.njabl.org.
    [11567] dbg: async: aborting after 24.830 s, past original deadline:
    URI-NS, NS:g4tv.com
    [11567] dbg: async: aborting after 24.819 s, past original deadline:
    DNSBL-A, dns:A:response.broadcaster.g4tv.com.bl.open-whois.org.
    [11567] dbg: async: aborting after 24.825 s, past original deadline:
    NO_DNS_FOR_FROM, DNSBL-A, dns:A:response.broadcaster.g4tv.com
    [11567] dbg: async: aborting after 24.818 s, past original deadline:
    DNSBL-A, dns:A:250.101.133.209.iadb.isipp.com.
    [11567] dbg: async: aborting after 24.831 s, past original deadline:
    URI-DNSBL, DNSBL:multi.surbl.org.:g4tv.com
    [11567] dbg: async: aborted 17 remaining lookups
    [11567] dbg: async: timing: 8.995 .
    dns:A:response.broadcaster.g4tv.com.fulldom.rfc-ignorant.org.
    [11567] dbg: async: timing: 8.997 . dns:TXT:250.101.133.209.list.dsbl.org.
    [11567] dbg: async: timing: 8.998 . dns:A:250.101.133.209.dnsbl.sorbs.net.
    [11567] dbg: async: timing: 8.998 . dns:A:250.101.133.209.list.dnswl.org.
    [11567] dbg: async: timing: 9.003 . dns:TXT:250.101.133.209.bl.spamcop.net.
    [11567] dbg: async: timing: 9.007 .
    DNSBL:dob.sibl.support-intelligence.net:g4tv.com

    or also not so well
    [27711] dbg: async: escaping: lost or timed out requests or responses
    [27711] dbg: async: aborting after 14.799 s, deadline shrunk: DNSBL-A,
    dns:A:navy.mil.bl.open-whois.org.
    [27711] dbg: async: aborting after 14.807 s, deadline shrunk: DNSBL-A,
    dns:A:44.0.162.138.dob.sibl.support-intelligence.net.
    [27711] dbg: async: aborting after 14.800 s, deadline shrunk: DNSBL-TXT,
    dns:TXT:44.0.162.138.sa-trusted.bondedsender.org.
    [27711] dbg: async: aborting after 14.808 s, deadline shrunk: DNSBL-A,
    dns:A:navy.mil.rhsbl.ahbl.org.
    [27711] dbg: async: aborting after 14.806 s, deadline shrunk:
    NO_DNS_FOR_FROM, DNSBL-MX, dns:MX:navy.mil
    [27711] dbg: async: aborting after 14.809 s, deadline shrunk: DNSBL-TXT,
    dns:TXT:44.0.162.138.bl.spamcop.net.
    [27711] dbg: async: aborting after 14.801 s, deadline shrunk: DNSBL-TXT,
    dns:TXT:44.0.162.138.list.dsbl.org.
    [27711] dbg: async: aborting after 14.802 s, deadline shrunk: DNSBL-A,
    dns:A:44.0.162.138.list.dnswl.org.
    [27711] dbg: async: aborting after 14.817 s, deadline shrunk: URI-DNSBL,
    DNSBL:multi.uribl.com.elorus.org
    [27711] dbg: async: aborting after 14.805 s, deadline shrunk: DNSBL-A,
    dns:A:44.0.162.138.dnsbl.sorbs.net.
    [27711] dbg: async: aborting after 14.806 s, deadline shrunk: DNSBL-A,
    dns:A:44.0.162.138.zen.spamhaus.org.
    [27711] dbg: async: aborting after 14.812 s, deadline shrunk: URI-NS,
    NSelorus.org
    [27711] dbg: async: aborting after 14.816 s, deadline shrunk: URI-DNSBL,
    DNSBL:bl.open-whois.org.elorus.org
    [27711] dbg: async: aborting after 14.815 s, deadline shrunk: URI-DNSBL,
    DNSBL:rhsbl.ahbl.org.elorus.org
    [27711] dbg: async: aborting after 14.810 s, deadline shrunk: DNSBL-A,
    dns:A:44.0.162.138.combined.njabl.org.
    [27711] dbg: async: aborting after 14.813 s, deadline shrunk: URI-DNSBL,
    DNSBL:dob.sibl.support-intelligence.netelorus.org
    [27711] dbg: async: aborting after 14.803 s, deadline shrunk: DNSBL-A,
    dns:A:navy.mil.dob.sibl.support-intelligence.net.
    [27711] dbg: async: aborting after 14.807 s, deadline shrunk:
    NO_DNS_FOR_FROM, DNSBL-A, dns:A:navy.mil
    [27711] dbg: async: aborting after 14.798 s, deadline shrunk: DNSBL-A,
    dns:A:navy.mil.fulldom.rfc-ignorant.org.
    [27711] dbg: async: aborting after 14.797 s, deadline shrunk: DNSBL-A,
    dns:A:44.0.162.138.iadb.isipp.com.
    [27711] dbg: async: aborted 20 remaining lookups
    [27711] dbg: async: timing: 1.221 .
    dns:A:44.0.162.138.sa-accredit.habeas.com.
    [27711] dbg: async: timing: 1.232 .
    dns:A:44.0.162.138.plus.bondedsender.org.
    [27711] dbg: async: timing: 1.235 . DNSBL:multi.surbl.org.elorus.org
    [27711] dbg: async: timing: 14.797 X dns:A:44.0.162.138.iadb.isipp.com.
    [27711] dbg: async: timing: 14.798 X
    dns:A:navy.mil.fulldom.rfc-ignorant.org.

    --
    Get my PGP Public key here:
    http://pelorus.org/skip@pelorus.org_public_key.asc


  2. Re: DNS Tests not always getting done

    Skip wrote:
    > Periodically I have seen spam come in my inbox and after reviewing the
    > headers, I'd see that it didn't hit any of the DNS/URL BL checks. So I
    > left SA running in debug mode for a while and saw some strange entries
    > (sorry for the long post here). Fortunately, these don't happen too
    > often, but I would like to know if there is anything I can do...
    > 1) ...to configure my setup more correctly. For instance, I believe
    > spamhaus is now closed, correct? I see that same abort message in EVERY
    > message. So, how should I disable the spamhaus check. Or, if it is
    > still working, why is mine not?


    possibly because you (or your dns forwarder) generate(s) too many
    connections per day:
    http://www.spamhaus.org/organization/dnsblusage.html


    >
    > 2) What can I do in procmail to check to make sure the DNS tests were
    > completed? Maybe give each mail a second or third chance to get the DNS
    > checks done. I'll probably have to pick one or two of them and call
    > them vital, and run a check against them just to see if it was
    > successful in testing the message, and if not, do it again. Something
    > like that, perhaps???


    I don't understand this part.


  3. Re: DNS Tests not always getting done

    mouss wrote:
    > Skip wrote:
    >> Periodically I have seen spam come in my inbox and after reviewing
    >> the headers, I'd see that it didn't hit any of the DNS/URL BL
    >> checks. So I left SA running in debug mode for a while and saw some
    >> strange entries (sorry for the long post here). Fortunately, these
    >> don't happen too often, but I would like to know if there is anything
    >> I can do...
    >> 1) ...to configure my setup more correctly. For instance, I believe
    >> spamhaus is now closed, correct? I see that same abort message in
    >> EVERY message. So, how should I disable the spamhaus check. Or, if
    >> it is still working, why is mine not?

    >
    > possibly because you (or your dns forwarder) generate(s) too many
    > connections per day:
    > http://www.spamhaus.org/organization/dnsblusage.html
    >
    >
    >>
    >> 2) What can I do in procmail to check to make sure the DNS tests were
    >> completed? Maybe give each mail a second or third chance to get the
    >> DNS checks done. I'll probably have to pick one or two of them and
    >> call them vital, and run a check against them just to see if it was
    >> successful in testing the message, and if not, do it again.
    >> Something like that, perhaps???

    >
    > I don't understand this part.
    >


    Looks like they have timeouts. Make sure you use a local caching
    nameserver. Sometimes things will just timeout due to other issues, but
    a caching nameserver helps big time.


  4. Re: DNS Tests not always getting done



    Richard Frovarp wrote:
    > mouss wrote:
    >> Skip wrote:
    >>> Periodically I have seen spam come in my inbox and after reviewing
    >>> the headers, I'd see that it didn't hit any of the DNS/URL BL
    >>> checks. So I left SA running in debug mode for a while and saw some
    >>> strange entries (sorry for the long post here). Fortunately, these
    >>> don't happen too often, but I would like to know if there is
    >>> anything I can do...
    >>> 1) ...to configure my setup more correctly. For instance, I believe
    >>> spamhaus is now closed, correct? I see that same abort message in
    >>> EVERY message. So, how should I disable the spamhaus check. Or, if
    >>> it is still working, why is mine not?

    >>
    >> possibly because you (or your dns forwarder) generate(s) too many
    >> connections per day:
    >> http://www.spamhaus.org/organization/dnsblusage.html
    >>
    >>
    >>>
    >>> 2) What can I do in procmail to check to make sure the DNS tests
    >>> were completed? Maybe give each mail a second or third chance to
    >>> get the DNS checks done. I'll probably have to pick one or two of
    >>> them and call them vital, and run a check against them just to see
    >>> if it was successful in testing the message, and if not, do it
    >>> again. Something like that, perhaps???

    >>
    >> I don't understand this part.
    >>

    >
    > Looks like they have timeouts. Make sure you use a local caching
    > nameserver. Sometimes things will just timeout due to other issues,
    > but a caching nameserver helps big time.
    >

    As for too many connection per day, my domain certainly does not
    generate anywhere near the 100,000 connections spamhaus considers as the
    cutoff, but I'll be my host (bluehost) does. If all they check is
    originating IP address, then I'm sure I'll fall in that category.

    As for the timeouts, I won't have access to that, since I am on a shared
    hosting system, but are you sure that those errors are what's being
    reported by the local nameserver? I am surprised that every test would
    fail (that is, not complete) in one case, and then in the next case all
    but the spamhaus test would complete.

    Finally, as for the procmail question, what I meant was, when those test
    complete, and the IP addresses were hit in the test, it's easy for me to
    write a rule in procmail because SA puts information in the headers
    about this fact. However, on the contrary, if a message is tested and
    passes (NON_HIT), then SA has no reason to write anything additional in
    the header. Futhermore, if the test fails completely (times out, for
    instance, and no report made at all), then again, no information is
    added to the header of the email. I have no way to test in procmail
    whether the test failed or passed--I can only test whether it was a
    "HIT". I would like to know if there's a clever way to add a little
    more information about the results of these tests in the headers (call
    it "HIT", "NON_HIT", and "FAIL"), so I can make decisions whether or not
    to reprocess the message the SA.

    Skip

    --
    Get my PGP Public key here:
    http://pelorus.org/skip@pelorus.org_public_key.asc


  5. Re: DNS Tests not always getting done

    Skip wrote on Thu, 17 Jul 2008 16:19:07 -0400:

    > As for too many connection per day, my domain certainly does not
    > generate anywhere near the 100,000 connections spamhaus considers as the
    > cutoff, but I'll be my host (bluehost) does. If all they check is
    > originating IP address, then I'm sure I'll fall in that category.


    Yeah, you actually query the resolver at your hosting provider. As do
    others of his customers. That combined connection pool may well exceed the
    limits. In that case you could set up a local caching nameserver and no
    forwarders. However, this would also impact your other dns queries. It
    might actually be a good idea if SA developers allowed to use a different
    resolver for SA than the system resolver.

    >
    > As for the timeouts, I won't have access to that, since I am on a shared
    > hosting system, but are you sure that those errors are what's being
    > reported by the local nameserver? I am surprised that every test would
    > fail (that is, not complete) in one case, and then in the next case all
    > but the spamhaus test would complete.


    Intermittant problems mean that a DNS is overloaded. Could be the typical
    sign of "spamassassinating" an RBL. I'm not surprised that many of your
    open-whois.org lookups fail. It wouldn't be the first RBL that falls apart
    after it got promoted to default use in SA.

    It's also possible that your forwarder DNS is sometimes overloaded. If you
    get timeouts on five RBLs and next second all of them are well and then
    again on a bunch of them I'd say that the bottleneck could actually be the
    forwarder.

    Also, several of these RBL checks do not add any extra value in my eyes.
    For instance habeas and bondedsender. I would get rid at least of these. I
    have been switching off SA RBL checks on all my systems almost right after
    I started using it years ago and still do so. I also don't use any of the
    distributed fingerprint systems. I use three RBLs I trust on MTA level for
    rejection. That's *much* more efficient. In SA I use only the other network
    checks for SURBL etc. as these *are* effective. (Although looking at the
    hit count all but one have declined in accurateness from last year.)

    Kai

    --
    Kai Schätzl, Berlin, Germany
    Get your web at Conactive Internet Services: http://www.conactive.com


  6. Re: DNS Tests not always getting done


    On Jul 18, 2008, at 6:31, Kai Schaetzl wrote:

    > Skip wrote on Thu, 17 Jul 2008 16:19:07 -0400:
    >
    >> As for too many connection per day, my domain certainly does not
    >> generate anywhere near the 100,000 connections spamhaus considers
    >> as the
    >> cutoff, but I'll be my host (bluehost) does. If all they check is
    >> originating IP address, then I'm sure I'll fall in that category.

    >
    > Yeah, you actually query the resolver at your hosting provider. As do
    > others of his customers. That combined connection pool may well
    > exceed the
    > limits. In that case you could set up a local caching nameserver and
    > no
    > forwarders. However, this would also impact your other dns queries. It
    > might actually be a good idea if SA developers allowed to use a
    > different
    > resolver for SA than the system resolver.
    >
    >>
    >> As for the timeouts, I won't have access to that, since I am on a
    >> shared
    >> hosting system, but are you sure that those errors are what's being
    >> reported by the local nameserver? I am surprised that every test
    >> would
    >> fail (that is, not complete) in one case, and then in the next case
    >> all
    >> but the spamhaus test would complete.

    >
    > Intermittant problems mean that a DNS is overloaded. Could be the
    > typical
    > sign of "spamassassinating" an RBL. I'm not surprised that many of
    > your
    > open-whois.org lookups fail. It wouldn't be the first RBL that falls
    > apart
    > after it got promoted to default use in SA.
    >
    > It's also possible that your forwarder DNS is sometimes overloaded.
    > If you
    > get timeouts on five RBLs and next second all of them are well and
    > then
    > again on a bunch of them I'd say that the bottleneck could actually
    > be the
    > forwarder.
    >
    > Also, several of these RBL checks do not add any extra value in my
    > eyes.
    > For instance habeas and bondedsender. I would get rid at least of
    > these. I
    > have been switching off SA RBL checks on all my systems almost right
    > after
    > I started using it years ago and still do so. I also don't use any
    > of the
    > distributed fingerprint systems. I use three RBLs I trust on MTA
    > level for
    > rejection. That's *much* more efficient.


    Zen should be one of them. Which Other two RBLs do you trust?

    [...]

    --
    Sahil Tandon


  7. Re: DNS Tests not always getting done



    Kai Schaetzl wrote:
    > Skip wrote on Thu, 17 Jul 2008 16:19:07 -0400:
    >
    >
    >> As for too many connection per day, my domain certainly does not
    >> generate anywhere near the 100,000 connections spamhaus considers as the
    >> cutoff, but I'll be my host (bluehost) does. If all they check is
    >> originating IP address, then I'm sure I'll fall in that category.
    >>

    >
    > Yeah, you actually query the resolver at your hosting provider. As do
    > others of his customers. That combined connection pool may well exceed the
    > limits. In that case you could set up a local caching nameserver and no
    > forwarders. However, this would also impact your other dns queries. It
    > might actually be a good idea if SA developers allowed to use a different
    > resolver for SA than the system resolver.
    >
    >
    >> As for the timeouts, I won't have access to that, since I am on a shared
    >> hosting system, but are you sure that those errors are what's being
    >> reported by the local nameserver? I am surprised that every test would
    >> fail (that is, not complete) in one case, and then in the next case all
    >> but the spamhaus test would complete.
    >>

    >
    > Intermittant problems mean that a DNS is overloaded. Could be the typical
    > sign of "spamassassinating" an RBL. I'm not surprised that many of your
    > open-whois.org lookups fail. It wouldn't be the first RBL that falls apart
    > after it got promoted to default use in SA.
    >
    > It's also possible that your forwarder DNS is sometimes overloaded. If you
    > get timeouts on five RBLs and next second all of them are well and then
    > again on a bunch of them I'd say that the bottleneck could actually be the
    > forwarder.
    >
    > Also, several of these RBL checks do not add any extra value in my eyes.
    > For instance habeas and bondedsender. I would get rid at least of these. I
    > have been switching off SA RBL checks on all my systems almost right after
    > I started using it years ago and still do so. I also don't use any of the
    > distributed fingerprint systems. I use three RBLs I trust on MTA level for
    > rejection. That's *much* more efficient. In SA I use only the other network
    > checks for SURBL etc. as these *are* effective. (Although looking at the
    > hit count all but one have declined in accurateness from last year.)
    >
    > Kai
    >
    >

    Wow, I wonder how I am going to convince Bluehost that they are having
    issues.

    What's the best way to disable individual RBL checks? I'm also curious
    which tests you consider to be most effective on your system.

    I was actually thinking the same thing about configuring SA to use a
    different resolver, but could not find such a configuration option.

    Skip

    --
    Get my PGP Public key here:
    http://pelorus.org/skip@pelorus.org_public_key.asc


  8. Re: DNS Tests not always getting done


    >>

    > Wow, I wonder how I am going to convince Bluehost that they are having
    > issues.
    >
    > What's the best way to disable individual RBL checks? I'm also
    > curious which tests you consider to be most effective on your system.
    >
    > I was actually thinking the same thing about configuring SA to use a
    > different resolver, but could not find such a configuration option.
    >
    > Skip
    >

    What is the generally approved way to disable individual RBL checks? I
    can easily disable all of them, but I haven't figured out how to disable
    individual ones.

    Skip

    --
    Get my PGP Public key here:
    http://pelorus.org/skip@pelorus.org_public_key.asc


  9. Re: DNS Tests not always getting done

    Hi!

    >> I was actually thinking the same thing about configuring SA to use a
    >> different resolver, but could not find such a configuration option.


    > What is the generally approved way to disable individual RBL checks? I can
    > easily disable all of them, but I haven't figured out how to disable
    > individual ones.


    Just score the tests you want to disable 0.

    Bye,
    Raymond.


  10. Re: DNS Tests not always getting done

    But I want to stop the test from even being done at all. I guess I
    should have included more of the previous post. Sorry

    Skip


    Raymond Dijkxhoorn wrote:
    > Hi!
    >
    >>> I was actually thinking the same thing about configuring SA to use a
    >>> different resolver, but could not find such a configuration option.

    >
    >> What is the generally approved way to disable individual RBL checks?
    >> I can easily disable all of them, but I haven't figured out how to
    >> disable individual ones.

    >
    > Just score the tests you want to disable 0.
    >
    > Bye,
    > Raymond.
    >


    --
    Get my PGP Public key here:
    http://pelorus.org/skip@pelorus.org_public_key.asc


  11. Re: DNS Tests not always getting done

    Hi!

    > But I want to stop the test from even being done at all. I guess I should
    > have included more of the previous post. Sorry


    >> Just score the tests you want to disable 0.


    Same answer, just score them 0.

    Bye,
    Raymond.


  12. Re: DNS Tests not always getting done

    Skip wrote:

    > But I want to stop the test from even being done at all. I guess I should
    > have included more of the previous post. Sorry


    Please do not top-post (google if you are unfamiliar with the term). And as
    already advised, just set score to 0 to disable individual DNSBLs. To
    disable all checks, set skip_rbl_checks to 1. This functionality is noted in
    the documentation:

    http://wiki.apache.org/spamassassin/DnsBlocklists

    --
    Sahil Tandon


  13. Re: DNS Tests not always getting done

    "Skip" wrote in message
    news:487F914D.8080104@pelorus.org...
    > Periodically I have seen spam come in my inbox and after reviewing the
    > headers, I'd see that it didn't hit any of the DNS/URL BL checks. So I
    > left SA running in debug mode for a while and saw some strange entries
    > (sorry for the long post here). Fortunately, these don't happen too
    > often, but I would like to know if there is anything I can do...
    > 1) ...to configure my setup more correctly. For instance, I believe
    > spamhaus is now closed, correct? I see that same abort message in EVERY
    > message. So, how should I disable the spamhaus check. Or, if it is
    > still working, why is mine not?


    Increase your timeout value.

    > 2) What can I do in procmail to check to make sure the DNS tests ...


    Procmail is too late. To get to that step, you've already accepted the
    message for delivery.



  14. Re: DNS Tests not always getting done



    Sahil Tandon wrote:
    > Skip wrote:
    >
    >
    >> But I want to stop the test from even being done at all. I guess I should
    >> have included more of the previous post. Sorry
    >>

    >
    > Please do not top-post (google if you are unfamiliar with the term). And as
    > already advised, just set score to 0 to disable individual DNSBLs. To
    > disable all checks, set skip_rbl_checks to 1. This functionality is noted in
    > the documentation:
    >
    > http://wiki.apache.org/spamassassin/DnsBlocklists
    >
    >

    Sorry about that I am actually quite familiar with bottom posting
    and wish it were used in the workplace, but I doubt we'll ever see
    that. And thanks for the answer to my question.

    Anyway, please bear with me as I do have a few more questions. In this
    thread before, some people thought I should look at a possible DNS
    problem, or perhaps my system is exceeding the daily threshold for
    spamhaus. All they say at the spamhaus FAQ is that if you exceed the
    threshold "your access to Spamhaus's public DNSBL servers is very likely
    to be cut off without warning". We already established that since I am
    on a shared hosting system, it is entirely possible that we (as a
    system, but not as a domain) may be exceeding the threshold, but I don't
    know how to go about checking at spamhaus to see if that is indeed the
    case. Anyway, I'd like to show one more snippet from my log, to see
    what you guys think.

    >grep spamhaus Procmail/pmlog-skip|grep 8874

    [8874] dbg: dns: checking RBL zen.spamhaus.org., set zen-lastexternal
    [8874] dbg: dns: launching DNS A query for 95.2.18.64.zen.spamhaus.org.
    in background
    [8874] dbg: async: starting: DNSBL-A, dns:A:95.2.18.64.zen.spamhaus.org.
    (timeout 15.0s, min 3.0s)
    [8874] dbg: dns: checking RBL zen.spamhaus.org., set zen-lastexternal
    [8874] dbg: dns: checking RBL zen.spamhaus.org., set zen
    [8874] dbg: dns: launching DNS A query for
    222.84.98.85.zen.spamhaus.org. in background
    [8874] dbg: async: starting: DNSBL-A,
    dns:A:222.84.98.85.zen.spamhaus.org. (timeout 15.0s, min 3.0s)
    [8874] dbg: async: starting: URI-DNSBL,
    DNSBL:sbl.spamhaus.org.:100.142.44.89 (timeout 15.0s, min 3.0s)
    [8874] dbg: async: completed in 5.040 s: URI-DNSBL,
    DNSBL:sbl.spamhaus.org.:100.142.44.89
    [8874] dbg: async: aborting after 7.527 s, deadline shrunk: DNSBL-A,
    dns:A:222.84.98.85.zen.spamhaus.org.
    [8874] dbg: async: aborting after 7.534 s, deadline shrunk: DNSBL-A,
    dns:A:95.2.18.64.zen.spamhaus.org.
    [8874] dbg: async: timing: 5.040 . DNSBL:sbl.spamhaus.org.:100.142.44.89
    [8874] dbg: async: timing: 7.527 X dns:A:222.84.98.85.zen.spamhaus.org.
    [8874] dbg: async: timing: 7.534 X dns:A:95.2.18.64.zen.spamhaus.org.

    Here you can see that three calls to spamhaus were going to be made for
    this message. The first call made it and was completed in 5.040 s. The
    other two were aborted after 7.5 s with that mysterious "deadline
    shrunk" message. Since I got a successful return on the first test, I
    don't think it could be a DNS problem on my end, but please correct me
    if I am mistaken and overlooking something. By the way, I googled
    "deadline shrunk". Twenty five hits total with the majority of them
    pointing to this thread and the spamassassin source code. No real
    help. Anyway, back to my log here. The one completed call is
    interesting because if you go to the spamhaus website, that IP address
    actually hits positive
    http://www.spamhaus.org/query/bl?ip=89.44.142.100
    *89.44.142.100 is listed in the SBL*, in the following records:

    * SBL65873
    * SBL65994

    But you'll notice that I don't get the hit message here in my log. In
    fact, I have never gotten a hit from spamhaus on ANY message.

    So, my question for the community is, what could I possibly have
    misconfigured here? Or is it most certainly that we (me and all
    customers using the same hosting company as me) are banned from spamhaus
    lookups do to our volume and I should look for resolution that way?
    Anyone know who I would email at spamhaus to find out? What information
    would I need to give them?

    Btw, I am using ver 3.2.4.

    Sorry for being such a pest, but before I go knocking on spamhaus'
    and/or bluehost's (my hosting company) door, I'd like to be as sure as
    possible about these things, and possibly even point them to this thread.

    Skip

    --
    Get my PGP Public key here:
    http://pelorus.org/skip@pelorus.org_public_key.asc


  15. Re: DNS Tests not always getting done

    Skip wrote:
    > [snip]
    > Anyway, please bear with me as I do have a few more questions. In this
    > thread before, some people thought I should look at a possible DNS
    > problem, or perhaps my system is exceeding the daily threshold for
    > spamhaus. All they say at the spamhaus FAQ is that if you exceed the
    > threshold "your access to Spamhaus's public DNSBL servers is very likely
    > to be cut off without warning". We already established that since I am
    > on a shared hosting system, it is entirely possible that we (as a
    > system, but not as a domain) may be exceeding the threshold, but I don't
    > know how to go about checking at spamhaus to see if that is indeed the
    > case.


    try:

    $ host 2.0.0.127.zen.spmahaus.org
    2.0.0.127.zen.spamhaus.org has address 127.0.0.4
    2.0.0.127.zen.spamhaus.org has address 127.0.0.10
    2.0.0.127.zen.spamhaus.org has address 127.0.0.2


    BTW, what DNS server(s) are you using?

    > [snip]
    >



  16. Re: DNS Tests not always getting done



    mouss wrote:
    > Skip wrote:
    >> [snip]
    >> Anyway, please bear with me as I do have a few more questions. In
    >> this thread before, some people thought I should look at a possible
    >> DNS problem, or perhaps my system is exceeding the daily threshold
    >> for spamhaus. All they say at the spamhaus FAQ is that if you exceed
    >> the threshold "your access to Spamhaus's public DNSBL servers is very
    >> likely to be cut off without warning". We already established that
    >> since I am on a shared hosting system, it is entirely possible that
    >> we (as a system, but not as a domain) may be exceeding the threshold,
    >> but I don't know how to go about checking at spamhaus to see if that
    >> is indeed the case.

    >
    > try:
    >
    > $ host 2.0.0.127.zen.spmahaus.org
    > 2.0.0.127.zen.spamhaus.org has address 127.0.0.4
    > 2.0.0.127.zen.spamhaus.org has address 127.0.0.10
    > 2.0.0.127.zen.spamhaus.org has address 127.0.0.2
    >
    >
    > BTW, what DNS server(s) are you using?
    >
    >> [snip]
    >>

    >
    >

    I got this:
    $ host 2.0.0.127.zen.spmahaus.org
    Host 2.0.0.127.zen.spmahaus.org not found: 3(NXDOMAIN)

    That can't be good. I do not know what dns server we are using at
    bluehost. I did a ps and searched for anything that looked like a dns
    server, but couldn't find any. Sometimes it can really suck being on a
    shared system like this.

    --
    Get my PGP Public key here:
    http://pelorus.org/skip@pelorus.org_public_key.asc


  17. Re: DNS Tests not always getting done

    Skip wrote:

    [...]

    >> try:
    >>
    >> $ host 2.0.0.127.zen.spmahaus.org
    >> 2.0.0.127.zen.spamhaus.org has address 127.0.0.4
    >> 2.0.0.127.zen.spamhaus.org has address 127.0.0.10
    >> 2.0.0.127.zen.spamhaus.org has address 127.0.0.2
    >>
    >> BTW, what DNS server(s) are you using?


    [...]

    > I got this:
    > $ host 2.0.0.127.zen.spmahaus.org
    > Host 2.0.0.127.zen.spmahaus.org not found: 3(NXDOMAIN)


    I see the same thing.

    > That can't be good. I do not know what dns server we are using at
    > bluehost. I did a ps and searched for anything that looked like a dns
    > server, but couldn't find any. Sometimes it can really suck being on a
    > shared system like this.


    What are the contents of /etc/resolv.conf?

    --
    Sahil Tandon


  18. Re: DNS Tests not always getting done

    Skip wrote:
    > I got this:
    > $ host 2.0.0.127.zen.spmahaus.org
    > Host 2.0.0.127.zen.spmahaus.org not found: 3(NXDOMAIN)
    >
    > That can't be good. I do not know what dns server we are using at
    > bluehost. I did a ps and searched for anything that looked like a dns
    > server, but couldn't find any. Sometimes it can really suck being on
    > a shared system like this.


    Skip,

    I tried to visit your web site, and got the following:

    ******************************
    Please contact this site's webmaster.

    Wait a few minutes and use your browser's "Back" button or click here
    :history.go(-1)> to try again.

    ------------------------------------------------------------------------
    If you are the webmaster, your account may have gotten this error for
    one or more of the following reasons:

    * Your account has used more than its share of the cpu in the past
    60 second sliding window.
    * Your account has too many concurrent processes running simultanously.
    * Your account has consumed too much memory.
    * Your site was recently very busy trying to run inefficient scripts.

    The solution would be to optimize your applications to use less CPU.
    Adding appropriate indeces to your SQL tables can often help reduce CPU.
    Using static .html documents instead of painful .php scripts will
    practically eliminate CPU usage.
    ******************************

    Maybe that has something to do with the problem?

    --
    Rob McEwen
    http://dnsbl.invaluement.com/


  19. Re: DNS Tests not always getting done

    Sahil Tandon wrote:

    [...]

    > > I got this:
    > > $ host 2.0.0.127.zen.spmahaus.org
    > > Host 2.0.0.127.zen.spmahaus.org not found: 3(NXDOMAIN)

    ^^^
    > I see the same thing.


    Woops! We both just copy&pasted the same typo. :-) This should work:

    # host 2.0.0.127.zen.spamhaus.org
    2.0.0.127.zen.spamhaus.org has address 127.0.0.2
    2.0.0.127.zen.spamhaus.org has address 127.0.0.10
    2.0.0.127.zen.spamhaus.org has address 127.0.0.4

    [...]

    --
    Sahil Tandon


  20. Re: DNS Tests not always getting done

    Skip wrote:
    >
    >
    > mouss wrote:
    >> Skip wrote:
    >>> [snip]
    >>> Anyway, please bear with me as I do have a few more questions. In
    >>> this thread before, some people thought I should look at a possible
    >>> DNS problem, or perhaps my system is exceeding the daily threshold
    >>> for spamhaus. All they say at the spamhaus FAQ is that if you exceed
    >>> the threshold "your access to Spamhaus's public DNSBL servers is very
    >>> likely to be cut off without warning". We already established that
    >>> since I am on a shared hosting system, it is entirely possible that
    >>> we (as a system, but not as a domain) may be exceeding the threshold,
    >>> but I don't know how to go about checking at spamhaus to see if that
    >>> is indeed the case.

    >>
    >> try:
    >>
    >> $ host 2.0.0.127.zen.spmahaus.org
    >> 2.0.0.127.zen.spamhaus.org has address 127.0.0.4
    >> 2.0.0.127.zen.spamhaus.org has address 127.0.0.10
    >> 2.0.0.127.zen.spamhaus.org has address 127.0.0.2
    >>
    >>
    >> BTW, what DNS server(s) are you using?
    >>
    >>> [snip]
    >>>

    >>
    >>

    > I got this:
    > $ host 2.0.0.127.zen.spmahaus.org
    > Host 2.0.0.127.zen.spmahaus.org not found: 3(NXDOMAIN)
    >



    my bad, it's spamhaus, not spmahaus.


    > That can't be good.


    it's good for now try with the correct name...

    > I do not know what dns server we are using at
    > bluehost.


    First, look in your /etc/resolv.conf. this will show you where the
    nameservers are.

    > I did a ps and searched for anything that looked like a dns
    > server, but couldn't find any. Sometimes it can really suck being on a
    > shared system like this.



    Running a mail server on a shared system is problematic. if you only do
    filtering (and not MX or submission), it should work provided you get
    the DNS right.


+ Reply to Thread
Page 1 of 2 1 2 LastLast