On Wed, Jun 12, 2013 at 03:23:38PM +0200, Jeroen Geilman wrote:
> On 06/12/2013 03:02 PM, Peter Bauer wrote:
> >
> >How can I check the certificate of the incoming email? By
> >fingerprint would be nice. And I would like to refuse it if check
> >fails.
>
> http://www.postfix.org/TLS_README.html#server_vrfy_client
Also
http://www.postfix.org/postconf.5.html#check_ccert_access
http://www.postfix.org/postconf.5.html#reject_plaintext_session
That said, the text below was written around 2005 (for Postfix
2.3), and remains equally applicable today. The OP's desire to
use TLS fingerprint security for "inbound" mail is largely misguided,
DKIM is likely a better option for message origin authentication
(and even that has limited benefits). TLS is a hop-by-hop
transmission-channel security mechanism, while origin authentication
is an end-to-end problem.
http://www.postfix.org/TLS_README.html#client_tls_limits
...
An important SMTP-specific observation is that a public MX host
is even more at the mercy of the SMTP client than is an HTTPS
server. Not only can it not enforce due care in the client's
use of TLS, but it cannot even enforce the use of TLS, because
TLS support in SMTP clients is still the exception rather than
the rule. One cannot, in practice, limit access to one's MX
hosts to just TLS-enabled clients. Such a policy would result
in a vast reduction in one's ability to communicate by email
with the world at large.
One may be tempted to try to enforce TLS for mail from specific
sending organizations, but this, too, runs into obstacles. One
such obstacle is that we don't know who is (allegedly) sending
mail until we see the "MAIL FROM:" SMTP command, and at that
point, if TLS is not already in use, a potentially sensitive
sender address (and with SMTP PIPELINING one or more of the
recipients) has (have) already been leaked in the clear. Another
obstacle is that mail from the sender to the recipient may be
forwarded, and the forwarding organization may not have any
security arrangements with the final destination. Bounces also
need to be protected. These can only be identified by the IP
address and HELO name of the connecting client, and it is
difficult to keep track of all the potential IP addresses or
HELO names of the outbound email servers of the sending
organization.
Consequently, TLS security for mail delivery to public MX hosts
is almost entirely the client's responsibility. The server is
largely a passive enabler of TLS security, the rest is up to
the client.
--
Viktor.
