On Aug 26, 2014, at 8:41 AM, Rick Macdougall <ri...@ummm-beer.com> wrote:
> On 2014-08-25 8:48 PM, Charles Sprickman wrote:
>> On Aug 25, 2014, at 3:04 PM, Rick Macdougall <ri...@ummm-beer.com> wrote:
>>> On 2014-08-25 2:55 PM, Charles Sprickman wrote:
>>>> Hello all,
>>>> A quick question, curious about what others are doing…
>>>> We still use qmailadmin with our vpopmail setup, because it does handle
>>>> all the basics pretty well. One weakness that’s giving us grief is
>>>> forwarding. Since qmailadmin has no option to both pipe the mail through
>>>> the spam scanner and *then* forward only clean emails, we end up
>>>> forwarding large amounts of spam to various large mail providers. These
>>>> providers may or may not view that as spam being sourced from *us*, and
>>>> then throttle/queue/block us.
>>>> For some people that I know are never going to touch qmailadmin, I put
>>>> together my own maildrop config to handle this, but I don’t have a
>>>> solution for the more general users that might change the forwarding
>>>> What’s everyone else doing?
>>> I block the spam before it enters the system using simscan.
>> Thanks - not an option here since I need to allow users to opt in or out,
>> I do run with the spamc and maildrop options enabled. I know that with the
>> spamc switch, all mail is being scanned. I’m not totally sure where
>> vdelivermail normally throws email to qmail-inject in the delivery path, or
>> if the maildrop patch causes maildrop to always do final delivery. If
>> maildrop is the last thing in the chain, I’m wondering if I can
>> short-circuit the existing forward mechanism and force a “toss this if spam
>> flag is “YES”…
>> Off to try to follow vdelivermail.c… :)
> If you are running with maildrop, vdelivermail isn't being used. Maildrop is
> doing the actual delivery to the Maildir.
To be specific, I’ve got vpopmail (5.4.33) compiled with the maildrop and
spamassassin configure options enabled. I put some log statements in my
maildroprc (basically the maildroprcv2 that comes with vpopmail) and also put a
wrapper around qmail-inject to log all args, envvars, and the parent process.
What I’ve found so far is that when per-user forwards are hit (ie: .qmail in
user’s $VHOME contains “&some...@gmail.com”), no part of maildroprc logs show
up, the calling process for qmail-inject is vdelivermail, and no spamassassin
headers yet exist. I really can’t quite follow the vdelivermail delivery
process very well, but I’m assuming this is intentional. There is clearly a
code path in vdelivermail where even with spamass and maildrop enabled, neither
of those touch the email.
My current plan, which avoids trying to patch something into vdelivermail, is
to wrap qmail-inject and pipe offsite forwards through spamc there (discarding
the message if spam threshold is exceeded). From what I see so far, mail that
ends up in the queue via qmail-inject is a very small proportion of our overall
volume, so I’m more comfortable catching the off-site forwards there than doing
something a bit heavier in qmail-queue (and the QMAILQUEUE patch for calling an
alternate qmail-queue). Very soon Postfix will be sitting in front of qmail as
well (oh, if I could just make postfix call vdelivermail…).