[Mailsec] CLIENTID with PIPELINING

[Andrew C Aitchison <[e-mail]>]

I am attempting to implement CLIENTID for Exim.

draft-storey-smtp-client-id-14.txt does not mention pipelining.

Would it be reasonable for the next draft to make a statement about
whether or not CLIENTID can be pipelined and/or must be synchronised ?

The Exim code  has:

/* RFC3030 section 2: "After all MAIL and RCPT responses are collected
   and processed the message is sent using a series of BDAT commands"
   implies that BDAT should be synchronised.  However, we see Google,
   at least, sending MAIL,RCPT,BDAT-LAST in a single packet, clearly
   not waiting for processing of the RCPT response(s).  We shall do the
   same, and not require synch for BDAT.  Worse, as the chunk may (very
   likely will) follow the command-header in the same packet we cannot
   do the usual "is there any follow-on data after the command line"
   even for non-pipeline mode.  So we'll need an explicit check after
   reading the expected chunk amount when non-pipe, before sending the
   ACK. */

Mad as it may be, Exim also accepts AUTH *when pipelining* - the code has
   /* I have been unable to find a statement about the use of pipelining
   with AUTH, so to be on the safe side it is here [in the list of
   non-sync commands when not pipelining], though I kind of feel
   it should be up there with the synchronized commands. */

Presumably STARTTLS and CLIENTID commands cannot be sent together,
since the CLIENTID must be encrypted, but
I would like to at least to know whether or not it is valid
for the CLIENTID and AUTH commands to be sent together.

As the Exim comments show,
if the RFC doesn't forbid it, developers have to allow for it.

Thanks,

-- 
Andrew C. Aitchison                      Kendal, UK
                    [e-mail]