dccifd vs. postfix

> From: "Tod D. Ihde" <toon@warmerbythelake.com>

>  What would be obscenely useful is if dccifd could speak to postfix as a
> content filter.
>
> http://www.postfix.org/CONTENT_INSPECTION_README.html explains how
> Postfix deal with content filtering. I'm a big fan of external,
> medium-weight, real-time, even though Mr. Venema cautions against it,
> simply because I can refuse the transaction without queuing the message
> (even though you have to get the whole message to do a checksumming, I
> know). YMMV.

You also can do greylisting.
And you can worry less about false positives, because the sender
will know, unlike the blackholes or backscatter of post-SMTP
transaction filtering.


> If you did implement this, I'd be one of the first to switch to it. I'm
> currently using dcc out of procmail, which I hate, as it doesn't
> interface with my vdomain setup; only local users get the benefit of dcc...

The more I see of Postfix, the less I like it.  I keep seeing more
statements in its documentation that strike me as similarly unsupportable
or even inaccurate as the qmail liturgy.  However, there's no accounting
for tastes.

I've seen http://www.postfix.org/SMTPD_PROXY_README.html
If I can figure out the subset of SMTP that postfix uses and
how to part Rctp_to values, it would be possible to use the greylisting
and bounded-time header and body URL DNS blacklist features of dccifd
with postfix.

Parsing Rcpt_To values is a problem for this idea.  If the postfix
front-end handles virtual domains and aliases, there's no problem.  I
suspect it doesn't.  Then there are SMTP address lists.  However, 
simplistic recipient handling in dccifd would at worst break per-user
logs and whitelists, including the per-user controls on greylisting and
DNS blacklist checks.


The new -B stuff in dccm, dccifd, and dccproc has configurable bounds
on the time spent waiting for DNS blacklisting.  If any of the DNS
resolutions required take too long or if their aggregate becomes too
much, my code gives up and passes the message.  I think this is required
for busy (>100K/day) SMTP servers.


Vernon Schryver    vjs@rhyolite.com