On 04.09.24 01:05, gilles@poolp.org wrote:
> September 4, 2024 12:47 AM, "Christian Schulte" <schulte.it@gmail.com> wrote:
> 
>> On 04.09.24 00:05, gilles@poolp.org wrote:
>>
>>> I'm not sure this is true:
>>>
>>> Submission *normally* takes place on port 587 but it may take place on port 25
>>> with optional auth and in this case you can no longer express it this way, and
>>> we start needing other knobs to be introduced.
>>>
>>> Genuine interrogation:
>>>
>>> Is there a case where a session authenticates (implying TLS / SMTPS regardless
>>> of any port), submits a message and that message shouldn't be F_SUBMISSION ?
>>
>> AUTH got introduced to mitigate against open relays - access control.
>>
>> "Relaying denied. Authentication required."
>>
>> In my personal setup, I am running OpenSMTPD locally on my laptop setup
>> to use a smarthost it needs to authenticate to, so that the smarthost
>> allows relaying. In that scenario the smarthost would not be the
>> submitting agent, but just a relay. Not the first hop. It would not do
>> any harm if that smarthost would apply submission semantics, even if it
>> is the second hop, as the first hop already performed submission semantics.
>>
> 
> Precisely.
> 
> In this case, the smarthost can unconditionally apply submission semantic
> on authenticated sessions without harm.
> 
> 
> 
>> That's just about the relaying part. If I would send a mail from the
>> laptop to a local user at that smarthost - so no relaying taking place -
>> this would work without authentication. In that scenario the smarthost
>> could not decide between submission or transfer based on authentication,
>> although the laptop would have authenticated either way.
>>
> 
> Unsure I understand your example.
> 
> smtp-in.poolp.org is my primary MX but it is also a smarthost for my workstation,
> my mail address can be reached through both paths.
> 
> Can you provide me with an example where I can't decide submission or transfer on
> that setup based on authentication ?
> 

I think that's not the point here. Is there any way to decide if a
client is a MUA or an MTA? That is what this decision is about. You
could decide this based on the port/service a client is connecting to,
just because no MTA will ever connect to something else than port 25.
But this leaves us to users of OpenSMTPD abusing port 25 as a way to
submit messages into the network. That's the whole point of splitting
transfer from submission by using different ports/services. My thinking
is to really introduce

listen ... service submission
listen ... service submissions
listen ... service smtp

in a way to switch to a convention over configuration kind of setup.
There is the port keyword, everyone can (a)buse to setup things the way
they like. Not for the service keyword. This keyword would apply
conventions, so that would really mean that "service smtp" would apply
rules according to MTA behaviour and would not allow anyone from setting
any flags not according to the convention of "service smtp". Everyone is
free to choose the "port submission" or whatever way they think fit. As
soon, as someone starts using "service whatever", conventions apply and
there is no way to change behaviour not in agreement with the various
RFCs (MTA, MSA, submission, submissions, etc.).

-- 
Christian