FAQ
Hello, All.

I've just set up my first Mailman mailing list in OS X Server. It sends mail
as welcome notifications were received by several different members
subscribed to the mailing list. However, it doesn't seem to be receiving
e-mail. All attempts I've made have resulted in Delivery Failure
Notifications.

This is the text returned with this Delivery Failure Notifications:
Delivery to the following recipient failed permanently:

list at 3domain.com

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient
domain. We recommend contacting the other email provider for further
information about the cause of this error. The error that the other server
returned was: 550 550 5.1.1 <list at domain.com>: Recipient address rejected:
User unknown in virtual alias table (state 14).
What could be the cause ?

In order for a Mailman list to work properly do I need to create an account
for it in Workgroup Manager with its e-mail address ?

Sorry if this is a simple question but I am not an IT specialist and don't
have any experience with Mailman.

Thank you in advance,

Joe

Search Discussions

  • Mark Sapiro at Dec 5, 2010 at 4:36 pm

    JRC Groups wrote:
    This is the text returned with this Delivery Failure Notifications:
    Delivery to the following recipient failed permanently:

    list at 3domain.com

    Technical details of permanent failure:
    Google tried to deliver your message, but it was rejected by the recipient
    domain. We recommend contacting the other email provider for further
    information about the cause of this error. The error that the other server
    returned was: 550 550 5.1.1 <list at domain.com>: Recipient address rejected:
    User unknown in virtual alias table (state 14).
    What could be the cause ?

    If your MTA is Postfix, you don't have entries for list at domain.com and
    the list-* administrative addresses in a virtual_alias_maps file.

    If it's some other MTA you have the equivalent issue.

    In order for a Mailman list to work properly do I need to create an account
    for it in Workgroup Manager with its e-mail address ?

    No.


    If you are using Apple's package, this is really a question for Apple,
    but we can try to help. If the MTA is Postfix, post the output from
    "sudo postconf -n". Also include a listing of the contents of
    Mailman's mm_cfg.py.

    Did you create the list with Mailman's bin/newlist, Mailman's web
    interface or Apple's GUI?

    See <http://www.list.org/mailman-install/node12.html> and its
    subsections 6.1.1 and 6.1.2. Also see the FAQ at
    <http://wiki.list.org/x/QoA9>.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • JRC Groups at Dec 6, 2010 at 6:22 am

    On 12/5/10 8:36 AM, "Mark Sapiro" wrote:

    JRC Groups wrote:
    This is the text returned with this Delivery Failure Notifications:
    Delivery to the following recipient failed permanently:

    list at 3domain.com

    Technical details of permanent failure:
    Google tried to deliver your message, but it was rejected by the recipient
    domain. We recommend contacting the other email provider for further
    information about the cause of this error. The error that the other server
    returned was: 550 550 5.1.1 <list at domain.com>: Recipient address rejected:
    User unknown in virtual alias table (state 14).
    What could be the cause ?

    If your MTA is Postfix, you don't have entries for list at domain.com and
    the list-* administrative addresses in a virtual_alias_maps file.

    If it's some other MTA you have the equivalent issue.

    In order for a Mailman list to work properly do I need to create an account
    for it in Workgroup Manager with its e-mail address ?

    No.

    If you are using Apple's package, this is really a question for Apple,
    but we can try to help. If the MTA is Postfix, post the output from
    "sudo postconf -n". Also include a listing of the contents of
    Mailman's mm_cfg.py.
    I am posting the output from "sudo postconf -n" in a following post to keep
    it separate from my answers here for clarity's sake. I tried to find the
    mm_cfg.py file but couldn't locate it. A spotlight search in OS X returned
    no entries under this name. Even a spotlight search under mailman returned
    no entries. Where would this file be located ?
    Did you create the list with Mailman's bin/newlist, Mailman's web
    interface or Apple's GUI?
    I created the list using Apple's GUI and then used Mailman's web interface
    to configure and change some settings according to the needs of the list I
    created.
    See <http://www.list.org/mailman-install/node12.html> and its
    subsections 6.1.1 and 6.1.2. Also see the FAQ at
    <http://wiki.list.org/x/QoA9>.
    Thank you,


    Joe
  • Mark Sapiro at Dec 6, 2010 at 5:18 pm

    On 12/5/2010 10:22 PM, JRC Groups wrote:
    I am posting the output from "sudo postconf -n" in a following post to keep
    it separate from my answers here for clarity's sake. I tried to find the
    mm_cfg.py file but couldn't locate it. A spotlight search in OS X returned
    no entries under this name. Even a spotlight search under mailman returned
    no entries. Where would this file be located ?

    According to the FAQ at <http://wiki.list.org/x/QoA9>, it should be
    /usr/share/mailman/Mailman/mm_cfg.py. If it's not there, I don't know
    where it might be.

    Did you create the list with Mailman's bin/newlist, Mailman's web
    interface or Apple's GUI?
    I created the list using Apple's GUI and then used Mailman's web interface
    to configure and change some settings according to the needs of the list I
    created.

    I don't know how Apple's GUI creates lists, but if it created entries
    for the list in /var/mailman/data/aliases it should also create virtual
    mappings in /var/mailman/data/virtual-mailman and that file should be
    referenced in Postfix main.cf virtual_alias_maps, e.g.

    virtual_alias_maps = hash:/etc/postfix/virtual_users,
    hash:/var/mailman/data/virtual-mailman

    If virtual-mailman is not created, there is something missing from
    mm_cfg.py. There should be

    POSTFIX_STYLE_VIRTUAL_DOMAINS = ['domain.com']

    in mm_cfg.py.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • JRC Groups at Dec 8, 2010 at 2:40 am
    Mark,


    Thank you for your help and for taking the time to answer my questions.

    Some questions and answers below next to your responses.

    On 12/6/10 9:18 AM, "Mark Sapiro" wrote:
    On 12/5/2010 10:22 PM, JRC Groups wrote:

    I am posting the output from "sudo postconf -n" in a following post to keep
    it separate from my answers here for clarity's sake. I tried to find the
    mm_cfg.py file but couldn't locate it. A spotlight search in OS X returned
    no entries under this name. Even a spotlight search under mailman returned
    no entries. Where would this file be located ?

    According to the FAQ at <http://wiki.list.org/x/QoA9>, it should be
    /usr/share/mailman/Mailman/mm_cfg.py. If it's not there, I don't know
    where it might be.
    I found it. The following are the contents of the
    /usr/share/mailman/Mailman/mm_cfg.py file I was able to display using the
    cat command:



    # -*- python -*-

    # Copyright (C) 1998,1999,2000,2001,2002 by the Free Software Foundation,
    Inc.
    #
    # This program is free software; you can redistribute it and/or
    # modify it under the terms of the GNU General Public License
    # as published by the Free Software Foundation; either version 2
    # of the License, or (at your option) any later version.
    #
    # This program is distributed in the hope that it will be useful,
    # but WITHOUT ANY WARRANTY; without even the implied warranty of
    # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
    # GNU General Public License for more details.
    #
    # You should have received a copy of the GNU General Public License
    # along with this program; if not, write to the Free Software
    # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
    USA.

    """This module contains your site-specific settings.
    From a brand new distribution it should be copied to mm_cfg.py. If you
    already have an mm_cfg.py, be careful to add in only the new settings you
    want. Mailman's installation procedure will never overwrite your mm_cfg.py
    file.

    The complete set of distributed defaults, with documentation, are in the
    file
    Defaults.py. In mm_cfg.py, override only those you want to change, after
    the

    from Defaults import *

    line (see below).

    Note that these are just default settings; many can be overridden via the
    administrator and user interfaces on a per-list or per-user basis.

    """

    ###############################################
    # Here's where we get the distributed defaults.

    from Defaults import *

    ##################################################
    # Put YOUR site-specific settings below this line.
    MTA = 'Postfix'
    DEFAULT_EMAIL_HOST = 'dentserv.main.private'
    DEFAULT_URL_HOST = 'dentserv.main.private'

    Did you create the list with Mailman's bin/newlist, Mailman's web
    interface or Apple's GUI?
    I created the list using Apple's GUI and then used Mailman's web interface
    to configure and change some settings according to the needs of the list I
    created.

    I don't know how Apple's GUI creates lists, but if it created entries
    for the list in /var/mailman/data/aliases it should also create virtual
    mappings in /var/mailman/data/virtual-mailman and that file should be
    referenced in Postfix main.cf virtual_alias_maps, e.g.

    virtual_alias_maps = hash:/etc/postfix/virtual_users,
    hash:/var/mailman/data/virtual-mailman

    If virtual-mailman is not created, there is something missing from
    mm_cfg.py. There should be

    POSTFIX_STYLE_VIRTUAL_DOMAINS = ['domain.com']

    in mm_cfg.py.
    I've tried Apple but it has become quite clear that they are neither
    properly equipped nor interested in resolving the problems with Mailman (or
    with OS X Server for that matter).

    Can you guide me on how to correct these problems ?

    Thank you in advance for your help,

    Joe
  • Mark Sapiro at Dec 8, 2010 at 4:13 pm

    JRC Groups wrote:
    ###############################################
    # Here's where we get the distributed defaults.

    from Defaults import *

    ##################################################
    # Put YOUR site-specific settings below this line.
    MTA = 'Postfix'
    DEFAULT_EMAIL_HOST = 'dentserv.main.private'
    DEFAULT_URL_HOST = 'dentserv.main.private'

    Assuming that all your Mailman lists are/will be in the domain.com
    domain and that mail will be sent to addresses like LIST at domain.com
    and web access to mailman will be via URLs beginning
    'http://www.domain.com/' (if this will be 'http://domain.com/', drop
    the 'www.' below), change the above two lines to

    DEFAULT_EMAIL_HOST = 'domain.com'
    DEFAULT_URL_HOST = 'www.domain.com'

    and add

    VIRTUAL_HOSTS.clear()
    add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)


    The original error and your postconf -n post indicate that domain.com
    is not local in Postfix. Thus you also need to add here

    POSTFIX_STYLE_VIRTUAL_DOMAINS = ['domain.com']

    After editing mm_cfg.py as above, run

    sudo /usr/share/mailman/bin/withlist -l -a -r fix_url

    followed by

    sudo /usr/share/mailman/bin/genaliases

    This should fix the mailman side of things, but I'm a bit confused.

    I think this will create/update the files aliases. aliases.db,
    virtual-mailman and virtual-mailman.db in the directory
    /usr/share/mailman/data/.

    My confusion is that your postconf -n had

    alias_maps = hash:/etc/aliases,hash:/var/mailman/data/aliases

    which says Mailman's aliases are in /var/mailman/data. This could be
    incorrect, or /var/mailman/data/ or /var/mailman/data/aliases* could
    be symlinks or Mailman might be configured with var-prefix =
    /var/mailman which would put the aliases* and virtual-mailman* files
    in /var/mailman/data/.

    I will assume the latter which means you should add
    hash:/var/mailman/data/virtual-mailman to virtual_alias_maps in
    Postfix main.cf to make it

    virtual_alias_maps = hash:/etc/postfix/virtual_users,
    hash:/var/mailman/data/virtual-mailman

    and then reload the Postfix service.

    In any case, the hash:/var/mailman/data/aliases in alias_maps and
    hash:/var/mailman/data/virtual-mailman in virtual_alias_maps should
    point to the files updated by Mailman's genaliases above.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • JRC Groups at Dec 8, 2010 at 8:01 pm
    Mark,

    I am extremely grateful that you took the time to help me with this issue.
    In order for me to make the changes you recommended please allow me to ask
    some truly basic questions since I have no experience with Unix or editing
    system files.

    Is there a simpler way than Terminal (command line) to edit these files and
    then resave them ? Something along the lines of a text editor. Or do I need
    to use Terminal to do it ?

    In this case, if Terminal is necessary, can you guide on how to take a step
    by step approach to getting it done ? I have never edited a file (specially
    a system file) in Terminal before and don't know how to go about it.

    On 12/8/10 8:13 AM, "Mark Sapiro" wrote:

    JRC Groups wrote:
    ###############################################
    # Here's where we get the distributed defaults.

    from Defaults import *

    ##################################################
    # Put YOUR site-specific settings below this line.
    MTA = 'Postfix'
    DEFAULT_EMAIL_HOST = 'dentserv.main.private'
    DEFAULT_URL_HOST = 'dentserv.main.private'

    Assuming that all your Mailman lists are/will be in the domain.com
    domain and that mail will be sent to addresses like LIST at domain.com
    and web access to mailman will be via URLs beginning
    'http://www.domain.com/' (if this will be 'http://domain.com/', drop
    the 'www.' below), change the above two lines to
    Yes. The lists will all be associated with one single domain. I have the
    server set up for virtual hosting and the domain used for the lists is one
    of the virtual domains (not the primary domain). All lists will be set up
    under one single domain. At the moment I have only one list set up. I am
    trying to have it working right before I attempt to create other lists.
    DEFAULT_EMAIL_HOST = 'domain.com'
    DEFAULT_URL_HOST = 'www.domain.com'

    and add

    VIRTUAL_HOSTS.clear()
    add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
    Where exactly do I add it ? Right below the two lines above ?
    The original error and your postconf -n post indicate that domain.com
    is not local in Postfix. Thus you also need to add here

    POSTFIX_STYLE_VIRTUAL_DOMAINS = ['domain.com']
    Where exactly do I add this line ? Is the location of the line in the file
    important or relevant ?
    After editing mm_cfg.py as above, run

    sudo /usr/share/mailman/bin/withlist -l -a -r fix_url

    followed by

    sudo /usr/share/mailman/bin/genaliases

    This should fix the mailman side of things, but I'm a bit confused.

    I think this will create/update the files aliases. aliases.db,
    virtual-mailman and virtual-mailman.db in the directory
    /usr/share/mailman/data/.

    My confusion is that your postconf -n had

    alias_maps = hash:/etc/aliases,hash:/var/mailman/data/aliases

    which says Mailman's aliases are in /var/mailman/data. This could be
    incorrect, or /var/mailman/data/ or /var/mailman/data/aliases* could
    be symlinks or Mailman might be configured with var-prefix =
    /var/mailman which would put the aliases* and virtual-mailman* files
    in /var/mailman/data/.

    I will assume the latter which means you should add
    hash:/var/mailman/data/virtual-mailman to virtual_alias_maps in
    Postfix main.cf to make it

    virtual_alias_maps = hash:/etc/postfix/virtual_users,
    hash:/var/mailman/data/virtual-mailman
    How do add it ?
    and then reload the Postfix service.
    In OS X's Server Admin there is an option under the Mail tab that allows
    Mail services to be stopped and then restarted again. Will this reload
    Postfix as you recommend ?
    In any case, the hash:/var/mailman/data/aliases in alias_maps and
    hash:/var/mailman/data/virtual-mailman in virtual_alias_maps should
    point to the files updated by Mailman's genaliases above.
    How do I verify if it is doing it ?

    Thank you again for your help.


    Joe
  • Mark Sapiro at Dec 8, 2010 at 11:51 pm

    JRC Groups wrote:
    I am extremely grateful that you took the time to help me with this issue.
    In order for me to make the changes you recommended please allow me to ask
    some truly basic questions since I have no experience with Unix or editing
    system files.

    Is there a simpler way than Terminal (command line) to edit these files and
    then resave them ? Something along the lines of a text editor. Or do I need
    to use Terminal to do it ?

    You can edit the files with the TextEdit application, but there may be
    serious issues with permissions or even navigating to the files in
    Finder or the TextEdit open dialog.


    I suggest you do the following:

    To change the postfix main.cf file, use the postconf command's -e
    option as in
    sudo postconf -e "virtual_alias_maps = hash:/etc/postfix/virtual_users, hash:/var/mailman/data/virtual-mailman"
    (above command is all on one line) See "man postconf" for details.

    To edit mm_cfg.py, in terminal you can do
    sudo /Applications/TextEdit.app/Comtents/MacOS/TextEdit /usr/share/mailman/Mailman/mm_cfg.py
    (above command is all on one line) This will open the file in TextEdit
    in a way that you can save your changes.

    There may be better ways to do this. For example, on my Mac I have a
    'root' user I can log on to. I would log on as this user and open
    terminal and then invoke the 'vi' editor on the files, but I can't
    explain how to use 'vi' as simply as I can explain the above.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • JRC Groups at Dec 9, 2010 at 12:45 am
    Mark,


    Again I can't thank you enough for all your help.

    I've done some research and received some advice from others on how to
    accomplish this with BBEdit which I have found to be a superbly simple and
    efficient way to accomplish this. I download the free trial demo and used it
    to edit mm_cfg.py file following your recommendations. I also ran the two
    sudo commands as you suggested.

    This is the output from the Terminal window:
    Last login: Tue Dec 7 18:19:11 on ttys000
    dentserv:~ locadmin$ sudo /usr/share/mailman/bin/withlist -l -a -r fix_url
    Password:
    Importing fix_url...
    Running fix_url.fix_url()...
    Loading list implants (locked)
    Saving list
    Loading list mailman (locked)
    Saving list
    Finalizing
    dentserv:~ locadmin$ sudo /usr/share/mailman/bin/genaliases
    dentserv:~ locadmin$
    I am trying as I type this to continue with the second part of your
    recommendations. Where exactly do I find the Postfix main.cf file so that I
    can edit it also ?

    On a different note, why is the clock on top of the terminal window above
    displaying Dec 7 18:19:11 when it is now Dec 8, 4:41 pm here in California ?
    The clock on the menu bar of the server computer has the proper time but the
    Terminal window seems to be almost a day behind. Could this be a problem ?

    Thanks again,


    Joe


    On 12/8/10 3:51 PM, "Mark Sapiro" wrote:

    JRC Groups wrote:
    I am extremely grateful that you took the time to help me with this issue.
    In order for me to make the changes you recommended please allow me to ask
    some truly basic questions since I have no experience with Unix or editing
    system files.

    Is there a simpler way than Terminal (command line) to edit these files and
    then resave them ? Something along the lines of a text editor. Or do I need
    to use Terminal to do it ?

    You can edit the files with the TextEdit application, but there may be
    serious issues with permissions or even navigating to the files in
    Finder or the TextEdit open dialog.

    I suggest you do the following:

    To change the postfix main.cf file, use the postconf command's -e
    option as in
    sudo postconf -e "virtual_alias_maps = hash:/etc/postfix/virtual_users,
    hash:/var/mailman/data/virtual-mailman"
    (above command is all on one line) See "man postconf" for details.

    To edit mm_cfg.py, in terminal you can do
    sudo /Applications/TextEdit.app/Comtents/MacOS/TextEdit
    /usr/share/mailman/Mailman/mm_cfg.py
    (above command is all on one line) This will open the file in TextEdit
    in a way that you can save your changes.

    There may be better ways to do this. For example, on my Mac I have a
    'root' user I can log on to. I would log on as this user and open
    terminal and then invoke the 'vi' editor on the files, but I can't
    explain how to use 'vi' as simply as I can explain the above.
  • Chris Tandiono at Dec 9, 2010 at 12:48 am

    On Wed, 08 Dec 2010 16:45:16 -0800, JRC Groups wrote:

    On a different note, why is the clock on top of the terminal window above
    displaying Dec 7 18:19:11 when it is now Dec 8, 4:41 pm here in
    California ?
    The clock on the menu bar of the server computer has the proper time but
    the
    Terminal window seems to be almost a day behind. Could this be a problem
    ?
    That's the "last login" date, i.e., the last date you logged in, which
    evidently was about a day ago. If you open up Terminal again it'll have
    changed to some time today.

    Also, might I recommend iTerm instead of Terminal? I can never get end and
    home to work properly in Terminal; they scroll up and down instead (which
    is fine for most Mac OS X apps, but the point of the Terminal is to be
    UNIX-y). They work in iTerm.

    Chris
  • Mark Sapiro at Dec 9, 2010 at 1:16 am

    Chris Tandiono wrote:
    That's the "last login" date, i.e., the last date you logged in, which
    evidently was about a day ago.

    Correct.

    If you open up Terminal again it'll have
    changed to some time today.

    No. In order to change the "last login" time, you have to actually log
    off and back on again. Simply quitting and reopening terminal won't do
    it.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Mark Sapiro at Dec 9, 2010 at 1:44 am

    Mark Sapiro wrote:
    Chris Tandiono wrote:
    If you open up Terminal again it'll have
    changed to some time today.

    No. In order to change the "last login" time, you have to actually log
    off and back on again. Simply quitting and reopening terminal won't do
    it.

    Nevermind! Chris is correct. I'm not sure what I did wrong when I
    checked this, but quitting and reopening terminal is sufficient to
    update the displayed "last login" time.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • JRC Groups at Dec 9, 2010 at 12:58 am
    Mark,


    I located the Postfix's main.cf file in /private/etc/postfix/main.cf and
    made the change you recommended. I then stopped Main services and restarted
    it.

    What is the best way to test if the list is now working properly ?

    Also, I followed a discussion on another forum where a new user reported
    having problems with OS X Server in regards to archives. According to him
    after using Mailman for a while he went to check for logs and archives only
    to found nothing there. What is the best way to set up Mailman now so that I
    have logs and (most importantly) archives of all posts that I can search in
    the future ? He also mentioned something about making the list private so
    that its contents wouldn't be search, found and indexed by search engines
    like Google. Is this even a possibility and in case it is what steps should
    I take to ensure the contents of my lists will remain private and only
    visible to those that are members ?

    Thank you again,


    Joe
  • Mark Sapiro at Dec 9, 2010 at 1:26 am

    JRC Groups wrote:
    What is the best way to test if the list is now working properly ?

    Try to send a message to the list or maybe send a message with subject
    "help" to the list-request address.

    Also, I followed a discussion on another forum where a new user reported
    having problems with OS X Server in regards to archives. According to him
    after using Mailman for a while he went to check for logs and archives only
    to found nothing there. What is the best way to set up Mailman now so that I
    have logs and (most importantly) archives of all posts that I can search in
    the future ?

    Try running

    sudo /usr/share/mailman/bin/check_perms -f

    If it runs cleanly (don't worry about the warning about
    archives/private being world searchable) logging and archiving should
    work.

    Also make sure your list's Mailman web admin Archiving Options ->
    Archive messages? setting is Yes.

    He also mentioned something about making the list private so
    that its contents wouldn't be search, found and indexed by search engines
    like Google. Is this even a possibility and in case it is what steps should
    I take to ensure the contents of my lists will remain private and only
    visible to those that are members ?

    On the same Archiving Options page set archive_private to private, and
    yes, if archive_private is public, the archives are world accessible
    via the web (at least assuming the host is reachable), and will be
    indexed in search engines.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • JRC Groups at Dec 9, 2010 at 1:51 am

    On 12/8/10 5:26 PM, "Mark Sapiro" wrote:

    JRC Groups wrote:
    What is the best way to test if the list is now working properly ?
    Try to send a message to the list or maybe send a message with subject
    "help" to the list-request address.
    I sent the message and this is what the log in Server Admin shows:

    Dec 8 17:48:13 dentserv postfix/smtpd[37996]: NOQUEUE: reject: RCPT from
    mail-gw0-f52.google.com[74.125.83.52]: 450 4.7.1
    <Implants-request at 3wforum.com>: Recipient address rejected: Service is
    unavailable; from=<joemailgroups at gmail.com>
    to=<Implants-request at 3wforum.com> proto=ESMTP helo=<mail-gw0-f52.google.com>
    Dec 8 17:48:13 dentserv postfix/smtpd[37996]: disconnect from
    mail-gw0-f52.google.com[74.125.83.52]

    Also, I followed a discussion on another forum where a new user reported
    having problems with OS X Server in regards to archives. According to him
    after using Mailman for a while he went to check for logs and archives only
    to found nothing there. What is the best way to set up Mailman now so that I
    have logs and (most importantly) archives of all posts that I can search in
    the future ?

    Try running

    sudo /usr/share/mailman/bin/check_perms -f

    If it runs cleanly (don't worry about the warning about
    archives/private being world searchable) logging and archiving should
    work.
    I ran it and the following is the output:

    dentserv:~ locadmin$ sudo /usr/share/mailman/bin/check_perms -f
    Password:
    Warning: Private archive directory is other-executable (o+x).
    This could allow other users on your system to read private
    archives.
    If you're on a shared multiuser system, you should consult the
    installation manual on how to fix this.
    /private/var/mailman/data/virtual-mailman.db owned by root (must be owned by
    _mailman (fixing)
    /private/var/mailman/data/virtual-mailman.db permissions must be 066x (got
    0100640) (fixing)
    Problems found: 2
    Re-run as _mailman (or root) with -f flag to fix

    Also make sure your list's Mailman web admin Archiving Options ->
    Archive messages? setting is Yes.
    I made the changes.
    He also mentioned something about making the list private so
    that its contents wouldn't be search, found and indexed by search engines
    like Google. Is this even a possibility and in case it is what steps should
    I take to ensure the contents of my lists will remain private and only
    visible to those that are members ?

    On the same Archiving Options page set archive_private to private, and
    yes, if archive_private is public, the archives are world accessible
    via the web (at least assuming the host is reachable), and will be
    indexed in search engines.
    Thank you, Mark. I am glad I've caught that before launching the list as it
    will hold discussions that are required to be maintained private and
    confidential (HIPAA law).

    Thank you, Mark.
  • Mark Sapiro at Dec 9, 2010 at 2:07 am

    JRC Groups wrote:
    I sent the message and this is what the log in Server Admin shows:

    Dec 8 17:48:13 dentserv postfix/smtpd[37996]: NOQUEUE: reject: RCPT from
    mail-gw0-f52.google.com[74.125.83.52]: 450 4.7.1
    <Implants-request at 3wforum.com>: Recipient address rejected: Service is
    unavailable; from=<joemailgroups at gmail.com>
    to=<Implants-request at 3wforum.com> proto=ESMTP helo=<mail-gw0-f52.google.com>
    Dec 8 17:48:13 dentserv postfix/smtpd[37996]: disconnect from
    mail-gw0-f52.google.com[74.125.83.52]

    This is Apple Postfix's greylisting at work. googlemail should retry
    the send after a few minutes and it should succeed. See, e.g.,
    <http://discussions.apple.com/message.jspa?messageID151235>.


    Try running

    sudo /usr/share/mailman/bin/check_perms -f

    If it runs cleanly (don't worry about the warning about
    archives/private being world searchable) logging and archiving should
    work.
    I ran it and the following is the output:

    dentserv:~ locadmin$ sudo /usr/share/mailman/bin/check_perms -f
    Password:
    Warning: Private archive directory is other-executable (o+x).
    This could allow other users on your system to read private
    archives.
    If you're on a shared multiuser system, you should consult the
    installation manual on how to fix this.

    This is the warning I meant to ignore.

    /private/var/mailman/data/virtual-mailman.db owned by root (must be owned by
    _mailman (fixing)
    /private/var/mailman/data/virtual-mailman.db permissions must be 066x (got
    0100640) (fixing)
    Problems found: 2
    Re-run as _mailman (or root) with -f flag to fix

    You already ran it via sudo with -f so the problems with
    virtual-mailman.db should be fixed now.


    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • JRC Groups at Dec 10, 2010 at 6:47 am
    Mark,


    Again, I can't thank you enough. The list(s) are up and running. I wouldn't
    have been able to get it to work had it not been for your help.

    I also want to thank those who responded either through the list or
    privately with helpful answers to my Unix-related questions. Your answers
    have helped me find my way around Unix and motivated me to further improve
    my understanding of it.

    There are a few things I still need to tweak and I thought I would ask you a
    few additional questions. I hope you don't mind.

    Question 1.

    I have created two additional lists for a total of three that I created plus
    one that Apple's own Server Admin requires (a list named Mailman). Using the
    web interface to check the lists hosted by my domain I find conflicting
    results. This is what I have:

    http://www.domain.com/mailman/listinfo

    List Description
    List 1 [no description available]
    List 2 [no description available]

    http://domain.com/mailman/listinfo

    List Description
    List 3 [no description available]
    List 4 [no description available]

    Shouldn't both www.domain.com and domain.com lead to the same results ? How
    can I make the necessary corrections so that both addresses are
    interchangeable and lead to the same results ?

    Question 2.

    As I made an attempt to create lists using the Mailman's web interface
    instead of Apple's Server Admin I couldn't get it done. Mailman kept
    returning an error message stating I didn't have permission to create lists.
    I tried numerous different passwords including the admin password for my
    server but it wouldn't work.

    What have I done wrong ?

    Thank you again for all your help.


    Joe


    On 12/8/10 6:07 PM, "Mark Sapiro" wrote:

    JRC Groups wrote:
    I sent the message and this is what the log in Server Admin shows:

    Dec 8 17:48:13 dentserv postfix/smtpd[37996]: NOQUEUE: reject: RCPT from
    mail-gw0-f52.google.com[74.125.83.52]: 450 4.7.1
    <Implants-request at 3wforum.com>: Recipient address rejected: Service is
    unavailable; from=<joemailgroups at gmail.com>
    to=<Implants-request at 3wforum.com> proto=ESMTP helo=<mail-gw0-f52.google.com>
    Dec 8 17:48:13 dentserv postfix/smtpd[37996]: disconnect from
    mail-gw0-f52.google.com[74.125.83.52]
    This is Apple Postfix's greylisting at work. googlemail should retry
    the send after a few minutes and it should succeed. See, e.g.,
    <http://discussions.apple.com/message.jspa?messageID151235>.
    Try running

    sudo /usr/share/mailman/bin/check_perms -f

    If it runs cleanly (don't worry about the warning about
    archives/private being world searchable) logging and archiving should
    work.
    I ran it and the following is the output:

    dentserv:~ locadmin$ sudo /usr/share/mailman/bin/check_perms -f
    Password:
    Warning: Private archive directory is other-executable (o+x).
    This could allow other users on your system to read private
    archives.
    If you're on a shared multiuser system, you should consult the
    installation manual on how to fix this.
    This is the warning I meant to ignore.
    /private/var/mailman/data/virtual-mailman.db owned by root (must be owned by
    _mailman (fixing)
    /private/var/mailman/data/virtual-mailman.db permissions must be 066x (got
    0100640) (fixing)
    Problems found: 2
    Re-run as _mailman (or root) with -f flag to fix
    You already ran it via sudo with -f so the problems with
    virtual-mailman.db should be fixed now.
  • Mark Sapiro at Dec 10, 2010 at 4:33 pm

    JRC Groups wrote:
    I have created two additional lists for a total of three that I created plus
    one that Apple's own Server Admin requires (a list named Mailman). Using the
    web interface to check the lists hosted by my domain I find conflicting
    results. This is what I have:

    http://www.domain.com/mailman/listinfo

    List Description
    List 1 [no description available]
    List 2 [no description available]

    http://domain.com/mailman/listinfo

    List Description
    List 3 [no description available]
    List 4 [no description available]

    Shouldn't both www.domain.com and domain.com lead to the same results ? How
    can I make the necessary corrections so that both addresses are
    interchangeable and lead to the same results ?


    See the FAQ at <http://wiki.list.org/x/lYA9>. In your case, the short
    answer is put

    VIRTUAL_HOST_OVERVIEW = Off

    in mm_cfg.py.

    As I made an attempt to create lists using the Mailman's web interface
    instead of Apple's Server Admin I couldn't get it done. Mailman kept
    returning an error message stating I didn't have permission to create lists.
    I tried numerous different passwords including the admin password for my
    server but it wouldn't work.

    There are only two passwords that work for the Mailman web create
    interface. Neither is set by default. These are the Mailman site
    password (which is like a super list admin password) and the Mailman
    list creator password.

    set the site password with

    sudo /usr/share/mailman/bin/mmsitepass password

    and set the list creator password with

    sudo /usr/share/mailman/bin/mmsitepass -c password

    See

    sudo /usr/share/mailman/bin/mmsitepass --help

    Note that if you have a site password, you don't need a list creator
    password unless you want to give the ability to create lists to
    someone who doesn't have the site password, and setting a list creator
    password the same as the site password is superfluous.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • JRC Groups at Dec 12, 2010 at 6:11 am
    Hi, Mark.

    On 12/10/10 8:33 AM, "Mark Sapiro" wrote:

    JRC Groups wrote:
    I have created two additional lists for a total of three that I created plus
    one that Apple's own Server Admin requires (a list named Mailman). Using the
    web interface to check the lists hosted by my domain I find conflicting
    results. This is what I have:

    http://www.domain.com/mailman/listinfo

    List Description
    List 1 [no description available]
    List 2 [no description available]

    http://domain.com/mailman/listinfo

    List Description
    List 3 [no description available]
    List 4 [no description available]

    Shouldn't both www.domain.com and domain.com lead to the same results ? How
    can I make the necessary corrections so that both addresses are
    interchangeable and lead to the same results ?


    See the FAQ at <http://wiki.list.org/x/lYA9>. In your case, the short
    answer is put

    VIRTUAL_HOST_OVERVIEW = Off

    in mm_cfg.py.
    I did just as you recommended but it didn't change the behavior displayed by
    the listinfo command.
    As I made an attempt to create lists using the Mailman's web interface
    instead of Apple's Server Admin I couldn't get it done. Mailman kept
    returning an error message stating I didn't have permission to create lists.
    I tried numerous different passwords including the admin password for my
    server but it wouldn't work.

    There are only two passwords that work for the Mailman web create
    interface. Neither is set by default. These are the Mailman site
    password (which is like a super list admin password) and the Mailman
    list creator password.

    set the site password with

    sudo /usr/share/mailman/bin/mmsitepass password

    and set the list creator password with

    sudo /usr/share/mailman/bin/mmsitepass -c password

    See

    sudo /usr/share/mailman/bin/mmsitepass --help

    Note that if you have a site password, you don't need a list creator
    password unless you want to give the ability to create lists to
    someone who doesn't have the site password, and setting a list creator
    password the same as the site password is superfluous.
    It worked just as you had recommended. I was able to assign new site and
    list creator passwords. I haven't yet had the opportunity to test it as I am
    first trying to get the problem above resolved before I make attempts to
    create other lists.

    One thing I noticed is that I can create lists under
    www.domain.com/mailman/create or domain.com/mailman/create. Each takes me to
    a page titled "Create a www.domain.com Mailing List" and "Create a
    domain.com Mailing List" respectively.

    If not the way you suggested above, what could be the problem and how can I
    resolve it ?

    Thank you again,


    Joe
  • Mark Sapiro at Dec 12, 2010 at 4:55 pm

    JRC Groups wrote:
    On 12/10/10 8:33 AM, "Mark Sapiro" wrote:

    JRC Groups wrote:
    I have created two additional lists for a total of three that I created plus
    one that Apple's own Server Admin requires (a list named Mailman). Using the
    web interface to check the lists hosted by my domain I find conflicting
    results. This is what I have:

    http://www.domain.com/mailman/listinfo

    List Description
    List 1 [no description available]
    List 2 [no description available]

    http://domain.com/mailman/listinfo

    List Description
    List 3 [no description available]
    List 4 [no description available]

    Shouldn't both www.domain.com and domain.com lead to the same results ? How
    can I make the necessary corrections so that both addresses are
    interchangeable and lead to the same results ?


    See the FAQ at <http://wiki.list.org/x/lYA9>. In your case, the short
    answer is put

    VIRTUAL_HOST_OVERVIEW = Off

    in mm_cfg.py.
    I did just as you recommended but it didn't change the behavior displayed by
    the listinfo command.

    If you have "VIRTUAL_HOST_OVERVIEW = Off" in mm_cfg.py and the lists
    which appear on the listinfo overview page depend on the host name in
    the URL used to visit the page, this must be due to some Apple
    modification. In standard GNU Mailman, VIRTUAL_HOST_OVERVIEW controls
    this behavior.


    [...]
    One thing I noticed is that I can create lists under
    www.domain.com/mailman/create or domain.com/mailman/create. Each takes me to
    a page titled "Create a www.domain.com Mailing List" and "Create a
    domain.com Mailing List" respectively.

    If not the way you suggested above, what could be the problem and how can I
    resolve it ?

    Again, this indicates either some Apple modification or somehow you
    haven't got "VIRTUAL_HOST_OVERVIEW = Off" in mm_cfg.py. In standard
    Gnu Mailman with "VIRTUAL_HOST_OVERVIEW = Off", the web create CGI
    will always assume the list domain is that defined by DEFAULT_URL_HOST.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • JRC Groups at Dec 12, 2010 at 7:35 am
    Hi, Mark.

    Just as a follow-up to my previous e-mail please read some added notes
    below.

    It worked just as you had recommended. I was able to assign new site and list
    creator passwords. I haven't yet had the opportunity to test it as I am first
    trying to get the problem above resolved before I make attempts to create
    other lists.
    One thing I noticed is that I can create lists under
    www.domain.com/mailman/create or domain.com/mailman/create. Each takes me to a
    page titled "Create a www.domain.com Mailing List" and "Create a domain.com
    Mailing List" respectively.
    If not the way you suggested above, what could be the problem and how can I
    resolve it ?
    Thank you again,
    Joe
    I made an attempt to create a new list using www.domain.com/mailman/create.
    At first I was prompted for an initial list password as Mailman didn't allow
    me to create a list without one. Next I received a response from Mailman
    stating that I didn't have permission to create lists. After I entered the
    site password in "List creator's (authentication) password:" I the received
    the following error message: "Unknown virtual host: www.domain.com"

    After that I thought I would try to create a new list using
    domain.com/mailman/create. The result was exactly the same. I received the
    same error message as above.

    What have I done wrong and how can I correct it ?

    Thank you again,


    Joe
  • Mark Sapiro at Dec 12, 2010 at 4:59 pm

    JRC Groups wrote:
    I made an attempt to create a new list using www.domain.com/mailman/create.
    At first I was prompted for an initial list password as Mailman didn't allow
    me to create a list without one. Next I received a response from Mailman
    stating that I didn't have permission to create lists. After I entered the
    site password in "List creator's (authentication) password:" I the received
    the following error message: "Unknown virtual host: www.domain.com"

    After that I thought I would try to create a new list using
    domain.com/mailman/create. The result was exactly the same. I received the
    same error message as above.

    What have I done wrong and how can I correct it ?


    I don't know. Please post the entire contents of your mm_cfg.py. The
    above errors indicate that there is no add_virtualhost() for
    www.domain.com, but this is not consistent with other things you
    observe.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • JRC Groups at Dec 13, 2010 at 6:01 am
    Hi, Mark.

    On 12/12/10 8:59 AM, "Mark Sapiro" wrote:

    I don't know. Please post the entire contents of your mm_cfg.py. The
    above errors indicate that there is no add_virtualhost() for
    www.domain.com, but this is not consistent with other things you
    observe.
    Here it is:

    # Put YOUR site-specific settings below this line.
    MTA = 'Postfix'
    DEFAULT_EMAIL_HOST = 'dentserv.main.private'
    DEFAULT_URL_HOST = 'dentserv.main.private'
    VIRTUAL_HOSTS.clear()
    add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
    POSTFIX_STYLE_VIRTUAL_DOMAINS = ['3wforum.com']
    VIRTUAL_HOST_OVERVIEW = Off

    As I copied the contents to paste them here I noticed that I had made a
    mistake. On the last entry I had "VIRTUAL_HOST_OVERVIEW - Off" instead of
    "VIRTUAL_HOST_OVERVIEW = Off". Once I corrected this entry I was able to
    have all lists displayed in the listinfo window.

    Now that I am able to view all lists displayed together in the same listinfo
    window I also noticed that the title to the listinfo page reads
    "dentserv.main.private Mailing Lists". In looking back at the mm_cfg.py file
    contents I noticed that something had been modified after I made the
    revisions you had suggested. The following entries were:

    DEFAULT_EMAIL_HOST = 'dentserv.main.private'
    DEFAULT_URL_HOST = 'dentserv.main.private'

    This is the name of my server and not the domain names as I had previously
    entered. So I proceeded to make the changes as you had previously suggested.

    DEFAULT_EMAIL_HOST = 'domain.com'
    DEFAULT_URL_HOST = 'www.domain.com'

    After these changes I was finally able to have the lists displayed in the
    listinfo window. I also noticed that the title above now reads
    "www.domain.com Mailing Lists". The titles is the same independent of
    whether I type "www.domain.com/mailman/listinfo" or
    "domain.com/mailman/listinfo".

    After that I also made an attempt to create a new list from the web
    interface using "www.domain.com/mailman/create" and this time it worked fine
    without any error messages.

    I am left with a question: Why were the two lines above changed from the
    domain names I had entered following your suggestion to the name of the
    server ? Do you think it has something to do with my server settings or do
    you think it may be related with Apple's implementation of Mailman ?

    Thank you again for your help.

    Joe
  • Mark Sapiro at Dec 13, 2010 at 6:22 am

    JRC Groups wrote:
    On 12/12/10 8:59 AM, "Mark Sapiro" wrote:

    I don't know. Please post the entire contents of your mm_cfg.py. The
    above errors indicate that there is no add_virtualhost() for
    www.domain.com, but this is not consistent with other things you
    observe.
    Here it is:

    # Put YOUR site-specific settings below this line.
    MTA = 'Postfix'
    DEFAULT_EMAIL_HOST = 'dentserv.main.private'
    DEFAULT_URL_HOST = 'dentserv.main.private'

    As you note below, the above entries are not what you want.

    VIRTUAL_HOSTS.clear()
    add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
    POSTFIX_STYLE_VIRTUAL_DOMAINS = ['3wforum.com']

    Is the '3wforum.com' domain what you refer to elsewhere as
    'domain.com'. If so, the above is probably fine (although the cat is
    now out of the bag). If not, then it probably should be.

    VIRTUAL_HOST_OVERVIEW = Off

    As I copied the contents to paste them here I noticed that I had made a
    mistake. On the last entry I had "VIRTUAL_HOST_OVERVIEW - Off" instead of
    "VIRTUAL_HOST_OVERVIEW = Off". Once I corrected this entry I was able to
    have all lists displayed in the listinfo window.

    Good.

    Now that I am able to view all lists displayed together in the same listinfo
    window I also noticed that the title to the listinfo page reads
    "dentserv.main.private Mailing Lists". In looking back at the mm_cfg.py file
    contents I noticed that something had been modified after I made the
    revisions you had suggested. The following entries were:

    DEFAULT_EMAIL_HOST = 'dentserv.main.private'
    DEFAULT_URL_HOST = 'dentserv.main.private'

    This is the name of my server and not the domain names as I had previously
    entered. So I proceeded to make the changes as you had previously suggested.

    DEFAULT_EMAIL_HOST = 'domain.com'
    DEFAULT_URL_HOST = 'www.domain.com'

    After these changes I was finally able to have the lists displayed in the
    listinfo window. I also noticed that the title above now reads
    "www.domain.com Mailing Lists". The titles is the same independent of
    whether I type "www.domain.com/mailman/listinfo" or
    "domain.com/mailman/listinfo".

    Yes, this is a result of "VIRTUAL_HOST_OVERVIEW = Off" which in
    addition to displaying all lists on the overview regardless of whether
    the list's URL host matches the host in the URL accessing the page
    also causes DEFAULT_URL_HOST to be treated as the host.

    After that I also made an attempt to create a new list from the web
    interface using "www.domain.com/mailman/create" and this time it worked fine
    without any error messages.

    I am left with a question: Why were the two lines above changed from the
    domain names I had entered following your suggestion to the name of the
    server ? Do you think it has something to do with my server settings or do
    you think it may be related with Apple's implementation of Mailman ?

    I think it must have something to do with Apple's implementation of
    Mailman. I suspect it has something to do with Apple's list creation
    process. There is nothing in standard GNU Mailman that would edit
    mm_cfg.py behind your back, nor would any non-Mailman process do this.

    Perhaps others on this list who are familiar with Apple Server could
    shed more light on this.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • JRC Groups at Apr 16, 2011 at 7:35 pm
    Mark,


    It has been suggested to me an approach that I thought might resolve the
    problem I am experiencing with the changes constantly made by OS X Server
    Admin application to Mailman's mm_cfg.py file. An it specialist who helped
    me review my OS X Server set-up and DNS settings suggested that I should
    change permissions on this file in order to prevent OS X Server from editing
    it. He tried changing the permissions on the file to rw-r--r-- but it still
    didn't work. From my limited knowledge of UNIX and terminal it appears to me
    that the ownership of the file belongs to -Mailman. Is this right ?

    Can either the permissions or the ownership (and perhaps both) on this file
    be modified so as to keep OS X Server from editing it ? Could these
    modifications have any adverse effect on Mailman's behavior or would the
    program work fine with this file as a read-only file ?

    What do you think ?

    According to the it specialist my set-up and DNS settings are fine. This is
    a relief. Now I know that the issue is very likely related to Apple's (poor)
    implementation of Mailman. I know one choice I have is to bypass this
    bundled version included with OS X Server and install a fresh version of
    Mailman. However, considering the work and time involved I would prefer, if
    possible, to work with the version I have and that is already set-up.

    What are your thoughts on this matter ?

    Thank you as always for your help,


    Joe

    On 12/12/10 10:22 PM, "Mark Sapiro" wrote:

    JRC Groups wrote:
    On 12/12/10 8:59 AM, "Mark Sapiro" wrote:

    I don't know. Please post the entire contents of your mm_cfg.py. The
    above errors indicate that there is no add_virtualhost() for
    www.domain.com, but this is not consistent with other things you
    observe.
    Here it is:

    # Put YOUR site-specific settings below this line.
    MTA = 'Postfix'
    DEFAULT_EMAIL_HOST = 'dentserv.main.private'
    DEFAULT_URL_HOST = 'dentserv.main.private'

    As you note below, the above entries are not what you want.

    VIRTUAL_HOSTS.clear()
    add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
    POSTFIX_STYLE_VIRTUAL_DOMAINS = ['3wforum.com']

    Is the '3wforum.com' domain what you refer to elsewhere as
    'domain.com'. If so, the above is probably fine (although the cat is
    now out of the bag). If not, then it probably should be.

    VIRTUAL_HOST_OVERVIEW = Off

    As I copied the contents to paste them here I noticed that I had made a
    mistake. On the last entry I had "VIRTUAL_HOST_OVERVIEW - Off" instead of
    "VIRTUAL_HOST_OVERVIEW = Off". Once I corrected this entry I was able to
    have all lists displayed in the listinfo window.

    Good.

    Now that I am able to view all lists displayed together in the same listinfo
    window I also noticed that the title to the listinfo page reads
    "dentserv.main.private Mailing Lists". In looking back at the mm_cfg.py file
    contents I noticed that something had been modified after I made the
    revisions you had suggested. The following entries were:

    DEFAULT_EMAIL_HOST = 'dentserv.main.private'
    DEFAULT_URL_HOST = 'dentserv.main.private'

    This is the name of my server and not the domain names as I had previously
    entered. So I proceeded to make the changes as you had previously suggested.

    DEFAULT_EMAIL_HOST = 'domain.com'
    DEFAULT_URL_HOST = 'www.domain.com'

    After these changes I was finally able to have the lists displayed in the
    listinfo window. I also noticed that the title above now reads
    "www.domain.com Mailing Lists". The titles is the same independent of
    whether I type "www.domain.com/mailman/listinfo" or
    "domain.com/mailman/listinfo".

    Yes, this is a result of "VIRTUAL_HOST_OVERVIEW = Off" which in
    addition to displaying all lists on the overview regardless of whether
    the list's URL host matches the host in the URL accessing the page
    also causes DEFAULT_URL_HOST to be treated as the host.

    After that I also made an attempt to create a new list from the web
    interface using "www.domain.com/mailman/create" and this time it worked fine
    without any error messages.

    I am left with a question: Why were the two lines above changed from the
    domain names I had entered following your suggestion to the name of the
    server ? Do you think it has something to do with my server settings or do
    you think it may be related with Apple's implementation of Mailman ?

    I think it must have something to do with Apple's implementation of
    Mailman. I suspect it has something to do with Apple's list creation
    process. There is nothing in standard GNU Mailman that would edit
    mm_cfg.py behind your back, nor would any non-Mailman process do this.

    Perhaps others on this list who are familiar with Apple Server could
    shed more light on this.
  • Mark Sapiro at Apr 16, 2011 at 11:06 pm

    JRC Groups wrote:
    It has been suggested to me an approach that I thought might resolve the
    problem I am experiencing with the changes constantly made by OS X Server
    Admin application to Mailman's mm_cfg.py file. An it specialist who helped
    me review my OS X Server set-up and DNS settings suggested that I should
    change permissions on this file in order to prevent OS X Server from editing
    it. He tried changing the permissions on the file to rw-r--r-- but it still
    didn't work. From my limited knowledge of UNIX and terminal it appears to me
    that the ownership of the file belongs to -Mailman. Is this right ?

    It doesn't matter what the owner is. Normally, the group is the mailman
    group (_mailman in Mac OS X/Darwin) and the file is group writable. In
    the case of mm_cfg.py, it doesn't need to be writable because Mailman
    doesn't change it, only you do, but it must be readable by the Mailman
    group (_mailman).

    Can either the permissions or the ownership (and perhaps both) on this file
    be modified so as to keep OS X Server from editing it ? Could these
    modifications have any adverse effect on Mailman's behavior or would the
    program work fine with this file as a read-only file ?

    You could edit it and then chmod it to r--r--r--, and as far as Mailman
    is concerned, it would be OK.

    What do you think ?

    I think it won't work because what ever process keeps reverting it is
    probably running as root and can write the file even without explicit
    permission. But, you could try. Presumably, when permissions were
    rw-r--r--, the owner was _mailman, so if the 'reversion' process is
    running as _mailman, changing the permissions to r--r--r-- may work if
    it doesn't cause any harmful side effects to the process doing the
    reversion.

    According to the it specialist my set-up and DNS settings are fine. This is
    a relief. Now I know that the issue is very likely related to Apple's (poor)
    implementation of Mailman. I know one choice I have is to bypass this
    bundled version included with OS X Server and install a fresh version of
    Mailman. However, considering the work and time involved I would prefer, if
    possible, to work with the version I have and that is already set-up.

    What are your thoughts on this matter ?

    If it were me, the first thing I would do is look in all the directories

    ~_mailman/Library/LaunchAgents
    /Library/LaunchAgents
    /Library/LaunchDaemons
    /System/Library/LaunchAgents
    /System/Library/LaunchDaemons

    for any .plist files with mailman in their names (or any files in the
    first directory) to see if I could figure out what process is
    reverting mm_cfg.py and then maybe edit the file to remove the process.

    If that didn't help, I would go to the FAQ at
    <http://wiki.list.org/x/O4A9> and from there to Larry Stone's posts on
    the subject and install Mailman from source. But, first I would be
    sure to back up my lists and archives and completely remove the Apple
    mailman to avoid conflicts and to hopefully keep whatever process is
    reverting your mm_cfg.py from continuing to do it.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • JRC Groups at Apr 18, 2011 at 6:53 am
    Mark,


    Just as you suspected changing permissions to r--r--r-- didn't resolve the
    problem. The file is still edited after the permission have been modified.

    On 4/16/11 4:06 PM, "Mark Sapiro" wrote:

    JRC Groups wrote:
    It has been suggested to me an approach that I thought might resolve the
    problem I am experiencing with the changes constantly made by OS X Server
    Admin application to Mailman's mm_cfg.py file. An it specialist who helped
    me review my OS X Server set-up and DNS settings suggested that I should
    change permissions on this file in order to prevent OS X Server from editing
    it. He tried changing the permissions on the file to rw-r--r-- but it still
    didn't work. From my limited knowledge of UNIX and terminal it appears to me
    that the ownership of the file belongs to -Mailman. Is this right ?

    It doesn't matter what the owner is. Normally, the group is the mailman
    group (_mailman in Mac OS X/Darwin) and the file is group writable. In
    the case of mm_cfg.py, it doesn't need to be writable because Mailman
    doesn't change it, only you do, but it must be readable by the Mailman
    group (_mailman).

    Can either the permissions or the ownership (and perhaps both) on this file
    be modified so as to keep OS X Server from editing it ? Could these
    modifications have any adverse effect on Mailman's behavior or would the
    program work fine with this file as a read-only file ?

    You could edit it and then chmod it to r--r--r--, and as far as Mailman
    is concerned, it would be OK.
    After modifying the file's permissions the system is still able to edit it
    and change it back.
    What do you think ?

    I think it won't work because what ever process keeps reverting it is
    probably running as root and can write the file even without explicit
    permission. But, you could try. Presumably, when permissions were
    rw-r--r--, the owner was _mailman, so if the 'reversion' process is
    running as _mailman, changing the permissions to r--r--r-- may work if
    it doesn't cause any harmful side effects to the process doing the
    reversion.
    You are right.
    According to the it specialist my set-up and DNS settings are fine. This is
    a relief. Now I know that the issue is very likely related to Apple's (poor)
    implementation of Mailman. I know one choice I have is to bypass this
    bundled version included with OS X Server and install a fresh version of
    Mailman. However, considering the work and time involved I would prefer, if
    possible, to work with the version I have and that is already set-up.

    What are your thoughts on this matter ?
    If it were me, the first thing I would do is look in all the directories

    ~_mailman/Library/LaunchAgents
    /Library/LaunchAgents
    /Library/LaunchDaemons
    /System/Library/LaunchAgents
    /System/Library/LaunchDaemons

    for any .plist files with mailman in their names (or any files in the
    first directory) to see if I could figure out what process is
    reverting mm_cfg.py and then maybe edit the file to remove the process.

    If that didn't help, I would go to the FAQ at
    <http://wiki.list.org/x/O4A9> and from there to Larry Stone's posts on
    the subject and install Mailman from source. But, first I would be
    sure to back up my lists and archives and completely remove the Apple
    mailman to avoid conflicts and to hopefully keep whatever process is
    reverting your mm_cfg.py from continuing to do it.
    I have read the page and also contacted Larry Stone. His instructions are
    for installation on OS X client and not OS X Server. I haven't found
    instructions on how to remove the Mailman version bundled by Apple with OS X
    Server. One of my concerns is that Apple's version and the downloaded
    version would both have several (if not all) files installed as default in
    the same location and this could lead to potential conflicts.

    Are you aware of any instructions on how to remove Mailman (hopefully from
    OS X Server) prior to the installation of a new version ?

    In case you aren't, do you think it would be a problem to have Mailman
    installed in a different location than the default just to avoid possible
    conflicts with the pre-existing version ?

    Thank you for your help,

    Joe
  • Larry Stone at Apr 18, 2011 at 11:28 am

    On 4/18/11 1:53 AM, JRC Groups at joemailgroups at gmail.com wrote:


    I have read the page and also contacted Larry Stone. His instructions are
    for installation on OS X client and not OS X Server. I haven't found
    instructions on how to remove the Mailman version bundled by Apple with OS X
    Server. One of my concerns is that Apple's version and the downloaded
    version would both have several (if not all) files installed as default in
    the same location and this could lead to potential conflicts.
    With some more thought than my quick private reply to you last night, I
    don't think this is an issue. IIRC, you choose where to install Mailman and
    I believe it is self-contained in that directory. My latest instructions
    (for Snow Leopard) suggest /usr/local/mailman but previous versions
    suggested /Applications/mailman (and if you wanted to, you could call it
    something like
    /usr/local/my_private_copy_of_mailman_which_does_not_conflict_with_Apples
    which is inelegant but would work and I'm pretty sure really does not
    conflict :-) ). So long as the directory you pick does not exist, then you
    will not be at risk of a conflict. You would, of course, have to change that
    name throughout my instructions but that is trivial.

    The instructions do call for modifying some configuration files of other
    software (Postfix and Apache) but those files are intended to be
    user-modifiable and Apple provided updates should not be overriding your
    mofications.

    --
    Larry Stone
    lstone19 at stonejongleux.com
    http://www.stonejongleux.com/
  • JRC Groups at Apr 21, 2011 at 6:42 am
    Larry,


    Thank you for your helpful reply.

    Although not enthusiastic about it I have decided to follow your advice as
    well as Mark's and just install a new version of Mailman. I was trying to
    save myself sometime but considering the explanations both of you have
    provided I believe it is better to just face the extra work and avoid
    Apple's version.

    Now that I now I can simply install it on a new directory that will not
    conflict with the existing version things should be much simpler.

    Thank you again for your reply and help with this issue.

    Best regards,


    Joe

    On 4/18/11 4:28 AM, "Larry Stone" wrote:

    On 4/18/11 1:53 AM, JRC Groups at joemailgroups at gmail.com wrote:

    I have read the page and also contacted Larry Stone. His instructions are
    for installation on OS X client and not OS X Server. I haven't found
    instructions on how to remove the Mailman version bundled by Apple with OS X
    Server. One of my concerns is that Apple's version and the downloaded
    version would both have several (if not all) files installed as default in
    the same location and this could lead to potential conflicts.
    With some more thought than my quick private reply to you last night, I
    don't think this is an issue. IIRC, you choose where to install Mailman and
    I believe it is self-contained in that directory. My latest instructions
    (for Snow Leopard) suggest /usr/local/mailman but previous versions
    suggested /Applications/mailman (and if you wanted to, you could call it
    something like
    /usr/local/my_private_copy_of_mailman_which_does_not_conflict_with_Apples
    which is inelegant but would work and I'm pretty sure really does not
    conflict :-) ). So long as the directory you pick does not exist, then you
    will not be at risk of a conflict. You would, of course, have to change that
    name throughout my instructions but that is trivial.

    The instructions do call for modifying some configuration files of other
    software (Postfix and Apache) but those files are intended to be
    user-modifiable and Apple provided updates should not be overriding your
    mofications.
  • JRC Groups at Apr 18, 2011 at 5:43 pm
    Mark,


    Based on what you describe below I thought of perhaps another alternative to
    this problem.

    Since there is a process in Apple's Server Admin application that keeps
    changing Mailman's mm_cfg.py file I think it is safe to assume it expects to
    find this file there to keep it updated and its removal may likely cause a
    conflict.

    Would it be possible to have a copy of this file moved to a different
    location and have Mailman look at the different location for this file while
    leaving the old one behind as a "dummy" file so that Apple's System Admin
    application finds the file it expects to find ? The changes would not impact
    Mailman as the mm_cfg.py it is using for its configuration is the one in the
    new location.

    Do you think this would work ?

    Thanks,


    Joe


    On 4/16/11 4:06 PM, "Mark Sapiro" wrote:

    It doesn't matter what the owner is. Normally, the group is the mailman
    group (_mailman in Mac OS X/Darwin) and the file is group writable. In
    the case of mm_cfg.py, it doesn't need to be writable because Mailman
    doesn't change it, only you do, but it must be readable by the Mailman
    group (_mailman).

    I think it won't work because what ever process keeps reverting it is
    probably running as root and can write the file even without explicit
    permission. But, you could try. Presumably, when permissions were
    rw-r--r--, the owner was _mailman, so if the 'reversion' process is
    running as _mailman, changing the permissions to r--r--r-- may work if
    it doesn't cause any harmful side effects to the process doing the
    reversion.

    If it were me, the first thing I would do is look in all the directories

    ~_mailman/Library/LaunchAgents
    /Library/LaunchAgents
    /Library/LaunchDaemons
    /System/Library/LaunchAgents
    /System/Library/LaunchDaemons

    for any .plist files with mailman in their names (or any files in the
    first directory) to see if I could figure out what process is
    reverting mm_cfg.py and then maybe edit the file to remove the process.
  • Mark Sapiro at Apr 18, 2011 at 5:54 pm

    JRC Groups wrote:
    Since there is a process in Apple's Server Admin application that keeps
    changing Mailman's mm_cfg.py file I think it is safe to assume it expects to
    find this file there to keep it updated and its removal may likely cause a
    conflict.

    Would it be possible to have a copy of this file moved to a different
    location and have Mailman look at the different location for this file while
    leaving the old one behind as a "dummy" file so that Apple's System Admin
    application finds the file it expects to find ? The changes would not impact
    Mailman as the mm_cfg.py it is using for its configuration is the one in the
    new location.

    Do you think this would work ?

    You would have to move the entire Mailman $prefix directory and then
    you would have to edit the prefix in all files that reference it
    including Defaults.py and all the paths.py files in Mailman's bin/,
    cron/ and tests/ directories and the MTA aliases and apache config,
    and you would have to set the new location in whatever Apple launchd
    processes that start Mailman and run Mailman's 'cron' jobs, and that
    would probably tell the Apple processes where the new mm_cfg.py was
    anyway.

    It would be much easier to simply install Mailman from source in some
    other location, move your lists and archives, update your MTA and
    apache configs and tell Apple to quit running Mailman.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • JRC Groups at Apr 19, 2011 at 7:14 pm
    Mark,


    Thanks again for your help. Since I already have Mailman configured and
    working in OS X Server I thought it might be worth finding a work around
    this problem.

    However, considering your detailed explanation below I will just forget it
    and try to install a new version.

    Best regards,


    Joe

    On 4/18/11 10:54 AM, "Mark Sapiro" wrote:

    JRC Groups wrote:
    Since there is a process in Apple's Server Admin application that keeps
    changing Mailman's mm_cfg.py file I think it is safe to assume it expects to
    find this file there to keep it updated and its removal may likely cause a
    conflict.

    Would it be possible to have a copy of this file moved to a different
    location and have Mailman look at the different location for this file while
    leaving the old one behind as a "dummy" file so that Apple's System Admin
    application finds the file it expects to find ? The changes would not impact
    Mailman as the mm_cfg.py it is using for its configuration is the one in the
    new location.

    Do you think this would work ?

    You would have to move the entire Mailman $prefix directory and then
    you would have to edit the prefix in all files that reference it
    including Defaults.py and all the paths.py files in Mailman's bin/,
    cron/ and tests/ directories and the MTA aliases and apache config,
    and you would have to set the new location in whatever Apple launchd
    processes that start Mailman and run Mailman's 'cron' jobs, and that
    would probably tell the Apple processes where the new mm_cfg.py was
    anyway.

    It would be much easier to simply install Mailman from source in some
    other location, move your lists and archives, update your MTA and
    apache configs and tell Apple to quit running Mailman.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • JRC Groups at May 8, 2011 at 6:22 am
    Mark and all members,


    Considering the mm_cfg.py file has been edited to display the following:

    MTA = 'Postfix'
    DEFAULT_EMAIL_HOST = 'domain.com'
    DEFAULT_URL_HOST = 'www.domain.com'
    VIRTUAL_HOSTS.clear()
    add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
    POSTFIX_STYLE_VIRTUAL_DOMAINS = ['domain.com']
    VIRTUAL_HOST_OVERVIEW = Off

    Should I expect to find the name of the server (not the name of the domain)
    on any of the e-mail sent by Mailman to subscribers ?

    After discussing the case with several people and a little bit of research I
    have come across a solution that seems to have prevented the mm_cfg.py from
    being edited by Apple's Server Admin application. Changing permissions
    didn't work as it was still edited probably by a process running as root. I
    tried instead to lock the file using the chflags command and it seems to
    have worked. Now, as I make changes to system settings using Apple's Server
    Admin application the mm_cfg.py files remains as is and isn't changed back.

    The command I used was:

    sudo chflags uchg /usr/share/mailman/Mailman/mm_cfg.py

    This has allowed the mm_cfg.py configuration file to remain as above with
    the name of the domain associated with Mailman. As it was before, any
    changes made in Server Admin would cause the domain name to be replaced with
    the computer name 'a.main.private' and this would show on e-mails sent by
    Mailman.

    Assuming this change will be permanent and the domain name will remain in
    the configuration file, should I expect the computer name to show up on any
    of the mail sent out to subscribers by Mailman, including the one sent
    monthly to remind subscribers about list rules ?

    I have received some mail from Mailman that looks as follows:

    From: mailman-owner@a.main.private (sent by mailman-bounces at domain.com)
    Date: ...
    To: ...
    Subject: a.main.private mailing list memberships reminder

    Now that the configuration has been changed should I expect to see the
    domain name where the name of the server appears ? Or is it normal to have
    the server's name appear in some parts of mail sent by Mailman ?

    Thank you as always for your help.

    Best regards,


    Joe

    PS: content of the e-mail if it is helpful.

    This is a reminder, sent out once a month, about your
    a.main.private mailing list memberships. It includes your
    subscription info and how to use it to change it or unsubscribe from a
    list.

    You can visit the URLs to change your membership status or
    configuration, including unsubscribing, setting digest-style delivery
    or disabling delivery altogether (e.g., for a vacation), and so on.

    In addition to the URL interfaces, you can also use email to make such
    changes. For more info, send a message to the '-request' address of
    the list (for example, mailman-request at a.main.private)
    containing just the word 'help' in the message body, and an email
    message will be sent to you with instructions.

    If you have questions, problems, comments, etc, send them to
    mailman-owner at a.main.private. Thanks!

    Passwords for member1 at gmail.com:

    List Password // URL
    ---- --------
    list1 at domain.com coceopxi
    http://www.domain.com/mailman/options/list1/member1%40gmail.com

    On 4/18/11 10:54 AM, "Mark Sapiro" wrote:

    JRC Groups wrote:
    Since there is a process in Apple's Server Admin application that keeps
    changing Mailman's mm_cfg.py file I think it is safe to assume it expects to
    find this file there to keep it updated and its removal may likely cause a
    conflict.

    Would it be possible to have a copy of this file moved to a different
    location and have Mailman look at the different location for this file while
    leaving the old one behind as a "dummy" file so that Apple's System Admin
    application finds the file it expects to find ? The changes would not impact
    Mailman as the mm_cfg.py it is using for its configuration is the one in the
    new location.

    Do you think this would work ?

    You would have to move the entire Mailman $prefix directory and then
    you would have to edit the prefix in all files that reference it
    including Defaults.py and all the paths.py files in Mailman's bin/,
    cron/ and tests/ directories and the MTA aliases and apache config,
    and you would have to set the new location in whatever Apple launchd
    processes that start Mailman and run Mailman's 'cron' jobs, and that
    would probably tell the Apple processes where the new mm_cfg.py was
    anyway.

    It would be much easier to simply install Mailman from source in some
    other location, move your lists and archives, update your MTA and
    apache configs and tell Apple to quit running Mailman.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Mark Sapiro at May 8, 2011 at 3:27 pm

    JRC Groups wrote:
    I have received some mail from Mailman that looks as follows:

    From: mailman-owner at a.main.private (sent by mailman-bounces at domain.com)
    Date: ...
    To: ...
    Subject: a.main.private mailing list memberships reminder

    Now that the configuration has been changed should I expect to see the
    domain name where the name of the server appears ? Or is it normal to have
    the server's name appear in some parts of mail sent by Mailman ?

    Since the envelope sender (or Sender: header) is
    mailman-bounces at domain.com, we know Mailman is using the domain.com
    domain. The message Mailman creates will have the domain.com domain in
    all Mailman/List addresses.

    It is your outgoing MTA that is rewriting the domain of the From:
    header to a.main.private.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • JRC Groups at May 8, 2011 at 7:48 pm
    Mark,

    The message I shared was sent by Mailman prior to the changes I made to the
    mm_cfg.py file. Is it possible that the reason a.main.private appeared on
    the e-mail was because the configuration file was edited by Apple's Server
    Admin and displayed it instead of domain.com as it should ?

    In other words, if the configuration file was as follows:

    MTA = 'Postfix'
    DEFAULT_EMAIL_HOST = 'a.main.private'
    DEFAULT_URL_HOST = 'a.main.private'
    VIRTUAL_HOSTS.clear()
    add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
    POSTFIX_STYLE_VIRTUAL_DOMAINS = ['domain.com']
    VIRTUAL_HOST_OVERVIEW = Off

    Would this generate the change in the e-mail sent by Mailman so that it
    would display the server name instead of the domain name ?

    Thank you again for your help.

    Joe

    On 5/8/11 8:27 AM, "Mark Sapiro" wrote:

    JRC Groups wrote:
    I have received some mail from Mailman that looks as follows:

    From: mailman-owner at a.main.private (sent by mailman-bounces at domain.com)
    Date: ...
    To: ...
    Subject: a.main.private mailing list memberships reminder

    Now that the configuration has been changed should I expect to see the
    domain name where the name of the server appears ? Or is it normal to have
    the server's name appear in some parts of mail sent by Mailman ?

    Since the envelope sender (or Sender: header) is
    mailman-bounces at domain.com, we know Mailman is using the domain.com
    domain. The message Mailman creates will have the domain.com domain in
    all Mailman/List addresses.

    It is your outgoing MTA that is rewriting the domain of the From:
    header to a.main.private.
  • Mark Sapiro at May 8, 2011 at 10:46 pm
    JRC Groups
    The message I shared was sent by Mailman prior to the changes I made to the
    mm_cfg.py file. Is it possible that the reason a.main.private appeared on
    the e-mail was because the configuration file was edited by Apple's Server
    Admin and displayed it instead of domain.com as it should ?

    In other words, if the configuration file was as follows:

    MTA = 'Postfix'
    DEFAULT_EMAIL_HOST = 'a.main.private'
    DEFAULT_URL_HOST = 'a.main.private'
    VIRTUAL_HOSTS.clear()
    add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
    POSTFIX_STYLE_VIRTUAL_DOMAINS = ['domain.com']
    VIRTUAL_HOST_OVERVIEW = Off

    Would this generate the change in the e-mail sent by Mailman so that it
    would display the server name instead of the domain name ?
    JRC Groups wrote:
    I have received some mail from Mailman that looks as follows:

    From: mailman-owner at a.main.private (sent by mailman-bounces at domain.com)
    Date: ...
    To: ...
    Subject: a.main.private mailing list memberships reminder

    Probably, but you need to look at the full raw headers of the message
    rather than what's displayed as From: by some MUA.

    with VIRTUAL_HOST_OVERVIEW Off, there are potentially 3 domains
    involved. These are the DEFAULT_EMAIL_HOST domain, the host_name
    attribute of the 'mailman' list and the 'host_name' attribute of the
    individual lists.

    The list(s) in the body of the password reminder are identified as
    list at domain. This domain is the host_name attribute of the list. This
    only appears in the body, not in the headers of the reminder.

    Additionally, the reminder is From: mailman-owner at domain where domain
    is DEFAULT_EMAIL_HOST, but the envelope sender (Return-Path: header)
    and the Sender: and Errors-To: headers are all mailman-bounces at domain
    where domain is the host_name attribute of the 'mailman' list.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • JRC Groups at May 10, 2011 at 5:14 am
    Mark,

    Is there a way to force Mailman to send this password reminder e-mails so
    that I can see what the message looks like now that I have been able to edit
    and lock the mm_cfg.py file ? I would like to verify if this has fixed the
    problem and also look at the headers.

    Thank you,

    Joe

    On 5/8/11 3:46 PM, "Mark Sapiro" wrote:

    JRC Groups
    The message I shared was sent by Mailman prior to the changes I made to the
    mm_cfg.py file. Is it possible that the reason a.main.private appeared on
    the e-mail was because the configuration file was edited by Apple's Server
    Admin and displayed it instead of domain.com as it should ?

    In other words, if the configuration file was as follows:

    MTA = 'Postfix'
    DEFAULT_EMAIL_HOST = 'a.main.private'
    DEFAULT_URL_HOST = 'a.main.private'
    VIRTUAL_HOSTS.clear()
    add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
    POSTFIX_STYLE_VIRTUAL_DOMAINS = ['domain.com']
    VIRTUAL_HOST_OVERVIEW = Off

    Would this generate the change in the e-mail sent by Mailman so that it
    would display the server name instead of the domain name ?
    JRC Groups wrote:
    I have received some mail from Mailman that looks as follows:

    From: mailman-owner at a.main.private (sent by mailman-bounces at domain.com)
    Date: ...
    To: ...
    Subject: a.main.private mailing list memberships reminder

    Probably, but you need to look at the full raw headers of the message
    rather than what's displayed as From: by some MUA.

    with VIRTUAL_HOST_OVERVIEW Off, there are potentially 3 domains
    involved. These are the DEFAULT_EMAIL_HOST domain, the host_name
    attribute of the 'mailman' list and the 'host_name' attribute of the
    individual lists.

    The list(s) in the body of the password reminder are identified as
    list at domain. This domain is the host_name attribute of the list. This
    only appears in the body, not in the headers of the reminder.

    Additionally, the reminder is From: mailman-owner at domain where domain
    is DEFAULT_EMAIL_HOST, but the envelope sender (Return-Path: header)
    and the Sender: and Errors-To: headers are all mailman-bounces at domain
    where domain is the host_name attribute of the 'mailman' list.
  • JRC Groups at May 10, 2011 at 5:25 am
    Mark,

    Any ideas as to why this is happening and how to fix it ?
    On 5/8/11 8:27 AM, "Mark Sapiro" wrote:

    Since the envelope sender (or Sender: header) is
    mailman-bounces at domain.com, we know Mailman is using the domain.com
    domain. The message Mailman creates will have the domain.com domain in
    all Mailman/List addresses.

    It is your outgoing MTA that is rewriting the domain of the From:
    header to a.main.private.
    Thank you,

    Joe
  • Mark Sapiro at May 10, 2011 at 6:07 am

    JRC Groups wrote:
    Any ideas as to why this is happening and how to fix it ?

    The statement quoted below is superceded by the answer at
    <http://mail.python.org/pipermail/mailman-users/2011-May/071554.html>.
    It is probably not correct in this case. Monthly password reminders
    are an exception.

    On 5/8/11 8:27 AM, "Mark Sapiro" wrote:

    Since the envelope sender (or Sender: header) is
    mailman-bounces at domain.com, we know Mailman is using the domain.com
    domain. The message Mailman creates will have the domain.com domain in
    all Mailman/List addresses.

    It is your outgoing MTA that is rewriting the domain of the From:
    header to a.main.private.
    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Larry Stone at Dec 9, 2010 at 12:05 am

    On 12/8/10 2:01 PM, JRC Groups at joemailgroups at gmail.com wrote:

    Is there a simpler way than Terminal (command line) to edit these files and
    then resave them ? Something along the lines of a text editor. Or do I need
    to use Terminal to do it ?

    In this case, if Terminal is necessary, can you guide on how to take a step
    by step approach to getting it done ? I have never edited a file (specially
    a system file) in Terminal before and don't know how to go about it.
    This is somewhat off-topic for the Mailman list but if you want to do any
    sort of advanced system administration on a Macintosh, you need, IMHO, to be
    familiar with Unix shell commands and related utility. The Mac OS X Terminal
    program just creates a shell process and window where you then execute shell
    commands.

    At a minimum, you need to be familiar with certain basic commands like ls
    (directory) and commands for creating (touch among others), renaming/MoVing
    (mv), and deleting/ReMoving (rm) files and directories (mkdir, mv, and rmdir
    respectively). You also need to be familiar with one of the standard text
    editors (vi or emacs) as well as commands for dealing with file ownership
    (chown) and permissions (chmod).

    --
    Larry Stone
    lstone19 at stonejongleux.com
    http://www.stonejongleux.com/
  • JRC Groups at Dec 15, 2010 at 6:30 am
    Larry,


    Thank you for your help and suggestions. I have researched your
    recommendations and am now learning about the specific commands you
    suggested.


    Joe

    On 12/8/10 4:05 PM, "Larry Stone" wrote:
    On 12/8/10 2:01 PM, JRC Groups at joemailgroups at gmail.com wrote:

    Is there a simpler way than Terminal (command line) to edit these files and
    then resave them ? Something along the lines of a text editor. Or do I need
    to use Terminal to do it ?

    In this case, if Terminal is necessary, can you guide on how to take a step
    by step approach to getting it done ? I have never edited a file (specially
    a system file) in Terminal before and don't know how to go about it.
    This is somewhat off-topic for the Mailman list but if you want to do any
    sort of advanced system administration on a Macintosh, you need, IMHO, to be
    familiar with Unix shell commands and related utility. The Mac OS X Terminal
    program just creates a shell process and window where you then execute shell
    commands.

    At a minimum, you need to be familiar with certain basic commands like ls
    (directory) and commands for creating (touch among others), renaming/MoVing
    (mv), and deleting/ReMoving (rm) files and directories (mkdir, mv, and rmdir
    respectively). You also need to be familiar with one of the standard text
    editors (vi or emacs) as well as commands for dealing with file ownership
    (chown) and permissions (chmod).
  • JRC Groups at Dec 6, 2010 at 6:26 am

    On 12/5/10 8:36 AM, "Mark Sapiro" wrote:


    If you are using Apple's package, this is really a question for Apple,
    but we can try to help. If the MTA is Postfix, post the output from
    "sudo postconf -n". Also include a listing of the contents of
    Mailman's mm_cfg.py.
    Output from the "sudo postconf -n" command:


    alias_maps = hash:/etc/aliases,hash:/var/mailman/data/aliases
    biff = no
    command_directory = /usr/sbin
    config_directory = /etc/postfix
    content_filter = smtp-amavis:[127.0.0.1]:10024
    daemon_directory = /usr/libexec/postfix
    debug_peer_level = 2
    enable_server_options = yes
    header_checks = pcre:/etc/postfix/custom_header_checks
    html_directory = /usr/share/doc/postfix/html
    inet_interfaces = all
    mail_owner = _postfix
    mailbox_size_limit = 0
    mailbox_transport = dovecot
    mailq_path = /usr/bin/mailq
    manpage_directory = /usr/share/man
    message_size_limit = 0
    mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
    mydomain = main.private
    mydomain_fallback = localhost
    mynetworks = 127.0.0.0/8,192.168.2.0/24
    newaliases_path = /usr/bin/newaliases
    owner_request_special = no
    queue_directory = /private/var/spool/postfix
    readme_directory = /usr/share/doc/postfix
    recipient_delimiter = +
    relayhost =
    sample_directory = /usr/share/doc/postfix/examples
    sendmail_path = /usr/sbin/sendmail
    setgid_group = _postdrop
    smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated
    permit
    smtpd_enforce_tls = no
    smtpd_helo_required = yes
    smtpd_helo_restrictions = reject_invalid_helo_hostname
    reject_non_fqdn_helo_hostname
    smtpd_pw_server_security_options = login,cram-md5
    smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks
    reject_unauth_destination check_policy_service unix:private/policy permit
    smtpd_sasl_auth_enable = yes
    smtpd_tls_CAfile =
    /etc/certificates/dentserv.main.private.F73718CA2507E8DBBF5C75FF9DF888A6F3E0
    2A28.chain.pem
    smtpd_tls_cert_file =
    /etc/certificates/dentserv.main.private.F73718CA2507E8DBBF5C75FF9DF888A6F3E0
    2A28.cert.pem
    smtpd_tls_exclude_ciphers = SSLv2, aNULL, ADH, eNULL
    smtpd_tls_key_file =
    /etc/certificates/dentserv.main.private.F73718CA2507E8DBBF5C75FF9DF888A6F3E0
    2A28.key.pem
    smtpd_tls_loglevel = 0
    smtpd_use_pw_server = yes
    smtpd_use_tls = no
    tls_random_source = dev:/dev/urandom
    unknown_local_recipient_reject_code = 550
    virtual_alias_domains = $virtual_alias_maps
    hash:/etc/postfix/virtual_domains
    virtual_alias_maps = hash:/etc/postfix/virtual_users

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedDec 5, '10 at 5:04a
activeMay 10, '11 at 6:07a
posts42
users4
websitelist.org

People

Translate

site design / logo © 2022 Grokbase