Re: [Mailman-Users] virtual domains

2008-05-22 Thread Stefan Förster
* Mark Sapiro [EMAIL PROTECTED] wrote:
 Melinda Gilmore wrote:
 
 I know this has been covered alot and I do see alot of talk in the
 archives, but I am new to the whole, mailman/postfix/apache/redhat
 world and the instructions are not clear to me because of that.  Is
 there anyone out there that has the actually settings and what files
 to change in postfix, apache, mta, and whatever to get virtual
 domains to work.  Am I to understand that if I had a list called
 [EMAIL PROTECTED] (our domain) and I want a virtual
 domain to go with it called [EMAIL PROTECTED] I can get this to work?
 
 
 Not exactly. If you have a list named something that is currently in
 the lists.service.osu.edu domain, you could move it to the network.org
 domain, but the whole idea of virtual domains in Mailman is that the
 various domains are disjoint (although currently list names still have
 to be globally unique).
 
 If you just want to be able to mail to [EMAIL PROTECTED] in
 addition to mailing to [EMAIL PROTECTED] and have either
 address go to the list, this would all be done in Postfix and DNS.

I think one would have to add [EMAIL PROTECTED] to
acceptable_aliases, too.

As a remark, I really think that integration of Mailman into Postfix
using relay_domains and postfix-to-mailman.py should be included in
the official installation documentation. Postfix's concept of
virtual_alias_domains is very poweful and therefore offers lot's of
ways you can totally break your mail system if you are inexperienced -
you can break recipient validation or introduce mail loops, for
example.

Any aliasing needed can still be done with virtual_alias_maps if one
absolutely _has_ to have aliases. With relay_recipient_maps you get
better control about acceptable recipients (although you have to set
this up yourself, I didn't see any way in Mailman to handle this in an
automatic way).

And as a last advantage, on a busy server, I personally would refrain
from using Berkeley BD hash tables, because updates to those are not
done atomically which might seriously break mail to lists if mail
arrives while the maps are updated. Using CBD tables help's a lot
here, safe for the much smaller memory footprint.



Cheers
Stefan
-- 
Stefan Förster http://www.incertum.net/ Public Key: 0xBBE2A9E9
Science is what happens when preconception meets verification.
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp

Re: [Mailman-Users] Problem with 2.1.9 acceptable_aliases

2008-05-22 Thread Barry Finkel
Barry Finkel wrote:

 There was a posting to a number of lists here yesterday 
 
  To: [EMAIL PROTECTED]
 
 all of the lists are linked; some of the lists are subscribed to others.
 I took that address and added it to
 
  acceptable_aliases


And Mark Sapiro replied:

What did you add to acceptable_aliases? And for which list(s)?

A post addressed to [EMAIL PROTECTED] will presumably be 
delivered to the comp_info list. In order for it not to be held by that 
list, you need either

[EMAIL PROTECTED]

or a regexp like

^comp_info([EMAIL PROTECTED])[EMAIL PROTECTED]

in the acceptable_aliases of the comp_info list. Then if other lists are 
members of the comp_info list, you need the same thing in 
acceptabale_aliases of those other lists to prevent the post from being 
held there.

and I replied:

For each of the five lists for which there was a posting held for
moderation I entered

 [EMAIL PROTECTED]

in the acceptable_aliases box on the admin web page via cut-and-paste.

The mailling list that, I assume, is part of the distribution list for
this comp_info_cats+noc list is

 [EMAIL PROTECTED]

That address is an accceptable_alias for the Mailman list

 [EMAIL PROTECTED]

and to that list is subscribed

 [EMAIL PROTECTED]
 [EMAIL PROTECTED]

In addition

 [EMAIL PROTECTED]

is an accceptable_alias for the Mailman list

 [EMAIL PROTECTED]

and to that itad list is subscribed three other Mailman lists:

 [EMAIL PROTECTED]
 [EMAIL PROTECTED]
 [EMAIL PROTECTED]

For each of these six lists (out, itad, opstr, ad, cs, us) I had added

 [EMAIL PROTECTED]

to accceptable_aliases.

The only thing strange about the string I added to acceptable_aliases
is the two + characters.  I did not know if the plus characters were
causing problems.

I ran another test:

1) I set up an e-mail alias

[EMAIL PROTECTED]

   that points to an existing test list on my test Mailman 2.1.9
   system.

2) Via that test list admin web page, I added

[EMAIL PROTECTED]

   to the acceptable_aliases list.  This address is the only entry in
   the list.

3) I sent test mail to

[EMAIL PROTECTED]

   and the mail was sent to the moderator (i.e., me) due to
   implicit destination

I have not looked at the code, and I am not an expert in regular
expressions.  I surmise that Mailman is treating the address as a
regular expression, which matches

 [EMAIL PROTECTED]
 [EMAIL PROTECTED]
 [EMAIL PROTECTED]
 [EMAIL PROTECTED]
 ...

but does not match

 [EMAIL PROTECTED]

I then changed the acceptable_aliases to

 [EMAIL PROTECTED]

and test mail was distributed.
--
Barry S. Finkel
Computing and Information Systems Division
Argonne National Laboratory  Phone:+1 (630) 252-7277
9700 South Cass Avenue   Facsimile:+1 (630) 252-4601
Building 222, Room D209  Internet: [EMAIL PROTECTED]
Argonne, IL   60439-4828 IBMMAIL:  I1004994

--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp


[Mailman-Users] archive/attachment preening

2008-05-22 Thread Savoy, Jim
 
Hi all,
 
  We have 870+ mailing lists and about 20 gigs worth of stuff in the
private/archives
directory. I thought I would do a little spring cleaning, such as
sending mail to list
owners to see if they still want their lists. But I would also like to
pare down the size
of the archives directory, which have been allowed to grow wild, using
cron jobs. Before
I do that, I want to get assurance from this list that I fully
understand how the archives
are written.
 
We are currently running Mailman v2.1.5 and we'll upgrade to v2.1.10
later this summer.
 
Please confirm the assumptions I am about to make before I write the
preening
scripts for cron. I also want to write a bunch of scripts that look for
certain information.
 
1) If a list is digestable and archiving was never turned on, then the
   archives/private/listname/index.html will contain only the
originally-created file
   (which basically says No messages have been posted to this list yet,
so the
   archives are currently empty).
 
2) If there is no mbox file in the /archives/private/listname.mbox
directory, then the list
has never had archiving turned on.
 
3) If a list is digestable but there is no attachments directory in
/archives/private/listname,
then the list has never had a message posted to it.
 
4) If the list is digestable, and archiving has never been turned on,
then files in the
archives/private/listname/attachments directory are only useful to
already-existing
subscribers who have digesting turned on (ie if I poll a list and it
has no members
subscribed as digest users, then it is safe to delete all files in
the attachments tree).
 
If all of my above assumptions are correct, my psuedo-code would do
something like this:
 
  if (list is not archived and has no digest members)
  keep stuff in attachments dir for 1 month;
  
  if (list is not archived but does have digest members)
keep stuff in attachments dir for 1 year;
 
  if (list is archived)
keep stuff in attachments dir for 3 years;
 
For the archived lists (we have about 150 of them) I will contact the
owners first, to warn them
that I plan to pare their archive down to 3 years max. If they protest,
I will add them as an
exception to the rule and skip over them during the cron job run. I know
that there is more to
be done with regards to reducing the size of archives (ie running arch
--wipe on the editted, pared
down .mbox file, but I will do that manually). For now I am mostly
interesting in keeping the
stuff in the attachments directories to a minimum. I realize that
deleting stuff in /attachments
breaks links in the archive and digest messages, but I think that is
reasonable for the really
old messages (provided the list owner concurs).
 
One final question. I know that you can change a list's settings with
/bin/config_list, but can you
poll a list for settings? For example, you can use /bin/list_members
-d to see which members
of a list read in digest mode, but how can I find out which lists have
archiving turned on? Or do I
have to examine the archives/private tree to garner that kind of info?
Thanks!
 
 - jim -
 
 
 
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp