From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mimir.eigenstate.org ([206.124.132.107]) by ewsd; Sun Oct 4 19:35:47 -0400 2020 Received: from abbatoir.fios-router.home (pool-74-101-2-6.nycmny.fios.verizon.net [74.101.2.6]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id f562f746 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO); Sun, 4 Oct 2020 16:35:37 -0700 (PDT) Message-ID: <8B0E324EB486017F84E81FD02A1C4D2D@eigenstate.org> To: ori@eigenstate.org, sl@stanleylieber.com, 9front@9front.org Subject: Re: [9front] /mail/lib: cleanup proposal Date: Sun, 04 Oct 2020 16:35:36 -0700 From: ori@eigenstate.org In-Reply-To: <244F88C3BD79577CE92C0A3495FBC369@eigenstate.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: encrypted managed realtime-oriented replication content-driven-based optimizer >> > I think this would make it easier to figure out what's going >> > on with upas configuration, and get a working system. >> > >> > Thoughts? Complaints? "Don't touch the artwork!"? >> >> please keep in mind all our shit (read: this mailing list, and my >> personal mail) runs on upas before committing breaking changes. > > Yep, definitely. That's why I'm trying to validate my assumptions > on what's actually considered configuration, and what's dumped > in there. > > Note, /mail/lib isn't in hg, so sysupdate doesn't touch it. > The changes I'm proposing would be in the defaults for new > installs. > > Any breakage would be from changes in /sys/src/cmd/upas, and > I don't see any problem with keeping things compatible. At > most it'd mean checking an extra path to decide what command > to run. > >> strongly in favor of simplifying setup. whatever we're currently >> shipping is the remnants of what actually ran at the labs. all that >> configuration (anti-spam, etc.) was theirs. i got all my own stuff >> working by reading the man pages and trial and error. > > Yeah. I'm doing that now as well for testing the smtpd changes > for date and time. I'm realizing that this stuff is simpler than > it looks, but the example config really overcomplicates things. > >> i thought incoming messages were piped through qmail somewhere along >> the line. > > Ah, I missed it in the rewrite file. Thanks for the cross check. So, after messing around with this over the weekend, I think I have a reasonable few defaults for /mail/lib. The files that we need for reasonable defaults to send mail: /mail/lib/ignore /mail/lib/qmail /mail/lib/remotemail /mail/lib/rewrite I'd like to make upas/fs use reasonable defaults for the ignore file so we can remove it (and maybe flip it to a keephdr file). I've also rewritten remotemail, so that it uses factotum to figure out where to send to. That means that configuring mail is adding upasname=user@server.com to your environment, and adding an 'email=user@server.com' to your smtp factotum key so we can decide which smtp server to use: echo 'key proto=pass server=server.com ' \ 'service=smtp user=user >>email=user@server.com<< !password=12345' Here's the rewritten remotemail: #!/bin/rc # allow users to do their own mail setup if(test -x $home/lib/mail/remotemail) exec $home/mail/lib/remotemail sender=$2 svcpat='[ ]service=smtp[ ]' addrpat='[ ]email='$2'[ ]' config=`{grep -e $svcpat -e $addrpat /mnt/factotum/ctl} if(~ $#config 0) exit 'no server' for(kv in $config){ parts=`'='{echo -n $kv} switch($parts(1)){ case server; server=$parts(2) case user; login=$parts(2) } } exec /bin/upas/smtp -as -u $login $server $addr $sender $*(4-) The ignore and qmail files are the same as we ship today. The rewrite rules are the same as our cureent rewrite.gateway, though I want to slim it down a bit, or at least comment it better. Separate mail incoming for that. The other files seem like they can become examples -- I'll look at putting together a proposal for some example configurations that we can ship separately. Is there anything that this setup is missing? Is there some edge case that this will break on?