The features missing from above are changing per domain (which even if
there was an option, it should just make the user's .qmail file filter
and not change the .qmail-default file). It is also missing the
.qmailadmin-limits directive.
Why is changing the .qmail-default file a bad thing?
Forgive me if this is a FAQ or something, but I don't see anything about
1.0.21 on the inter7 site (inter7.com) -- is there a better place to be
looking?
Public CVS access maybe?
Jeff Hedlund wrote:
Derek Watson wrote:
Just to recap:
The community wants SpamAssassin integration in
QmailAdmin is now on sourceforge: http://sourceforge.net/projects/qmailadmin/
I think there is a link to it from the development page on Inter 7's site:
http://www.inter7.com/develop.html
I've been playing with per-user SA config, and I thought I had a good
solution until I realized that
Rob Genovesi wrote:
QmailAdmin is now on sourceforge:
http://sourceforge.net/projects/qmailadmin/
I think there is a link to it from the development page on Inter 7's
site: http://www.inter7.com/develop.html
Found it there, thanks.
I've been playing with per-user SA config, and I thought I
Benjamin Tomhave wrote:
Why is changing the .qmail-default file a bad thing?
The reason I chose to move away from using the .qmail-default file is
because you won't always get the correct username. If you are not using
per-user preferences, then it wouldn't matter.
So it's not a matter of
Derek Watson wrote:
What I still don't understand is why we are still passing the local
catch all account to vdelivermail as a Maildir (from .qmail-default).
In my opinion, this should be an email address
([EMAIL PROTECTED]) so that, once again, the message can take
advantage of .qmail
On Tuesday, July 8, 2003, at 09:12 AM, Benjamin Tomhave wrote:
Why is changing the .qmail-default file a bad thing? Why not setup
filtering for the whole domain in one move rather than having to setup
spam-filtering on a per-user basis? I want spam filtering on by
default,
and I can't really
On Tuesday, July 8, 2003, at 10:27 AM, Tom Collins wrote:
In QmailAdmin 1.0.21, we stopped using aliases and replaced them with
forwards, so instead of having qmail drop the message in a Maildir
(without any processing of that user's .qmail file), it will get
redelivered. So, if .qmail-user
As a followup to my own message, Jeff Hedlund has a patch for
vdelivermail that will process the .qmail file even when doing a
Maildir delivery.
Excellent -- Jeff, care to share the patch? Am I correct to assume
that this patch made it into the next vdelivermail?
Does anybody have an objection to a new line in .qmailadmin-limits that
toggles the ability to spam filter on a per-domain basis? Is this
something that I should code myself, or would the main developers prefer
a 'Feature Request?
This thread explains why we left it as a Maildir.
I am also integrating SA support into my PostOffice front-end project so I want to
see where this is leading development-wise before I start making decisions in the
code as to the logic and functionality.
Todd Brill
One Smart Company Hosting Inc.
Affordable
Company Sysadmin [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 12:04 PM
To: [EMAIL PROTECTED]
Subject: Re: [qmailadmin] Help with code! SpamAssassin integration
I am also integrating SA support into my PostOffice front-end
project so I want to
see where this is leading development-wise
Message-
From: Todd Brill - One Smart Company Sysadmin [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 12:04 PM
To: [EMAIL PROTECTED]
Subject: Re: [qmailadmin] Help with code! SpamAssassin integration
I am also integrating SA support into my PostOffice front-end
project so I want
Benjamin Tomhave wrote:
The reason I chose to move away from using the .qmail-default file is
because you won't always get the correct username. If you are not using
per-user preferences, then it wouldn't matter.
I'm using sql-based per-user preferences with maildrop and SpamAssassin.
Everything
Are you using a catchall? I think I was getting the incorrect username
when using a catchall.. but maybe I had already fixed that problem, I
don't remember.
For our primary domain, no, we're not using a catchall. However, some other
domains are using a catchall, for which I've found a way to
Benjamin Tomhave wrote:
Are you using a catchall? I think I was getting the incorrect username
when using a catchall.. but maybe I had already fixed that problem, I
don't remember.
For our primary domain, no, we're not using a catchall. However, some other
domains are using a catchall, for
Joseph Young
Involved.com
System Admin
The patch that I was creating will not be finished as that QmailAdmin 1.0.22
has the code I needed.
it adds to .qmail-default the preline maildrop mailfilter bit.
joe
- Original Message -
From: Derek Watson [EMAIL PROTECTED]
To: [EMAIL
For our primary domain, no, we're not using a catchall.
However, some other
domains are using a catchall, for which I've found a way to solve the
problem. Would be more than happy to share my mailfilter (for maildrop)
script with anyone interested.
Yes, I'm curious to see your script.
: Re: [qmailadmin] Help with code! SpamAssassin integration
Joseph Young
Involved.com
System Admin
The patch that I was creating will not be finished as that
QmailAdmin 1.0.22
has the code I needed.
it adds to .qmail-default the preline maildrop mailfilter bit.
joe
- Original
Benjamin Tomhave wrote:
So, I just modified that check as follows:
DUMMY=`test -d $VHOME/Maildir`
if ( $RETURNCODE == 1 )
{
to ! [EMAIL PROTECTED]
exit
}
And as you mention below, this makes it so you cannot change your
catchall through qmailadmin...
I see... qmailadmin does not handle
I would recommend you set qmailadmin to allow the use to set one of the
following toggle:
1. No spam filtering
2. Only Tag the spam do nothing else for POP3 users.
3. Filter the spam into a spam folder which means you need IMAP to get
to it.
4. Delete all mail tagged as spam
It could look like
Benjamin Tomhave wrote:
Yep, though if there was a consensus on this list about an effective
mailfilter file, I think it would be easy for qmailadmin to change the
catchall and rewrite the mailfilter file.
There's no reason for qmailadmin to modify the mailfilter file. There
exists a way to
Benjamin Tomhave wrote:
Yep, though if there was a consensus on this list about an effective
mailfilter file, I think it would be easy for qmailadmin to change the
catchall and rewrite the mailfilter file.
There's no reason for qmailadmin to modify the mailfilter file. There
exists a
On Tuesday, July 8, 2003, at 12:29 PM, Benjamin Tomhave wrote:
I do, however, already have a small plugin for
my SquirrelMail webmail interface that customers use to modify their SA
preferences (required_hits, blacklist_from, whitelist_from). If we all
compare notes on current implementation
On Tuesday, July 8, 2003, at 12:51 PM, Benjamin Tomhave wrote:
Just curious, but is the preline needed? I'm just using | maildrop
mailfilter in my .qmail-default file today and it seems to work just
fine.
I didn't think it was needed either -- that it was just for mbox
delivery. If it's
On Tuesday, July 8, 2003, at 01:08 PM, Jeff Hedlund wrote:
So anyway, back to the original topic of why I avoided using
.qmail-default: It allows for a global mailfilter script that doesn't
break functionality of qmailadmin (with regard to catchall, etc) and
that works in all situations.
Can you forward me a URL to that SquirrelMail plugin?
Weelllnot exactly. We wrote our own plugin (see sanitized
attached). We did not contribute it to SM plugins, either, since we don't
have the luxury of time to clean it up and make it SM-ish.
It looks like there are many options
On Tuesday, July 8, 2003, at 01:08 PM, Jeff Hedlund wrote:
So anyway, back to the original topic of why I avoided using
.qmail-default: It allows for a global mailfilter script that doesn't
break functionality of qmailadmin (with regard to catchall, etc) and
that works in all
On Tuesday, July 8, 2003, at 03:01 PM, Benjamin Tomhave wrote:
Thank you for the link, Joe. I think that, alone, proves that preline
is
not necessary. Reading up on it, it seems to set headers that would
only
make sense to courierdeliver. I don't know, maybe lots of folks are
using
I agree with Benjamin. The message should already have Delivered-To:
and Return-Path: headers at this point, and the addition of a From
line
is unnecessary for non-mbox setups.
At this poing to only way to get the Delivered-To: and
Return-Path: headers is to use preline.
The problem with
30 matches
Mail list logo
