On Thu, Jan 25, 2007 at 09:32:02PM -0500, up@3.am wrote:
> > So... what about those of us that *are* using sbl-xbl in either
> > SpamAssassin-type rulesets (aka 'deep parsing'), or who do want top have
> > SBL/XBL protection on our smarthosts and outbound smtp-auth'd customer
> > servers (to prevent IPs infected with Outlook-setting-hijacking viruses
> > from doing too much damage)?
>
> Wouldn't a user the authenticates via SMTP unset the RBLSMTPD variable,
> just like it does with vpopmail type POP before SMTP authentication?
>
> Or would they be prevented from authenticating by rblsmtpd in the first
> place?
rblsmtpd comes first than qmail-smtpd, so there is no way to say "hey, I'm
authenticated, let me in!".
I solve this problem using qmail-dnsbl (http://qmail-dnsbl.sourceforge.net/),
that acts like rblsmtpd but lets the user to authenticate (via SMTP-AUTH or
via SSL certificates) before performing dnsbl lookups.
It can be useful in servers where external users (coming from dialup and
"insecure" addresses) should relay, like ISP or smarthosts.
The other problem is that the blacklisted ip (the ip the user comes from) is
stored in a Received: header anyway, so further dnsbl lookups from software
like SpamAssassin report a positive response (and not only on your host, but
on each host the mail pass through).
You can solve using the trustedrelay patch (no webpage available yet):
http://qmail-dnsbl.sourceforge.net/qmail-tlssmtpauth-trustedrelay-20070109.patch
This patch modifies the Received: header adding a "_trustedrelay" string at the
end of the ip address if your relay is "trusted" (authenticated users,
relayclient)
in a way that SpamAssassin doesn't perform any dnsbl check, but the ip is
readable
by humans for tracking purposes:
Received: from unknown (HELO example.com) (192.0.34.166)
| |
v
Received: from unknown (HELO example.com) (192.0.34.166_trustedrelay)
The patch was successfully tested, but it hasn't been stressed and widely
discussed
yet, so comments are welcome :)
Bye
Fabio
|