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

[Douglas Foster <[e-mail]>]

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
>