On Fri, 25 Feb 2005 16:47:36 -0500 (EST), Ron Dyck <[EMAIL PROTECTED]> wrote:
> I'm currently upgrading my mail server and am installing simscan. Simscan
> claims that there is an option to configure vpopmail with spamassassin
> option:
> --enable-spamassassin
> (http://www.qmailwiki.org/Simscan/Gu
Jason S wrote:
On Fri, 25 Feb 2005 16:47:36 -0500 (EST), Ron Dyck <[EMAIL PROTECTED]> wrote:
I'm currently upgrading my mail server and am installing simscan. Simscan
claims that there is an option to configure vpopmail with spamassassin
option:
--enable-spamassassin
(http://www.qmailwiki.org/Sims
On Feb 25, 2005, at 4:12 PM, Rick Macdougall wrote:
That is a 5.5 option and is not available in the 5.4 series. I do
know a few people do run the 5.5 series in production but I do not
recommend it unless you are reading the vpopmail-dev list and are
prepared to debug some code. Ken and Tom ma
On Friday 25 February 2005 3:47 pm, Ron Dyck wrote:
> I'm currently upgrading my mail server and am installing simscan. Simscan
> claims that there is an option to configure vpopmail with spamassassin
> option:
> --enable-spamassassin
> (http://www.qmailwiki.org/Simscan/Guide)
> The allows vpopmail
On Feb 25, 2005, at 8:48 PM, Ken Jones wrote:
I wrote the code since we needed to support per user spamassasin
preferences. At Tom's request I put it in the 5.5 development version.
We run a 5.5.1 version production with no problems.
I think it's about time we merged this feature into the 5.4 relea
Will this also allow the user to sort spam to a user specified folder as
well? Would be nice to cut out a procmail process too.
--
Regards,
Tom
> On Feb 25, 2005, at 8:48 PM, Ken Jones wrote:
>> I wrote the code since we needed to support per user spamassasin
>> preferences. At Tom's request I pu
on 2/25/05 3:43 PM, Jason S <[EMAIL PROTECTED]> wrote:
> On Fri, 25 Feb 2005 16:47:36 -0500 (EST), Ron Dyck <[EMAIL PROTECTED]> wrote:
>> I'm currently upgrading my mail server and am installing simscan. Simscan
>> claims that there is an option to configure vpopmail with spamassassin
>> option:
>
Tom wrote:
Will this also allow the user to sort spam to a user specified folder as
well? Would be nice to cut out a procmail process too.
My interest is peaked. I am currently investigating doing just that and
not finding any good solutions. I just hate to use another perl or shell
script do to
On Saturday 26 February 2005 10:36 am, Tom Collins wrote:
> On Feb 25, 2005, at 8:48 PM, Ken Jones wrote:
> > I wrote the code since we needed to support per user spamassasin
> > preferences. At Tom's request I put it in the 5.5 development version.
> > We run a 5.5.1 version production with no pro
On Saturday 26 February 2005 1:19 pm, Tom wrote:
> Will this also allow the user to sort spam to a user specified folder as
> well? Would be nice to cut out a procmail process too.
Sounds like a good idea. We just need a place to store that information.
Perhaps an optional new file that could spec
On Sunday 27 February 2005 2:42 am, Kurt Bigler wrote:
> on 2/25/05 3:43 PM, Jason S <[EMAIL PROTECTED]> wrote:
> > On Fri, 25 Feb 2005 16:47:36 -0500 (EST), Ron Dyck <[EMAIL PROTECTED]>
wrote:
> >> I'm currently upgrading my mail server and am installing simscan.
> >> Simscan claims that there is
On Saturday 26 February 2005 1:19 pm, Tom wrote:
>> Will this also allow the user to sort spam to a user specified folder as
>> well? Would be nice to cut out a procmail process too.
>
> Sounds like a good idea. We just need a place to store that information.
> Perhaps an optional new file that cou
At 12:06 28/2/2005, you wrote:
..snip...
> How are you planning on
making per-user options available to individual
> users for editing? I thought I had read something about using
SqWebmail
> for this but I can not find the message now and can find no
other
> confirmation, and the SqWebmail info
On Fri, 25 Feb 2005, Ken Jones wrote:
I wrote the code since we needed to support per user spamassasin
preferences. At Tom's request I put it in the 5.5 development version.
We run a 5.5.1 version production with no problems.
I think it's about time we merged this feature into the 5.4 release.
Any
On Feb 28, 2005, at 2:36 PM, Bill Wichers wrote:
Maybe even a site-wite compile-time directive? Probably the most common
would be something like SPAM under the INBOX for the filtered messages.
Having it in SQL would be nice (allow users to configure it if they
call
the SPAM dir something else in t
on 2/28/05 7:06 AM, Ken Jones <[EMAIL PROTECTED]> wrote:
> On Sunday 27 February 2005 2:42 am, Kurt Bigler wrote:
>> How are you planning on making per-user options available to individual
>> users for editing? I thought I had read something about using SqWebmail
>> for this but I can not find th
Tom Collins wrote:
On Feb 28, 2005, at 2:36 PM, Bill Wichers wrote:
Maybe even a site-wite compile-time directive? Probably the most common
would be something like SPAM under the INBOX for the filtered messages.
Having it in SQL would be nice (allow users to configure it if they call
the SPAM dir s
>> How about if a mailbox called SPAM exists, put it there, otherwise just
>> drop it in the INBOX?
>
> That would be my choice, a lot of the systems I've looked at used the
> IMAP folder "Spam" to hold the messages tagged by spamc. That is how I
> had been planning to do it. Alternatively couldn't
On Monday 28 February 2005 6:51 pm, Tom Collins wrote:
> On Feb 28, 2005, at 2:36 PM, Bill Wichers wrote:
> > Maybe even a site-wite compile-time directive? Probably the most common
> > would be something like SPAM under the INBOX for the filtered messages.
> > Having it in SQL would be nice (allow
> >
> > How about if a mailbox called SPAM exists, put it there, otherwise
just
> > drop it in the INBOX?
>
> That sounds nice and clean. I like it.
>
> Ken Jones
If you implement this, please do not remove the ability to simply have
the message tagged and then be able to pass it to procmail or
Nick Harring wrote:
How about if a mailbox called SPAM exists, put it there, otherwise
just
drop it in the INBOX?
That sounds nice and clean. I like it.
Ken Jones
If you implement this, please do not remove the ability to simply have
the message tagged and then be able to pass it to procmail or mai
>
> Guilty, I have thousands of accounts, mostly commercial, and mail
comes
> constantly 24 hours a day. While there are some nice programs out
there
> to replace qmail-queue or to drop inside a dot qmail file, I really
want
> to avoid running the perl interpreter (once sometimes twice) for each
>
> Putting the spamc->spamd calls inside vpopmail makes sense to me.
> However then putting the logic that decides where to deliver the mail,
> and tying those to irrevocably together is what I'm asking not be done.
> I'm in the same load situation as you, my systems do a couple hundred
> thousand l
On Tuesday 01 March 2005 1:05 pm, Bill Wichers wrote:
> > Putting the spamc->spamd calls inside vpopmail makes sense to me.
> > However then putting the logic that decides where to deliver the mail,
> > and tying those to irrevocably together is what I'm asking not be done.
> > I'm in the same load
ing Spamassassin. Let simscan and qmail-scanner take care of
calling Spamassassin.
Charlie
-Original Message-----
From: Bill Wichers [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 01, 2005 11:05 AM
To: vchkpw@inter7.com
Subject: RE: [vchkpw] Spamassin configuration
> Putting the sp
On Mar 1, 2005, at 11:05 AM, Bill Wichers wrote:
Running spamc/spamd directly from vpopmail seems very, very scary to
me.
We handle well over 1 million messages/day here and have several beefy
machines front-ending for our mail system that do all the filtering
(ClamAV and Spamassassin). Running Sp
Tom Collins wrote:
On Mar 1, 2005, at 11:05 AM, Bill Wichers wrote:
Just a quick note.
vdelivermail already parses headers to make sure mail is not looping.
It could easily check for SpamAssassin headers and filter based on
that. Again, this would be a compile-time option, and those who kno
On Mar 1, 2005, at 1:34 PM, Rick Macdougall wrote:
Is that a good idea ? Say a spam slips through that forges the SA
headers ?
(Yes, I'm playing devil's advocate here, since SA already checks for
just that type of thing and ignores them/strips them out, but what
happens when some new admin doe
Tom Collins wrote:
On Mar 1, 2005, at 1:34 PM, Rick Macdougall wrote:
Is that a good idea ? Say a spam slips through that forges the SA
headers ?
(Yes, I'm playing devil's advocate here, since SA already checks for
just that type of thing and ignores them/strips them out, but what
happens whe
> On Mar 1, 2005, at 1:34 PM, Rick Macdougall wrote:
> > Is that a good idea ? Say a spam slips through that forges the SA
> > headers ?
> >
> > (Yes, I'm playing devil's advocate here, since SA already checks for
> > just that type of thing and ignores them/strips them out, but what
> > happens w
On Tuesday 01 March 2005 5:54 pm, Nick Harring wrote:
> > On Mar 1, 2005, at 1:34 PM, Rick Macdougall wrote:
> > > Is that a good idea ? Say a spam slips through that forges the SA
> > > headers ?
> > >
> > > (Yes, I'm playing devil's advocate here, since SA already checks for
> > > just that type
On Tuesday 01 March 2005 2:27 pm, Charles J. Boening wrote:
>
> I saw some discussion the other day about the pw_uid and pw_gid fields
> in the vpopmail sql tables. I vote to use the unused one (pw_gid IIRC)
> to store the spam setting. Say relative path to SPAM maildir. If the
> value is there
on 2/28/05 5:02 PM, Kurt Bigler <[EMAIL PROTECTED]> wrote:
> on 2/28/05 7:06 AM, Ken Jones <[EMAIL PROTECTED]> wrote:
>
>> We are almost ready to release a new php web interface that talks to the
>> vpopmail daemon where we planned on adding support for this spamassassin
>> stuff.
>
> You mentio
> On a high volume system like yours we could just check for spamassassin
> headers to see if it is marked as spam. That should not add too much extra
> processing since we already read through the email.
That's what I was thinking, and what we already have a lot of users doing.
It's easy to key i
specified when vdelivermail was called.
How about making it an environment variable that could be set via
tcpserver?
Charlie
-Original Message-
From: Ken Jones [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 01, 2005 4:46 PM
To: vchkpw@inter7.com
Subject: Re: [vchkpw] Spamassin configurati
PROTECTED]
Sent: Tuesday, March 01, 2005 3:50 PM
To: vchkpw@inter7.com
Subject: Re: [vchkpw] Spamassin configuration
Tom Collins wrote:
> On Mar 1, 2005, at 1:34 PM, Rick Macdougall wrote:
>
>> Is that a good idea ? Say a spam slips through that forges the SA
>> headers ?
&g
I don't think vdelivermail or vpopmail in general should be calling
spamc/spamassassin. Let that be handled elsewhere. Let's stick to
delivering mail and deciding where it goes.
However, lets remember that if spam is only scanned at the MTA level,
SpamAssassin user preferences will not function
On Tuesday 01 March 2005 7:48 pm, Kurt Bigler wrote:
> on 2/28/05 5:02 PM, Kurt Bigler <[EMAIL PROTECTED]> wrote:
> > on 2/28/05 7:06 AM, Ken Jones <[EMAIL PROTECTED]> wrote:
> >> We are almost ready to release a new php web interface that talks to the
> >> vpopmail daemon where we planned on addin
On Wednesday 02 March 2005 12:22 am, Charles J. Boening wrote:
> I guess the pw_gid/pw_uid fields are numeric.
Yeah. bit flags.
> Saving a file open/read/close is a good idea if possible. That's why I
> was thinking if the current vpasswd/database structure could be modified
> it wouldn't be too
On Mar 1, 2005, at 5:48 PM, Kurt Bigler wrote:
What I should have said was that my ps listing shows nothing that I
recognize as a vpopmail daemon. I didn't think vdelivermail was a
daemon,
but that may be my ignorance of what a daemon is.
So you could clarify "vpopmail daemon"?
In the vpopmail 5
On Mar 1, 2005, at 10:22 PM, Charles J. Boening wrote:
Would another option be to pass the spam directory as an option to
vdelivermail in the .qmail-default file for a domain? Granted it
wouldn't address making the spam folder settable on a per user basis
but
then again I guess it doesn't really
Point taken. And a good one. :)
-Original Message-
From: Paul Oehler [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 02, 2005 12:36 AM
To: vchkpw@inter7.com
Subject: Re: [vchkpw] Spamassin configuration
> I don't think vdelivermail or vpopmail in general should be calling
>
> > How about making it an environment variable that could be set via
> > tcpserver?
>
> I don't think that would work, since the environment variables only
> flow through to qmail-smtpd. I don't think there's a way for the
> variables to flow through to qmail-local.
>
Correct, they cannot pr
> -Original Message-
> From: Paul Oehler [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 02, 2005 12:36 AM
> To: vchkpw@inter7.com
> Subject: Re: [vchkpw] Spamassin configuration
>
> > I don't think vdelivermail or vpopmail in general should be calling
>
On Wednesday 02 March 2005 01:49 pm, Nick Harring wrote:
> > -Original Message-
> > From: Paul Oehler [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, March 02, 2005 12:36 AM
> > To: vchkpw@inter7.com
> > Subject: Re: [vchkpw] Spamassin configuration
> >
On Mar 2, 2005, at 11:49 AM, Nick Harring wrote:
Obviously this is a current limitation in simscan, however I think the
correct behavior would be to scan once for scoring, then gather white
and black lists, modify scoring accordingly, then delete anybody who
has
exceeded their threshold from the r
he filtering on their end?
On the environment variable option. Is there a way we can set variables
for vpopmail?
Charlie
-Original Message-
From: Ken Jones [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 02, 2005 7:14 AM
To: vchkpw@inter7.com
Subject: Re: [vchkpw] Spamassin co
l Message-
From: Ken Jones [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 02, 2005 7:14 AM
To: vchkpw@inter7.com
Subject: Re: [vchkpw] Spamassin configuration
On Wednesday 02 March 2005 12:22 am, Charles J. Boening wrote:
> I guess the pw_gid/pw_uid fields are numeric.
Yeah. bit flags.
&
> > > > I don't think vdelivermail or vpopmail in general should be
calling
> > > > spamc/spamassassin. Let that be handled elsewhere. Let's stick
to
> > > > delivering mail and deciding where it goes.
> > >
> > > However, lets remember that if spam is only scanned at the MTA
level,
> > > SpamAss
On Thursday 03 March 2005 08:59 am, Nick Harring wrote:
> > > > > I don't think vdelivermail or vpopmail in general should be
>
> calling
>
> > > > > spamc/spamassassin. Let that be handled elsewhere. Let's stick
>
> to
>
> > > > > delivering mail and deciding where it goes.
> > > >
> > > > Howev
> >
> > Simscan isn't replacing qmail-smtpd, so this isn't strictly an smtp
> > limitation. Perhaps I'm just not getting it, but why wouldn't the
> > following work:
> > Email comes in for users A, B and C. A and B have an SA threshold of
5,
> > C has a threshold of 9. The message scores at 7. Dele
On Thursday 03 March 2005 10:54 am, Nick Harring wrote:
> I attempted to use the archive of the simscan list, and found one
> discussion which ended with the abrupt declaration from you that it
> couldn't be done. Perhaps you could point me at a thread where there's
> real discussion of this?
I wi
On Mar 3, 2005, at 8:54 AM, Nick Harring wrote:
No, it wouldn't require this. It would require that you edit the
recipient list prior to queueing. There's nothing 'ugly' that I can see
about that process.
I think Nick's method would work for those who want to block anything
that scores as spam but
> How many messages come into a server for multiple recipients in the
> same domain? I guess if someone was mailing multiple people at the
> same company, it would happen. But with most mailing lists using
> custom bounce messages for each recipient, they wouldn't be affected.
>
> How about the
On Wed, 2 Mar 2005, Ken Jones wrote:
We are using it in vhostadmin to build a php based management interface.
Since vpopmaild can be run under tcpserver (over ssl if you need), it lets
management interfaces to run on any computer and access vpopmaild
over the net.
I have a development version of vh
on 3/3/05 8:54 AM, Nick Harring <[EMAIL PROTECTED]> wrote:
>>> Simscan isn't replacing qmail-smtpd, so this isn't strictly an smtp
>>> limitation. Perhaps I'm just not getting it, but why wouldn't the
>>> following work:
>>> Email comes in for users A, B and C. A and B have an SA threshold of
> 5,
on 3/3/05 12:03 PM, Tom Collins <[EMAIL PROTECTED]> wrote:
> On Mar 3, 2005, at 8:54 AM, Nick Harring wrote:
>> No, it wouldn't require this. It would require that you edit the
>> recipient list prior to queueing. There's nothing 'ugly' that I can see
>> about that process.
>
> I think Nick's met
57 matches
Mail list logo
