From: Christian Schulte Subject: Re: smtpd(8) should add missing date and message id headers also on port 465 To: gilles@poolp.org, tech@openbsd.org Date: Tue, 3 Sep 2024 23:25:05 +0200 On 03.09.24 14:41, gilles@poolp.org wrote: > September 3, 2024 12:04 AM, "Christian Schulte" wrote: > >> This adds a new flag F_SUBMISSION to be used to decide if a listener >> is to be operating as an MSA and moves the existing logic deciding this >> into where listeners are configured (parse.y). >> >> This could later be extended and used to do more checks or verifications >> based on RFC 6409. Only functional difference is that port 465 is handled >> the same way as port 587. >> >> Maybe a new listener option msa (!msa) can be introduced in a later step >> giving users a chance to control the behaviour themselves and stop >> deciding this automatically based on port numbers. No changes to the >> smtpd.conf(5) format for now. >> >> Ok? >> > > 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 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 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. > > 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. -- Christian