RBLs and Freemail Forwards

[decoder]

Hello,


on our private mail server we now have quite some forwards from freemail
providers like yahoo, gmx and such. This wasn't a big problem previously
but there is quite some spam arriving now over those forwards that isn't
tagged as such (mainly I think because RBLs can't strike on those).

Is there away to modify the trust path such that I can actually trust
the Received header added by the freemailer MTA (so that RBLs can match
the Received line which is before the freemailer MTAs) ? I wouldn't
really add all those to trusted hosts (and for yahoo, there are tons of
mtas it seems).



Thanks in advance,


Chris

[Matt Kettler-3]

decoder wrote:

> Hello,
>
>
> on our private mail server we now have quite some forwards from
> freemail providers like yahoo, gmx and such. This wasn't a big problem
> previously but there is quite some spam arriving now over those
> forwards that isn't tagged as such (mainly I think because RBLs can't
> strike on those).
>
> Is there away to modify the trust path such that I can actually trust
> the Received header added by the freemailer MTA (so that RBLs can
> match the Received line which is before the freemailer MTAs) ? I
> wouldn't really add all those to trusted hosts (and for yahoo, there
> are tons of mtas it seems).

Nearly all positive-score RBLs will check all untrusted hosts in
Received: headers, except the DUL RBLs and XBL which only check the
first untrusted because they are designed to be used in that manner.

ie: SBL will be tested against *ALL* untrusted hosts, including the IP
delivering mail to the freemailer, not just the freemailer itself.

And of course, nearly every message coming from a freemailer is going to
originate a a DUL, spam or otherwise, so all you'd do here is make every
message from the freemailer match the DULs.

Unless you're hoping to make the whitelist-style RBLs match a message,
there's no reason to trust freemailers for RBL reasons. In fact, it's
contrary to the whole reason the DUL RBLs only check the first untrusted
host in the first place. (i.e.: you shouldn't be nailing messages with
DUL RBLs if they're properly relaying through a server instead of direct
mailing).

[decoder]

Matt Kettler wrote:
> Nearly all positive-score RBLs will check all untrusted hosts in
> Received: headers, except the DUL RBLs and XBL which only check the
> first untrusted because they are designed to be used in that manner.
>
> ie: SBL will be tested against *ALL* untrusted hosts, including the IP
> delivering mail to the freemailer, not just the freemailer itself.
>
Thanks for the clarification, I thought that all RBLs only hit on the
first untrusted host for performance reasons. If that isn't the case,
then I'll have to find another way to get rid of that specific spam type
which is getting quite annoying.. :D


Best regards,


Chris

[Matt Kettler-3]

decoder wrote:

> Matt Kettler wrote:
>> Nearly all positive-score RBLs will check all untrusted hosts in
>> Received: headers, except the DUL RBLs and XBL which only check the
>> first untrusted because they are designed to be used in that manner.
>>
>> ie: SBL will be tested against *ALL* untrusted hosts, including the
>> IP delivering mail to the freemailer, not just the freemailer itself.
>>
> Thanks for the clarification, I thought that all RBLs only hit on the
> first untrusted host for performance reasons. If that isn't the case,
> then I'll have to find another way to get rid of that specific spam
> type which is getting quite annoying.. :D

Nope.. in general, it's all untrusted, unless there's good reasons to do
otherwise due to the content of the RBL. (ie: whitelists, DULS, etc)