Conflicts:
	puppet/modules/site_postfix/manifests/mx.pp

replacement wasn't being done. (#7890)

This moves that replacement into its own class, clears the old value and
sets it properly in the smtps transport.

Change-Id: I27c02730597df4943761d8bcb61014aeded9dc75

smtpd_relay_restrictions was added in postfix 2.10 (jessie
has 2.11 atm). Without this, outbound mails are rejected to
be relayed.

from http://www.postfix.org/SMTPD_ACCESS_README.html:

    NOTE: Postfix versions before 2.10 did not have
    smtpd_relay_restrictions. They combined the mail relay and spam blocking
    policies, under smtpd_recipient_restrictions. This could lead to
    unexpected results. For example, a permissive spam blocking policy could
    unexpectedly result in a permissive mail relay policy. An example of
    this is documented under "Dangerous use of
    smtpd_recipient_restrictions".

smtpd_relay_restrictions defaults to
'permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination'
and is configured here to check for a valid client cert.

see http://www.postfix.org/postconf.5.html#smtpd_relay_restrictions

- Resolves: #7856

ensuring the satellite hosts are setup properly (#7611)

Change-Id: I9dce57c305a6fd6a39596a941174fe1879af5e4f

without getting blocked by the rbl (#7819)

Change-Id: Ib7a00f810b6c49528e5f99a1d83296553a81e65e

debconf selections, are set correctly (#7478)

Change-Id: I3bd261fd6fe27bbf10b8994ffff9f8b7be5b9de0

to relay mail through us (#3634)

Change-Id: I46cf3ffbef4261839c376f4c36a50d9c44eb1374

This change will make sure that the user/group for leap-mx exist, and it
changes the mail location from /var/mail/vmail to the more helpful name
/var/mail/leap-mx.

This change requires:

https://github.com/leapcode/leap_mx/pull/78

and it would replace merge request:

https://github.com/leapcode/leap_mx/pull/65

and fix https://leap.se/code/issues/6936 and
https://leap.se/code/issues/7635

Change-Id: Idbe678dc999e394232c2eeef2b2018d39ab7cc3b

When mail comes in to the system, a lookup is done to see if it is a
valid leap user, if it is, leap_mx now returns something of the form:
uuid@deliver.local (see #5959). The virtual_mailbox_domains lists
deliver.local, so postfix choses to deliver to
virtual_mailbox_base (/var/mail/vmail) which has been hardcoded to the
'vmail' maildir and user.

We want leap related mail and leap aliases to go through the virtual
alias system, all the hard-coded universal aliases we want to go through
the local system and we dont want these separate. Known domains that are
considered 'virtual' will be forwarded or delivered to the vmail user,
the rest rejected as unknown recipient, instead of being handed off to
leap-mx.

Previously, the way this was done is we leaned (too heavily) on the
'luser_relay' postfix configuration which sent anything that wasn't
locally configured right to the leap_mx spool. That meant everything
went there, including addresses that didn't exist, and leap-mx would
then have to process those and bounce them. This removes the
'luser_relay' option, so any address that doesn't resolve properly to
either a local address/alias, or a leap address or alias (through
tcp lookups on 2424 and 4242) will get bounced as an unknown user.

Change-Id: I3c22e9383861b3794dd9adfd7aa6a0cf0a773a18