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 method would
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
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
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.
However, lets remember that if
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. Delete A and B
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
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
, 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 ?
(Yes, I'm playing devil's advocate here, since SA already
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 adding support
On Wednesday 02 March 2005 12:22 am, Charles J. Boening wrote:
slaps forehead 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
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
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
spamc
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 propagate
-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
spamc/spamassassin. Let
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
I don't think vdelivermail or vpopmail
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
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 configuration
[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:
slaps forehead I guess the pw_gid/pw_uid fields are numeric.
Yeah. bit flags.
Saving a file open
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 users
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 maildrop.
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
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 local
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
-
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 spamc-spamd calls inside vpopmail makes sense to me.
However then putting the logic that decides where to deliver the mail
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
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
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
On Tuesday 01 March 2005 2:27 pm, Charles J. Boening wrote:
snip
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
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 mention vpopmail
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 in
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 configuration
On Tuesday 01 March 2005 2
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 problems.
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
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 an option
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
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 does
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
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 the
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
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 a env
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 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
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 put it
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/Guide)
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
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
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 user
52 matches
Mail list logo
