Subject: [Emailcore] 3.1 - Session Initiation

From: "Brotman, Alex" <[email-masked]>
Date: Mon, 6 Dec 2021 18:22:53 +0000

>From 3.1: "A server taking this approach MUST still wait for the client to send a QUIT (see Section 4.1.1.10) before closing the connection and SHOULD respond to any intervening commands with "503 bad sequence of commands".

I feel like this may not match reality as it exists today.  From a receiver side, this could allow an attacker to hold open sessions for a quite a bit of time.  Many mail systems do not allow a session to progress once they believe the sending IP is abusive or there may be some other trouble on the system (over some internal queue level, etc).  While it may not match real-world experiences, I'm not sure we want to change this or endorse this, but thought it worth mentioning.

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

---

From: John C Klensin <[email-masked]>
Date: Mon, 06 Dec 2021 17:36:34 -0500

--On Monday, December 6, 2021 18:22 +0000 "Brotman, Alex"
<Alex_Brotman=[email-masked]> wrote:

>> From 3.1: "A server taking this approach MUST still wait for
>> the client to send a QUIT (see Section 4.1.1.10) before
>> closing the connection and SHOULD respond to any intervening
>> commands with "503 bad sequence of commands".
> 
> I feel like this may not match reality as it exists today.
> From a receiver side, this could allow an attacker to hold
> open sessions for a quite a bit of time.  Many mail systems do
> not allow a session to progress once they believe the sending
> IP is abusive or there may be some other trouble on the system
> (over some internal queue level, etc).  While it may not match
> real-world experiences, I'm not sure we want to change this or
> endorse this, but thought it worth mentioning.

Alex,

Definitely worth mentioning.  Please have a[nother] look at
Sections 6 and 7, especially 7.8, and see if that is helpful
vis-a-vis the text and situation you describe.  Would a
cross-reference be useful and, if so, pointing where?  Do we
need additional text somewhere? 

In general, Section 7.8 was intended to allow exceptions to any
rule if the exception is needed to resist an attack.  Seems to
me that why you are talking about falls into that category.

  best,
  john

---

From: "Brotman, Alex" <[email-masked]>
Date: Thu, 9 Dec 2021 13:57:56 +0000

Thanks for the pointer.  I was in the middle of reading 06 when you released 07.  Thought I should send in the note before I started anew.  My apologies.

Perhaps in the introduction for section 3 for a note to suggest that section 7 contains deviations that may be more optimal for some situations.

> -----Original Message-----
> From: John C Klensin <[email-masked]>
> Sent: Monday, December 6, 2021 5:37 PM
> To: Brotman, Alex <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Emailcore] 3.1 - Session Initiation
>
>
>
> >> From 3.1: "A server taking this approach MUST still wait for the
> >> client to send a QUIT (see Section 4.1.1.10) before closing the
> >> connection and SHOULD respond to any intervening commands with "503
> >> bad sequence of commands".
> >
> > From a receiver side, this could allow an attacker to hold open
> > sessions for a quite a bit of time.  Many mail systems do not allow a
> > session to progress once they believe the sending IP is abusive or
> > there may be some other trouble on the system (over some internal
> > queue level, etc).  While it may not match real-world experiences, I'm
> > not sure we want to change this or endorse this, but thought it worth
> > mentioning.
>
> Alex,
>
> Definitely worth mentioning.  Please have a[nother] look at Sections 6 and 7,
> especially 7.8, and see if that is helpful vis-a-vis the text and situation you
> describe.  Would a cross-reference be useful and, if so, pointing where?  Do
> we need additional text somewhere?
>
> In general, Section 7.8 was intended to allow exceptions to any rule if the
> exception is needed to resist an attack.  Seems to me that why you are
> talking about falls into that category.
>
>   best,
>   john