Forgot your password?
New user?
Document Actions
4. SecMX: Level 1
This section introduces SecMX, a standard that will help secure email communications between government, business and citizens.
4. SecMX
This section introduces SecMX, a standard that will secure email
communications between government, business and citizens, without the
issues of SEEMail.
4.1. TLS
In SEEMail, security is gateway to gateway. Experience with SEEMail
showed that this model worked exceedingly well. SecMX is a gateway
based model, without the limitations of SEEMail. This RFC proposes
that TLS is a suitable alternative.
Why TLS? It is a gateway based model, operating between SMTP
servers.
o Cost: There are not significant capital costs. TLS is bundled
with most operating systems;
o Experience: It is already active (slightly more than 10% of 4000
New Zealand domains tested already had TLS enabled on their SMTP
servers).
o Robustness: TLS is a mature standard and operates transparently to
secure transport protocols;
4.2. Postal mail equivalence
SecMX secures the transport of email, in an analogous way to the
postal system and paper mail.
Postal system
* >| |<
* Government > Post > Citizen
* Government > Post > PO Box > Citizen
SecMX
* >| |<
* Government > Email > Mail Box > Citizen
In addition, ISPs Mail Box services can be securely accessed using
POPS and IMAPS or HTTPS for Web based services.
4.3. SecMX: Level 1
All MTAs must enable TLS if possible.
SecMX defines two new behaviours for MTAs:
Best Effort Sender (BES): A BES will attempt to transfer all email
securely (SMTP over TLS), but will fall back to standard SMTP if a
TLS session cannot be established with the receiving server.
Best Effort Receiver (BER): A BER will prefer to receive mail
securely (SMTP over TLS), but will also receive email over
standard SMTP if a TLS session cannot be established with the
sending server.
MTAs that support BES and BER will be known as Best Effort SecMX
servers.
SecMX -- a better way to send email
It makes NO difference what protocol is used, or what it’s called.
The real problem is the very fact that internet protocols are used at all. The internet was never designed with security in mind and as I mention in section 3 ‘Motivation’, it’s highly dangerous to provide any type of connection between two electronic environments where one is inherently secure and the other is inherently insecure.
Therefore any move from SMTP to a TLS protocol will never achieve the desired results.
If ISP’s do move across (and there is no incentive for them to do so), you will end up with not just with all the same internet problems you face today, but you will also create many new ones.
The internet and all its protocols are anarchic. There is, and can never be control over emails where using standard internet delivery mechanisms are involved in the delivery process. Without control you can never offer any guarantees. Without guarantees there will never be any trust.
So the questions then become… can messages be sent electronically in such a way that there is control over the entire delivery process? And in such a way that internet protocols are not used? And in such a way that digital certificates are not required?
The answer is yes there is.