On Mon, Mar 08, 1999 at 10:53:58AM +0100, Harald Hanche-Olsen wrote:
> | How would you propose going about writing clairvoyant code which would
> | know in advance that the client on the other side of a new SMTP connection
> | will do a MAIL FROM: with an unresolvable address at some point in the
> | future?
>
> Clearly, you can't. But what you could do is to have a program
> sitting between the TCP socket and qmail-smtpd. Normally, it would
> just pass every incoming command to qmail-smtpd, but it would check
> any MAIL command first. If it's bad, it will take over and reject
> every RCPT or DATA command until a RSET or new MAIL command appears.
What I was thinking about is a program that carried out the SMTP
conversation until the MAIL FROM occurred, and then checked that the address
was "correct" (by DNS lookup). If it isn't, drop the SMTP as spam, otherwise
turn around and replay the conversation to qmail-smtpd and then link the two
together.
> Avoiding patches is a valid goal, but not at any price.
Too true. However I am concerned that there are a LOT of patches for Qmail
now that are needed to make it compete with sendmail (anti-UCE support is
extremely lacking in "pure" qmail), and if I go down the path of shoving all
the (great) patches available into qmail, I'll end up with something
unsubstainable. DJB certainly implies he thinks most of these patches should
be done as standalone apps instead of qmail patches (rblsmtpd is an example
of this) - so I'm just asking what he's suggesting...
Personally I think http://www.flame.org/qmail/mlg-patches.diff is a great
patch (does all I'm asking, AND assigns "spam points" to each message -
bouncing when a threshold level has been met, adding a "X-Spam" header
otherwise so that you can then filter it).
--
Cheers
Jason Haar
Unix/Network Specialist, Trimble NZ
Phone: +64 3 3391 377 Fax: +64 3 3391 417
