[Mailman-Users] no mail delivery to site list

[Larry Kuenning]

On 5/9/2013 9:43 PM, Mark Sapiro 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.

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.

>> mailman unix - n n - - pipe flags=R user=mailman:mailman
>> argv=/usr/lib64/plesk-9.0/postfix-mailman ${nexthop} ${user} ${recipient}
>
> 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.

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 at qhpress.org        mailman:post
test-admin at qhpress.org  mailman:admin
test-bounces at qhpress.org        mailman:bounces
test-leave at qhpress.org  mailman:leave
test-owner at qhpress.org  mailman:owner
test-request at qhpress.org        mailman:request
test-unsubscribe at qhpress.org    mailman:unsubscribe
test-confirm at qhpress.org        mailman:confirm
test-join at qhpress.org   mailman:join
test-subscribe at qhpress.org      mailman:subscribe
# grep 'mailman[@-]' transport
[no output]

The virtual file shows virtually the same thing:

# grep test virtual
test at qhpress.org        test at qhpress.org
test-admin at qhpress.org  test-admin at qhpress.org
test-bounces at qhpress.org        test-bounces at qhpress.org
test-leave at qhpress.org  test-leave at qhpress.org
test-owner at qhpress.org  test-owner at qhpress.org
test-request at qhpress.org        test-request at qhpress.org
test-unsubscribe at qhpress.org    test-unsubscribe at qhpress.org
test-confirm at qhpress.org        test-confirm at qhpress.org
test-join at qhpress.org   test-join at qhpress.org
test-subscribe at qhpress.org      test-subscribe at qhpress.org
# grep mailman virtual
mailman-loop at qhpress.org        mailman-loop at 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?

>> 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.)
>
> 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.

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 at qhpress.org