Re: [Emailcore] Revisiting Issue 40 - A/S and Use of SMTP Extensions

[John C Klensin <[e-mail]>]

No, the future is certain.   It is actually in AUTH48 with the
RFC Editor and, I believe, would have been out of it had I not
decided to prioritize rfc5321bis... because WGLC is supposed to
end today and for the reason Rob Sayre just pointed out and to
which I responded.

So, with a bit of luck, expect draft-freed-smtp-limits to be
published as RFC 9422 late this week or early next.

best,
   john


--On Monday, January 15, 2024 13:13 -0500 Douglas Foster
<[e-mail]> wrote:

> This draft:
>    https://datatracker.ietf.org/doc/draft-freed-smtp-limits/07/
> was proposed to deal with several issues, including the
> problems that occur when pipelining is used and a local Max
> Recipients limit is enforced.   The draft has not been killed,
> but it had no workgroup sponsorship so I thought its future
> was dim.
> 
> DF
> 
> On Mon, Jan 15, 2024 at 12:21 PM Michael Peddemors
> <[e-mail]> wrote:
> 
>> On 2024-01-09 07:10, Alexey Melnikov wrote:
>> > Hi all,
>> > 
>> > On 04/01/2024 17:18, John Levine wrote:
>> >> It appears that Michael Peddemors<[e-mail]>
>> >> said:
>> >>> Strongly disagree.. This can be a MAY, however modern
>> >>> MTA's do a lot of inline decision making, that conflict
>> >>> with PIPELINING..
>> >> I'm coming up blank here.  Can you give us an example or
>> >> two?
>> 
>> Sorry, wasn't clear that this comment may have been directed
>> to me, and rushing in a response (just got back from holidays)
>> 
>> MTA's (for instance our own, but several other MTA's allow for
>> replicating the same behavior) can explicitly reject at
>> stages like RCPT TO, and a PIPELINE would accept a string of
>> consecutive RCPT TO's, however what happens if it exceeds for
>> instance a built-in rate limiter? At that point, the MTA
>> would return a 5XX immediately, but the PIPELINE connection
>> would continue streaming commands .. and only handling the
>> responses at the end of the pipeline.
>> 
>> Much bot activity attempts to exploit this, during both SMTP
>> authentication attacks and spam attacks, as well as 'list
>> washers'.
>> 
>> By turning off PIPELINE, it is much easier to identify those
>> that try to abuse it.
>> 
>> I never said that there was anything 'wrong' with the
>> extension, only that it's importance has reduced with modern
>> speeds of the internet, and changes to how MTA"s are much
>> more 'intelligent' in the SMTP layer than in the past, and
>> have the performance to do in transaction decision making,
>> which MIGHT direct the client to stop/change its behavior,
>> contrary to a PIPELINE which will continue.
>> 
>> As such, the 'SHOULD' is no longer prudent, but an MTA 'MAY'
>> is perfectly fine..
>> 
>> 
>> 
>> > As a SMTP server and client implementor, I agree with John.
>> > This discussion didn't convince me that there is anything
>> > wrong with the PIPELINING extension, even though I agree
>> > that there are issues with specific implementations and
>> > clarifying server behaviour would help.
>> >> Keep in mind that you can pipeline MAIL FROM and RCPT TO
>> >> but you have to synchronize at DATA.
>> > 
>> > Best Regards,
>> > 
>> > Alexey
>> > 
>> > 
>> 
>> 
>> --
>> "Catch the Magic of Linux..."
>> -------------------------------------------------------------
>> ----------- Michael Peddemors, President/CEO LinuxMagic Inc.
>> Visit us at http://www.linuxmagic.com @linuxmagic
>> A Wizard IT Company - For More Info http://www.wizard.ca
>> "LinuxMagic" a Registered TradeMark of Wizard Tower
>> TechnoServices Ltd.
>> -------------------------------------------------------------
>> ----------- 604-682-0300 Beautiful British Columbia, Canada
>> 
>> This email and any electronic data contained are confidential
>> and intended solely for the use of the individual or entity
>> to which they are addressed. Please note that any views or
>> opinions presented in this email are solely those of the
>> author and are not intended to represent those of the company.
>> 
>> --
>> Emailcore mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/emailcore
>>