From nobody Sun Jan 30 14:01:33 2022 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2DDF5198FE45 for ; Sun, 30 Jan 2022 14:01:45 +0000 (UTC) (envelope-from fm-7517-20220130140134635822a728a3855306-MmR4lo@rts-flowmailer.siemens.com) Received: from mta-64-227.siemens.flowmailer.net (mta-64-227.siemens.flowmailer.net [185.136.64.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JmtCq5LnLz5377 for ; Sun, 30 Jan 2022 14:01:43 +0000 (UTC) (envelope-from fm-7517-20220130140134635822a728a3855306-MmR4lo@rts-flowmailer.siemens.com) Received: by mta-64-227.siemens.flowmailer.net with ESMTPSA id 20220130140134635822a728a3855306 for ; Sun, 30 Jan 2022 15:01:34 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=fm1; d=siemens.com; i=michael.osipov@siemens.com; h=Date:From:Subject:To:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To; bh=lpNDNo0TQpZXW6Of7rZQip1To8S5cs1R2a+iabgsadI=; b=OS1UhWvLdBw/jF4d2CzSLB1DD6tQVPEGB+Da8MsBb5NYhqIyuLijxvtv996FZeH3zumfoU +D1OfP/l2sY3ZFDbji5Cgweo/+5WZjG5X5LsFt8Qwmz4fkYAiHVDYtMLcjvdzlx+NO0K4BET BFOkd0lS8F8Hq6jr3rXrzeAtKANGc=; Message-ID: <835dc887-6491-602c-7d71-d99309871126@siemens.com> Date: Sun, 30 Jan 2022 15:01:33 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: michael.osipov@siemens.com Subject: Re: Dragonfly Mail Agent (dma) in the base system Content-Language: de-DE In-Reply-To: To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Flowmailer-Platform: Siemens Feedback-ID: 519:519-7517:519-21489:flowmailer X-Rspamd-Queue-Id: 4JmtCq5LnLz5377 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=siemens.com header.s=fm1 header.b=OS1UhWvL; dmarc=pass (policy=none) header.from=siemens.com; spf=pass (mx1.freebsd.org: domain of fm-7517-20220130140134635822a728a3855306-MmR4lo@rts-flowmailer.siemens.com designates 185.136.64.227 as permitted sender) smtp.mailfrom=fm-7517-20220130140134635822a728a3855306-MmR4lo@rts-flowmailer.siemens.com X-Spamd-Result: default: False [-3.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[185.136.64.227:from]; R_SPF_ALLOW(-0.20)[+ip4:185.136.64.224/29]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[siemens.com:+]; DMARC_POLICY_ALLOW(-0.50)[siemens.com,none]; FORGED_SENDER(0.30)[michael.osipov@siemens.com,fm-7517-20220130140134635822a728a3855306-MmR4lo@rts-flowmailer.siemens.com]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:50018, ipnet:185.136.64.0/24, country:NL]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[michael.osipov@siemens.com,fm-7517-20220130140134635822a728a3855306-MmR4lo@rts-flowmailer.siemens.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[siemens.com:s=fm1]; DWL_DNSWL_MED(-2.00)[siemens.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(1.00)[1.000]; FROM_NO_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[185.136.64.227:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Ed, thanks for raising, this is just on time for us. I'd like to describe what both cover and not cover and I would expect from a minimal MTA. I am on 12-STABLE/12.3-RELEASE. We solely use sendmail with relay via sendmail invocation or SMTP on localhost:25. Minimal configuration for scripts and applications running on hosts and jails. Our current corporate messaging service is being phased out for a new one which requires authentication via LOGIN or PLAIN and mandatory STARTTLS, previous was anonymous and unencrypted. Sendmail: The biggest problem is that authentication strictly requires Cyrus SASL, even for stupid ones like PLAIN/LOGIN, accourding to the handbook you must recompile sendmail from base with Cyrus SASL from ports to make this possible. A showstopper actually, for two reasons: 1. I don't like mixing base and ports, it just creates a messy system. 2. While this may work with hosts, when you have jails running off a RELEASE in Bastille this obviously will not work. Not going to work with sendmail easily. DMA: Disclaimer: I haven't tried, but read documentation and source code. Although it supports TLS, I don't see any of these [1], I fail to see how it verifies the peer. I have never seen something to provide the server's fingerprint to verification. It very much feels like an SSH-like approach. It does not listen, as documented, on localhost, so applications supporting SMTP only will need extra configuration to reach out to the relay host directly. Central config at MTA side not possible anymore. Although, I don't need certificate-based authentication against the relay and DMA supports it, it does not support of using a passphrase for the certificate key file like HTTPd supports through mod_ssl. Should be a no-brainer these days. Requirements for a simplistic MTA with a relay host: * Support TLS or STARTTLS through OpenSSL in base * Verify server's certificate chain against default certstore (/etc/ssl/certs) and log success/failure, e.g, sendmail does this after config * Properly rewrite FROM for local users user@localhost or even <> when delivered with sendmail executable * Accept messages on localhost:25 or a configurable loopback address in general (e.g., multihomed with cloned interface and jails) for those applications which only support SMTP (e.g., Java Mail or other programming libraries) The issues with certificates and OpenSSL in the base system I have already extensively dicussed with kevans@ [2]. I hope this can be put into consideration. Regards, Michael [1] https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_default_verify_paths.html [2] https://reviews.freebsd.org/D31487#710650