During the jessie to stretch upgrade of my mail server:

    -postfix 2.11.3-1+deb8u2 amd64
    +postfix 3.1.4-7 amd64

The following happened to my `master.cf` file:

    -pickup    fifo  n       -       -       60      1       pickup
    -cleanup   unix  n       -       -       -       0       cleanup
    +pickup     fifo  n       -       y       60      1       pickup
    +cleanup    unix  n       -       y       -       0       cleanup

ie. most Postfix processes now run in a chroot. This includes the
endpoints Mailman talks with. This makes the location of the LMTP and
transport files created by mailman 3 unreadable by postfix, even
though the README.Debian suggests the following configuration:

    transport_maps = hash:/var/lib/mailman3/data/postfix_lmtp
    local_recipient_maps = proxy:unix:passwd.byname $alias_maps hash:/var/lib/mailman3/data/postfix_lmtp
    relay_domains = ${{$compatibility_level} < {2} ? {$mydestination} : {}} hash:/var/lib/mailman3/data/postfix_domains

That configuration doesn't work, as Postfix can't read those
directories. I used this configuration instead:

    transport_maps = hash:/etc/postfix/transport
                     hash:mailman3/postfix_lmtp
    local_recipient_maps = proxy:unix:passwd.byname $alias_maps hash:mailman3/postfix_lmtp
    relay_domains = ${{$compatibility_level} < {2} ? {$mydestination} : {}} hash:mailman3/postfix_domains

And then created the directories in the new location:

    touch /var/spool/postfix/mailman3/postfix_domains /var/spool/postfix/mailman3/postfix_lmtp
    chown list:list /var/spool/postfix/mailman3/postfix_*
    postmap /var/spool/postfix/mailman3/postfix_domains /var/spool/postfix/mailman3/postfix_lmtp
    ln -s /var/spool/postfix/mailman3/postfix_domains /var/spool/postfix/mailman3/postfix_lmtp /var/lib/mailman3/data/

Finally, the `data_dir` location needs to be changed in the
`mailman.cfg` as well:

    data_dir: /var/spool/postfix/mailman3/

I'm surprised the suggested configuration works for people - I suspect
it might only work on older machines that upgraded Postfix from
stretch without accepting the upstream changes.

That or I'm some paranoid freak that over-chrooted stuff I shouldn't
have, which is also entirely possible.

Either case, some improvements to the README.Debian seem in order.

Hi,

I can confirm this observation.

The file /etc/postfix/transport does not exist by default, so it should not be
included in a future README.Debian.

Are you sure those were the steps you followed?

With how you are doing it, /var/spool/postfix/mailman3 will not be owned by
list:list and thus mailman3 cannot create additional files in it.

Also, instead of creating a symbolic link to the individual files, maybe
instead do:

    $ ln -s /var/spool/postfix/mailman3 /var/lib/mailman3/data/

And in the beginning an mkdir command is missing.

It certainly didn't work for me.

Please fix README.Debian.

Thanks!

cheers, josch

Hello.

My solution for postfix in chroot:

/etc/init.d/mailman3 stop
mv /var/lib/mailman3/data /var/spool/postfix/mailman3
ln -s /var/spool/postfix/mailman3 /var/lib/mailman3/data
/etc/init.d/mailman3 start

postfix main.cf:

transport_maps = hash:mailman3/postfix_lmtp
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
hash:mailman3/postfix_lmtp relay_domains = ${{$compatibility_level} < {2} ? {$mydestination} : {}} hash:mailman3/postfix_domains

Regards,

J.K.