Loading ...
Sorry, an error occurred while loading the content.

Re: smtpd_client_restrictions = reject_unauth_pipelining weirdness

Expand Messages
  • 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
    Message 1 of 7 , Jul 28, 2013
    • 0 Attachment
      On Mon, Jul 29, 2013 at 3:56 AM, Wietse Venema <wietse@...> wrote:
      > 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.
      >

      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
      ... Allow me to repeat my reply above: Current reject_unauth_pipelining implementations [...] don t reject clients that talk before Postfix greets them. To
      Message 2 of 7 , Jul 28, 2013
      • 0 Attachment
        Jeffrey 'jf' Lim:
        > On Mon, Jul 29, 2013 at 3:56 AM, Wietse Venema <wietse@...> wrote:
        > > 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.
        > >
        >
        > 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.

        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
        Message 3 of 7 , Jul 28, 2013
        • 0 Attachment
          On Mon, Jul 29, 2013 at 4:13 AM, Wietse Venema <wietse@...> wrote:
          > Jeffrey 'jf' Lim:
          >> On Mon, Jul 29, 2013 at 3:56 AM, Wietse Venema <wietse@...> wrote:
          >> > 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.
          >> >
          >>
          >> 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.
          >
          > 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?

          -jf
        • Wietse Venema
          ... 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
          Message 4 of 7 , Jul 28, 2013
          • 0 Attachment
            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
            ... I see. Thanks for the confirmation! ... gotcha. thanks, -jf -- He who settles on the idea of the intelligent man as a static entity only shows himself to
            Message 5 of 7 , Jul 28, 2013
            • 0 Attachment
              On Mon, Jul 29, 2013 at 4:51 AM, Wietse Venema <wietse@...> 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,
              -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
            Your message has been successfully submitted and would be delivered to recipients shortly.