carconni wrote: > >I've just been updated by more of the users/list admins. It seems >that every-time the mail-server bounces/restarts, configurations are >lost. Members fall off lists, lists stop running, or are no longer >recognized by the mail server. Is there a central DB or something >that is rolling back to an earlier version?
Could be, but it is pretty clear to me that the problem is with your MTA, not with mailman. Since your MTA is Postfix, and delivery is via aliases, this can't be a Mailman (other than aliases) issue because the mail is being bounced by Postfix because "Recipient address rejected: User unknown in local recipient table" which means that somehow the aliases for this list are being lost. When the problem occurs, are the aliases still in /var/mailman/data/aliases? What is the mod time on /var/mailman/data/aliases.db? Are all the list's (working and non-working) aliases in /var/mailman/data/aliases and nowhere else (eg /etc/postfix/lmail/company.aliases or /etc/aliases)? >> I have spent the better part of 6 hours looking for a reason. I've >> checked permissions, not just with checkperms but manually, step by >> step, directory by directory comparing the broken list to a list that >> is known to be working. Nothing in Mailman is causing this. It is postfix that 'forgets' how to deliver to [EMAIL PROTECTED] Apparently deleting and recreating the list fixes the problem because it runs Postfix's /usr/sbin/postalias command abd rebuilds /var/mailman/data/aliases.db from /var/mailman/data/aliases. Probably just running postalias would fix it too without the pain of recreating the list. <stuff not relevant to the issue snipped> >> I've checked the alias file in /var/mailman/data/aliases: >> (Everything looks ok) >> >> # STANZA START: qvc-requests >> # CREATED: Wed Aug 1 09:09:12 2007 >> qvc-requests: "|/usr/share/mailman/mail/mailman post qvc- >> requests" >> qvc-requests-admin: "|/usr/share/mailman/mail/mailman admin qvc- >> requests" >> qvc-requests-bounces: "|/usr/share/mailman/mail/mailman bounces >> qvc-requests" >> qvc-requests-confirm: "|/usr/share/mailman/mail/mailman confirm >> qvc-requests" >> qvc-requests-join: "|/usr/share/mailman/mail/mailman join qvc- >> requests" >> qvc-requests-leave: "|/usr/share/mailman/mail/mailman leave qvc- >> requests" >> qvc-requests-owner: "|/usr/share/mailman/mail/mailman owner qvc- >> requests" >> qvc-requests-request: "|/usr/share/mailman/mail/mailman request >> qvc-requests" >> qvc-requests-subscribe: "|/usr/share/mailman/mail/mailman subscribe >> qvc-requests" >> qvc-requests-unsubscribe: "|/usr/share/mailman/mail/mailman >> unsubscribe qvc-requests" >> # STANZA END: qvc-requests >> >> I've checked locks: - nothing regarding this list there. Mailman locks aren't relevant to this. >> main.cf shows: alias_maps = hash:/etc/postfix/lmail/ >> company.aliases,hash:/var/mailman/data/aliases Looks OK to me, but I'm not a postfix guy? >> Where else can I check? Something is happening when Postfix is restarted that is causing this, but I don't know what or why. I'm guessing the /var/mailman/data/aliases.db file gets modified somehow using data other than that in /var/mailman/data/aliases, but I have no idea how this can happen. But, I can tell you, look to Postfix, not Mailman. Other than /var/mailman/data/aliases*, there's nothing in Mailman that's relevant to this issue. -- Mark Sapiro <[EMAIL PROTECTED]> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan ------------------------------------------------------ Mailman-Users mailing list [email protected] http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
