September 6, 2024 12:25 PM, "Christian Schulte" <schulte.it@gmail.com> wrote:

>>> 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.

I disagree, because from where I stand I can look at any config I wrote in
the last 20 years and I'd be able to flag the submission sessions properly
on all of them without introducing change to the config nor looking at the
ports.

Given that we try to never introduce configuration changes unless they are
required, it is very important that we question if there are examples that
disprove the understanding we have of an issue.

I won't ok or commit a diff for a non-blocking issue that close to 7.6, so
we might as well take time to do things right for 7.7


> Is there any way to decide if a client is a MUA or an MTA?
> That is what this decision is about.

Well I think for the very vast majority of cases, we can, so unless I miss
the point completely, there's already a lot we can do for the default case
without introducing any configuration change.


> 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.

no, this won't work, we can't rely on ports for this


> 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
> 

Yes, I understood your idea, but before we introduce such a change I must
be confident it was required and at this point I'm not convinced as I can
identify transfer from submission on any port by looking at session and I
am pretty sure it'll work for the vast majority of cases.

If that's true, the discussion shifts from changing configuration for all
users to changing configuration for the corner cases that are not covered
by the default behavior, something that bothers me less.