You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by "Eric W. Bates" <er...@vineyard.net> on 2006/03/10 20:42:15 UTC
trusted_networks seems to be ignored after upgrade
I recently upgraded from 2.63 to 3.1 and having done so, my entries for
trusted_networks no longer seem to functional.
I have way to many trusted network lines, but in particular I know that:
trusted_networks 68.64/13
is no longer working because:
Content analysis details: (5.9 points, 5.0 required)
pts rule name description
---- ----------------------
--------------------------------------------------
-0.0 SPF_PASS SPF: sender matches SPF record
2.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP
address
[68.64.105.61 listed in dnsbl.sorbs.net]
2.2 RCVD_IN_WHOIS_INVALID RBL: CompleteWhois: sender on invalid IP block
[68.64.105.61 listed in
combined-HIB.dnsiplists.completewhois.com]
1.7 RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP
[68.64.105.61 listed in combined.njabl.org]
As you know, 68.64.105.61 falls within 68.64.0.0/13; so none of these
rules should have hit, correct?
Thanks for your time.
--
Eric W. Bates
Re: trusted_networks seems to be ignored after upgrade
Posted by "Eric W. Bates" <er...@vineyard.net>.
Matt Kettler wrote:
...
>>
>>Is the whole trusted_net, dnsbl business written up somewhere? I would
>>rather not waste your time; but searching the wiki doesn't turn anything up.
>>
>>
>
>
>
> Not really, but I can go over it really fast..
>
>
> First, SA parses all the received headers, in backward order, starting with the
> most recent. While doing so, it determines if each host is trusted or untrusted,
> and internal or external (by default trusted_networks == internal_networks, so
> for you, the two are the same).
>
> Let's make a "simple" example here, that somewhat reflects your situation. In
> this case "B" is taking the place of your 127.0.0.1.
>
> trusted_networks A
> trusted_networks C
>
> And a message:
> Received from B by A
> Received from C by B
> Received from D by C
> Received from E by D
>
> In this case, SA would determine:
> A - trusted, internal
> B - untrusted, external
> C - untrusted, external, because it's "outside" of B.
> D - untrusted, external
> E - untrusted, external
>
>
> Now, when evaluating RBLs, the first thing SA does is eliminate all the internal
> hosts from the list. Poof, A disappears from the list.
>
> For all of the "dialup" type RBLs, SA excludes the first hop. Poof, E
> disappears. So SA will check B, C, and D against the various DUL RBLs.
>
> In your case, C happens to be a dialup-node, so it matches against SORBS_DUL and
> similar rules.
>
>
> Now, if you had:
>
> trusted_networks A
> trusted_networks B
> trusted_networks C
>
> Then SA would parse as:
>
> A - trusted, internal
> B - trusted, internal
> C - trusted, internal (because there's no "break" in the path)
> D - untrusted, external
> E - untrusted, external
>
> Now when evaluating the DUL RBLs, A,B and C will be dropped because they're
> internal, and E will be dropped because it's a first-hop. Only D gets checked.
>
> As long as D isn't a dialup node, SORBS_DUL won't hit.
>
Excellent description, thank you. Clearly worthy of inclusion on the
wiki. Adding 127/8 to the trusted list seems to be behaving as you
described. All is well.
Re: trusted_networks seems to be ignored after upgrade
Posted by Matt Kettler <mk...@evi-inc.com>.
Eric W. Bates wrote:
> Eric W. Bates wrote:
>> Matt Kettler wrote:
>>
>> ...
>>
>>>>>>> No, it could fire on *ANY* external IP that isn't the first hop.
>>>>> I don't think I was clear. I don't question that any IP in the chain
>>>>> might cause the difficuly. I was questioning why, if 127.0.0.1 is the
>>>>> problem, why it was reported as 68.64.105.61 in the rule.
>>>>
>>>> Because 127.0.0.1 doesn't match the rule. However, the lack of trust in
>>>> 127.0.0.1 is causing 68.64.105.61 to be treated as external.
>>>>
>>>> RCVD_IN_SORBS_DUL can only match external hosts that are not the first hop.
>>>>
>>
>> I appreciate your patience in helping me get this straight.
>>
>> It sounds as tho having amavis STOP adding the extra recieved header in
>> the message may address the problem?
Yeah that would work, but the right way would be to add 127.0.0.1 to the
trusted_networks.
Really, set trusted_networks to contain the IPs of all the mailservers that add
Received: headers you control. You can have multiple trusted_networks statements
to concat
>>
>>
>>>>> Also, adding 127.0.0.1 to trusted_network will, in fact, cause ALL
>>>>> inbound mail to be trusted, would it not?
>
> Is the whole trusted_net, dnsbl business written up somewhere? I would
> rather not waste your time; but searching the wiki doesn't turn anything up.
>
>
Not really, but I can go over it really fast..
First, SA parses all the received headers, in backward order, starting with the
most recent. While doing so, it determines if each host is trusted or untrusted,
and internal or external (by default trusted_networks == internal_networks, so
for you, the two are the same).
Let's make a "simple" example here, that somewhat reflects your situation. In
this case "B" is taking the place of your 127.0.0.1.
trusted_networks A
trusted_networks C
And a message:
Received from B by A
Received from C by B
Received from D by C
Received from E by D
In this case, SA would determine:
A - trusted, internal
B - untrusted, external
C - untrusted, external, because it's "outside" of B.
D - untrusted, external
E - untrusted, external
Now, when evaluating RBLs, the first thing SA does is eliminate all the internal
hosts from the list. Poof, A disappears from the list.
For all of the "dialup" type RBLs, SA excludes the first hop. Poof, E
disappears. So SA will check B, C, and D against the various DUL RBLs.
In your case, C happens to be a dialup-node, so it matches against SORBS_DUL and
similar rules.
Now, if you had:
trusted_networks A
trusted_networks B
trusted_networks C
Then SA would parse as:
A - trusted, internal
B - trusted, internal
C - trusted, internal (because there's no "break" in the path)
D - untrusted, external
E - untrusted, external
Now when evaluating the DUL RBLs, A,B and C will be dropped because they're
internal, and E will be dropped because it's a first-hop. Only D gets checked.
As long as D isn't a dialup node, SORBS_DUL won't hit.
Re: trusted_networks seems to be ignored after upgrade
Posted by "Eric W. Bates" <er...@vineyard.net>.
Eric W. Bates wrote:
> Matt Kettler wrote:
>
> ...
>
>>>>>>No, it could fire on *ANY* external IP that isn't the first hop.
>>>>
>>>>I don't think I was clear. I don't question that any IP in the chain
>>>>might cause the difficuly. I was questioning why, if 127.0.0.1 is the
>>>>problem, why it was reported as 68.64.105.61 in the rule.
>>>
>>>
>>>Because 127.0.0.1 doesn't match the rule. However, the lack of trust in
>>>127.0.0.1 is causing 68.64.105.61 to be treated as external.
>>>
>>>RCVD_IN_SORBS_DUL can only match external hosts that are not the first hop.
>>>
>
>
> I appreciate your patience in helping me get this straight.
>
> It sounds as tho having amavis STOP adding the extra recieved header in
> the message may address the problem?
>
>
>>>>Also, adding 127.0.0.1 to trusted_network will, in fact, cause ALL
>>>>inbound mail to be trusted, would it not?
>>>
Is the whole trusted_net, dnsbl business written up somewhere? I would
rather not waste your time; but searching the wiki doesn't turn anything up.
Re: trusted_networks seems to be ignored after upgrade
Posted by Matt Kettler <mk...@evi-inc.com>.
Eric W. Bates wrote:
>
>
> Matt Kettler wrote:
>>> Eric W. Bates wrote:
>>>
>>>> Matt Kettler wrote:
>>>>
>>>>> Eric W. Bates wrote:
>>>>>
>>>>>
>>>>>> I recently upgraded from 2.63 to 3.1 and having done so, my entries for
>>>>>> trusted_networks no longer seem to functional.
>>>>>>
>>>>>> I have way to many trusted network lines, but in particular I know that:
>>>>>>
>>>>>> trusted_networks 68.64/13
>>>>>>
>>>>>> is no longer working because:
>>>>>>
>>>>>> Content analysis details: (5.9 points, 5.0 required)
>>>>>>
>>>>>> pts rule name description
>>>>>> ---- ----------------------
>>>>>> --------------------------------------------------
>>>>>> -0.0 SPF_PASS SPF: sender matches SPF record
>>>>>> 2.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP
>>>>>> address
>>>>>> [68.64.105.61 listed in dnsbl.sorbs.net]
>>>>>> 2.2 RCVD_IN_WHOIS_INVALID RBL: CompleteWhois: sender on invalid IP block
>>>>>> [68.64.105.61 listed in
>>>>>> combined-HIB.dnsiplists.completewhois.com]
>>>>>> 1.7 RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP
>>>>>> [68.64.105.61 listed in combined.njabl.org]
>>>>>>
>>>>>>
>>>>>> As you know, 68.64.105.61 falls within 68.64.0.0/13; so none of these
>>>>>> rules should have hit, correct?
>>>>> Maybe.. Were there any untrusted hosts in-between 68.64.105.61 and your network
>>>>> in the Received: headers?
>>>> No. But even if there were, wouldn't the rule fire on the offensive IP
>>>> rather than the one listed as 'trusted'?
>>>
>>> No, it could fire on *ANY* external IP that isn't the first hop.
>
> I don't think I was clear. I don't question that any IP in the chain
> might cause the difficuly. I was questioning why, if 127.0.0.1 is the
> problem, why it was reported as 68.64.105.61 in the rule.
Because 127.0.0.1 doesn't match the rule. However, the lack of trust in
127.0.0.1 is causing 68.64.105.61 to be treated as external.
RCVD_IN_SORBS_DUL can only match external hosts that are not the first hop.
>
> Also, adding 127.0.0.1 to trusted_network will, in fact, cause ALL
> inbound mail to be trusted, would it not?
>
> --
> Eric W. Bates
> ericx@vineyard.net
Re: trusted_networks seems to be ignored after upgrade
Posted by Matt Kettler <mk...@evi-inc.com>.
Eric W. Bates wrote:
> Matt Kettler wrote:
>> Eric W. Bates wrote:
>>
>>> I recently upgraded from 2.63 to 3.1 and having done so, my entries for
>>> trusted_networks no longer seem to functional.
>>>
>>> I have way to many trusted network lines, but in particular I know that:
>>>
>>> trusted_networks 68.64/13
>>>
>>> is no longer working because:
>>>
>>> Content analysis details: (5.9 points, 5.0 required)
>>>
>>> pts rule name description
>>> ---- ----------------------
>>> --------------------------------------------------
>>> -0.0 SPF_PASS SPF: sender matches SPF record
>>> 2.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP
>>> address
>>> [68.64.105.61 listed in dnsbl.sorbs.net]
>>> 2.2 RCVD_IN_WHOIS_INVALID RBL: CompleteWhois: sender on invalid IP block
>>> [68.64.105.61 listed in
>>> combined-HIB.dnsiplists.completewhois.com]
>>> 1.7 RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP
>>> [68.64.105.61 listed in combined.njabl.org]
>>>
>>>
>>> As you know, 68.64.105.61 falls within 68.64.0.0/13; so none of these
>>> rules should have hit, correct?
>>
>> Maybe.. Were there any untrusted hosts in-between 68.64.105.61 and your network
>> in the Received: headers?
>
> No. But even if there were, wouldn't the rule fire on the offensive IP
> rather than the one listed as 'trusted'?
No, it could fire on *ANY* external IP that isn't the first hop.
Re: trusted_networks seems to be ignored after upgrade
Posted by Matt Kettler <mk...@evi-inc.com>.
Eric W. Bates wrote:
> Eric W. Bates wrote:
>>> Matt Kettler wrote:
>>>
>>>> Eric W. Bates wrote:
>>>>
>
> ...
>>>>
>>>>
>>>> Maybe.. Were there any untrusted hosts in-between 68.64.105.61 and your network
>>>> in the Received: headers?
>>>
>>> No. But even if there were, wouldn't the rule fire on the offensive IP
>>> rather than the one listed as 'trusted'?
>>>
>
> Well, I may have misspoken. 127.0.0.1 is in the path because I'm
> handing off from smtpd to amavis before returning back to smtpd again:
Well you better add 127.0.0.1 to your trusted networks then..
Re: trusted_networks seems to be ignored after upgrade
Posted by "Eric W. Bates" <er...@vineyard.net>.
Matt Kettler wrote:
> Eric W. Bates wrote:
>
>>I recently upgraded from 2.63 to 3.1 and having done so, my entries for
>>trusted_networks no longer seem to functional.
>>
>>I have way to many trusted network lines, but in particular I know that:
>>
>>trusted_networks 68.64/13
>>
>>is no longer working because:
>>
>>Content analysis details: (5.9 points, 5.0 required)
>>
>> pts rule name description
>>---- ----------------------
>>--------------------------------------------------
>>-0.0 SPF_PASS SPF: sender matches SPF record
>> 2.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP
>>address
>> [68.64.105.61 listed in dnsbl.sorbs.net]
>> 2.2 RCVD_IN_WHOIS_INVALID RBL: CompleteWhois: sender on invalid IP block
>> [68.64.105.61 listed in
>>combined-HIB.dnsiplists.completewhois.com]
>> 1.7 RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP
>> [68.64.105.61 listed in combined.njabl.org]
>>
>>
>>As you know, 68.64.105.61 falls within 68.64.0.0/13; so none of these
>>rules should have hit, correct?
>
>
> Maybe.. Were there any untrusted hosts in-between 68.64.105.61 and your network
> in the Received: headers?
No. But even if there were, wouldn't the rule fire on the offensive IP
rather than the one listed as 'trusted'?
> Trust isn't just by IP.. it's a path. SA works backwards through the received:
> headers. Once it sees a host that isn't trusted, all the other received headers
> can't be trusted or internal because that one untrusted host could have forged
> the extra Received: headers.
>
>
Re: trusted_networks seems to be ignored after upgrade
Posted by Matt Kettler <mk...@evi-inc.com>.
Eric W. Bates wrote:
> I recently upgraded from 2.63 to 3.1 and having done so, my entries for
> trusted_networks no longer seem to functional.
>
> I have way to many trusted network lines, but in particular I know that:
>
> trusted_networks 68.64/13
>
> is no longer working because:
>
> Content analysis details: (5.9 points, 5.0 required)
>
> pts rule name description
> ---- ----------------------
> --------------------------------------------------
> -0.0 SPF_PASS SPF: sender matches SPF record
> 2.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP
> address
> [68.64.105.61 listed in dnsbl.sorbs.net]
> 2.2 RCVD_IN_WHOIS_INVALID RBL: CompleteWhois: sender on invalid IP block
> [68.64.105.61 listed in
> combined-HIB.dnsiplists.completewhois.com]
> 1.7 RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP
> [68.64.105.61 listed in combined.njabl.org]
>
>
> As you know, 68.64.105.61 falls within 68.64.0.0/13; so none of these
> rules should have hit, correct?
Maybe.. Were there any untrusted hosts in-between 68.64.105.61 and your network
in the Received: headers?
Trust isn't just by IP.. it's a path. SA works backwards through the received:
headers. Once it sees a host that isn't trusted, all the other received headers
can't be trusted or internal because that one untrusted host could have forged
the extra Received: headers.