"Fossies" - the Fresh Open Source Software Archive
Member "courier-1.2.2/courier/doc/draft-varshavchik-security-smtpext.txt" (25 Aug 2013, 8297 Bytes) of package /linux/misc/courier-1.2.2.tar.bz2:
As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard
) with prefixed line numbers.
Alternatively you can here view
the uninterpreted source code file.
7 1. Abstract
9 This document describes an [ESMTP] extension that enables the sender
10 to explicitly indicate the transport security level the mail system
11 must use in delivering the given message.
13 The SECURITY extension can also be used to establish secure mail
14 delivery channels between trusted hosts, connected by an untrusted
15 public network.
17 2. Introduction
19 [STARTTLS] defines an SMTP service extension for using TLS/SSL to
20 send mail between ESMTP mail relays. [STARTTLS] is an optional SMTP
21 extension, but sometimes the sender might wish to require that
22 [STARTTLS], or an equivalent, must be used to deliver a particular
23 message. Even if two mail nodes - the sending and the receiving
24 nodes - are set up to use [STARTTLS], there are known methods of
25 attack - such as [DNS] cache poisoning - which can be used to
26 intercept mail traffic.
28 3. Framework for the SECURITY SMTP transport extension
30 This [ESMTP] transport extension is laid out as follows.
32 (1) The name of the SMTP transport extension defined here is
33 Message Security Level.
35 (2) The EHLO keyword associated with this extension is SECURITY.
37 (3) The SECURITY EHLO keyword takes a comma-delimited list as a
40 (4) One optional ESMTP keyword SECURITY is associated with the
41 MAIL FROM command. This parameter takes a comma-delimited list
42 as a parameter.
44 (5) No additional ESMTP verbs are defined by this extension.
46 (6) The next section specifies how support for this extension
47 affects the behavior of a server and client SMTP.
49 4. The SECURITY SMTP extension
51 The EHLO keyword SECURITY takes a comma-separated list of words as an
52 argument. This document defines two words that may appear in the
53 EHLO SECURITY list:
58 S. Varshavchik Expires XXX XX, XXXX [Page 1]
60 SECURITY SMTP Extension S. Varshavchik XXX XX, XXXX
63 NONE - No security.
65 STARTTLS - Must use STARTTLS to deliver the message.
68 The optional SECURITY ESMTP keyword to the MAIL FROM command MUST use
69 one of these words as a parameter (if the SECURITY keyword is
70 provided at all). This is used to select the requested security
71 level in transmitting this message
73 SECURITY=NONE essentially requests no security whatsoever, for this
74 message. It is equivalent to complete absence of an explicit
75 SECURITY setting.
77 SECURITY=STARTTLS specifies that the mail relay MUST use [STARTTLS]
78 with a remote mail node. The mail relay ignores this option if it
79 delivers the message to a local mailbox. The sending mail relay MUST
80 also verify the X.509 certificate received from the remote mail relay
81 during TLS negotiation. The remote relay’s X.509 certificate MUST be
82 signed by a certificate authority that is known and trusted by the
83 sending relay. If the remote relay does not support [STARTTLS], or
84 is unable to provide a satisfactory X.509 certificate, the message
85 MUST be returned as undeliverable.
87 Note that [STARTTLS] allows the mail node to initially advertise
88 STARTTLS as its only [ESMTP] extension, until TLS is established.
89 Therefore, TLS MUST be established first, before checking for the
90 SECURITY [ESMTP] extension.
92 Note that after TLS is established, the EHLO no longer shows
93 STARTTLS, since TLS is already being used, and EHLO will now list the
94 SECURITY keyword without a STARTTLS keyword. SECURITY may also
95 appear without STARTTLS even if TLS has not been established. This
96 situation may happen with a connection over an internal, secure
97 network, to a mail firewall, essentially instructing the mail
98 firewall to use SECURITY to deliver the message over an external
99 network, even though TLS is not necessary to forward the mail from
100 the sender over the secure, internal, network.
102 A mail relay MAY automatically "upgrade" the SECURITY level of a
103 message based on the mail relay’s administrative policies. A node
104 MUST NOT automatically downgrade the SECURITY level. For the purpose
105 of determining the security level SECURITY=STARTTLS is considered to
106 be more secure than SECURITY=NONE. This allows the implementation of
107 a secure mail delivery framework between trusted nodes, over an
108 untrusted network, without any modification to existing mail user
114 S. Varshavchik Expires XXX XX, XXXX [Page 2]
116 SECURITY SMTP Extension S. Varshavchik XXX XX, XXXX
119 5. Example
121 220 example.com ESMTP
122 EHLO domain.com
123 250-example.com ESMTP
124 250 STARTTLS
126 220 Go ahead.
127 [4m(TLS[24m [4mnegotiation[24m [4mtakes[24m [4mplace)[0m
128 EHLO domain.com
129 250-example.com ESMTP
133 250 HELP
134 MAIL FROM:<firstname.lastname@example.org> SIZE=1250 SECURITY=STARTTLS
135 250 Ok
136 [4m(Normal[24m [4mSMTP[24m [4mdialogue[24m [4mcontinues...)[0m
138 6. Delivery Status Notifications
140 [DSN] messages generated for a message with any SECURITY keyword MUST
141 also use the same SECURITY keyword for the DSN. This is because DSNs
142 may include portions of the original message. The presumption is
143 that if a secure path existed between the sender, and the DSN-
144 generating node, a return secure path also exists.
146 7. Security concerns
148 Note that it is not necessary for a mail client to negotiate TLS/SSL
149 in order to submit the message for delivery. A mail node SHOULD
150 advertise and enable SECURITY in both plaintext and TLS/SSL-secured
153 The SECURITY extension allows a fairly straightforward way to set up
154 a secure mail transmission infrastructure between trusted hosts over
155 a public, untrusted, network. This is done by installing X.509
156 certificates signed by a trusted certificate authority, then using
157 SECURITY to require [STARTTLS] (or configuring the mail relay’s
158 configuration to automatically upgrade SECURITY for outgoing
161 The trusted CA must be a private CA that is used only by these nodes.
162 The secure mail traffic can still be intercepted if a public CA is
163 used. This is because other techniques, such as IP address spoofing
164 or [DNS] cache poisoning, can be used to redirect mail to a node with
165 a valid certificate signed by a public CA.
170 S. Varshavchik Expires XXX XX, XXXX [Page 3]
172 SECURITY SMTP Extension S. Varshavchik XXX XX, XXXX
175 Note that a trusted mail node CAN use DNS cache poisoning to
176 intercept mail addressed to another trusted mail node, since the
177 attacker will have a certificate signed by the private CA. It is
178 important to understand that the SECURITY extension is designed to
179 defend against attacks from untrusted mail nodes only.
181 The SECURITY extension’s scope is limited to delivery of a message to
182 the recipient’s mailbox. Once a message is delivered, it is the
183 recipient’s responsibility to access the message in a secure
184 environment, such as by using SSL/TLS-wrapped versions of existing
185 mailbox access protocols.
187 8. References
189 [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker,
190 D. "SMTP Service Extensions", RFC 1425, United Nations
191 University, Innosoft International, Inc., Dover Beach
192 Consulting, Inc., Network Management Associates, Inc., The
193 Branch Office, February 1993
195 [STARTTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over
196 TLS", RFC 2487, Internet Mail Consortium, January 1999
198 [DSN] Moore, K. "SMTP Service Extension for Delivery Status
199 Notifications", RFC 1891, University of Tennessee, January
202 [DNS] Mockapetris, P., "Domain Names - Implementation and
203 Specification", RFC 1035, ISI, November 1987
205 9. Author’s address
207 Sam Varshavchik
208 Double Precision, Inc.
209 402 Main Street Suite 100-241
210 Metuchen, NJ 08840
226 S. Varshavchik Expires XXX XX, XXXX [Page 4]