Qmail
[Top] [All Lists]

Re: SMTP_AUTH + RBLs

To: qmail list <qmail@list.cr.yp.to>
Subject: Re: SMTP_AUTH + RBLs
From: Kyle Wheeler <kyle-qmail@memoryhole.net>
Date: Fri, 9 Mar 2007 12:49:44 -0700
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Delivered-to: sp-com-lists@consult.net
Delivered-to: gmail-qmail@securepoint.com
Delivered-to: sp.com.list@gmail.com
Delivered-to: mailing list qmail@list.cr.yp.to
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=memoryhole.net; b=a02mLNSkTUIdpAYqjP/NQXi8mEX8ZNb4+9TxwF/a1ongETJBagbBeAvzr6Owy/xEEMd2OeHqAicMgWPV798Wt0v/+ybEqt55iPL8uT9J6cCWRoX5BWgTeKcPBJPlYsPbQyNpmS3U2Vw+jDHbUcBeMIZE9lTTLqyglID8VPD6/4E= ;
Domainkey-status: good
In-reply-to: <1f4ef0970703090910s6e36cae7j51f63a938ea98ff5@mail.gmail.com>
Mail-followup-to: qmail list <qmail@list.cr.yp.to>
Mailing-list: contact qmail-help@list.cr.yp.to; run by ezmlm
References: <1f4ef0970703090910s6e36cae7j51f63a938ea98ff5@mail.gmail.com>
User-agent: Mutt/1.5.14 (2007-03-06)
On Friday, March  9 at 11:10 AM, quoth Steve Brown:
I've got a user that cannot send mail from home.  They are on a DSL
line that has been listed in Spamhaus Policy Black List, probably
because its in a dynamic IP block.  zen.spamhaus.org consults this
list, so when the user tries to connect, there are logs returning a
451 when querying the Spamhaus.

Okay.

All this is well and good, but my question is, shouldn't the user be
allowed to relay based on the fact that he has an authenticated SMTP
session?

No. Think about it: what is the process here?

Your run file looks like this:

    tcpserver {options} \
        rblsmtpd {options} \
        fixcrio \
        qmail-smtpd {options}

In otherwords, you have told it to do the following whenever anyone connects:

    1. tcpserver sets environment variables, and calls... rblsmtpd
2. rblsmtpd looks up the IP address of the connecting client and either disconnects (if it's in the RBL) or calls... fixcrio
    3. fixcrio sets up pipes and calls... qmail-smtpd
4. qmail-smtpd talks SMTP to the client, through which they could potentially use SMTP-AUTH and authenticate themselves

***IN THAT ORDER***

So, when your user from the DSL line connects, what happens?

    1. tcpserver sets environment variables, and calls... rblsmtpd
2. rblsmtpd looks up the IP address of the connecting client, and since it is listed in a blacklist, immediately disconnects

And there the connection ends.

The short version is: rblsmtpd doesn't let the connection get far enough to allow the user to attempt to authenticate. That's the whole POINT of using it.

Obviously this is not the case, so is there a more appropriate way to handle this scenario than what I am currently doing?

Yes. You have a couple choices:

1. Don't use black lists (debate the moral rectitude of using blacklists elsewhere, but the long and short is that their purpose is to do precisely this. Complaining about blacklists blocking email indiscriminately is like complaining that missiles blow up buildings without checking the papers of everyone inside. If you don't like what they do, don't use them. The entire purpose of a blacklist to block email indiscriminately.) 2. Have the user connect to send mail via an alternate port (e.g. 587), and set up qmail without rblsmtpd to listen to that alternate port in addition to what you already have set up. 3. Hack qmail-smtpd such that it does what rblsmtpd does only when clients issue a MAIL FROM command, and only if they haven't already authenticated. (I seem to vaguely recall that someone wrote a patch to do this, but I can't vouch for the quality of such patches... in my personal opinion, this is a bad solution.)

I recommend option 2. It solves a lot of problems, including the problem of ISPs that block all port 25 access.

I realize that I could resolve this issue by choosing a different RBL,
but I view that as a workaround, not a solution.

You're right, using a different RBL would only fix THIS case, not all cases. The instant you get a client whose IP address used to be used by a spammer, you'll have the same problem.

~Kyle
--
Of course it's the same old story. Truth usually is the same old story.
                                                  -- Margaret Thatcher

Attachment: pgpMXrTFnR3MG.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>