no mail delivery to site list
Unlike Francesco's problem, my site list does exist (it was given as part of the pre-installed Mailman on my Linux VPS from Network Solutions), and after some trouble I've gotten it to put its configuration pages at the right URL (lists.mydomain), to list me as the owner (instead of noreply@networksolutions.com), and to let me in with a password of my own devising.
But mail doesn't get delivered to it. Mail to mailman@mydomain lands in my catchall mailbox, where all the spam for unknown users goes.
This doesn't happen to my regular mailing lists, which I created on this server using Plesk (which came preinstalled). (These lists existed on my previous server but were managed by different mailing list software.) Only after setting up my regular lists did I find there was supposed to be a "site list" called mailman@mydomain.
I realize this may conceivably be a Postfix issue, or even a Plesk issue, but I thought someone here might be able to guess the answer. My own guess, as far as it goes, is that the problem has something to do with this server being set up to host multiple virtual domains, and with the site list having been created by Network Solutions before I installed my own virtual domain.
I've thought of deleting the existing site list and recreating it through Plesk, since I know that lists created through Plesk work. I'm reluctant to try this since it would create an interval when the site list doesn't exist at all, and I've read that Mailman refuses to operate at all under those conditions. Anyway I would rather know how to find whatever is misconfigured about the present site list.
My VPS is running GNU/Linux kernel 2.6.18-028stab101.1 on some kind of x86_64 (data reported by uname). From the generic hardware name and the fact that they call it a VPS I suppose this is a virtual machine running on some more powerful kind of hardware.
Thanks,
-- Larry Kuenning larry@qhpress.org
A few minutes ago I wrote:
I think I've just found the problem. Doing a dumpdb on the site list and on one of my regular lists, I find that 'host_name' is different.
So probably all I need to know is how to get the correct name (the virtual domain name) into the list database where Mailman will find it.
I'm still new to Mailman and Python, though I've done various other sorts of Unix programming (including writing my own software for the previous incarnation of my mailing lists, using shellscripts).
-- Larry Kuenning larry@qhpress.org
Oops, another self-reply:
I think I've just found the problem. Doing a dumpdb on the site list and on one of my regular lists, I find that 'host_name' is different.
Wrong. I was looking at an old dumpdb output file, from before I ran fix_url to get the configuration pages to show up. On rerunning dumpdb I find that host_name has been correct for a day or two now and the problem must be somewhere else.
-- Larry Kuenning larry@qhpress.org
On 05/08/2013 08:50 AM, Larry Kuenning wrote:
My best SWAG (sophisticated wild-ass guess) is you have Postfix/Mailman integration and the necessary aliases and virtual mappings were generated for each list as you created it, but since the 'mailman' list pre-existed, it doesn't have them.
If this is the case, i.e. if you look at Mailman's data/aliases (and data/virtual-mailman if there is one) files and see entries for all but the mailman list, running Mailmamn's bin/genaliases should fix it.
If the issue is something else, we'd need to start by seeing the output of 'postconf -n' and the contents of mm_cfg.py.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 5/8/2013 7:06 PM, Mark Sapiro wrote:
Sounds plausible. Unfortunately I don't know enough about either Postfix or Mailman yet to have a clear idea how to explore the way they might be integrated on this system.
By "data/" I suppose you mean (on my system) /var/lib/mailman/data/. /var/lib/mailman/ contains four subdirectories: archives, data, lists, and spam. But in this data directory there's nothing but some heldmsg-[listname]-[n].pck files and a symbolic link to /etc/mailman/sitelist.cfg. Nothing called aliases or virtual-mailman.
sitelist.cfg sounds like it might be relevant, but grepping it for blank lines not beginning with # I don't see any plausible leads, just a bunch of list management options like "advertised = 0".
If the issue is something else, we'd need to start by seeing the output of 'postconf -n' and the contents of mm_cfg.py.
OK, here they are:
-----<begin output of postconf -n>---- alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases, hash:/var/spool/postfix/plesk/aliases allow_mail_to_commands = alias, forward allow_mail_to_files = alias, forward command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix debug_peer_level = 2 disable_vrfy_command = yes html_directory = no inet_interfaces = all inet_protocols = all mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man message_size_limit = 10240000 mydestination = localhost.$mydomain, localhost, localhost.localdomain myhostname = 0373951.netsolvps.com mynetworks = 127.0.0.0/8 [::1]/128 207.204.52.48/32 newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES sample_directory = /usr/share/doc/postfix-2.3.3/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtp_send_xforward_command = yes smtp_tls_security_level = may smtp_use_tls = no smtpd_authorized_xforward_hosts = 127.0.0.0/8 [::1]/128 smtpd_client_restrictions = smtpd_proxy_timeout = 3600s smtpd_recipient_restrictions = permit_mynetworks, check_client_access pcre:/var/spool/postfix/plesk/no_relay.re, permit_sasl_authenticated, reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sender_restrictions = check_sender_access hash:/var/spool/postfix/plesk/blacklists, permit_sasl_authenticated, check_client_access pcre:/var/spool/postfix/plesk/non_auth.re smtpd_timeout = 3600s smtpd_tls_cert_file = /etc/postfix/postfix_default.pem smtpd_tls_key_file = $smtpd_tls_cert_file smtpd_tls_security_level = may smtpd_use_tls = yes transport_maps = hash:/var/spool/postfix/plesk/transport unknown_local_recipient_reject_code = 550 virtual_alias_maps = $virtual_maps, hash:/var/spool/postfix/plesk/virtual virtual_gid_maps = static:31 virtual_mailbox_base = /var/qmail/mailnames virtual_mailbox_domains = $virtual_mailbox_maps, hash:/var/spool/postfix/plesk/virtual_domains virtual_mailbox_maps = hash:/var/spool/postfix/plesk/vmailbox virtual_transport = plesk_virtual virtual_uid_maps = static:110 -----<end output of postconf -n>-----
So much for postconf -n, which I guess tells us where to look for the relevant aliases. Unfortunately I don't know enough about Postfix yet to be familiar with digging through these compiled database files and changing their values.
Now here's mm_cfg.py, which seems to contain a lot of commentary by at least two different authors (the second one says he's about to "override shipped defaults"), with one line at the very end that's really specific to my setup. (Some of the lines here may be wrapped sooner than they should be, unless that's just the way Thunderbird displays them to me.)
-----<begin mm_cfg.py>----- # -*- 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., 59 Temple Place - Suite 330, Boston, MA 02111-1307, 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 * import pwd, grp
################################################## # Put YOUR site-specific settings below this line.
############################################################## # Here's where we override shipped defaults with settings # # suitable for the RPM package. # MAILMAN_UID = pwd.getpwnam('mailman')[2] MAILMAN_GID = grp.getgrnam('mailman')[2]
############################################################## # Set URL and email domain names # # # Mailman needs to know about (at least) two fully-qualified domain # names (fqdn) # # 1) the hostname used in your urls (DEFAULT_URL_HOST) # 2) the hostname used in email addresses for your domain (DEFAULT_EMAIL_HOST) # # For example, if people visit your Mailman system with # "http://www.dom.ain/mailman" then your url fqdn is "www.dom.ain", # and if people send mail to your system via "yourlist@dom.ain" then # your email fqdn is "dom.ain". DEFAULT_URL_HOST controls the former, # and DEFAULT_EMAIL_HOST controls the latter. Mailman also needs to # know how to map from one to the other (this is especially important # if you're running with virtual domains). You use # "add_virtualhost(urlfqdn, emailfqdn)" to add new mappings.
# Default to using the FQDN of machine mailman is running on. # If this is not correct for your installation delete the following 5 # lines that acquire the FQDN and manually edit the hosts instead.
from socket import * try: fqdn = getfqdn() except: fqdn = 'mm_cfg_has_unknown_host_domains'
DEFAULT_URL_HOST = fqdn DEFAULT_EMAIL_HOST = fqdn
# Because we've overriden the virtual hosts above add_virtualhost # MUST be called after they have been defined.
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
############################################################## # Put YOUR site-specific configuration below, in mm_cfg.py . # # See Defaults.py for explanations of the values. #
# Note - if you're looking for something that is imported from mm_cfg, but you # didn't find it above, it's probably in Defaults.py. add_virtualhost('lists.qhpress.org', 'qhpress.org') -----<end mm_cfg.py>-----
(This is me again.) That last line was different until I changed it just now; it was: add_virtualhost('lists.qhpress.org') which looks to me like it might have been the problem.
But maybe it wasn't. After changing it I've tried posting to the site list again, with no luck. Repeated this after reloading Mailman, and yet again after stopping and restarting Mailman -- still no luck. (At least I didn't break the other lists in the process!) Does this file have to be compiled before it works? I see a .pyc and a .pyo next to it in the ~mailman/Mailman directory. I don't know anything yet about compiling Python files.
If I had landed in this system after careful planning, probably I would have learned more about Postfix and Mailman before starting to use it. Unfortunately there was a disaster on my previous host which caused a near-total e-mail delivery failure for about a week, and this prompted me to jump into a new hosting solution as fast as I could. Hence this help-what-do-I-do-now approach to learning how to use it.
Thanks for taking a look at this stuff!
-- Larry Kuenning larry@qhpress.org
On 05/08/2013 05:53 PM, Larry Kuenning wrote:
What's in the aliases, transport and virtual files in /var/spool/postfix/plesk/?
Also, what's in /etc/postfix/master.cf?
Aside, please see the FAQs at <http://wiki.list.org/x/tIA9> and <http://wiki.list.org/x/OIDD>.
Actually,
add_virtualhost('lists.qhpress.org', 'qhpress.org')
and
add_virtualhost('lists.qhpress.org')
are equivalent because if the second argument is omitted, it is constricted by stripping the initial part up through the first dot from the first argument.
Python will detect that the .py is newer than the .py[co] and recompile automatically on import.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 5/9/2013 12:55 PM, Mark Sapiro wrote:
Well, that's what they used to call the $64000 question. These are all Berkeley Database .db files, which I've never worked with before. If I knew how to read these files (and understand their content, and edit them where necessary) I might be able to solve the whole problem from there.
Apparently this server already has a package called db4-utils installed. I don't know whether these are enough. It's not clear whether there are normal man pages for them.
Also, what's in /etc/postfix/master.cf?
# # Postfix master process configuration file. For details on the format # of the file, see the master(5) manual page (command: "man 5 master"). # # ========================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # ========================================================================== smtp inet n - n - - smtpd -o smtpd_proxy_filter=127.0.0.1:10025 #submission inet n - n - - smtpd # -o smtpd_enforce_tls=yes # -o smtpd_sasl_auth_enable=yes # -o smtpd_client_restrictions=permit_sasl_authenticated,reject #smtps inet n - n - - smtpd # -o smtpd_tls_wrappermode=yes # -o smtpd_sasl_auth_enable=yes # -o smtpd_client_restrictions=permit_sasl_authenticated,reject #628 inet n - n - - qmqpd pickup fifo n - n 60 1 pickup -o content_filter=smtp:127.0.0.1:10027 cleanup unix n - n - 0 cleanup qmgr fifo n - n 1 1 qmgr #qmgr fifo n - n 300 1 oqmgr tlsmgr unix - - n 1000? 1 tlsmgr rewrite unix - - n - - trivial-rewrite bounce unix - - n - 0 bounce defer unix - - n - 0 bounce trace unix - - n - 0 bounce verify unix - - n - 1 verify flush unix n - n 1000? 0 flush proxymap unix - - n - - proxymap smtp unix - - n - - smtp # When relaying mail as backup MX, disable fallback_relay to avoid MX loops relay unix - - n - - smtp -o fallback_relay= # -o smtp_helo_timeout=5 -o smtp_connect_timeout=5 showq unix n - n - - showq error unix - - n - - error discard unix - - n - - discard local unix - n n - - local virtual unix - n n - - virtual lmtp unix - - n - - lmtp anvil unix - - n - 1 anvil scache unix - - n - 1 scache # # ==================================================================== # Interfaces to non-Postfix software. Be sure to examine the manual # pages of the non-Postfix software to find out what options it wants. # # Many of the following services use the Postfix pipe(8) delivery # agent. See the pipe(8) man page for information about ${recipient} # and other message envelope options. # ==================================================================== # # maildrop. See the Postfix MAILDROP_README file for details. # Also specify in main.cf: maildrop_destination_recipient_limit=1 # maildrop unix - n n - - pipe flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient} # # The Cyrus deliver program has changed incompatibly, multiple times. # old-cyrus unix - n n - - pipe flags=R user=cyrus argv=/usr/lib/cyrus-imapd/deliver -e -m ${extension} ${user} # Cyrus 2.1.5 (Amos Gouaux) # Also specify in main.cf: cyrus_destination_recipient_limit=1 cyrus unix - n n - - pipe user=cyrus argv=/usr/lib/cyrus-imapd/deliver -e -r ${sender} -m ${extension} ${user} # # See the Postfix UUCP_README file for configuration details. # uucp unix - n n - - pipe flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient) # # Other external delivery methods. # ifmail unix - n n - - pipe flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient) bsmtp unix - n n - - pipe flags=Fq. user=foo argv=/usr/local/sbin/bsmtp -f $sender $nexthop $recipient
plesk_virtual unix - n n - - pipe flags=DORhu user=popuser:popuser argv=/usr/lib64/plesk-9.0/postfix-local -f ${sender} -d ${recipient} -p /var/qmail/mailnames mailman unix - n n - - pipe flags=R user=mailman:mailman argv=/usr/lib64/plesk-9.0/postfix-mailman ${nexthop} ${user} ${recipient} 127.0.0.1:10025 inet n n n - - spawn user=mhandlers-user argv=/usr/lib64/plesk-9.0/postfix-queue 127.0.0.1 10027 before-queue 127.0.0.1:10026 inet n - n - - smtpd -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions= -o receive_override_options=no_unknown_recipient_checks 127.0.0.1:10027 inet n n n - - spawn user=mhandlers-user argv=/usr/lib64/plesk-9.0/postfix-queue 127.0.0.1 10026 before-remote plesk_saslauthd unix y y n - 1 plesk_saslauthd status=5 listen=6 dbpath=/var/spool/postfix/plesk/passwd.db smtps inet n - n - - smtpd -o smtpd_proxy_filter=127.0.0.1:10025 -o smtpd_tls_wrappermode=yes
[ end of /etc/postfix/master.cf ]
Aside, please see the FAQs at <http://wiki.list.org/x/tIA9> and <http://wiki.list.org/x/OIDD>.
Yes, I saw these; that's why I wrote in my first post, "I realize this may conceivably be a Postfix issue, or even a Plesk issue, but I thought someone here might be able to guess the answer."
I would most like to find out how to get into those .db files. Failing that, I wonder if it would do any good to delete the site list from the command line and recreate it using Plesk (which seems to produce usable lists on this system). But can this be done safely? Doesn't it say somewhere that Mailman won't run if the site list doesn't exist? (It would have to go out of existence briefly in order to recreate it.)
-- Larry Kuenning larry@qhpress.org
On 05/09/2013 05:59 PM, Larry Kuenning wrote:
There should be both an aliases (plain text) and an aliases.db (database) and likewise for virtual(.db) and transport(.db). The .db files are made from the plain text files by the Postfix commands postalias in the case of aliases and postmap in the case of the others.
If those plain text files aren't in the same directory, they are somewhere, but I can't imagine why they're not there. You might try locate or find to find them.
OK, so Plesk has it's own transport for Mailman, possibly related to the (hated by me) postfix_to_mailman.py <http://wiki.list.org/x/EYDt>
So we need to see the aliases, virtual and transport files in order to know exactly what addresses are delivered via the 'mailman' transport and why the 'mailman' list addresses aren't among them.
Or, maybe (thinking diabolically here) Plesk's postfix-mailman process just discards that mail.
I would most like to find out how to get into those .db files.
You shouldn't have to. The plain text source must be somewhere.
You could do that and as long as my diabolical conjecture is not in play, it should work. It is safe as long as it doesn't take forever and isn't done when cron/mailpasswds is running as that 'sends from' the site list and requires it.
The other process that requires the site list is mailmanctl which refuses to start Mailman if there's no site list, but it won't notice if the list disappears after the qrunners are running.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/09/2013 06:43 PM, Mark Sapiro wrote:
I would most like to find out how to get into those .db files.
You shouldn't have to. The plain text source must be somewhere.
Possibly I should stay out of this; I haven't carefully read the full thread. But there is the detail of converting those plain text sources to the .db files. At least some files--I'm not sure on the mailman side--need to be converted with a manual step:
http://www.postfix.org/DB_README.html
It looks like the relevant commands are postalias (which I've never used, at least by that name) and postmap.
David Benfell / benfell@parts-unknown.org Please see https://parts-unknown.org/node/2 for GnuPG information (or the attachment you don't understand) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRjFTRAAoJELJhbl/uPb4SS/cP/2GJkJFOeSP4CvEb73hlfql4 nFmJVpuuNvK9XZ5ySIZjVVLYb/fmmaObXStFv9eFU23x2in5lVCkpHjnijEGU2AK Wl2qIff/XqIr+WXxwunWF4dgl4hF5mHQL0fby4FFQgYvs88BRjUSQMBdKXm/gGxP tif2AnCUvxez5qRQ+AAgYIcMbbSxPjWdk+7P9t9geFswyRDOCLEMOHb/Ft/zJcee aAFohkkY+CBGqNdZLqbOwMjIsWqCSlu+W5OoJLfdVD1Qzu91F5YcgQ0M2HGcPhw3 M8w6435P+yZPwtBb7SyUzMtKzNwcm0WAjn/1ds9vPHayu/K/szIpl5SQ0XWMXWiW X+Tqc1rxIetQ7+zFYJi2rzmrsZw8OEroOhKqF9M+S99qEeu61bH6ubWcxZr09Bjn gdV4wkQxmHOd1YMa5eQQkR6b+LYajUFqHe3SyEsq0Doa1I+Z3gkFsrd4Z1zcq/mO cDo03Uf5VQthtPtUMITmgbP/UPy6KvoQysGez/r5NWlke7eGrwZWnVvXmk1JNjbW PtpraTkdrwhXqvls3+owy2i2eNqqYloU5ja4GuOJxVYyXjHXPPsJ67uCoyBIqcrX 2mMhBR+EZ7Uyve1T3UyhsR+A730MTqQqmw8GJtgV1bXqQmg+OMrxnWIDPu3+q5Gw S+5yueF3rnvckYONWXr0 =/2zm -----END PGP SIGNATURE-----
On 5/9/2013 10:00 PM, David Benfell wrote:
It looks like the relevant commands are postalias (which I've never used, at least by that name) and postmap.
Thanks! Actually I ran across postalias and postmap a couple of hours before I saw your post, but it's nice to have this confirmed by someone else. (Actually Mark Sapiro also mentioned them, but I think I saw yours first.)
Both of these programs can, I think, be used to create missing text files; the difference seems to be that postalias inserts the colons needed for alias files and postmap just uses whitespace. To create the text file aliases from the db file aliases.db, the command is:
postalias -s aliases > aliases
-- where the extension .db is not mentioned on either side of the redirect but is assumed by postalias on the left side. If you explicitly mention aliases.db then postalias fails and complains that aliases.db.db is missing. The same syntax works for postmap.
Both programs have reasonable man pages.
More on the results in an upcoming reply to Mark Sapiro.
-- Larry Kuenning larry@qhpress.org
On 5/9/2013 9:43 PM, Mark Sapiro wrote:
They're not there, or anywhere else. Or rather they weren't there until I created them using postalias as pointed out by David Benfell.
I'm guessing this means that Plesk creates the .db files directly without using text files. Ugh. Now I wonder, if I use postalias to update the .db files after editing my newly created text files, will Plesk eventually overwrite my work, say the next time I create a mailbox or an e-mail alias? I guess the way to find out is to try.
The aliases file tells us nothing to the point (except that it contains one example of delivery to a program, which I had tried unsuccessfully to do in /etc/aliases -- now I know where to try again).
The transport file shows that Plesk's transport for Mailman is being applied to my successfully working lists but not to the site list:
# grep test transport test@qhpress.org mailman:post test-admin@qhpress.org mailman:admin test-bounces@qhpress.org mailman:bounces test-leave@qhpress.org mailman:leave test-owner@qhpress.org mailman:owner test-request@qhpress.org mailman:request test-unsubscribe@qhpress.org mailman:unsubscribe test-confirm@qhpress.org mailman:confirm test-join@qhpress.org mailman:join test-subscribe@qhpress.org mailman:subscribe # grep 'mailman[@-]' transport [no output]
The virtual file shows virtually the same thing:
# grep test virtual test@qhpress.org test@qhpress.org test-admin@qhpress.org test-admin@qhpress.org test-bounces@qhpress.org test-bounces@qhpress.org test-leave@qhpress.org test-leave@qhpress.org test-owner@qhpress.org test-owner@qhpress.org test-request@qhpress.org test-request@qhpress.org test-unsubscribe@qhpress.org test-unsubscribe@qhpress.org test-confirm@qhpress.org test-confirm@qhpress.org test-join@qhpress.org test-join@qhpress.org test-subscribe@qhpress.org test-subscribe@qhpress.org # grep mailman virtual mailman-loop@qhpress.org mailman-loop@localhost.localdomain
My current idea is to add "mailman" lines similar to all the "test" lines in transport and virtual and then update transport.db and virtual.db with postmap. (After first making backups of the current forms!) If this creates valid files, will Postfix start using the new versions immediately, or do I need to do something else to draw its attention to the changes?
I see cron/mailpasswds is supposed to run on the first of each month. It wasn't done this month (which was the only opportunity so far). I guess that was because it couldn't use the site list.
-- Larry Kuenning larry@qhpress.org
On 5/10/2013 9:03 AM, I wrote:
I tried this and it works: I can now post to the site list.
After updating transport.db and virtual.db, and before posting, I ran newaliases just in case, with the result that now I don't know whether that step was necessary.
I tried this too, creating a new alias for my catchall box after my first successful post. A second post arrived with no trouble, and examining the .db files with postmap shows they are as they should be. So at any rate Plesk doesn't throw away data it finds in those files that it didn't put there.
Thanks for all your help!
-- Larry Kuenning larry@qhpress.org
On 05/10/2013 07:53 AM, Larry Kuenning wrote:
Per my reply that you hadn't seen yet, no it wasn't. newaliases just updates the .db files for those files in alias_database, i.e. /etc/aliases in your case.
Interesting.
Anyway, I'm glad it's working for you.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 05/10/2013 06:03 AM, Larry Kuenning wrote:
I'm guessing Plesk doesn't create the .db files directly, but rather creates/updates some plain text file and invokes postmap/postalias to create the .db files, but whether and why it hides the text files with a different name or doesn't keep them, I have no idea.
Anyway, if you make changes to the aliases.db, virtual.db and/or transport.db files, Plesk will overwrite them unless it actually uses these files as the starting point when it adds/deletes info for a list.
Trying will tell.
Aliases in /etc/aliases for the 'mailman' list should work, but you also in your case need virtual mappings to map the 'mailman' list addresses in the virtual domain to local addresses.
Actually, the mapings above don't make sense. They map, e.g., the virtual domain address test@qhpress.org to the same address, test@qhpress.org. If this were actually used by Postfix, it would be a loop. Thus, I think qhpress.org must actually be a Postfix local domain.
But, if that is the case, putting the appropriate
mailman: "|/path/to/mailman/mail/mailman post mailman" mailman-admin: "|/path/to/mailman/mail/mailman admin mailman" mailman-bounces: "|/path/to/mailman/mail/mailman bounces mailman" ...
entries in /etc/aliases and reloading Postfix should work, assuming there is a mailman/mail/mailman wrapper and it doesn't result in a group mismatch error <http://wiki.list.org/x/tYA9>.
That should work, and Postfix will use it more or less immediately (it detects the change). However, Plesk may reverse it the next time it makes a change.
I don't think so. I don't think the list address has to work. The list only has to exist. But, check the cron log (maybe /var/log/cron or a rotated older one) to see if there's anything there. Also, it is a good idea to put a MAILTO= with a good address in Mailman's crontab. Without it, cron errors probably get mailed to 'mailman' which in your case doesn't work, and even if it does, the list may not be configured to accept them even though it should be.
I suspect you'll finally end up deleting the 'mailman' list with bin/rmlist and then recreating it with Plesk.
The real question is why a Plesk Mailman doesn't have the site list deliverable in the first place.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 05/08/2013 08:15 AM, Larry Kuenning wrote:
But mail doesn't get delivered to it. Mail to mailman@mydomain lands in my catchall mailbox, where all the spam for unknown users goes.
This is a Postfix issue and it's probably as simple as missing aliases or virtual mappings.
I will comment further in additional replies.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
A few minutes ago I wrote:
I think I've just found the problem. Doing a dumpdb on the site list and on one of my regular lists, I find that 'host_name' is different.
So probably all I need to know is how to get the correct name (the virtual domain name) into the list database where Mailman will find it.
I'm still new to Mailman and Python, though I've done various other sorts of Unix programming (including writing my own software for the previous incarnation of my mailing lists, using shellscripts).
-- Larry Kuenning larry@qhpress.org
Oops, another self-reply:
I think I've just found the problem. Doing a dumpdb on the site list and on one of my regular lists, I find that 'host_name' is different.
Wrong. I was looking at an old dumpdb output file, from before I ran fix_url to get the configuration pages to show up. On rerunning dumpdb I find that host_name has been correct for a day or two now and the problem must be somewhere else.
-- Larry Kuenning larry@qhpress.org
On 05/08/2013 08:50 AM, Larry Kuenning wrote:
My best SWAG (sophisticated wild-ass guess) is you have Postfix/Mailman integration and the necessary aliases and virtual mappings were generated for each list as you created it, but since the 'mailman' list pre-existed, it doesn't have them.
If this is the case, i.e. if you look at Mailman's data/aliases (and data/virtual-mailman if there is one) files and see entries for all but the mailman list, running Mailmamn's bin/genaliases should fix it.
If the issue is something else, we'd need to start by seeing the output of 'postconf -n' and the contents of mm_cfg.py.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 5/8/2013 7:06 PM, Mark Sapiro wrote:
Sounds plausible. Unfortunately I don't know enough about either Postfix or Mailman yet to have a clear idea how to explore the way they might be integrated on this system.
By "data/" I suppose you mean (on my system) /var/lib/mailman/data/. /var/lib/mailman/ contains four subdirectories: archives, data, lists, and spam. But in this data directory there's nothing but some heldmsg-[listname]-[n].pck files and a symbolic link to /etc/mailman/sitelist.cfg. Nothing called aliases or virtual-mailman.
sitelist.cfg sounds like it might be relevant, but grepping it for blank lines not beginning with # I don't see any plausible leads, just a bunch of list management options like "advertised = 0".
If the issue is something else, we'd need to start by seeing the output of 'postconf -n' and the contents of mm_cfg.py.
OK, here they are:
-----<begin output of postconf -n>---- alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases, hash:/var/spool/postfix/plesk/aliases allow_mail_to_commands = alias, forward allow_mail_to_files = alias, forward command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix debug_peer_level = 2 disable_vrfy_command = yes html_directory = no inet_interfaces = all inet_protocols = all mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man message_size_limit = 10240000 mydestination = localhost.$mydomain, localhost, localhost.localdomain myhostname = 0373951.netsolvps.com mynetworks = 127.0.0.0/8 [::1]/128 207.204.52.48/32 newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES sample_directory = /usr/share/doc/postfix-2.3.3/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtp_send_xforward_command = yes smtp_tls_security_level = may smtp_use_tls = no smtpd_authorized_xforward_hosts = 127.0.0.0/8 [::1]/128 smtpd_client_restrictions = smtpd_proxy_timeout = 3600s smtpd_recipient_restrictions = permit_mynetworks, check_client_access pcre:/var/spool/postfix/plesk/no_relay.re, permit_sasl_authenticated, reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sender_restrictions = check_sender_access hash:/var/spool/postfix/plesk/blacklists, permit_sasl_authenticated, check_client_access pcre:/var/spool/postfix/plesk/non_auth.re smtpd_timeout = 3600s smtpd_tls_cert_file = /etc/postfix/postfix_default.pem smtpd_tls_key_file = $smtpd_tls_cert_file smtpd_tls_security_level = may smtpd_use_tls = yes transport_maps = hash:/var/spool/postfix/plesk/transport unknown_local_recipient_reject_code = 550 virtual_alias_maps = $virtual_maps, hash:/var/spool/postfix/plesk/virtual virtual_gid_maps = static:31 virtual_mailbox_base = /var/qmail/mailnames virtual_mailbox_domains = $virtual_mailbox_maps, hash:/var/spool/postfix/plesk/virtual_domains virtual_mailbox_maps = hash:/var/spool/postfix/plesk/vmailbox virtual_transport = plesk_virtual virtual_uid_maps = static:110 -----<end output of postconf -n>-----
So much for postconf -n, which I guess tells us where to look for the relevant aliases. Unfortunately I don't know enough about Postfix yet to be familiar with digging through these compiled database files and changing their values.
Now here's mm_cfg.py, which seems to contain a lot of commentary by at least two different authors (the second one says he's about to "override shipped defaults"), with one line at the very end that's really specific to my setup. (Some of the lines here may be wrapped sooner than they should be, unless that's just the way Thunderbird displays them to me.)
-----<begin mm_cfg.py>----- # -*- 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., 59 Temple Place - Suite 330, Boston, MA 02111-1307, 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 * import pwd, grp
################################################## # Put YOUR site-specific settings below this line.
############################################################## # Here's where we override shipped defaults with settings # # suitable for the RPM package. # MAILMAN_UID = pwd.getpwnam('mailman')[2] MAILMAN_GID = grp.getgrnam('mailman')[2]
############################################################## # Set URL and email domain names # # # Mailman needs to know about (at least) two fully-qualified domain # names (fqdn) # # 1) the hostname used in your urls (DEFAULT_URL_HOST) # 2) the hostname used in email addresses for your domain (DEFAULT_EMAIL_HOST) # # For example, if people visit your Mailman system with # "http://www.dom.ain/mailman" then your url fqdn is "www.dom.ain", # and if people send mail to your system via "yourlist@dom.ain" then # your email fqdn is "dom.ain". DEFAULT_URL_HOST controls the former, # and DEFAULT_EMAIL_HOST controls the latter. Mailman also needs to # know how to map from one to the other (this is especially important # if you're running with virtual domains). You use # "add_virtualhost(urlfqdn, emailfqdn)" to add new mappings.
# Default to using the FQDN of machine mailman is running on. # If this is not correct for your installation delete the following 5 # lines that acquire the FQDN and manually edit the hosts instead.
from socket import * try: fqdn = getfqdn() except: fqdn = 'mm_cfg_has_unknown_host_domains'
DEFAULT_URL_HOST = fqdn DEFAULT_EMAIL_HOST = fqdn
# Because we've overriden the virtual hosts above add_virtualhost # MUST be called after they have been defined.
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
############################################################## # Put YOUR site-specific configuration below, in mm_cfg.py . # # See Defaults.py for explanations of the values. #
# Note - if you're looking for something that is imported from mm_cfg, but you # didn't find it above, it's probably in Defaults.py. add_virtualhost('lists.qhpress.org', 'qhpress.org') -----<end mm_cfg.py>-----
(This is me again.) That last line was different until I changed it just now; it was: add_virtualhost('lists.qhpress.org') which looks to me like it might have been the problem.
But maybe it wasn't. After changing it I've tried posting to the site list again, with no luck. Repeated this after reloading Mailman, and yet again after stopping and restarting Mailman -- still no luck. (At least I didn't break the other lists in the process!) Does this file have to be compiled before it works? I see a .pyc and a .pyo next to it in the ~mailman/Mailman directory. I don't know anything yet about compiling Python files.
If I had landed in this system after careful planning, probably I would have learned more about Postfix and Mailman before starting to use it. Unfortunately there was a disaster on my previous host which caused a near-total e-mail delivery failure for about a week, and this prompted me to jump into a new hosting solution as fast as I could. Hence this help-what-do-I-do-now approach to learning how to use it.
Thanks for taking a look at this stuff!
-- Larry Kuenning larry@qhpress.org
On 05/08/2013 05:53 PM, Larry Kuenning wrote:
What's in the aliases, transport and virtual files in /var/spool/postfix/plesk/?
Also, what's in /etc/postfix/master.cf?
Aside, please see the FAQs at <http://wiki.list.org/x/tIA9> and <http://wiki.list.org/x/OIDD>.
Actually,
add_virtualhost('lists.qhpress.org', 'qhpress.org')
and
add_virtualhost('lists.qhpress.org')
are equivalent because if the second argument is omitted, it is constricted by stripping the initial part up through the first dot from the first argument.
Python will detect that the .py is newer than the .py[co] and recompile automatically on import.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 5/9/2013 12:55 PM, Mark Sapiro wrote:
Well, that's what they used to call the $64000 question. These are all Berkeley Database .db files, which I've never worked with before. If I knew how to read these files (and understand their content, and edit them where necessary) I might be able to solve the whole problem from there.
Apparently this server already has a package called db4-utils installed. I don't know whether these are enough. It's not clear whether there are normal man pages for them.
Also, what's in /etc/postfix/master.cf?
# # Postfix master process configuration file. For details on the format # of the file, see the master(5) manual page (command: "man 5 master"). # # ========================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # ========================================================================== smtp inet n - n - - smtpd -o smtpd_proxy_filter=127.0.0.1:10025 #submission inet n - n - - smtpd # -o smtpd_enforce_tls=yes # -o smtpd_sasl_auth_enable=yes # -o smtpd_client_restrictions=permit_sasl_authenticated,reject #smtps inet n - n - - smtpd # -o smtpd_tls_wrappermode=yes # -o smtpd_sasl_auth_enable=yes # -o smtpd_client_restrictions=permit_sasl_authenticated,reject #628 inet n - n - - qmqpd pickup fifo n - n 60 1 pickup -o content_filter=smtp:127.0.0.1:10027 cleanup unix n - n - 0 cleanup qmgr fifo n - n 1 1 qmgr #qmgr fifo n - n 300 1 oqmgr tlsmgr unix - - n 1000? 1 tlsmgr rewrite unix - - n - - trivial-rewrite bounce unix - - n - 0 bounce defer unix - - n - 0 bounce trace unix - - n - 0 bounce verify unix - - n - 1 verify flush unix n - n 1000? 0 flush proxymap unix - - n - - proxymap smtp unix - - n - - smtp # When relaying mail as backup MX, disable fallback_relay to avoid MX loops relay unix - - n - - smtp -o fallback_relay= # -o smtp_helo_timeout=5 -o smtp_connect_timeout=5 showq unix n - n - - showq error unix - - n - - error discard unix - - n - - discard local unix - n n - - local virtual unix - n n - - virtual lmtp unix - - n - - lmtp anvil unix - - n - 1 anvil scache unix - - n - 1 scache # # ==================================================================== # Interfaces to non-Postfix software. Be sure to examine the manual # pages of the non-Postfix software to find out what options it wants. # # Many of the following services use the Postfix pipe(8) delivery # agent. See the pipe(8) man page for information about ${recipient} # and other message envelope options. # ==================================================================== # # maildrop. See the Postfix MAILDROP_README file for details. # Also specify in main.cf: maildrop_destination_recipient_limit=1 # maildrop unix - n n - - pipe flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient} # # The Cyrus deliver program has changed incompatibly, multiple times. # old-cyrus unix - n n - - pipe flags=R user=cyrus argv=/usr/lib/cyrus-imapd/deliver -e -m ${extension} ${user} # Cyrus 2.1.5 (Amos Gouaux) # Also specify in main.cf: cyrus_destination_recipient_limit=1 cyrus unix - n n - - pipe user=cyrus argv=/usr/lib/cyrus-imapd/deliver -e -r ${sender} -m ${extension} ${user} # # See the Postfix UUCP_README file for configuration details. # uucp unix - n n - - pipe flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient) # # Other external delivery methods. # ifmail unix - n n - - pipe flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient) bsmtp unix - n n - - pipe flags=Fq. user=foo argv=/usr/local/sbin/bsmtp -f $sender $nexthop $recipient
plesk_virtual unix - n n - - pipe flags=DORhu user=popuser:popuser argv=/usr/lib64/plesk-9.0/postfix-local -f ${sender} -d ${recipient} -p /var/qmail/mailnames mailman unix - n n - - pipe flags=R user=mailman:mailman argv=/usr/lib64/plesk-9.0/postfix-mailman ${nexthop} ${user} ${recipient} 127.0.0.1:10025 inet n n n - - spawn user=mhandlers-user argv=/usr/lib64/plesk-9.0/postfix-queue 127.0.0.1 10027 before-queue 127.0.0.1:10026 inet n - n - - smtpd -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions= -o receive_override_options=no_unknown_recipient_checks 127.0.0.1:10027 inet n n n - - spawn user=mhandlers-user argv=/usr/lib64/plesk-9.0/postfix-queue 127.0.0.1 10026 before-remote plesk_saslauthd unix y y n - 1 plesk_saslauthd status=5 listen=6 dbpath=/var/spool/postfix/plesk/passwd.db smtps inet n - n - - smtpd -o smtpd_proxy_filter=127.0.0.1:10025 -o smtpd_tls_wrappermode=yes
[ end of /etc/postfix/master.cf ]
Aside, please see the FAQs at <http://wiki.list.org/x/tIA9> and <http://wiki.list.org/x/OIDD>.
Yes, I saw these; that's why I wrote in my first post, "I realize this may conceivably be a Postfix issue, or even a Plesk issue, but I thought someone here might be able to guess the answer."
I would most like to find out how to get into those .db files. Failing that, I wonder if it would do any good to delete the site list from the command line and recreate it using Plesk (which seems to produce usable lists on this system). But can this be done safely? Doesn't it say somewhere that Mailman won't run if the site list doesn't exist? (It would have to go out of existence briefly in order to recreate it.)
-- Larry Kuenning larry@qhpress.org
On 05/09/2013 05:59 PM, Larry Kuenning wrote:
There should be both an aliases (plain text) and an aliases.db (database) and likewise for virtual(.db) and transport(.db). The .db files are made from the plain text files by the Postfix commands postalias in the case of aliases and postmap in the case of the others.
If those plain text files aren't in the same directory, they are somewhere, but I can't imagine why they're not there. You might try locate or find to find them.
OK, so Plesk has it's own transport for Mailman, possibly related to the (hated by me) postfix_to_mailman.py <http://wiki.list.org/x/EYDt>
So we need to see the aliases, virtual and transport files in order to know exactly what addresses are delivered via the 'mailman' transport and why the 'mailman' list addresses aren't among them.
Or, maybe (thinking diabolically here) Plesk's postfix-mailman process just discards that mail.
I would most like to find out how to get into those .db files.
You shouldn't have to. The plain text source must be somewhere.
You could do that and as long as my diabolical conjecture is not in play, it should work. It is safe as long as it doesn't take forever and isn't done when cron/mailpasswds is running as that 'sends from' the site list and requires it.
The other process that requires the site list is mailmanctl which refuses to start Mailman if there's no site list, but it won't notice if the list disappears after the qrunners are running.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/09/2013 06:43 PM, Mark Sapiro wrote:
I would most like to find out how to get into those .db files.
You shouldn't have to. The plain text source must be somewhere.
Possibly I should stay out of this; I haven't carefully read the full thread. But there is the detail of converting those plain text sources to the .db files. At least some files--I'm not sure on the mailman side--need to be converted with a manual step:
http://www.postfix.org/DB_README.html
It looks like the relevant commands are postalias (which I've never used, at least by that name) and postmap.
David Benfell / benfell@parts-unknown.org Please see https://parts-unknown.org/node/2 for GnuPG information (or the attachment you don't understand) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRjFTRAAoJELJhbl/uPb4SS/cP/2GJkJFOeSP4CvEb73hlfql4 nFmJVpuuNvK9XZ5ySIZjVVLYb/fmmaObXStFv9eFU23x2in5lVCkpHjnijEGU2AK Wl2qIff/XqIr+WXxwunWF4dgl4hF5mHQL0fby4FFQgYvs88BRjUSQMBdKXm/gGxP tif2AnCUvxez5qRQ+AAgYIcMbbSxPjWdk+7P9t9geFswyRDOCLEMOHb/Ft/zJcee aAFohkkY+CBGqNdZLqbOwMjIsWqCSlu+W5OoJLfdVD1Qzu91F5YcgQ0M2HGcPhw3 M8w6435P+yZPwtBb7SyUzMtKzNwcm0WAjn/1ds9vPHayu/K/szIpl5SQ0XWMXWiW X+Tqc1rxIetQ7+zFYJi2rzmrsZw8OEroOhKqF9M+S99qEeu61bH6ubWcxZr09Bjn gdV4wkQxmHOd1YMa5eQQkR6b+LYajUFqHe3SyEsq0Doa1I+Z3gkFsrd4Z1zcq/mO cDo03Uf5VQthtPtUMITmgbP/UPy6KvoQysGez/r5NWlke7eGrwZWnVvXmk1JNjbW PtpraTkdrwhXqvls3+owy2i2eNqqYloU5ja4GuOJxVYyXjHXPPsJ67uCoyBIqcrX 2mMhBR+EZ7Uyve1T3UyhsR+A730MTqQqmw8GJtgV1bXqQmg+OMrxnWIDPu3+q5Gw S+5yueF3rnvckYONWXr0 =/2zm -----END PGP SIGNATURE-----
On 5/9/2013 10:00 PM, David Benfell wrote:
It looks like the relevant commands are postalias (which I've never used, at least by that name) and postmap.
Thanks! Actually I ran across postalias and postmap a couple of hours before I saw your post, but it's nice to have this confirmed by someone else. (Actually Mark Sapiro also mentioned them, but I think I saw yours first.)
Both of these programs can, I think, be used to create missing text files; the difference seems to be that postalias inserts the colons needed for alias files and postmap just uses whitespace. To create the text file aliases from the db file aliases.db, the command is:
postalias -s aliases > aliases
-- where the extension .db is not mentioned on either side of the redirect but is assumed by postalias on the left side. If you explicitly mention aliases.db then postalias fails and complains that aliases.db.db is missing. The same syntax works for postmap.
Both programs have reasonable man pages.
More on the results in an upcoming reply to Mark Sapiro.
-- Larry Kuenning larry@qhpress.org
On 5/9/2013 9:43 PM, Mark Sapiro wrote:
They're not there, or anywhere else. Or rather they weren't there until I created them using postalias as pointed out by David Benfell.
I'm guessing this means that Plesk creates the .db files directly without using text files. Ugh. Now I wonder, if I use postalias to update the .db files after editing my newly created text files, will Plesk eventually overwrite my work, say the next time I create a mailbox or an e-mail alias? I guess the way to find out is to try.
The aliases file tells us nothing to the point (except that it contains one example of delivery to a program, which I had tried unsuccessfully to do in /etc/aliases -- now I know where to try again).
The transport file shows that Plesk's transport for Mailman is being applied to my successfully working lists but not to the site list:
# grep test transport test@qhpress.org mailman:post test-admin@qhpress.org mailman:admin test-bounces@qhpress.org mailman:bounces test-leave@qhpress.org mailman:leave test-owner@qhpress.org mailman:owner test-request@qhpress.org mailman:request test-unsubscribe@qhpress.org mailman:unsubscribe test-confirm@qhpress.org mailman:confirm test-join@qhpress.org mailman:join test-subscribe@qhpress.org mailman:subscribe # grep 'mailman[@-]' transport [no output]
The virtual file shows virtually the same thing:
# grep test virtual test@qhpress.org test@qhpress.org test-admin@qhpress.org test-admin@qhpress.org test-bounces@qhpress.org test-bounces@qhpress.org test-leave@qhpress.org test-leave@qhpress.org test-owner@qhpress.org test-owner@qhpress.org test-request@qhpress.org test-request@qhpress.org test-unsubscribe@qhpress.org test-unsubscribe@qhpress.org test-confirm@qhpress.org test-confirm@qhpress.org test-join@qhpress.org test-join@qhpress.org test-subscribe@qhpress.org test-subscribe@qhpress.org # grep mailman virtual mailman-loop@qhpress.org mailman-loop@localhost.localdomain
My current idea is to add "mailman" lines similar to all the "test" lines in transport and virtual and then update transport.db and virtual.db with postmap. (After first making backups of the current forms!) If this creates valid files, will Postfix start using the new versions immediately, or do I need to do something else to draw its attention to the changes?
I see cron/mailpasswds is supposed to run on the first of each month. It wasn't done this month (which was the only opportunity so far). I guess that was because it couldn't use the site list.
-- Larry Kuenning larry@qhpress.org
On 5/10/2013 9:03 AM, I wrote:
I tried this and it works: I can now post to the site list.
After updating transport.db and virtual.db, and before posting, I ran newaliases just in case, with the result that now I don't know whether that step was necessary.
I tried this too, creating a new alias for my catchall box after my first successful post. A second post arrived with no trouble, and examining the .db files with postmap shows they are as they should be. So at any rate Plesk doesn't throw away data it finds in those files that it didn't put there.
Thanks for all your help!
-- Larry Kuenning larry@qhpress.org
On 05/10/2013 07:53 AM, Larry Kuenning wrote:
Per my reply that you hadn't seen yet, no it wasn't. newaliases just updates the .db files for those files in alias_database, i.e. /etc/aliases in your case.
Interesting.
Anyway, I'm glad it's working for you.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 05/10/2013 06:03 AM, Larry Kuenning wrote:
I'm guessing Plesk doesn't create the .db files directly, but rather creates/updates some plain text file and invokes postmap/postalias to create the .db files, but whether and why it hides the text files with a different name or doesn't keep them, I have no idea.
Anyway, if you make changes to the aliases.db, virtual.db and/or transport.db files, Plesk will overwrite them unless it actually uses these files as the starting point when it adds/deletes info for a list.
Trying will tell.
Aliases in /etc/aliases for the 'mailman' list should work, but you also in your case need virtual mappings to map the 'mailman' list addresses in the virtual domain to local addresses.
Actually, the mapings above don't make sense. They map, e.g., the virtual domain address test@qhpress.org to the same address, test@qhpress.org. If this were actually used by Postfix, it would be a loop. Thus, I think qhpress.org must actually be a Postfix local domain.
But, if that is the case, putting the appropriate
mailman: "|/path/to/mailman/mail/mailman post mailman" mailman-admin: "|/path/to/mailman/mail/mailman admin mailman" mailman-bounces: "|/path/to/mailman/mail/mailman bounces mailman" ...
entries in /etc/aliases and reloading Postfix should work, assuming there is a mailman/mail/mailman wrapper and it doesn't result in a group mismatch error <http://wiki.list.org/x/tYA9>.
That should work, and Postfix will use it more or less immediately (it detects the change). However, Plesk may reverse it the next time it makes a change.
I don't think so. I don't think the list address has to work. The list only has to exist. But, check the cron log (maybe /var/log/cron or a rotated older one) to see if there's anything there. Also, it is a good idea to put a MAILTO= with a good address in Mailman's crontab. Without it, cron errors probably get mailed to 'mailman' which in your case doesn't work, and even if it does, the list may not be configured to accept them even though it should be.
I suspect you'll finally end up deleting the 'mailman' list with bin/rmlist and then recreating it with Plesk.
The real question is why a Plesk Mailman doesn't have the site list deliverable in the first place.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 05/08/2013 08:15 AM, Larry Kuenning wrote:
But mail doesn't get delivered to it. Mail to mailman@mydomain lands in my catchall mailbox, where all the spam for unknown users goes.
This is a Postfix issue and it's probably as simple as missing aliases or virtual mappings.
I will comment further in additional replies.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (3)
-
David Benfell -
Larry Kuenning -
Mark Sapiro