On Mon, Jan 11, 2016 at 03:49:20PM -0600, Jacob Arthur wrote:
> I have a rather unique situation where I'm looking to introduce a Postfix
> server as an outbound mail server to enforce and be able to report on
> encrypted messaging leaving the organization. Postfix version I'm using
> currently is 2.11, but happy to upgrade if that helps.
>
> What I'd like to have happen is this:
> 1. Message is received from an internal user by the Postfix server
> 2. The server attempts to deliver directly to the host specified by the MX
> record, and does so if encryption can be negotiated to match the specified
> policy
> 3. If encryption to the remote server cannot be negotiated directly,
> forward the message to another relay for delivery (in reality, this is a
> secure mail portal that requires the user to come and authenticate to get
> the message).
TLS policy is based on the nexthop domain, not the recipient domain (the
two typically, but don't always coincide). Thus for example, with:
transport:
example.com smtp:example.net
the TLS policy for [email protected] will be the one for "example.net".
The reason I mention this, is that this explains the semantics of
TLS in the context of smtp_fallback_relay:
transport:
example.com smtp:example.net
main.cf:
smtp_fallback_relay = example.org
The initial delivery to [email protected] is via the MX hosts of
example.net and the TLS policy for that domain, but if those tempfail
for *any* reason (TLS failure, failure to connect, or greylisting),
then the Postfix will try the fallback relay. For the fallback
relay, the TLS security policy is that for example.org, as configured
in smtp_tls_policy_maps, ...
The main difficulty is the "for any reason" part, not all temporary
failures will be TLS failures. There is no mechanism to restrict
fallback to just TLS errors. That would require tracking for each
envelope recipient whether that recipient is deferred due to a TLS
policy error or some other error, and using the fallback relay only
in the former case.
This is a rather delicate configuration, it might be better to
explicitly configure TLS for destinations you know support it and
use the fallback unconditionally for all others. In other words,
not leave it up to chance.
You can also transform TLS temporary errors, into permanent errors
that bounce immediately:
http://www.postfix.org/postconf.5.html#smtp_delivery_status_filter
http://www.postfix.org/postconf.5.html#default_delivery_status_filter
then the user can redirect the mail appropriately. This requires 3.0
--
Viktor.
