Project

General

Profile

Actions

Bug #1232

closed

dma(8): Always send EHLO after TLS negotiation

Added by roe about 15 years ago. Updated over 14 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

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.
[...]

Files

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

Updated by matthias about 15 years ago

Hi,

Thanks, I take care of it.

Cheers

Matthias
Actions #2

Updated by corecode over 14 years ago

fixed in master

Actions

Also available in: Atom PDF