I suppose it can be, but it is a question of where you implement your security.
If mailman is to use SQL to store preferences then it is up to mm to deal with
what records a user can update. If the mm interface to LDAP goes through one
master LDAP account, then it is still mm's job... But if mm bin
I feel bad about jumping in to this discussion, and not necessaraly being
prepared to offer any real help, but anyway.
LDAP may be a better data[base|sink] for configuration data then SQL. It may be
harder to work with (only because less people have experience with it), and it
may be less usefull t
I just happen to remember a note from the Cyrus-IMAP docs that may help you, if
you happen to be running linux with ext2. Quote: "LINUX SYSTEMS USING EXT2FS
ONLY: Set the user, quota, and partition directories to update synchronously."
http://asg.web.cmu.edu/cyrus/download/imapd/install-configure.h
I dont know of any, and this sugestion is off the cuff. (but it would be fun to
try :P)... Do it at the MTA level, ie: (just invented pseudo alias-code)
[EMAIL PROTECTED]: |$MAILMAN cvs
[EMAIL PROTECTED]: |$MAILMAN dev
[EMAIL PROTECTED]: |$MAILMAN dev
The cvs list may
- If all the SPAM is coming from one server, block the server at the
SMTP level.
- Spammers using Mailman to send out spam is a Spam problem, not a
Mailman problem.
- Spammers might not actually be using Mailman, just forging the
appearance of mail. I think this is far more likely. While all of
sp
Im not what you could consiter a power user as far as Mailman is
concerned, but it is my understanding that there is more then one way
for messages to get into the 'admindb' (if thats what the
to-be-moderated queue is called). Being flaged as spam would be another
way to enter that queue. How it g
I have a couple of questions.
First: If I was to submit a (compleate) set of patches that allow at
least some per list configuration for SpamAssassin integration, would
they be accepted?
As a first attempt I would be just concerned with setting the score, and
actions to take. Likely it would be
On Mon, 2003-11-17 at 20:17, J C Lawrence wrote:
> On Mon, 17 Nov 2003 19:22:22 -0400
> Jeff Warnica <[EMAIL PROTECTED]> wrote:
> > Uh, because ISPs cant be deleting mail, ever?
> Actually they can and do, constantly, now, today and for many
> yesterdays.
The default
Uh, because ISPs cant be deleting mail, ever? Or at least deleting
messages with an extreemly high score. Tag everything and leave it up to
something else to deal with. Something else being procmail, seive,
mailman, or the end user agent. Even if you want resonably scored spam
not to reach Mailman
12:02, PieterB wrote:
> On Tue, Nov 11, 2003 at 10:07:52PM -0400, Jeff Warnica wrote:
> > ID 840426
> >
> > This is different from the 'other' SA handler as it deals with pre-taged
> > messages. IMHO this is far more likely to be the case in an ISP
> > e
sourceforge patch id: 840432
I may have posted it to the zmailer lsit before, but no harm in
reminding people of my all around brilliance.
A patch for ZMailers alias.cf file that allows for Mailman integration
into this alternative, high performance, MTA in the same style as all
the other MTA in
ID 840426
This is different from the 'other' SA handler as it deals with pre-taged
messages. IMHO this is far more likely to be the case in an ISP
enviroment. The general concensious on my MTA's mailing list being that
all mail should be tagged, flagged, and passed on leaving it up to
'something
12 matches
Mail list logo
