On 1/27/19 2:32 AM, Stephan Bosch wrote:
Op 27/01/2019 om 06:13 schreef Jim Fenton:
The draft discusses situations where intermediaries (relays) might
generate bounce messages and the like, but doesn't deal with what are
effectively reply messages back to the originator of the message.
Op 27/01/2019 om 06:13 schreef Jim Fenton:
Thanks for the review, Stephan.
On 1/25/19 1:58 PM, Stephan Bosch wrote:
I just quickly reviewed this document. I notice that this extension
also applies to LMTP. Now, I wonder what should happen when Sieve [RFC
5228] is involved there,
Hi Russ,
On 1/26/19 7:27 AM, Russ Housley wrote:
> I have no problem with the protocol itself, but I do not understand how this
> specification can not have a reference to TLS.
It does have at least a couple of indirect references to TLS, through
STARTTLS (RFC 3207) and BCP 195. An informative
Thanks for the review, Stephan.
On 1/25/19 1:58 PM, Stephan Bosch wrote:
>
> I just quickly reviewed this document. I notice that this extension
> also applies to LMTP. Now, I wonder what should happen when Sieve [RFC
> 5228] is involved there, particularly when actions like "redirect",
>
I have no problem with the protocol itself, but I do not understand how this
specification can not have a reference to TLS.
Russ
> On Jan 25, 2019, at 10:00 AM, The IESG wrote:
>
>
> The IESG has received a request from the Using TLS in Applications WG (uta)
> to consider the following
Hi,
Op 25/01/2019 om 16:00 schreef The IESG:
Abstract
The SMTP STARTTLS option, used in negotiating transport-level
encryption of SMTP connections, is not as useful from a security
standpoint as it might be because of its opportunistic nature;
message delivery is, by default,
The IESG has received a request from the Using TLS in Applications WG (uta)
to consider the following document: - 'SMTP Require TLS Option'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive
