FAQ
Hello,

Apologies for jumping onto the list and posting right away, I realise
it's bad netiquette.

I admin two servers for a large non-profit organisation. On Thursday, one
of them died. At the time we were using a different mailing list manager,
but had plans to gently migrate the dozens of lists to Mailman. Now what
was going to be an orderly migration is now a frantic scramble, as mailing
lists are the lifeblood of the workings of the organisation.

But I've run into a problem. I'd assumed that Mailman could support
virtual domains without list-name collisions, as I'd seen it done in a few
places. But according to the FAQ and everything else I've read this
evening, it's not the case.

This is about all I know though. There seems to be much posted on the
subject. It seems it'll be in version 3, and people have asked for it to
be in version 2.2. I've seen mentions of multiple patches and multiple
versions ranging over the last 6 years or so. And the WIKI FAQ entry,
which itself was updated 2 years ago, points to a patch at
http://nix.lauft.net/htdocs/mailman/ which is generating a "Connection
Refused" error. So I'm a bit stuck and am not sure where to go next.

I see I've only really got 4 choices:

1. Use some other list manager. I'm not keen on this. I very much like
Mailman and so does everyone else with any influence in the technical
area. Since we've struggled under the weight of an ancient version of
EZMLM for 8 years, I'm *very* keen to move to Mailman ... and I'm not the
only one. I expect a revolt if I even dare to suggest this.

2. Just install the Ubuntu package (2.1.9) as is and hope for the best.
NOt a good idea. Since I will be supporting at least 7 domains and
probably 40+ mailing lists, the chances of a name collision is pretty
high. And I don't want to get the various list admins to put a prefix or
suffix on their list names because people are bound to forget ... besides,
there's also the domain-specific admin password that I also want.

3. Multiple installs. I'd rather not do this if I can help it. Not only
do I have to make sure that all of them play nice with the mail system
(postfix), but I can see the day when we'll want to upgrade, and that's
going to mean upgrading something like 7 installations. ergh.

4. Use one of these patches. This is my prefered route. I can see I'm
going to have to install from sources most likely unless there's a patched
deb out there somewhere that's fairly current. But as long as the patch
does what is eventually going to be merged into the mainline code so that
our lists won't break when we can finally upgrade to it, I should be OK to
run it.

I thank you in advance for any advice anyone can give. I've got a lot of
people waiting for this installation, but I've said that I'm not going to
rush it. Still, I don't think I can stall too long either.

Cheers,
Geoff.

Search Discussions

  • Geoff Shang at Oct 4, 2009 at 4:05 pm
    Hello,

    Apologies for jumping onto the list and posting right away, I realise it's bad
    netiquette.

    I admin two servers for a large non-profit organisation. On Thursday, one of
    them died. At the time we were using a different mailing list manager, but had
    plans to gently migrate the dozens of lists to Mailman. Now what was going to
    be an orderly migration is now a frantic scramble, as mailing lists are the
    lifeblood of the workings of the organisation.

    But I've run into a problem. I'd assumed that Mailman could support virtual
    domains without list-name collisions, as I'd seen it done in a few places. But
    according to the FAQ and everything else I've read this evening, it's not the
    case.

    This is about all I know though. There seems to be much posted on the subject.
    It seems it'll be in version 3, and people have asked for it to be in version
    2.2. I've seen mentions of multiple patches and multiple versions ranging over
    the last 6 years or so. And the WIKI FAQ entry, which itself was updated 2
    years ago, points to a patch at http://nix.lauft.net/htdocs/mailman/ which is
    generating a "Connection Refused" error. So I'm a bit stuck and am not sure
    where to go next.

    I see I've only really got 4 choices:

    1. Use some other list manager. I'm not keen on this. I very much like
    Mailman and so does everyone else with any influence in the technical area.
    Since we've struggled under the weight of an ancient version of EZMLM for 8
    years, I'm *very* keen to move to Mailman ... and I'm not the only one. I
    expect a revolt if I even dare to suggest this.

    2. Just install the Ubuntu package (2.1.9) as is and hope for the best. NOt a
    good idea. Since I will be supporting at least 7 domains and probably 40+
    mailing lists, the chances of a name collision is pretty high. And I don't
    want to get the various list admins to put a prefix or suffix on their list
    names because people are bound to forget ... besides, there's also the
    domain-specific admin password that I also want.

    3. Multiple installs. I'd rather not do this if I can help it. Not only do I
    have to make sure that all of them play nice with the mail system (postfix),
    but I can see the day when we'll want to upgrade, and that's going to mean
    upgrading something like 7 installations. ergh.

    4. Use one of these patches. This is my prefered route. I can see I'm going
    to have to install from sources most likely unless there's a patched deb out
    there somewhere that's fairly current. But as long as the patch does what is
    eventually going to be merged into the mainline code so that our lists won't
    break when we can finally upgrade to it, I should be OK to run it.

    I thank you in advance for any advice anyone can give. I've got a lot of
    people waiting for this installation, but I've said that I'm not going to rush
    it. Still, I don't think I can stall too long either.

    Cheers,
    Geoff.
  • Mark Sapiro at Oct 5, 2009 at 4:40 pm

    Geoff Shang wrote:
    This is about all I know though. There seems to be much posted on the
    subject. It seems it'll be in version 3, and people have asked for it to
    be in version 2.2. I've seen mentions of multiple patches and multiple
    versions ranging over the last 6 years or so. And the WIKI FAQ entry,
    which itself was updated 2 years ago, points to a patch at
    http://nix.lauft.net/htdocs/mailman/ which is generating a "Connection
    Refused" error. So I'm a bit stuck and am not sure where to go next.

    You seem to have done your homework well, and to have a good
    understanding of the issues.

    I found http://ndim.fedorapeople.org/stuff/mailman-vhost/ which appears
    to contain the same patches that were at
    http://nix.lauft.net/htdocs/mailman/.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Geoff Shang at Oct 5, 2009 at 6:06 pm

    On Mon, 5 Oct 2009, Mark Sapiro wrote:

    You seem to have done your homework well, and to have a good
    understanding of the issues.
    You can learn a lot in 5 hours of reading. :)
    I found http://ndim.fedorapeople.org/stuff/mailman-vhost/ which appears
    to contain the same patches that were at
    http://nix.lauft.net/htdocs/mailman/.
    Thanks for this.

    This stuff looks a bit old. It's patches against Mailman 2.1.7 and files
    seem to date back to 2006. The docs talk about what's going to happen in
    2008.

    Does this code patch against 2.1.12? Is there newer code than this or
    should I get it from git? And is there any more documentation than the
    ReadMe files on this site?

    I thought I saw a branch up in the Launchpad project that deals with this.
    Is that a better place to start than these patches? Are these patches
    still the recommended way to achieve what I'm looking for?

    My concerns right now are:

    1. I need to implement this on a production system, so it has to implement
    the ability to have the same list names on multiple domains and
    domain-specific site passwords. And it needs to be stable (i.e. it needs
    to work as advertised).

    2. I need to deploy this pretty quickly so I need some documentation or
    at least people willing to help if I get stuck.

    and
    3. I need to know if the changes proposed here (or anywhere) will be
    compatible with what will eventually be adopted in mainline, or at least
    that there will be some kind of migration path. I can't really afford to
    send us down a dead-end path.

    I'm sorry about all the questions but I'm a bit under the pump here, but
    I also want to do it right the first time. Any advice anyone can give
    will be most gratefully received.

    Geoff.
  • Mark Sapiro at Oct 5, 2009 at 8:32 pm
    Geoff Shang wrote
    This stuff looks a bit old. It's patches against Mailman 2.1.7 and files
    seem to date back to 2006. The docs talk about what's going to happen in
    2008.

    Does this code patch against 2.1.12? Is there newer code than this or
    should I get it from git? And is there any more documentation than the
    ReadMe files on this site?

    I just applied the mailman-2.1.7-20060114-to-vhost.patch to the 2.1.12
    base and it applied with only two rejects, both of which are easy to
    fix. Whether the patched code will actually work and meet your
    requirements, I can't say.

    I thought I saw a branch up in the Launchpad project that deals with this.
    Is that a better place to start than these patches?

    Maybe, but I don't see one at
    <https://code.launchpad.net/mailman?field.lifecycle=ALL>.

    Are these patches
    still the recommended way to achieve what I'm looking for?

    I don't recommend any of these patches. Multiple Mailman instances is
    the recommended way for Mailman 2.1

    My concerns right now are:

    1. I need to implement this on a production system, so it has to implement
    the ability to have the same list names on multiple domains and
    domain-specific site passwords. And it needs to be stable (i.e. it needs
    to work as advertised).

    I don't see that these patches implement a domain specific site
    password.

    2. I need to deploy this pretty quickly so I need some documentation or
    at least people willing to help if I get stuck.

    I'm not aware of any documentation for this patch beyond what's in the
    README files.

    and
    3. I need to know if the changes proposed here (or anywhere) will be
    compatible with what will eventually be adopted in mainline, or at least
    that there will be some kind of migration path. I can't really afford to
    send us down a dead-end path.

    My recommendation would be to create separate Mailman instances per
    domain. I know you said originally
    3. Multiple installs. I'd rather not do this if I can help it. Not
    only do I have to make sure that all of them play nice with the mail
    system (postfix), but I can see the day when we'll want to upgrade, and
    that's going to mean upgrading something like 7 installations. ergh.

    This may be a pain if you use a package that isn't designed for it, but
    if you install from source and you have Mailman generating aliases and
    virtual maps for Postfix, all this means is you need to add 7 entries
    to alias_maps and virtual_alias_maps instead of just one.

    And as long as you keep track of your configure commands, upgrading a
    source install is very easy and straightforward. Upgrading 7 unpatched
    installations is probably easier than upgrading 1 patched one.

    We know this works, and there will be a migration path to MM 3.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Geoff Shang at Oct 5, 2009 at 9:32 pm

    On Mon, 5 Oct 2009, Mark Sapiro wrote:

    I just applied the mailman-2.1.7-20060114-to-vhost.patch to the 2.1.12
    base and it applied with only two rejects, both of which are easy to
    fix. Whether the patched code will actually work and meet your
    requirements, I can't say.
    I probably can't afford the luxury of testing it, at least not now.
    I thought I saw a branch up in the Launchpad project that deals with this.
    Is that a better place to start than these patches?
    Maybe, but I don't see one at
    <https://code.launchpad.net/mailman?field.lifecycle=ALL>.
    Well it was something like 3 in the morning when I was looking. Let me
    see...

    Ok, scrub that. Was something else.
    Are these patches
    still the recommended way to achieve what I'm looking for?

    I don't recommend any of these patches. Multiple Mailman instances is
    the recommended way for Mailman 2.1
    ah. This is what I need to hear.
    My concerns right now are:

    1. I need to implement this on a production system, so it has to implement
    the ability to have the same list names on multiple domains and
    domain-specific site passwords. And it needs to be stable (i.e. it needs
    to work as advertised).

    I don't see that these patches implement a domain specific site
    password.
    hmmm...I see it's listed as an outstanding issue.
    My recommendation would be to create separate Mailman instances per
    domain. I know you said originally
    3. Multiple installs. I'd rather not do this if I can help it. Not
    only do I have to make sure that all of them play nice with the mail
    system (postfix), but I can see the day when we'll want to upgrade, and
    that's going to mean upgrading something like 7 installations. ergh.

    This may be a pain if you use a package that isn't designed for it, but
    I wouldn't do this with a package, I can't see how I could get it to
    install into different places without a *lot* of gymnastics like chroots.
    if you install from source and you have Mailman generating aliases and
    virtual maps for Postfix, all this means is you need to add 7 entries
    to alias_maps and virtual_alias_maps instead of just one.
    Ok...This is tarting to sound doable. It also means I can get the most
    important domains up quickly. Is there any documentation for doing this?
    I need to have 7 lots of everything, right?
    And as long as you keep track of your configure commands, upgrading a
    source install is very easy and straightforward. Upgrading 7 unpatched
    installations is probably easier than upgrading 1 patched one.
    Yeah I guess it would be.
    We know this works, and there will be a migration path to MM 3.
    That was my other concern about this approach - how to integrate into a
    unified install once it is officially supported. But if you will be
    providing an upgrade path from multiple installs then this makes me more
    comfortable with the idea.

    Geoff.
  • Mark Sapiro at Oct 5, 2009 at 9:55 pm

    Geoff Shang wrote:
    Ok...This is tarting to sound doable. It also means I can get the most
    important domains up quickly. Is there any documentation for doing this?
    I need to have 7 lots of everything, right?

    The post at
    <http://mail.python.org/pipermail/mailman-users/2004-June/037443.html>
    (linked from the FAQ at
    <http://wiki.list.org/pages/viewpage.action?pageId@30604>) has good
    information. I don't thing there's anything better collected in one
    place.

    You do need to have 7 complete installations of Mailman, but only one
    Postfix and one web server.

    You can start with just one or two instances, but give some thought to
    how you will name things before you start.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Geoff Shang at Oct 7, 2009 at 7:04 pm
    Hi Mark,

    re multiple installs,
    On Mon, 5 Oct 2009, Mark Sapiro wrote:

    The post at
    <http://mail.python.org/pipermail/mailman-users/2004-June/037443.html>
    (linked from the FAQ at
    <http://wiki.list.org/pages/viewpage.action?pageId@30604>) has good
    information. I don't thing there's anything better collected in one
    place.
    I'm now working through this and have hit a bit of a problem. The post in
    question reads as follows:
    Where thing may get more complicated is setting up your local MTA to
    support virtual hosts. For instance, aliases generated by the per-host
    copies of $per-host-prefix/bin/newlist will generate alias definitions
    that pipe to the correct per-host instance of the Mailman delivery
    agent script but getting your MTA to recognise the aliases belong to
    one host rather than another is not something I am familiar with.
    This would appear to be the sticking point. The aliases file doesn't
    generate fully-qualified Email addresses, only local parts. How do I
    ensure that a message to announce at foo.com doesn't go to announce at bar.org?
    This must be doable, because if it's not, then this defeats the whole
    point of doing this in the first place.

    Presumably I need to do this in postfix/main.cf somehow but I'm at a loss
    as to how to do this.

    Geoff.
  • Ashley M. Kirchner at Oct 7, 2009 at 7:42 pm

    Geoff Shang wrote:
    This would appear to be the sticking point. The aliases file doesn't
    generate fully-qualified Email addresses, only local parts. How do I
    ensure that a message to announce at foo.com doesn't go to
    announce at bar.org? This must be doable, because if it's not, then this
    defeats the whole point of doing this in the first place.

    Presumably I need to do this in postfix/main.cf somehow but I'm at a
    loss as to how to do this.
    Not sure if this will help you or not, but I'll share anywhere ...

    I have a multi setup for mailman to host multiple domains. All my
    list domains are configured as 'lists.$domain', for example
    'lists.yeehaw.net'. My mailman installations all go under
    /home/mailman/lists.$domain

    I don't know how this is done in postfix, but in sendmail I have the
    following:

    =====> /etc/mail/aliases/$domain-aliases
    mailman-lists.$domain \
    "|/home/mailman/lists.$domain/mail/$domain-mailman post mailman"
    mailman-admin-lists.$domain: \
    "|/home/mailman/lists.$domain/mail/$domain-mailman admin mailman"
    mailman-bounces-lists.$domain: \
    "|/home/mailman/lists.$domain/mail/$domain-mailman bounces mailman"
    mailman-confirm-lists.$domain: \
    "|/home/mailman/lists.$domain/mail/$domain-mailman confirm mailman"

    =====> /etc/mail/virtusertable
    mailman at lists.$domain mailman-lists.$domain
    mailman-admin at lists.$domain mailman-admin-lists.$domain
    mailman-bounces at lists.$domain mailman-bounces-lists.$domain
    mailman-confirm at lists.$domain mailman-confirm-lists.$domain

    This ensures that an incoming e-mail to say for example
    'mailman-admin at lists.$domain' gets rerouted to
    'mailman-admin-lists.$domain' which the alias then expands in to
    '"|/home/mailman/lists.$domain/mail/$domain-mailman admin mailman"'

    This allows one to have various mailman@'various domains' going to
    the same server through the same MTA without it going nutso.

    Now you may be wondering why I renamed the 'mailman' binary to
    '$domain-mailman'. That's because of permissions within sendmail. Any
    binary that is going to be sending stuff out needs to be allowed by
    sendmail, and since I have multiple installations of mailman, in
    different paths, you can't just tell sendmail it's called 'mailman'. It
    will get utterly confused when the various lists are trying to send
    something out. So, by renaming each one to their respective $domain, it
    keeps sendmail from going bonkers.

    In my /usr/adm/sm.bin/ I have various symlinks to $domain-mailman
    which link back to /home/mailman/lists-$domain/mail/$domain-mailman

    Cheers

    --
    W | It's not a bug - it's an undocumented feature.
    +--------------------------------------------------------------------
    Ashley M. Kirchner <mailto:ashley at pcraft.com> . 303.442.6410 x130
    IT Director / SysAdmin / Websmith . 800.441.3873 x130
    Photo Craft Imaging . 2901 55th Street
    http://www.pcraft.com ..... . . . Boulder, CO 80301, U.S.A.
  • Geoff Shang at Oct 7, 2009 at 9:05 pm

    On Wed, 7 Oct 2009, Ashley M. Kirchner wrote:

    Geoff Shang wrote:
    This would appear to be the sticking point. The aliases file doesn't
    generate fully-qualified Email addresses, only local parts. How do I
    ensure that a message to announce at foo.com doesn't go to announce at bar.org?
    [snip]
    I have a multi setup for mailman to host multiple domains. All my list
    domains are configured as 'lists.$domain', for example 'lists.yeehaw.net'.
    My mailman installations all go under /home/mailman/lists.$domain

    I don't know how this is done in postfix, but in sendmail I have the
    following:

    =====> /etc/mail/aliases/$domain-aliases
    mailman-lists.$domain \
    "|/home/mailman/lists.$domain/mail/$domain-mailman post mailman"
    mailman-admin-lists.$domain: \
    "|/home/mailman/lists.$domain/mail/$domain-mailman admin mailman"
    Ok but how do you get Mailman to produce alias tables that look like that?
    Or don't you? Mine only have the list address part, not the fully
    qualified list address.

    Geoff.
  • Mark Sapiro at Oct 8, 2009 at 12:32 am

    Geoff Shang wrote:
    On Wed, 7 Oct 2009, Ashley M. Kirchner wrote:

    I have a multi setup for mailman to host multiple domains. All my list
    domains are configured as 'lists.$domain', for example 'lists.yeehaw.net'.
    My mailman installations all go under /home/mailman/lists.$domain

    I don't know how this is done in postfix, but in sendmail I have the
    following:

    =====> /etc/mail/aliases/$domain-aliases
    mailman-lists.$domain \
    "|/home/mailman/lists.$domain/mail/$domain-mailman post mailman"
    mailman-admin-lists.$domain: \
    "|/home/mailman/lists.$domain/mail/$domain-mailman admin mailman"
    Ok but how do you get Mailman to produce alias tables that look like that?
    Or don't you? Mine only have the list address part, not the fully
    qualified list address.

    For Postfix integration, you need to do a few things.

    Consider only the one mailman instance for the domain example.com. The
    others will be analagous.

    in mm_cfg.py, add

    POSTFIX_STYLE_VIRTUAL_DOMAINS = ['example.com']

    This will cause mailman to also write data/virtual-mailman with entries
    like

    list at example.com list
    list-admin at example.com list-admin
    ...

    in addition to data/aliases with entries like

    list: "|path/to/wrapper post list"
    list-admin: "|path/to/wrapper admin list"
    ...

    for each list. The data/virtual-mailman(.db) is analagous to Ashley's
    /etc/mail/virtusertable.

    There is still a problem in that there is a potential list name
    conflict, so to resolve that, you need to make a patch (see attached
    Postfix.patch.txt) to Mailman/MTA/Postfix to make virtual-mailman and
    aliases look like

    list at example.com list.example.com
    list-admin at example.com list-admin.example.com
    ...

    and

    list.example.com: "|path/to/wrapper post list"
    list-admin.example.com: "|path/to/wrapper admin list"
    ...


    Then you need the following in Postfix's main.cf

    alias_maps = ...
    hash:/path/to/example.com's/data/aliases


    virtual_alias_domains ... example.com

    virtual_alias_maps = ...
    hash:/path/to/example.com's/data/virtual-mailman

    And probably also if you don't have them anyway

    recipient_delimiter = +
    unknown_local_recipient_reject_code = 550

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan

    -------------- next part --------------
    An embedded and charset-unspecified text was scrubbed...
    Name: Postfix.patch.txt
    URL: <http://mail.python.org/pipermail/mailman-users/attachments/20091007/a36408f0/attachment.txt>
  • Geoff Shang at Oct 8, 2009 at 12:42 am

    On Wed, 7 Oct 2009, Mark Sapiro wrote:

    Geoff Shang wrote:
    On Wed, 7 Oct 2009, Ashley M. Kirchner wrote:

    =====> /etc/mail/aliases/$domain-aliases
    mailman-lists.$domain \
    "|/home/mailman/lists.$domain/mail/$domain-mailman post mailman"
    mailman-admin-lists.$domain: \
    "|/home/mailman/lists.$domain/mail/$domain-mailman admin mailman"
    Ok but how do you get Mailman to produce alias tables that look like that?
    Or don't you? Mine only have the list address part, not the fully
    qualified list address.
    {snip}
    There is still a problem in that there is a potential list name
    conflict, so to resolve that, you need to make a patch (see attached
    ah...

    I will review your patch, and I used list-domain.tld instead of
    list.domain.tld, but I basically came to the same conclusion and just
    implemented same. I got the idea from
    http://mail.python.org/pipermail/mailman-users/2008-September/063254.html

    This really needs to be documented somewhere.

    does using a dash vs a dot as a separater make any difference re eventual
    upgrade path? I'm still testing at this point but I'll be making a lot of
    lists soon, so now's the time to change anything.

    Thanks again,
    Geoff.
  • Mark Sapiro at Oct 8, 2009 at 12:59 am

    Geoff Shang wrote:
    On Wed, 7 Oct 2009, Mark Sapiro wrote:

    There is still a problem in that there is a potential list name
    conflict, so to resolve that, you need to make a patch (see attached
    ah...

    I will review your patch, and I used list-domain.tld instead of
    list.domain.tld, but I basically came to the same conclusion and just
    implemented same. I got the idea from
    http://mail.python.org/pipermail/mailman-users/2008-September/063254.html

    This really needs to be documented somewhere.

    Yes. I'll see about a FAQ. Maybe you could help when you get it all
    worked through.

    does using a dash vs a dot as a separater make any difference re eventual
    upgrade path? I'm still testing at this point but I'll be making a lot of
    lists soon, so now's the time to change anything.

    I don't think so. I actually was going to use an underscore, but I went
    with the dot because Ashley was using a dot.

    Changing after the fact is not hard. You'd only need to change
    Mailman/MTA/Postfix.py and run bin/genaliases for each domain.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Terri Oda at Oct 8, 2009 at 4:30 pm

    Geoff Shang wrote:
    I will review your patch, and I used list-domain.tld instead of
    list.domain.tld, but I basically came to the same conclusion and just
    implemented same. I got the idea from
    http://mail.python.org/pipermail/mailman-users/2008-September/063254.html

    This really needs to be documented somewhere.
    And by "somewhere" I recommend you put it into the Mailman Wiki,
    probably just add it to the FAQs:

    http://wiki.list.org/display/DOC/Frequently+Asked+Questions

    I'm guessing it should be in site admin tasks:

    http://wiki.list.org/display/DOC/4+Site+administrator+tasks

    So here's a link to a page where you can cut and paste the info that you
    think should be recorded:

    http://wiki.list.org/pages/createpage.action?spaceKey=DOC&fromPageId@30488


    So if you've got a minute to summarize the stuff and put it there, that
    would be awesome. Thanks! :)

    Terri
  • Geoff Shang at Oct 8, 2009 at 5:15 pm

    On Thu, 8 Oct 2009, Terri Oda wrote:

    Geoff Shang wrote:
    I will review your patch, and I used list-domain.tld instead of
    This really needs to be documented somewhere.
    And by "somewhere" I recommend you put it into the Mailman Wiki, probably
    just add it to the FAQs:
    I'll do this. I probably won't get a chance for a few days as we're still
    madly setting up stuff over here but I will definitely write up something.

    Geoff.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedOct 4, '09 at 1:29a
activeOct 8, '09 at 5:15p
posts15
users4
websitelist.org

People

Translate

site design / logo © 2022 Grokbase