smtp-sink shows one more empty EHLO option

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

smtp-sink shows one more empty EHLO option

Mark Martinec-5
Seems like the smtp-sink appends one empty EHLO option
at the end of its reply to an ehlo command.
Should this be fixed? - my content filter is currently logging
a warning, I wonder if I should remove the warning  :)

Using postfix-current-2.9.20111012 from FreeBSD ports.

$ smtp-sink 127.0.0.1:20025 30

$ telnet 127.0.0.1 20025  # connection to smtp-sink
220 smtp-sink ESMTP
ehlo test
250-smtp-sink
250-PIPELINING
250-8BITMIME
250-AUTH PLAIN LOGIN
250-XCLIENT NAME HELO
250-XFORWARD NAME ADDR PROTO HELO
250-ENHANCEDSTATUSCODES
250
quit
221 Bye

$ telnet 127.0.0.1 25   # connection to postfix, normal
220 mail.ijs.si ESMTP Postfix
ehlo test
250-mail.ijs.si
250-PIPELINING
250-SIZE 26214400
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
quit
221 2.0.0 Bye


  Mark
Reply | Threaded
Open this post in threaded view
|

Re: smtp-sink shows one more empty EHLO option

Wietse Venema
Mark Martinec:

> Seems like the smtp-sink appends one empty EHLO option
> at the end of its reply to an ehlo command.
> Should this be fixed? - my content filter is currently logging
> a warning, I wonder if I should remove the warning  :)
>
> Using postfix-current-2.9.20111012 from FreeBSD ports.
>
> $ smtp-sink 127.0.0.1:20025 30
>
> $ telnet 127.0.0.1 20025  # connection to smtp-sink
> 220 smtp-sink ESMTP
> ehlo test
> 250-smtp-sink
> 250-PIPELINING
> 250-8BITMIME
> 250-AUTH PLAIN LOGIN
> 250-XCLIENT NAME HELO
> 250-XFORWARD NAME ADDR PROTO HELO
> 250-ENHANCEDSTATUSCODES
> 250
> quit
> 221 Bye

Postfix is written not by imitation, but by following the specification.
When smtp-sink was written, that specification was RFC 821. In this
document appears the following text:

     The last line will begin with the reply code, followed
     immediately by <SP>, optionally some text, and <CRLF>.

If later RFC versions invalidate this aspect of RFC 821, then that
is unfortunate. I really can't revalidate every line of Postfix
source code whenever a new RFC comes out.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: smtp-sink shows one more empty EHLO option

Rod Dorman
On Thursday, October 27, 2011, 13:07:37, Wietse Venema wrote:

> Mark Martinec:
>> Seems like the smtp-sink appends one empty EHLO option
>> at the end of its reply to an ehlo command.
>> Should this be fixed? - my content filter is currently logging
>> a warning, I wonder if I should remove the warning  :)
>>
>> Using postfix-current-2.9.20111012 from FreeBSD ports.
>>
>> $ smtp-sink 127.0.0.1:20025 30
>>
>> $ telnet 127.0.0.1 20025  # connection to smtp-sink
>> 220 smtp-sink ESMTP
>> ehlo test
>> 250-smtp-sink
>> 250-PIPELINING
>> 250-8BITMIME
>> 250-AUTH PLAIN LOGIN
>> 250-XCLIENT NAME HELO
>> 250-XFORWARD NAME ADDR PROTO HELO
>> 250-ENHANCEDSTATUSCODES
>> 250
>> quit
>> 221 Bye
>
> Postfix is written not by imitation, but by following the specification.
> When smtp-sink was written, that specification was RFC 821. In this
> document appears the following text:
>
>      The last line will begin with the reply code, followed
>      immediately by <SP>, optionally some text, and <CRLF>.
>
> If later RFC versions invalidate this aspect of RFC 821, then that
> is unfortunate. I really can't revalidate every line of Postfix
> source code whenever a new RFC comes out.

Nope, RFC 2821 and RFC 5321 still has the same text.

It even goes on to say
  As noted above, servers SHOULD send the <SP> if subsequent text
  is not sent, but clients MUST be prepared for it to be omitted.

--
[hidden email]     "The avalanche has already started, it is too
Rod Dorman              late for the pebbles to vote." - Ambassador Kosh


Reply | Threaded
Open this post in threaded view
|

Re: smtp-sink shows one more empty EHLO option

Mark Martinec-5
> Nope, RFC 2821 and RFC 5321 still has the same text.
> It even goes on to say ...

RFC 5321 does not allow empty ehlo-keyword:

section 4.1.1.1:

   ehlo-ok-rsp    = ( "250" SP Domain [ SP ehlo-greet ] CRLF )
                    / ( "250-" Domain [ SP ehlo-greet ] CRLF
                    *( "250-" ehlo-line CRLF )
                    "250" SP ehlo-line CRLF )

   ehlo-line      = ehlo-keyword *( SP ehlo-param )

   ehlo-keyword   = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
                    ; additional syntax of ehlo-params depends on
                    ; ehlo-keyword


and neither does RFC 2821.

  Mark
Reply | Threaded
Open this post in threaded view
|

Re: smtp-sink shows one more empty EHLO option

Wietse Venema
Mark Martinec:

> > Nope, RFC 2821 and RFC 5321 still has the same text.
> > It even goes on to say ...
>
> RFC 5321 does not allow empty ehlo-keyword:
>
> section 4.1.1.1:
>
>    ehlo-ok-rsp    = ( "250" SP Domain [ SP ehlo-greet ] CRLF )
>                     / ( "250-" Domain [ SP ehlo-greet ] CRLF
>                     *( "250-" ehlo-line CRLF )
>                     "250" SP ehlo-line CRLF )
>
>    ehlo-line      = ehlo-keyword *( SP ehlo-param )
>
>    ehlo-keyword   = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
>                     ; additional syntax of ehlo-params depends on
>                     ; ehlo-keyword
>
>
> and neither does RFC 2821.
 
Please read RFC documents carefully. RFC 5321 says that the ABNF
is not authoritative.

    The metalinguistic notation used in this document corresponds to the
    "Augmented BNF" used in other Internet mail system documents.
    [...]
    The reader is cautioned that the grammar expressed in the
    metalanguage is not comprehensive.  There are many instances in which
    provisions in the text constrain or otherwise modify the syntax or
    semantics implied by the grammar.

For this reason, the text that defines multi-line responses takes
precedence over the grammar for specific replies.  The text says
that in the last line of a multi-line reply, the text between SP
and CRLF is optional. This text makes no exceptions for EHLO, and
that is a good thing.

        Wietse