> I can give you a good point on #2 why it should be done by QMAIL-SMTP
rather
> than TCPSERVER -- if you want to inhibit *all* connection from known
SPAMmer
> IP blocks _except_ where the sender can do SMTP-AUTH... TCPSERVER has no
way
> of handling this... Also, TCPSERVER doesn't provide SMTP error messages
> back (you can modify it fairly easily to allow QMAIL-SMTP to send the
error
> message on it's behalf, and do tar pitting, etc etc etc).
yes, tarpitting has to be done in qmail-smtpd, but using tarpitting implies
that you're still accepting the mail. if you're not going to accept the
mail anyway, why bother allowing the connection to succeed and then closing
it? tcpserver will catch the IP blocks and just refuse the connection.
smtp-auth isn't exactly a reason to move the ip checking into qmail-smtpd.
if you're denying a net block unless they use smtp-auth, you aren't gaining
anything - anyone on that net block can spoof the connection. if you want
real security use ssh and forward ports.
> And, speaking from experience, putting a patch together sounds easy, but
> isn't always that simple. I run QMAIL with a fair number of changes that
> are of little interest to most people; building a patch is a little more
> tedious when it needs to be able to be applied to a generic QMAIL
> distribution. Don't get me wrong, PATCHES are the right way -- but
> sometimes providing the modified source is the most expedient to get
> comments from others and allow them access to your work.
bah. "man diff" - it's fairly straightforward. if you intend to distribute
your patches you should be building them and running diff's off of a
pristine qmail install. otherwise there could be hidden conflicts between
your changes and some other patch you've installed.
shag
=====
Judd Bourgeois | CNM Network +1 (805) 520-7170
Software Architect | 1900 Los Angeles Avenue, 2nd Floor
[EMAIL PROTECTED] | Simi Valley, CA 93065
Quidquid latine dictum sit, altum viditur.
