problem with RDNS_NONE: false positive - SpamAssassin

This is a discussion on problem with RDNS_NONE: false positive - SpamAssassin ; I'm experiencing a strange problem with RDNS_NONE. On the same sender host, sometimes it is marked with RDNS_NONE, and sometimes not. The host has a reverse dns! Example: Received: from dadosoftware.com (dns2.dadosoftware.com [217.199.13.2]) -> OK Received: from dadosoftware.com (unknown [217.199.13.2]) ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: problem with RDNS_NONE: false positive

  1. problem with RDNS_NONE: false positive

    I'm experiencing a strange problem with RDNS_NONE.

    On the same sender host, sometimes it is marked with RDNS_NONE, and
    sometimes not.

    The host has a reverse dns!

    Example:
    Received: from dadosoftware.com (dns2.dadosoftware.com [217.199.13.2]) -> OK

    Received: from dadosoftware.com (unknown [217.199.13.2]) -> FALSE POSITIVE

    But 217.199.13.2 has a reverse dns!
    2.13.199.217.in-addr.arpa. 11894 IN PTR dns2.dadosoftware.com.

    Who decides the presence of RDNS_NONE ?
    A real dns check or a parsing of the email headers?

    And, in case of parse who decides to write dns2.dadosoftware.com
    [217.199.13.2] instead of unknown [217.199.13.2]?

    Thanks to all in advance.

    --
    /*************/
    nik600
    http://www.kumbe.it


  2. Re: problem with RDNS_NONE: false positive


    > Example:
    > Received: from dadosoftware.com (dns2.dadosoftware.com [217.199.13.2]) ->
    > OK
    >
    > Received: from dadosoftware.com (unknown [217.199.13.2]) -> FALSE POSITIVE


    I get timeouts on one of the servers (dns2.bkom.it) responsible to resolve
    217.199.13.2. This may explain the inconsistent behaviour you're seeing (I
    wouldn't call it a false positive).

    -- Matthias


  3. Re: problem with RDNS_NONE: false positive

    On Thu, Oct 2, 2008 at 10:22 AM, Rasmus Haslund wrote:
    >>From: nik600 [mailto:nik600@gmail.com]
    >>And, in case of parse who decides to write dns2.dadosoftware.com

    > [217.199.13.2] instead of unknown >[217.199.13.2]?
    >
    > Your MTA decides to write unknown because it is most likely not
    > configured to perform reverse dns lookups - or it could just not resolve
    > it.
    >
    > NOWACO A/S
    > Rasmus Haslund
    >

    i'm not pretty sure about it because on the same mail sometimes it's resolved?

    Ok, this seems an MTA problem i'll investigate on it, so the RDNS_NONE
    is based on header parsing and not on a real dns check?



    --
    /*************/
    nik600
    http://www.kumbe.it


  4. Re: problem with RDNS_NONE: false positive

    On Thu, Oct 2, 2008 at 10:38 AM, Matthias Leisi wrote:
    >
    >> Example:
    >> Received: from dadosoftware.com (dns2.dadosoftware.com [217.199.13.2]) ->
    >> OK
    >>
    >> Received: from dadosoftware.com (unknown [217.199.13.2]) -> FALSE POSITIVE

    >
    > I get timeouts on one of the servers (dns2.bkom.it) responsible to resolve
    > 217.199.13.2. This may explain the inconsistent behaviour you're seeing (I
    > wouldn't call it a false positive).
    >
    > -- Matthias
    >
    >
    >


    Yeah, i were suspecting something about timeouts.. thanks!

    --
    /*************/
    nik600
    http://www.kumbe.it


  5. Re: problem with RDNS_NONE: false positive



    nik600 hotmail wrote:
    >
    > I'm experiencing a strange problem with RDNS_NONE.
    >
    > On the same sender host, sometimes it is marked with RDNS_NONE, and
    > sometimes not.
    >
    > The host has a reverse dns!
    >
    > Example:
    > Received: from dadosoftware.com (dns2.dadosoftware.com [217.199.13.2]) ->
    > OK
    >
    > Received: from dadosoftware.com (unknown [217.199.13.2]) -> FALSE POSITIVE
    >
    > But 217.199.13.2 has a reverse dns!
    > 2.13.199.217.in-addr.arpa. 11894 IN PTR dns2.dadosoftware.com.
    >
    > Who decides the presence of RDNS_NONE ?
    > A real dns check or a parsing of the email headers?
    >
    > And, in case of parse who decides to write dns2.dadosoftware.com
    > [217.199.13.2] instead of unknown [217.199.13.2]?
    >
    >


    Hello,

    I'm also experiencing some issues with RDNS_NONE, for example:


    Return-Path:
    Delivered-To: recipient@nekotectelecom.com
    Received: from mail.telcel.com (mail.telcel.com [200.38.208.219])
    by server.nekotec.com.mx (Postfix) with ESMTP id 8DE0DE42BD;
    Wed, 1 Oct 2008 13:10:42 -0500 (CDT)
    Received: from MXVIBOFICOR04 ([10.203.6.79])
    by xiang.telcel.com (Sun Java System Messaging Server 6.2-7.05 (built Sep
    5
    2006)) with ESMTP id <0K8200KZDNPVSTA0@xiang.telcel.com>; Wed,
    01 Oct 2008 13:08:20 -0500 (CDT)
    Date: Wed, 01 Oct 2008 13:10:08 -0500
    From: sender
    Subject: =?iso-8859-1?Q?RE:_Reuni=F3n_con_Sergio_Ruelas?=
    In-reply-to:
    To: some-email@mail.telcel.com, 'A Person'
    Cc: ='someone else' ,
    'Another Person'
    Reply-to: sender@mail.telcel.com
    Message-id: <001001c923f0$f0843850$2305c80a@ingenieria.telcel.n et>
    Organization: Radiomovil DIPSA S.A. DE C.V.
    MIME-version: 1.0
    X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
    X-Mailer: Microsoft Office Outlook 11
    Content-type: multipart/related;
    boundary="Boundary_(ID_qVeDaZ+jbYnMrmKcL4ak9w)"
    Thread-index: AckjH+1ELYTEgSMgStiE9TLFCGpJTwAER6RgAC/RkyA=
    X-TM-IMSS-Message-ID: <408092710013632f@mail.telcel.com>
    X-TM-AS-Product-Ver: IMSS-7.0.0.6219-5.5.0.1027-16192.001
    X-TM-AS-Result: No--29.940-7.0-31-1
    X-imss-scan-details: No--29.940-7.0-31-1;No--29.940-7.0-31-1
    X-Virus-Scanned: ClamAV version 0.94, clamav-milter version 0.94 on
    server.nekotec.com.mx
    X-Virus-Status: Clean
    X-Spam-Status: No, score=-6.7 required=2.5 tests=BAYES_00,HTML_MESSAGE,
    RDNS_NONE,SHORT_HELO_AND_INLINE_IMAGE,SNS_FROM_TEL CEL,SNS_HAM_KEYWORDS
    autolearn=ham version=3.2.5
    X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on
    server.nekotec.com.mx


    The PTR:

    ; <<>> DiG 9.3.4 <<>> -x 200.38.208.219
    ;; global options: printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8556
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

    ;; QUESTION SECTION:
    ;219.208.38.200.in-addr.arpa. IN PTR

    ;; ANSWER SECTION:
    219.208.38.200.in-addr.arpa. 2797 IN PTR mail.telcel.com.

    ;; AUTHORITY SECTION:
    208.38.200.in-addr.arpa. 2797 IN NS nsmex4.uninet.net.mx.
    208.38.200.in-addr.arpa. 2797 IN NS
    dnsadm-interno.uninet.net.mx.
    208.38.200.in-addr.arpa. 2797 IN NS nsmex3.uninet.net.mx.

    ;; ADDITIONAL SECTION:
    nsmex3.uninet.net.mx. 97 IN A 200.33.146.211
    nsmex4.uninet.net.mx. 157 IN A 200.33.146.217
    dnsadm-interno.uninet.net.mx. 157 IN A 200.33.150.193

    The fwd record matches:

    ; <<>> DiG 9.3.4 <<>> mail.telcel.com
    ;; global options: printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26651
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

    ;; QUESTION SECTION:
    ;mail.telcel.com. IN A

    ;; ANSWER SECTION:
    mail.telcel.com. 11456 IN A 200.38.208.219

    ;; AUTHORITY SECTION:
    telcel.com. 11456 IN NS dns1i.itelcel.com.
    telcel.com. 11456 IN NS dns01.amigokit.com.

    I have other hosts that trigger the RDNS_NONE rule as well. They are never
    enough to classify the message as spam, though. But it's kind of bothersome
    that SA fires up a false positive for rDNS.

    I'm really confused as to how SA parses the email to trigger (or not) the
    RDNS_NONE rule.

    Dan.


    --
    View this message in context: http://www.nabble.com/problem-with-R...p19780402.html
    Sent from the SpamAssassin - Users mailing list archive at Nabble.com.


  6. Re: problem with RDNS_NONE: false positive

    nik600 wrote:
    > I'm experiencing a strange problem with RDNS_NONE.
    >
    > On the same sender host, sometimes it is marked with RDNS_NONE, and
    > sometimes not.
    >
    > The host has a reverse dns!
    >
    > Example:
    > Received: from dadosoftware.com (dns2.dadosoftware.com [217.199.13.2]) -> OK
    >
    > Received: from dadosoftware.com (unknown [217.199.13.2]) -> FALSE POSITIVE


    you seem to have a special conception of "false positive"?

    your MTA can decide that it is "unknown" for many reasons, including:
    - not configured to lookup rdns
    - dns lookup timeout

    in these two cases, there is no point to talk about "false positive".

    >
    > But 217.199.13.2 has a reverse dns!
    > 2.13.199.217.in-addr.arpa. 11894 IN PTR dns2.dadosoftware.com.


    just for info, this is not enough. always check the returned name, like this

    $ host dns2.dadosoftware.com
    dns2.dadosoftware.com has address 217.199.13.2
    so the resulting IP is the original one. otherwise, the rdns is
    irrelevant (in case of mismatch, it is "unknown" in postfix, tcp
    wrappers, ... etc).


    >
    > Who decides the presence of RDNS_NONE ?
    > A real dns check or a parsing of the email headers?
    >
    > And, in case of parse who decides to write dns2.dadosoftware.com
    > [217.199.13.2] instead of unknown [217.199.13.2]?
    >


    for one, it is your MTA that does the dns lookup, so whatever it could
    be, it's not an SA issue.

    secundo, the default configuration has
    score RDNS_NONE 0.1

    if this causes an FP, then you must be living in a different Cantor space.


  7. Re: problem with RDNS_NONE: false positive




    nik600 hotmail wrote:
    >
    > I'm experiencing a strange problem with RDNS_NONE.
    >
    > On the same sender host, sometimes it is marked with RDNS_NONE, and
    > sometimes not.
    >
    > The host has a reverse dns!
    >
    > Example:
    > Received: from dadosoftware.com (dns2.dadosoftware.com [217.199.13.2]) ->
    > OK
    >
    > Received: from dadosoftware.com (unknown [217.199.13.2]) -> FALSE POSITIVE
    >
    > But 217.199.13.2 has a reverse dns!
    > 2.13.199.217.in-addr.arpa. 11894 IN PTR dns2.dadosoftware.com.
    >
    > Who decides the presence of RDNS_NONE ?
    > A real dns check or a parsing of the email headers?
    >
    > And, in case of parse who decides to write dns2.dadosoftware.com
    > [217.199.13.2] instead of unknown [217.199.13.2]?
    >
    > Thanks to all in advance.
    >
    > --
    > /*************/
    > nik600
    > http://www.kumbe.it
    >
    >


    I don't sure will it help or not but I've faced with very similar issue:

    ******** Received: from relay.blablabla.net (unknown [xxx.xxx.xxx.xxx])
    **********

    host relay.blablabla.net has PTR record:

    host xxx.xxx.xxx.xxx
    xxx.xxx.xxx.xxx.in-addr.arpa domain name pointer relay.blablabla.net.

    then I tried:
    host relay.blablabla.net
    relay.blablabla.net has address yyy.yyy.yyy.yyy

    and:
    host yyy.yyy.yyy.yyy
    yyy.yyy.yyy.yyy.in-addr.arpa domain name pointer relay.blablabla.net.

    So. I see that the host blablabla has two A records registered in DNS and
    two PTR.

    All I had to do in this case is:

    /etc/postfix/master.cf:
    smtp unix - - n - - smtp -o
    smtp_bind_address=yyy.yyy.yyy.yyy

    It helped me.

    Thank you.



    --
    View this message in context: http://www.nabble.com/problem-with-R...p20360888.html
    Sent from the SpamAssassin - Users mailing list archive at Nabble.com.


  8. Re: problem with RDNS_NONE: false positive

    > nik600 hotmail wrote:
    > > I'm experiencing a strange problem with RDNS_NONE.
    > >
    > > On the same sender host, sometimes it is marked with RDNS_NONE, and
    > > sometimes not.
    > >
    > > The host has a reverse dns!
    > >
    > > Example:
    > > Received: from dadosoftware.com (dns2.dadosoftware.com [217.199.13.2]) ->
    > > OK
    > >
    > > Received: from dadosoftware.com (unknown [217.199.13.2]) -> FALSE POSITIVE


    well, either your MX does resolve 217.199.13.2 to a name, or it does not.
    If it sometimes does resolve, sometimes not, it's a problem of DNS.

    If you have different mailers of which one does not resolve DNS, it's
    problem of its configuration.

    SA does not resolve that IP, the MTA must do that.

    > > But 217.199.13.2 has a reverse dns!
    > > 2.13.199.217.in-addr.arpa. 11894 IN PTR dns2.dadosoftware.com.


    It also must point back, but it does:

    dns2.dadosoftware.com has address 217.199.13.2

    > > Who decides the presence of RDNS_NONE ?
    > > A real dns check or a parsing of the email headers?
    > >
    > > And, in case of parse who decides to write dns2.dadosoftware.com
    > > [217.199.13.2] instead of unknown [217.199.13.2]?


    it's the MTA who constructs the Received: line.

    On 06.11.08 05:22, derHummel wrote:
    > I don't sure will it help or not but I've faced with very similar issue:
    >
    > ******** Received: from relay.blablabla.net (unknown [xxx.xxx.xxx.xxx])
    > **********
    >
    > host relay.blablabla.net has PTR record:
    >
    > host xxx.xxx.xxx.xxx
    > xxx.xxx.xxx.xxx.in-addr.arpa domain name pointer relay.blablabla.net.
    >
    > then I tried:
    > host relay.blablabla.net
    > relay.blablabla.net has address yyy.yyy.yyy.yyy
    >
    > and:
    > host yyy.yyy.yyy.yyy
    > yyy.yyy.yyy.yyy.in-addr.arpa domain name pointer relay.blablabla.net.
    >
    > So. I see that the host blablabla has two A records registered in DNS and
    > two PTR.


    No. If it has to A records, the "host" would return them both:

    host relay.blablabla.net
    relay.blablabla.net has address yyy.yyy.yyy.yyy
    relay.blablabla.net has address xxx.xxx.xxx.xxx

    If it does not, then the problem is that xxx.xxx.xxx.xxx has invalid reverse
    DNS, because the name it points to does NOT resolve back to that IP.

    --
    Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
    Warning: I wish NOT to receive e-mail advertising to this address.
    Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
    (R)etry, (A)bort, (C)ancer


  9. Re: problem with RDNS_NONE: false positive


    On Thu, November 6, 2008 14:22, derHummel wrote:

    > /etc/postfix/master.cf:
    > smtp unix - - n - - smtp
    > -o smtp_bind_address=yyy.yyy.yyy.yyy

    -o smtp_helo_name=relay.blablabla.net

    > It helped me.


    it aint windows

    --
    Benny Pedersen
    Need more webspace ? http://www.servage.net/?coupon=cust37098


  10. Re: problem with RDNS_NONE: false positive

    derHummel wrote:
    >
    >
    > nik600 hotmail wrote:
    >> I'm experiencing a strange problem with RDNS_NONE.
    >>
    >> On the same sender host, sometimes it is marked with RDNS_NONE, and
    >> sometimes not.
    >>
    >> The host has a reverse dns!
    >>
    >> Example:
    >> Received: from dadosoftware.com (dns2.dadosoftware.com [217.199.13.2]) ->
    >> OK
    >>
    >> Received: from dadosoftware.com (unknown [217.199.13.2]) -> FALSE POSITIVE
    >>


    either rdns lookup is disabled or there was a failure. This is one of
    the reasons why RDNS_NONE should have a low score.

    >> But 217.199.13.2 has a reverse dns!
    >> 2.13.199.217.in-addr.arpa. 11894 IN PTR dns2.dadosoftware.com.
    >>
    >> Who decides the presence of RDNS_NONE ?


    the MTA added the Received header.

    >> A real dns check or a parsing of the email headers?
    >>
    >> And, in case of parse who decides to write dns2.dadosoftware.com
    >> [217.199.13.2] instead of unknown [217.199.13.2]?


    MTA adds Received headers.

    >>
    >> Thanks to all in advance.
    >>
    >> --
    >> /*************/
    >> nik600
    >> http://www.kumbe.it
    >>
    >>

    >
    > [snip]
    > All I had to do in this case is:
    >
    > /etc/postfix/master.cf:
    > smtp unix - - n - - smtp -o
    > smtp_bind_address=yyy.yyy.yyy.yyy
    >
    > It helped me.
    >


    no, it did not. you didn't test enough (you've been mystified by DNS
    caching?).

    - if you have multiple PTRs for an IP, then they must all resolve back
    to the IP. otherwise, with round robin, you'll get random failures.

    - if you have multiple A for a name, then it's ok as one of the IPs
    matches the client IP.

    The logic is:

    1- let $ip be the client IP
    2- let $ptr be the first PTR for the $ip
    3- resolve $ptr to IPs: you get $ip[0], $ip[1], $ip[2], ...
    4- check whether $ip = $ip[k] for some k (MTA is free to only check
    first m records).

    at step 2, if you have multiple PTRs and if they are returned in a round
    robin manner, steps 3 and 4 may work or not.

    at any step, a DNS failure will break the test. postfix and other MTAs
    will set the rdns to "unknown". so you can't distinguish rdns
    misconfiguration from temp failures, or from cases when rdns lookup is
    disabled.


+ Reply to Thread