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.
