Re: [Mailsec] CLIENTID and ESMTP and LMTP Transmission Types Registration

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

On Tue, 28 Mar 2023, Michael Peddemors wrote:

> On 2023-03-27 10:10, Andrew C Aitchison wrote:
> >
> > [ I am attempting to implement CLIENTID for Exim the MTA. ]
> >
> > https://www.rfc-editor.org/rfc/rfc3848
> > added ESMTPA, ESMTPS, ESMTPSA, LMTP, LMTPA, LMTPS and LMTPSA
> > to SMTP and ESMTP for use in the "with" clause of a Received
> > header in an Internet message.
> >
> > Would we want CLIENTID to add to this list ?
> > My thought is that this would risk leaking information
> > which might allow a third party to infer facts about the
> > heuristics or rules used, so my guess is "no".
> >
> > If we *did* decide to add to this list, would ESMTPSC and ESMTPSCA
> > be sufficient, or do we want LMTPSC and LMTPSCA too ?

> and since this is limited to authentication at this time,
> I don't see even where ESMTPS would be used,
> but someone else might have an argument for that use case.

If
    EHLO - STARTTLS - CLIENTID - MAIL FROM:
is valid, that would be ESMTPS rather than ESMTPSA.

I suppose you could read that into Section 4, fifth restriction:
    An SMTP client MUST issue any CLIENTID commands prior to
    issuing an [AUTH] command.
but I had not read that as saying that an AUTH is required between
CLIENTID and MAIL FROM: (just that CLIENTID is not valid after AUTH).

I see that your servers do reject that pattern, with
501 Rejecting MAIL FROM, Return Sender address not accepted by policy (#5.5.2)
but I don't see anything in the draft rfc that requires that rejection.

Thanks,

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