On Fri, Mar 09, 2007 at 14:46:10 -0700, Kyle Wheeler wrote:
...
> Plus, the more you modify the source, the more conflicts you have
> between your patches
Only if you are idiot.
> >Of course you have to edit qmail-smtpd.c if you add that feature
> >into qmail-smtpd.c.
>
> Which is precisely what I don't like about it.
>
> >>2. It requires qmail-smtpd to rely on a resolver library.
> >
> >Untrue. It can also use djb's dns library, just like rblsmtpd.
>
> Wait, so you're telling me that by making qmail-smtpd rely on DJB's
> resolver library, that somehow it is untrue that qmail-smtpd will rely
> on a resolver library? Truly, your logic is mysterious.
>
> Yes, rblsmtpd relies on a resolver library. The resolver library it
> relies on is DJB's resolver library. If you make qmail-smtpd perform
> rblsmtpd's task, it will also rely on a resolver library (unless you
> plan on copying an entire resolver library into qmail-smtpd's code).
Done that some years ago.
http://riemann.fmi.uni-sofia.bg/vladov/ftp/qmail%2bdjbdns-0.16.tar.gz
> The library it relies on may indeed be the one written by DJB. Is
> there something unclear about this relationship?
Looks like it.
But maybe you get it.
> >>3. Blacklists must either be hardcoded, or require command-line
> >> options (which requires more complex command-line parsing, which
> >> will require hand-tuning to work well with your SMTP-AUTH patch),
> >> or defined in yet-another-control-file.
> >
> >And rblsmtpd does not "require command-line options"?
> >It even has hardcoded, useless default RBL.
>
> We're not talking about rblsmtpd, we're talking about qmail-smtpd. By
> saying I do not recommend a particular solution involving modifying
> qmail-smtpd, I am not implicitly endorsing rblsmtpd as the paragon of
> perfection. It is not. Are you happy now?
Good that you can say so.
I also think rblsmtpd sucks.
But someone may find it useful.
> >And with rblsmtpd you have to use same settings for every mailbox.
> >How lame is that?
>
> And with rblsmtpd you ordinarily use blacklists. How lame is that?
I think it's extremely wise thing to do.
Oh, and also whitelists.
> Modifying qmail-smtpd to do rblsmtpd lookups when the client sends a
> MAIL FROM command ALSO uses the same settings for every mailbox
> (because, if you knew anything about SMTP, you'd know that at that
You do?
> point there are no recipients). And assuming you feel like performing
> your blacklist lookup only after RCPT TO commands, just what do you
Where else?
> propose to do about messages with multiple recipients, eh? And where
The same as postfix and other sane SMTP servers, why?
Don't you know anything about SMTP?
> will you store your per-user configuration settings, a central
cdb file.
> sysadmin-only config file, or a per-user user-definable config file?
ACL contains option which points to a file which lists
the DNSbls to use.
For example, ACL "Dlistinfo:"
$ cat /var/qmail/control/rbl/listinfo
# http://www.routeviews.org/
aspath.routeviews.org addheader txt AS Path
It writes into headers:
X-RBL: 205.206.231.27 found on aspath.routeviews.org (TXT record): AS Path [
1299 852/205.206.0.0/16 ]
(Of course reject/rejecttemp/whitelist can be used in place of
addheader)
> Will you give qmail-smtpd sufficient permissions to read every user's
> home directory for these configs (and thus subvert the entire qmail
Home directory? Sufficient permissions?
As if it was rocket science to periodically copy files from ~luser to
/var/qmail/control/rbl/ , if that was needed.
> security architecture), or will you also be linking in an SQL database
> library to query?
Not right now for simple dnsbl feature.
But greylist uses sqlite3.
>How bloated and ugly do you really like your email software?
$ size /var/qmail/bin/qmail-smtpd
text data bss dec hex filename
180334 3228 20956 204518 31ee6 /var/qmail/bin/qmail-smtpd
> Here's another reason:
>
> 5. It requires giving qmail-smtpd permission to use the network.
No shit? Well not much different than rblsmtpd or tcpserver, then.
> Ordinarily, there is *no* reason to allow that and every reason to
> forbid it (if you can, e.g. via iptables, AppArmor, or SELinux).
Been doing that.
--
pgpokhH2riTuG.pgp
Description: PGP signature
|