From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 07 13:27:18 2022 Received: (at 56046) by debbugs.gnu.org; 7 Jul 2022 17:27:18 +0000 Received: from localhost ([127.0.0.1]:57770 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o9VHa-0003Cm-9h for submit@debbugs.gnu.org; Thu, 07 Jul 2022 13:27:18 -0400 Received: from mx1.dismail.de ([78.46.223.134]:19716) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o9VHX-0003CX-Ky for 56046@debbugs.gnu.org; Thu, 07 Jul 2022 13:27:16 -0400 Received: from mx1.dismail.de (localhost [127.0.0.1]) by mx1.dismail.de (OpenSMTPD) with ESMTP id 8a5a8c96; Thu, 7 Jul 2022 19:27:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=dismail.de; h= mime-version:date:content-type:content-transfer-encoding:from :message-id:subject:to:in-reply-to:references; s=20190914; bh=KK FthKd3VPVD4OaTYVTeHhHA4n5uu4SnNIdgq3XKyj4=; b=aFOMhEax1erZyLmV57 cxp9JQNWsd43eB4Mh4Ei2xvGILWSa3lOoe1vOG2wkq3OOH7RoS8uSkvnFq3va1hW mdsSOI2OG8dmuKUg80cEORyJCpCG4viFdvw7R+UnGRBjqTtw35CYJ2gKX4xrEXvb tYuWszs3m6n+cjxRykiB9oU9PEvUASBS6F5spU51HGMGUGGP9jF8b1ezjmzkYn4j +lsUtOD2cqMjFHFCVU1dICkaISlbw/xxKUEsufmLo49qzehdI2oWzQvTeaubMHAa 09nmYwiX/s1jtWFS3RxWmBqvjojdEXYmMLziGtf74sgAN3NMPr2Mi+lKk/mnGJQz tCgw== Received: from smtp2.dismail.de ( [10.240.26.12]) by mx1.dismail.de (OpenSMTPD) with ESMTP id 122b0778; Thu, 7 Jul 2022 19:27:07 +0200 (CEST) Received: from smtp2.dismail.de (localhost [127.0.0.1]) by smtp2.dismail.de (OpenSMTPD) with ESMTP id 7d3c90f9; Thu, 7 Jul 2022 19:27:07 +0200 (CEST) Received: by dismail.de (OpenSMTPD) with ESMTPSA id 0992026e (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 7 Jul 2022 19:27:07 +0200 (CEST) MIME-Version: 1.0 Date: Thu, 07 Jul 2022 17:27:06 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: RainLoop/1.16.0a From: jbranso@dismail.de Message-ID: <338cfc2ca96492218838280d8961bef7@dismail.de> Subject: Re: [PATCH] services: mail: add opensmtpd records to enhance opensmtpd-configuration. Version 2 To: "Liliana Marie Prikler" , 56046@debbugs.gnu.org In-Reply-To: References: <756a905107d7783bab238091d668fddbc1e712ab.camel@gmail.com> <20220704211759.8314-1-jbranso@dismail.de> <6a272ff438ca4e2efc8e196c9160f857@dismail.de> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 56046 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) July 7, 2022 2:48 AM, "Liliana Marie Prikler" = wrote: > Am Mittwoch, dem 06.07.2022 um 21:51 +0000 schrieb jbranso@dismail.de: >=20 >>=20I do not believe that guile has a file-exists? thunk.=20 >>=20I could use (access? file F_OK) every time, but I think >> file-exists? is easier to use. My two cents. >=20 >=20scheme@(guile-user)> file-exists? > $1 =3D # ok. Good to know! >=20 >>=20What is a "listen-on"? >>=20 >>=20"listen-on" refers to the "listen on" in smtpd.conf: >> https://man.openbsd.org/smtpd.conf >>=20 >>=20lan_addr =3D "192.168.0.1" >> listen on $lan_addr >> listen on $lan_addr tls auth >=20 >=20Okay, but what would you call that? An address maybe? >=20 >>>=20+(define-record-type* >> configuration> >>=20 >>=20Again, could this just be ? >>=20 >>=20I would prefer to have two data types for "listen on" and >> "listen on socket". "listen on socket" only supports 3 options, >> where "listen on" supports 19. >=20 >=20I am not questioning whether it makes sense to add a configuration > record =E2=80=93 it probably does =E2=80=93 but whether you're using th= e best name for > that record. We are not Java programmers here, a little abstraction > goes a long way. >=20 >>=20From the documentation: >>=20 >>=20listen on interface [family] [options] >> Listen on the interface for incoming connections, using the same >> syntax as ifconfig(8). The interface parameter may also be an >> interface group, an IP address, or a domain name. Listening can >> optionally be restricted to a specific address family, which can be >> either inet4 or inet6. >>=20 >>=20listen on socket [options] >> Listen for incoming SMTP connections on the Unix domain socket >> /var/run/smtpd.sock. This is done by default, even if the directive >> is absent. >=20 >=20So you can either have an opensmtp-interface (with family and a bunch > of options) or an opensmtp-socket (with a bunch of options). Sounds > like a much nicer ontology, doesn't it? That does make much more sense! I'll do that. >=20 >>>=20[...] >>=20 >>=20Too much to check, too little time. Maybe return later. >>=20 To=20summarize the updated tasks that you have given me are: =20 =201) Write a proper changelog. 2) define "string-in-list?" with member? Are there other procedures that could use this? 3) DONE replace [] with () 4) Shorten the sanitize procedure for opensmtpd-option-configuration 5) Review your class names. I also don't think it makes too much sense to add -configuration for anything but the top-level configuration record, it just requires you to type much more configuration than you probably want. Also does guix have a style guide for writing services? Do we usually only put "-configuration" for the top level configuration? Is that the current style recommendations? =20 eg:=20rename opensmtpd-listen-on-configuration and opensmtpd-listen-on-socket-configuration to opensmtpd-interface and opensmtpd-socket.