[exim] Development Request for Selectable Opportunistic vs. …

Top Page
Delete this message
Reply to this message
Author: Stan Haimes, MD
Date:  
To: exim-users
Subject: [exim] Development Request for Selectable Opportunistic vs. Forced TLS
I have a need for a slightly different implementation of Opportunistic
TLS in EXIM.  I am also willing to provide compensation for its
development and would be happy to donate the code to public distribution
if it would be useful to others.

For most messages, sending the outgoing email by Opportunistic TLS would
be desirable and perfect.

However, if the Subject field contains "[Secure]", I would like that to
trigger different message handling by EXIM.  The presence of this
character string in the Subject field would indicate that the sender was
requiring that this message be sent via TLS or not at all.  As a result,
if the email could be sent via Forced (Mandatory) TLS, the email
submission would complete in the usual manner.  However, if the
attempted TLS connection was not successful, the email would be
redirected to the sender with an indication that the secure TLS email
transmission was not successful.

The manner of this failure notification can be up to the developer.  As
a minimum, I would like a "secure email encryption failure" message to
be generated to the From field of the outgoing email, which would
perhaps have [Secure Email Encryption Failure] in the Subject field
prefixed to the previous Subject field, with perhaps the original From,
To, CC, BCC, Reply-To, and Subject fields formatted as the body of the
notification message.  It would be nice to forward the unsent message
back to the From field of the unsent message.

The reason for this is to send medical information in an encrypted
manner between MTA's, in a method that allows this to be selected on an
individual message basis without requiring all messages from the server
or EXIM installation to be sent in Forced TLS mode.  This would also
avoid the need to purchase additional end-to-end encryption software and
have the users deal with the unnecessary complexity that such a solution
would force the users to accommodate.

Thank you for your consideration.

Stan Haimes

stan@???