John Jetmore:
> On Mon, Oct 30, 2017 at 3:34 PM, Noel Jones <njo...@megan.vbhcs.org> wrote:
>
> > On 10/30/2017 1:43 PM, John Jetmore wrote:
> > > 2. Is it correct that STARTTLS must always precede XCLIENT? It
> > > appears that postfix owns the XCLIENT extension, is there any
> > > non-postfix implementor for whom the order might be different or
> > > more lax?
> >
>
>
> > Your other questions are answered in RFC3207 and RFC7817 which
> > describe the behavior of STARTTLS with SMTP.
> >
> > Two important points from those RFCs: If a client is configured to
> > require STARTTLS it may refuse other commands. Secondly, after
> > STARTTLS completes, all previous state must be discarded and the
> > conversation restarts.
> >
> > Those two points should make it clear that STARTTLS must be sent
> > before other commands. This isn't really a postfix issue, but rather
> > a protocol issue.
>
>
> I think my thought process when implementing it was that doing XCLIENT
> first would allow you to test possible connection-specific TLS
> configurations. But I'm here to interact with reality, not to dictate it,
> so I'm happy to change it around and work. Thanks for your response, Noel.
Hmm.. XCLIENT's main purpose is impersonation, and the feature is
restricted with an access list to prevent misuse, so one could argue
that XCLIENT should be allowed to take precedence.
I could change that, but only in Postfix 3.3, as features are not
added to stable releases, and this is not an emergency.
Wietse
