Quoting postconf(5):

    smtpd_reject_unlisted_recipient (default: yes)
        Request that the Postfix SMTP server rejects mail for unknown recipient
        addresses, even when no explicit reject_unlisted_recipient access
        restriction is specified. This prevents the Postfix queue from filling
        up with undeliverable MAILER-DAEMON messages.

        An address is always considered "known" when it matches a virtual(5)
        alias or a canonical(5) mapping.
        […]
        * The recipient domain matches $virtual_alias_domains but the recipient
          is not listed in $virtual_alias_maps.
        * The recipient domain matches $virtual_mailbox_domains but the
          recipient is not listed in $virtual_mailbox_maps, and
          $virtual_mailbox_maps is not null.

Since we alias everything under special, "invalid", domains (mda.f.o and
mailman.f.o), our $virtual_mailbox_maps was null, which led to
reject_unlisted_recipient not being triggered for say, "noone@fripost.org".
However, replacing $virtual_mailbox_domains with $virtual_alias_domains fits
into the second point above.

So our suffix is now a mere 'dc=fripost,dc=org'.  We're also using the
default '/var/lib/ldap' as olcDbDirectory (hence we don't clear it
before hand).

That is, don't put a leading virtual_ or a trailing _maps in file names.

We introduce a limitation on the domain-aliases: they can't have
children (e.g., lists or users) any longer.

The whole alias resolution, including catch-alls and domain aliases, is
now done in 'virtual_alias_maps'. We stop the resolution by returning a
dummy alias A -> A for mailboxes, before trying the catch-all maps.

We're still using transport_maps for lists. If it turns out to be a
bottleneck due to the high-latency coming from LDAP maps, (and the fact
that there is a single qmgr(8) daemon), we could rewrite lists to a
dummy subdomain and use a static transport_maps instead:

  virtual_alias_maps:
    mylist@example.org -> mylist#example.org@mlmmj.localhost.localdomain

  transport_maps:
    mlmmj.localhost.localdomain mlmmj:

Right now the list server cannot be hosted with a MX, due to bug 51:

    http://mlmmj.org/bugs/bug.php?id=51

Web archive can be compiled with MHonArc, but the web server
configuration is not there yet.