Mailman list sends but doesn't receive mail.
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@3domain.comTechnical 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@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
JRC Groups wrote:
This is the text returned with this Delivery Failure Notifications:
Delivery to the following recipient failed permanently:
list@3domain.comTechnical 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@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@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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 12/5/10 8:36 AM, "Mark Sapiro" <mark@msapiro.net> wrote:
JRC Groups wrote:
This is the text returned with this Delivery Failure Notifications:
Delivery to the following recipient failed permanently:
list@3domain.comTechnical 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@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@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
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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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" <mark@msapiro.net> 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
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@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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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" <mark@msapiro.net> 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@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
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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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" <mark@msapiro.net> 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.
On Wed, 08 Dec 2010 16:45:16 -0800, JRC Groups <joemailgroups@gmail.com>
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
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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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
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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 12/8/10 5:26 PM, "Mark Sapiro" <mark@msapiro.net> 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@3wforum.com>: Recipient address rejected: Service is unavailable; from=<joemailgroups@gmail.com> to=<Implants-request@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.
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@3wforum.com>: Recipient address rejected: Service is unavailable; from=<joemailgroups@gmail.com> to=<Implants-request@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?messageID=10151235>.
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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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" <mark@msapiro.net> 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@3wforum.com>: Recipient address rejected: Service is unavailable; from=<joemailgroups@gmail.com> to=<Implants-request@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?messageID=10151235>.
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.
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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi, Mark.
On 12/10/10 8:33 AM, "Mark Sapiro" <mark@msapiro.net> 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
JRC Groups wrote:
On 12/10/10 8:33 AM, "Mark Sapiro" <mark@msapiro.net> 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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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
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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi, Mark.
On 12/12/10 8:59 AM, "Mark Sapiro" <mark@msapiro.net> 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
JRC Groups wrote:
On 12/12/10 8:59 AM, "Mark Sapiro" <mark@msapiro.net> 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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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" <mark@msapiro.net> wrote:
JRC Groups wrote:
On 12/12/10 8:59 AM, "Mark Sapiro" <mark@msapiro.net> 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.
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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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" <mark@msapiro.net> 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
On 4/18/11 1:53 AM, JRC Groups at joemailgroups@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@stonejongleux.com http://www.stonejongleux.com/
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" <lstone19@stonejongleux.com> wrote:
On 4/18/11 1:53 AM, JRC Groups at joemailgroups@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.
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" <mark@msapiro.net> 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.
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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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" <mark@msapiro.net> 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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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@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@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@a.main.private. Thanks!
Passwords for member1@gmail.com:
List Password // URL
list1@domain.com coceopxi http://www.domain.com/mailman/options/list1/member1%40gmail.com
On 4/18/11 10:54 AM, "Mark Sapiro" <mark@msapiro.net> 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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
JRC Groups wrote:
I have received some mail from Mailman that looks as follows:
From: mailman-owner@a.main.private (sent by mailman-bounces@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@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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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" <mark@msapiro.net> wrote:
JRC Groups wrote:
I have received some mail from Mailman that looks as follows:
From: mailman-owner@a.main.private (sent by mailman-bounces@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@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.
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@a.main.private (sent by mailman-bounces@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@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@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@domain where domain is the host_name attribute of the 'mailman' list.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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" <mark@msapiro.net> 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@a.main.private (sent by mailman-bounces@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@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@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@domain where domain is the host_name attribute of the 'mailman' list.
JRC Groups wrote:
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.
See "cron/mailpasswds --help".
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark,
Any ideas as to why this is happening and how to fix it ?
On 5/8/11 8:27 AM, "Mark Sapiro" <mark@msapiro.net> wrote:
Since the envelope sender (or Sender: header) is mailman-bounces@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
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" <mark@msapiro.net> wrote:
Since the envelope sender (or Sender: header) is mailman-bounces@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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 12/8/10 2:01 PM, JRC Groups at joemailgroups@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@stonejongleux.com http://www.stonejongleux.com/
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" <lstone19@stonejongleux.com> wrote:
On 12/8/10 2:01 PM, JRC Groups at joemailgroups@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).
On 12/5/10 8:36 AM, "Mark Sapiro" <mark@msapiro.net> 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
participants (4)
-
Chris Tandiono -
JRC Groups -
Larry Stone -
Mark Sapiro