RE: [qmailtoaster-devel] QMT v2 chat

Sounds like something similar to  TrendMicro's + qmail in sandwich mode. Two
instances of qmail for incoming and outgoing. Incoming instance will receive
mail from external or internal domains and then send for scanning and then
again  sending it for local delivery. 

-----Original Message-----
From: Jake Vickers [mailto:jake <at> qmailtoaster.com] 
Sent: 05 July 2010 21:24
To: qmailtoaster-devel <at> qmailtoaster.com
Subject: [qmailtoaster-devel] QMT v2 chat

So I started to work on v2 again a little - basically repackage some of the
initial packages to fit the "new way of doing things" (ie: Cent and Fedora
for now, other distros as others contribute).

For those new to the list, v2 of QMT is going to use amavisd-new. This will
allow the elimination of a spamassassin-toaster package, and possibly a
clamav-toaster package. Spamassassin will use the upstream package, and I
think we can make clam work from upstream but I have not fully investigated
this yet. May require a *small* config change (not sure if upstream uses
sockets or not).
Anyway, mail flow will work like this (hopefully email formatting does not
get mangled):

   I
   V
(Incoming qmail-smtp)    ->    (amavisd-new)    ->    (Scanned 
qmail-smtp)    ->    (qmail-local)

So incoming mail comes into an incoming qmail-smtp where we can pre-process
mail, and it then gets sent to amavisd-new (instead of simscan). Amavisd-new
processes it (spam, virus, etc.) and then send it to a "it's been scanned"
qmail-smtp process to be sent to qmail-local for delivery.

The two qmail-smtp processes pose some interesting features. There will be
slightly more overhead, but I think it will be negligible.
Some of these features can be viewed as drawbacks as well. This thread is
for polite, constructive talk, and for me to let you know where I'm heading
with this, and ask for feedback.

Since there will be two qmail-smtp processes, we can work this one of two
ways. The one that I am leaning towards is separate configs. Meaning that
each qmail-smtp process has it's won tcp.smtp file, and it's own control dir
for config files. I think this will allow the greatest flexibility, which
outweighs the extra configuration needed. The control files *could* be
sym-linked to each other for ease, or both qmail-smtp processes could use
the same control dir if we decide that's the better way to go.
Ideally you could control how mail is handled on the initial qmail-smtp
process (relay without scanning, per IP mail control, many of the same
features we have now). Amavisd-new gives us spam and virus scanning, with
maximum flexibility. Per-user spam controls are on the top of the list. A
quarantine for virus/spam emails that can be released by Postmaster is also
on the radar (if possible).
The second qmail-smtp process allows mail to be manipulated again - ie: 
put in a spam folder, relayed after being scanned for those that want to use
it as a spam gateway, etc. Lots of possibilities.

I will give each qmail-smtp process a name, just like qmail-smtp and
submission have their own names (but are both qmail-smtp) to make
differentiating between the two easy (ie: qmail-smtp and qmail-inside, or
qmail-outside and qmail-inside, or something - naming is irrelevant except
for to the user).

This will bring up an interesting chat about patches for the main
qmail-toaster package as well. I had looked at starting over with the patch
list, and also looked at John Simpson's big patch
(http://qmail.jms1.net/patches/), but am leaning more towards keeping the
patch set we already have. If we keep with the patch set we already have, I
would update the patches as much as possible (ie: new version of chkuser -
and more flexibility, so while your tcp.smtp file will be 50+ entries, there
will not be any more complaints about not being able to do something).

Well, that's about all of the time I have for today. Got to run. This should
let you guys know where I am in the design process, and where I'm at
cross-roads.
The 1.3 branch will stay available. Once the v2 branch is out, I'll go back
and "freshen" some of the packages for the 1.3 branch and users will (for
the short-term future) have the option of installing either version.

---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-devel-unsubscribe <at> qmailtoaster.com
For additional commands, e-mail: qmailtoaster-devel-help <at> qmailtoaster.com