Re: XCLIENT/STARTTLS interaction

[Wietse Venema]

John Jetmore:
> On Mon, Oct 30, 2017 at 3:34 PM, Noel Jones  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

Re: XCLIENT/STARTTLS interaction

[John Jetmore]

On Mon, Oct 30, 2017 at 3:34 PM, Noel Jones  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.

--John

Re: XCLIENT/STARTTLS interaction

[Noel Jones]

On 10/30/2017 1:43 PM, John Jetmore wrote:
> (Apologies if this is a duplicate post. I sent the first one before
> I confirmed my list membership and I don't see it in the online
> archives so I am assuming it wasn't sent)
> 
> Hi postfix-users.  I am the author of the swaks SMTP tool.  A user
> pointed out to me recently that swaks, postfix, xclient, and
> starttls don't play well together.
> 
> If a user requests both STARTTLS and XCLIENT, swaks attempts XCLIENT
> first.  This result (for the swaks user) in:
> 
> 530 5.7.0 Must issue a STARTTLS command first
> 
> As far as I can tell, postfix owns the XCLIENT extension and is
> solely defined here: http://www.postfix.org/XCLIENT_README.html
> .
> 
> Some hopefully quick questions:
> 
> 1. Is the URL above the authoritative document for how XCLIENT
> behaves?  I was unable to find anything else
> 
> 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?
> 
> 3.  XCLIENT_README.html doesn't mention the order (there's only one
> brief mention of TLS) and it also uses the language "The XCLIENT
> command may be sent at any time, except in the middle of a mail
> delivery transaction (i.e. between MAIL and DOT, or MAIL and RSET)"
> which makes it sound like it should be agnostic about the order.  I
> suspect I'm going to be told that STARTTLS must always come first,
> no exceptions, in which case noting that in the doc might be worthwhile.
> 
> Thanks
> --John


Thanks for your useful swaks tool!  I've used it quit a bit.

Yes, the postfix XCLIENT_README is the authoritative documentation
for the XCLIENT extension.

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.





  -- Noel Jones