smtpd_client_restrictions = reject_unauth_pipelining weirdness

[Jeffrey 'jf' Lim]

Am I misunderstanding something here, that setting
'smtpd_client_restrictions = reject_unauth_pipelining' should reject a
client that sends the EHLO, or HELO before the smtp banner?
(http://www.postfix.org/postconf.5.html#reject_unauth_pipelining:
'Reject the request when the client sends SMTP commands ahead of time
where it is not allowed, ...')

In an effort to test this out (and following the example provided at
http://www.postfix.org/postconf.5.html#smtpd_client_restrictions !):

/etc/postfix/main.cf:
smtpd_client_restrictions =
sleep 1, reject_unauth_pipelining
smtpd_delay_reject = no


# ( echo -e 'helo f'; sleep 0.5; echo -e 'mail from:<a...@a.com>'; sleep
0.5; echo 'rcpt to:<a...@xx.com>' ) | nc 127.0.0.1 25
220 xx.com ESMTP xx
250 xx.com
250 2.1.0 Ok
250 2.1.5 Ok
#

I've even tried this with 'smtpd_delay_reject = yes', with the same result.


Now you'll notice that a sleep is inserted between each command -
'helo', 'mail', and 'rcpt'. What is interesting, though, is what
happens when I take out the delay between the 'helo' and the 'mail':

with smtpd_delay_reject = no :

# ( echo -e 'helo f'; echo -e 'mail from:<a...@a.com>'; sleep 0.5; echo
'rcpt to:<a...@xx.com>' ) | nc 127.0.0.1 25
220 xx.com ESMTP xx
250 xx.com
250 2.1.0 Ok
250 2.1.5 Ok
#

with smtpd_delay_reject = yes, however???:

# ( echo -e 'helo f'; echo -e 'mail from:<a...@a.com>'; sleep 0.5; echo
'rcpt to:<a...@xx.com>' ) | nc 127.0.0.1 25
220 xx.com ESMTP xx
250 xx.com
250 2.1.0 Ok
503 5.5.0 <localhost[127.0.0.1]>: Client host rejected: Improper use
of SMTP command pipelining
#

(Note that I get the same results even if I take out the 'sleep 1'
from smtpd_client_restrictions)


And so it seems that I'm forced to come to the following conclusions:
1. 'smtpd_delay_reject = no' messes up 'smtpd_client_restrictions =
reject_unauth_pipelining' somehow
2. early ehlo, or helo does not register as "unauth pipelining"
3. no delay between the 'helo' and 'mail' commands = command
pipelining, but only if 'smtpd_delay_reject = yes'!

I am running postfix 2.9.6.

-jf

--
He who settles on the idea of the intelligent man as a static entity
only shows himself to be a fool.

"Every nonfree program has a lord, a master --
and if you use the program, he is your master."
--Richard Stallman

[Wietse Venema]

Jeffrey 'jf' Lim:

> Am I misunderstanding something here, that setting
> 'smtpd_client_restrictions = reject_unauth_pipelining' should reject a
> client that sends the EHLO, or HELO before the smtp banner?
> (http://www.postfix.org/postconf.5.html#reject_unauth_pipelining:
> 'Reject the request when the client sends SMTP commands ahead of time
> where it is not allowed, ...')

Current reject_unauth_pipelining implementations reject clients
that pipeline input that *follows* EHLO/HELO and later commands.
They don't reject clients that talk before Postfix greets them.

To reject clients that talk before Postfix greets them, use
Postscreen's pregreet detection feature.

Wietse

[Jeffrey 'jf' Lim]

ok, thanks. How about my problems with setting 'smtpd_delay_reject =
no'? It just seems that with it smtpd_delay_reject set to 'no', the
rejection just isn't done (or detected?), for whatever reason.

-jf

[Wietse Venema]

Jeffrey 'jf' Lim:

Allow me to repeat my reply above:

Current reject_unauth_pipelining implementations [...] don't reject

clients that talk before Postfix greets them.

To reject clients that talk before Postfix greets them, use
Postscreen's pregreet detection feature.

Wietse

[Jeffrey 'jf' Lim]

Yes, I got that.

I also highlighted another question/issue I have in the 2nd part of my
question, where the pipelining occurs *after* ehlo/helo. In that case,
smtpd_delay_reject set to 'no' does not work. Should that be expected
behaviour?

-jf

[Wietse Venema]

Jeffrey 'jf' Lim:

> > Allow me to repeat my reply above:
> >
> > Current reject_unauth_pipelining implementations [...] don't reject
> > clients that talk before Postfix greets them.
> >
> > To reject clients that talk before Postfix greets them, use
> > Postscreen's pregreet detection feature.
> >
>
> Yes, I got that.
>
> I also highlighted another question/issue I have in the 2nd part of my
> question, where the pipelining occurs *after* ehlo/helo. In that case,
> smtpd_delay_reject set to 'no' does not work. Should that be expected
> behaviour?

That's a bug. As of Postfix 2.6, reject_unauth_pipelining works
only after the Postfix SMTP server has read input. I am currently
too busy with real work to fix that.

If you must block clients that talk too soon, use postscreen. It
does a much better job, and it even has a trick to make buggy
clients talk too soon.

Wietse

[Jeffrey 'jf' Lim]

On Mon, Jul 29, 2013 at 4:51 AM, Wietse Venema <wie...@porcupine.org> wrote:
> Jeffrey 'jf' Lim:
>> > Allow me to repeat my reply above:
>> >
>> > Current reject_unauth_pipelining implementations [...] don't reject
>> > clients that talk before Postfix greets them.
>> >
>> > To reject clients that talk before Postfix greets them, use
>> > Postscreen's pregreet detection feature.
>> >
>>
>> Yes, I got that.
>>
>> I also highlighted another question/issue I have in the 2nd part of my
>> question, where the pipelining occurs *after* ehlo/helo. In that case,
>> smtpd_delay_reject set to 'no' does not work. Should that be expected
>> behaviour?
>
> That's a bug. As of Postfix 2.6, reject_unauth_pipelining works
> only after the Postfix SMTP server has read input. I am currently
> too busy with real work to fix that.
>

I see. Thanks for the confirmation!

> If you must block clients that talk too soon, use postscreen. It
> does a much better job, and it even has a trick to make buggy
> clients talk too soon.
>

gotcha.

thanks,