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

[Michael Peddemors <[e-mail]>]

On 2023-03-29 05:00, Andrew C Aitchison wrote:
> 
> 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,
> 

Thanks.. ticketed for next draft update, be more clear on this topic, 
but CLIENTID is designed for authentication.

EHLO->STARTTLS->CLIENTID->MAIL FROM 'technically' is allowed in this 
current iteration, but of course if AUTH is required that is separate 
from the CLIENTID interaction.  It was left that way in case there is 
another form of authentication that is external, that we haven't 
considered, eg AUTH not required from a specific IP Address for example.

Do you feel that the Draft should be more specific in this regard, and 
explicitly require AUTH after CLIENTID?

(off topic, our servers would have failed you the same way even if you 
hadn't sent CLIENTID, given that the MAIL FROM is not an address an 
address this server is responsible for, and you are connecting to a 
SUBMISSION port, OR you are using an address that IS on this server, and 
you did NOT present AUTH before MAIL FROM)



-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.