Debugging TrustPath Problem - SpamAssassin

This is a discussion on Debugging TrustPath Problem - SpamAssassin ; I am trying to debug my trust path problem with this simplified message: http://pastebin.com/m48bf6057 Basically the headers I am looking at are: Received: from [199.232.76.173] (port=52195 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KSITK-0001ms-HD for devel-owner@example.com ; Sun, 10 ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Debugging TrustPath Problem

  1. Debugging TrustPath Problem

    I am trying to debug my trust path problem with this simplified
    message:

    http://pastebin.com/m48bf6057

    Basically the headers I am looking at are:

    Received: from [199.232.76.173] (port=52195 helo=monty-python.gnu.org)
    by lists.gnu.org with esmtp (Exim 4.43) id 1KSITK-0001ms-HD
    for devel-owner@example.com; Sun, 10 Aug 2008 17:29:06 -0400
    Received: from [201.3.246.120] (port=3977
    helo=idff.brasiltelecom.net.br)
    by monty-python.gnu.org with smtp (Exim 4.60)
    (envelope-from ) id 1KSITJ-0000Aw-GX
    for devel-owner@example.com; Sun, 10 Aug 2008 17:29:06 -0400

    Shouldn't that message trigger RCVD_IN_SORBS_DUL?

    I have set the following in my user_prefs in order to trust the first
    relay in the message. The first Received should be trusted and the
    next IP should be untrusted.

    trusted_networks 199.232.76.173

    I see the following in the debug output:

    dbg: received-header: parsed as [ ip=199.232.76.173 rdns= helo=monty-python.gnu.org by=lists.gnu.org ident= envfrom= intl=0 id=1KSITK-0001ms-HD auth= msa=0 ]
    dbg: received-header: relay 199.232.76.173 trusted? yes internal? no msa? no
    dbg: received-header: parsed as [ ip=201.3.246.120 rdns= helo=idff.brasiltelecom.net.br by=monty-python.gnu.org ident= envfrom=nobody@mydatacare.com intl=0 id=1KSITJ-0000Aw-GX auth= msa=0 ]
    dbg: received-header: relay 201.3.246.120 trusted? no internal? no msa? no
    dbg: metadata: X-Spam-Relays-Trusted: [ ip=199.232.76.173 rdns= helo=monty-python.gnu.org by=lists.gnu.org ident= envfrom= intl=0 id=1KSITK-0001ms-HD auth= msa=0 ]
    dbg: metadata: X-Spam-Relays-Untrusted: [ ip=201.3.246.120 rdns= helo=idff.brasiltelecom.net.br by=monty-python.gnu.org ident= envfrom=nobody@mydatacare.com intl=0 id=1KSITJ-0000Aw-GX auth= msa=0 ]
    dbg: metadata: X-Spam-Relays-Internal:
    dbg: metadata: X-Spam-Relays-External: [ ip=199.232.76.173 rdns= helo=monty-python.gnu.org by=lists.gnu.org ident= envfrom= intl=0 id=1KSITK-0001ms-HD auth= msa=0 ] [ ip=201.3.246.120 rdns= helo=idff.brasiltelecom.net.br by=monty-python.gnu.org ident= envfrom=nobody@mydatacare.com intl=0 id=1KSITJ-0000Aw-GX auth= msa=0 ]
    ...
    dbg: dns: hit 127.0.0.10
    dbg: dns: hit 127.0.0.4
    dbg: dns: hit 127.0.0.11

    Doesn't that say that 199.232.76.173 is trusted and 201.3.246.120 is
    the first external IP and is not trusted?
    But RCVD_IN_* is not triggered. All that is indicated is RDNS_NONE.

    If I remove the last Received: line then I get an expected result of
    RCVD_IN_SORBS_DUL and other lists. But with the trusted relay in
    place then it doesn't.

    Here is the debug trace output subset that I can post without tripping
    the pastebin's own spam filters. (If I submit the full trace then the
    paste is rejected.)

    http://pastebin.com/m54e2e745

    Any hints as to what I am doing wrong? I have been staring at it for
    a while and am blind to the problem.

    Thanks
    Bob


  2. Re: Debugging TrustPath Problem

    On 10.08.08 18:09, Bob Proulx wrote:
    > I am trying to debug my trust path problem with this simplified
    > message:
    >
    > http://pastebin.com/m48bf6057
    >
    > Basically the headers I am looking at are:
    >
    > Received: from [199.232.76.173] (port=52195 helo=monty-python.gnu.org)
    > by lists.gnu.org with esmtp (Exim 4.43) id 1KSITK-0001ms-HD
    > for devel-owner@example.com; Sun, 10 Aug 2008 17:29:06 -0400
    > Received: from [201.3.246.120] (port=3977
    > helo=idff.brasiltelecom.net.br)
    > by monty-python.gnu.org with smtp (Exim 4.60)
    > (envelope-from ) id 1KSITJ-0000Aw-GX
    > for devel-owner@example.com; Sun, 10 Aug 2008 17:29:06 -0400
    >
    > Shouldn't that message trigger RCVD_IN_SORBS_DUL?


    only if 199.232.76.173 is in your internal_networks...

    > trusted_networks 199.232.76.173

    [...]
    > dbg: metadata: X-Spam-Relays-External: [ ip=199.232.76.173 rdns= helo=monty-python.gnu.org by=lists.gnu.org ident= envfrom= intl=0 id=1KSITK-0001ms-HD auth= msa=0 ] [ ip=201.3.246.120 rdns= helo=idff.brasiltelecom.net.br by=monty-python.gnu.org ident= envfrom=nobody@mydatacare.com intl=0 id=1KSITJ-0000Aw-GX auth= msa=0 ]


    and it is not....

    > Doesn't that say that 199.232.76.173 is trusted and 201.3.246.120 is
    > the first external IP and is not trusted?
    > But RCVD_IN_* is not triggered. All that is indicated is RDNS_NONE.


    RBL checks (RCVD_IN_*) apply for all untrusted hosts, while dynamic checks
    apply only for external hosts. You can't know if the trusted host trusts
    that IP, e.g. if it hasn't used some kind of authentication ... can you?

    --
    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.
    "The box said 'Requires Windows 95 or better', so I bought a Macintosh".


  3. Re: Debugging TrustPath Problem

    Matus UHLAR - fantomas wrote:
    > Bob Proulx wrote:
    > > Shouldn't that message trigger RCVD_IN_SORBS_DUL?
    > > trusted_networks 199.232.76.173

    > only if 199.232.76.173 is in your internal_networks...


    Hmm... I had never realized the difference between trusted_networks
    and internal_networks previously. I had always set the
    trusted_networks parameter and didn't even know about the
    internal_networks one. The TrustPath entry on the SA wiki doesn't
    even mention it. I just added a quick comment there.

    Your hint about internal_networks was definitely the problem. Because
    each is set from the other then as soon as either is set then it must
    always be set fully from then on out.

    A single IP entry was set in internal_networks and therefore the value
    of trusted_networks wasn't copied into it. That was the root cause of
    my problem. Once I removed the single lonely internal_networks
    setting then once again the entire trusted_networks value was copied
    into the internal_networks and everything started working again.

    A note to the developers... Is there really value in having both of
    these configurations? Now that I am aware of internal_networks I read
    through the documentation carefully several times and I couldn't
    imagine a configuration where splitting this was useful. If someone
    had an example of such to add to the documentation that would make the
    differentiation of these two more clear.

    Thanks!
    Bob


  4. Message-ID:Reply-To:References:MIME-Version:Content-Type:In-Reply-To; b=Idj68nT1pIo3dmCyWGuyqdP2WeZe9nf1sTJIVSp0WZrV8YaB ogTVnoZkRi9DFNWZgSivbQQWwjHGxXVr9LWsxxLjI79GLqi3DD Peo5GJqITZWApLFXHLZSFNlDL3H4QawF6XHAMSIjzt65dQxn64 SXxrrDce3mI72UmPm64iXH4=

    On Mon, Aug 11, 2008 at 01:35:30PM -0600, Bob Proulx wrote:
    > Hmm... I had never realized the difference between trusted_networks
    > and internal_networks previously. I had always set the
    > trusted_networks parameter and didn't even know about the
    > internal_networks one. The TrustPath entry on the SA wiki doesn't
    > even mention it.


    It does. Also read TrustedRelays page, which is linked there.

    > A note to the developers... Is there really value in having both of
    > these configurations?


    Yes.

    > Now that I am aware of internal_networks I read through the documentation
    > carefully several times and I couldn't imagine a configuration where
    > splitting this was useful. If someone had an example of such to add to
    > the documentation that would make the differentiation of these two more
    > clear.


    It's been discussed time and time again, but no one has yet written a cookie
    cutter example. I don't know if it's possible to do at that level.

    Internal border is for direct-to-MX checks (dialup-RBL, SPF etc). Trusted
    can extend further for whitelisting purposes. TrustedRelays page has
    examples.

    A little simplification and list of checks that are done at each border
    would be nice. But most of the information is there, you just need the
    general experience in finding all the bits and understanding complex things.
    Especially in mail/spam business.


  5. Re: Debugging TrustPath Problem

    > On Mon, Aug 11, 2008 at 01:35:30PM -0600, Bob Proulx wrote:
    > > Now that I am aware of internal_networks I read through the documentation
    > > carefully several times and I couldn't imagine a configuration where
    > > splitting this was useful. If someone had an example of such to add to
    > > the documentation that would make the differentiation of these two more
    > > clear.


    On 11.08.08 23:14, Henrik K wrote:
    > It's been discussed time and time again, but no one has yet written a cookie
    > cutter example. I don't know if it's possible to do at that level.
    >
    > Internal border is for direct-to-MX checks (dialup-RBL, SPF etc). Trusted
    > can extend further for whitelisting purposes. TrustedRelays page has
    > examples.
    >
    > A little simplification and list of checks that are done at each border
    > would be nice. But most of the information is there, you just need the
    > general experience in finding all the bits and understanding complex things.
    > Especially in mail/spam business.


    For DUL cheks, it's easy: your trusted relays may trust or authenticate DUL
    host without you knowing that. Running DUL checks there would lead to false
    positives.


    --
    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


  6. Re: Debugging TrustPath Problem

    Matus UHLAR - fantomas wrote:
    > Bob Proulx wrote:
    > > Now that I am aware of internal_networks I read through the documentation
    > > carefully several times and I couldn't imagine a configuration where
    > > splitting this was useful. If someone had an example of such to add to
    > > the documentation that would make the differentiation of these two more
    > > clear.

    >
    > For DUL cheks, it's easy: your trusted relays may trust or authenticate DUL
    > host without you knowing that. Running DUL checks there would lead to false
    > positives.


    Aha! A very good example! I updated the TrustPath wiki page with
    this example.

    Thanks
    Bob


+ Reply to Thread