Bug #1232

dma(8): Always send EHLO after TLS negotiation

Added by roe almost 6 years ago. Updated about 5 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:matthias% Done:

0%

Category:-
Target version:-

Description

The attached patch fixes dma(8) to issue EHLO again after
STARTTLS. Some MTAs require EHLO to be issued after STARTTLS and
will refuse RCPT TO directly following STARTTLS.

dma(8) currently only issues EHLO after negotiating TLS if
port-465-style SMTPS (no STARTTLS) was configured. However,
since the server is required to discard any knowledge obtained
from the client previously, EHLO should be issued again after
STARTTLS. The relevant passage from RFC 3207:

4.2 Result of the STARTTLS Command

Upon completion of the TLS handshake, the SMTP protocol is reset to
the initial state (the state in SMTP after a server issues a 220
service ready greeting). The server MUST discard any knowledge
obtained from the client, such as the argument to the EHLO command,
which was not obtained from the TLS negotiation itself. The client
MUST discard any knowledge obtained from the server, such as the list
of SMTP service extensions, which was not obtained from the TLS
negotiation itself. The client SHOULD send an EHLO command as the
first command after a successful TLS negotiation.

[...]

patch-libexec_dma_net.c.diff Magnifier (670 Bytes) roe, 01/17/2009 06:42 PM

History

#1 Updated by matthias almost 6 years ago

Hi,

Thanks, I take care of it.

Cheers

Matthias

#2 Updated by corecode about 5 years ago

fixed in master

Also available in: Atom PDF