I've been in lurk mode for quite some time, but I have to throw in my $0.02. As an admin of several
busy servers, and mailman lists that send out close to a million emails per week, I can say that I
don't have the time to deal with trying to create a new interface. I made my own cheat sheet of h
HI guys,
Pardon the OT request, but I have a Python app that is generating an occasional error, and I need
someone fluent in Python to help me fix it. Its probably some simple error trapping that is
needed. My Python skills are limited to some MM 2.x hacking, and that's about it! Please cont
Mark Sapiro wrote:
Barry Warsaw wrote:
So I'd like to solicit your input on how you use the feature, and if
you have any ideas for an approach that would be easier to understand,
more useful, or both.
My typical list is set up as follows to allow plain text only. List
mail is not
Hey gang,
In 2.0.x, how do you bump the volume number, and reset the digest number back to 1?
Bob
___
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-developers
> My simplification assumes that temporary failures really /are/
> temporary! I think my approach is robust in the face of probably the
> most common temporary failure I see as a list admin: a user running
> out of disk space for a period of several days or a week. Once they
> get a clue and fre
Ok, I've thought more about this today, and optimized my code a little..
Check this out:
min_bounce_days = 5 (max # of days we say it will take for a bounce to come to us)
max_bounce_days = 14 (number of days to allow bouncing)
Once every day (really doesn't matter when), post_counter is incre
> Hmm, my current approach has simply been to write db entries to a file
> pointed to by the alias_maps variable.
Right, and this is still necessary. But the virtual maps are also equally as
important, since the newbies are still gonna say "Why is mail to the list bouncing if
it automagically
> I actually don't plan on updating auto for MM2.1. To use it requires
> you to configure Postfix in ways that could interact poorly with other
> parts of your mail system, depending on your topology. I'm not sure
> if I should leave it around for posterity, or just zap it.
Hey Barry,
So then