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

>> 
>> Generally ok with the idea of introducing F_SUBMISSION, also ok with the idea
>> to later introduce a listener mode (though I think keyword "submission" would
>> be better as "msa" will confuse most users).
>> 
>> I'm however not sure about adding port 465 as part of this diff, smtps is not
>> necessarily a submission port: private mail networks may mandate its use even
>> for MX to MX communications, and all sessions would be flagged incorrectly as
>> submission with this diff.
> 
> We already have "submission" in smtpd.conf(5). It's not documented in
> the man page.
> 
> listen ... port submission
> 
> If we need to keep backwards compatibility for users using
> 
> listen ... port submissions
> 


it's not documented because it's not a keyword but a service name to be resolved
by getservbyname(3):


		| PORT STRING			{
			struct servent	*servent;

			[...]

			servent = getservbyname($2, "tcp");

			[...]

			listen_opts.port = ntohs(servent->s_port);
		}


I'm not sure I understand the backwards compatibility comment, sorry



> as in RFC 8314 - there is no other way than to add a new option mutually
> exclusive with port. What about this:
> 
> listen on egress service smtp
> listen on egress service submission
> listen on egress service submissions
> 

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 ?



> or
> 
> listen on egress services {smtp,submission,submissions}.
> 
> This would allow us to get rid of comparing hard coded port numbers as
> well. For example, a listener is providing the submission(s) service, so
> we know the port and all the other options by default and can set flags
> based on that. Same for service submission.
> 
> submission - RFC 6409
> submissions - RFC 8314
> 
> Maybe we first settle on the grammar to use. I find this way more
> expressive than "port 587" + tons of options to get MSA behaviour when
> "service submission" can be used to set all the recommended flags
> automatically. The port option already supports service names and
> already uses getservbyname(3). We could do the same with a new service
> option and can retain backwards compatibility this way. I'll write a
> patch for this the next days.
> 

I think the first step is figuring out the answer to my interrogation above
because we don't want new configuration constructions if unncessary.



>> Since the code has assumed 587 == submission for a long time without any user
>> complaining, we might want to just introduce F_SUBMISSION on local and 587 as
>> a first step, it would be iso with today's behavior, then we can work on that
>> mode for listeners and let users set mode themselves for port 587 and 465.
>> 
>> I also need to read RFC 6409 before I comment further, I have an intuition we
>> can be smarter than this but I need to be sure it is legal: shouldn't we flag
>> F_SUBMISSION any mail that was submitted from an authenticated session ?
> 
> Maybe. I am keen on 5.2 from RFC 6409 and all possible ways to at least
> inform a user or an operator that something is really wrong so that
> things don't go through unnoticed.
>