From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from 104.59.85.219 ([104.59.85.219]) by ewsd; Sun Sep 20 17:27:24 EDT 2020 Date: Sun, 20 Sep 2020 17:27:19 -0400 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9front] /mail/lib: cleanup proposal To: 9front@9front.org From: Stanley Lieber Message-ID: <5B3C3AFC-BBCB-45E2-95C8-D0C40C5C3400@stanleylieber.com> List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: persistence template CSS layer On September 20, 2020 2:05:01 PM EDT, ori@eigenstate=2Eorg wrote: >While it's fresh in my mind, I'm looking at /mail/lib=2E There >are a lot of example files there, and it's a bit confusing >what needs to be configured, when the scripts are invoked, >what's intended to be configuration, and what's probably >best to leave alone=2E > >What I'd like is to ship 9ront up with a minimal config >that works out of the box for sending email through a >remote SMTP server=2E Ideally, all we'd need would be >setting a from address, and adding the keys in factotum=2E > >In an ideal world, I'd just have to do: > > echo 'ori@eigenstate=2Eorg' >> $home/lib/mail/sender > >I'd also like to take a minimal config for receiving email >on @EXAMPLE=2ECOM and put that into a separate directory, like: > > /mail/lib/example=2Edirect > >For that, I need to understand what exactly belongs in a >config, and what it does=2E > >So, to that end, here's my (likely wrong) understanding >of what the files in /lib/mail do, and whether we actually >need them=2E > >It seems like the shit in /mail/lib falls into five >categories: > - Config (and scripts that act as config) > - Example config (which isn't labelled as such) > - Bodies for /bin/upas/foo stubs > - State for upas programs > - Admin utilities not invoked by the mail system > >So, my current understanding of the files: > > blocked: > optional; a list of ip addresses that are probably > spammy=2E Horribly out of date, should probably not > be in our default config=2E >=09 > classify=2Ere: > useful for mail servers, but not human config, can > we move to a place that makes it clear? /mail/state, > or something? >=09 > gone=2Efishing: > optional: away message handling=2E would like to > document, but not put into the example config=2E >=09 > gone=2Emsg: > see above=2E >=09 > ignore: > needed, but why? a list of headers for upas/fs > to filter out=2E I don't think any of our mail > clients show the headers raw, seems like we > can drop this file=2E=2E=2E? >=09 > isspam=2Erc: > spam=2Erc: > unspam=2Erc: > msgcat=2Erc: > mandatory and not config=2E Exec'ed by /bin/upas/isspam; > doesn't seem to be intended for edits by user=2E would > like to the contents to /bin/upas/isspam, and maybe > add an 'if(test -f /mail/lib/isspam=2Erc) exec=2E=2E=2E' for > allowing customization=2E >=09 > At the very least, would like to move out of /mail/lib > to a place that makes it clear it's probably not > for users to touch in most cases=2E /mail/rc? /mail/lib/rc? >=09 > justqmail: > optional? admin script? used by lazyqmail >=09 > kickqueue: > optional? admin util; do we need to have this > in /lib/mail? >=09 > mailnews: > obsolete: seems to be a util for sending newsletters > about plan 9 to a list of subscribers=2E >=09 > namefiles: > mandatory for smtpd: a list of alias lists; needed for > smtpd config, not for local mailing=2E >=09 > names=2Elocal: > mandatory for smtpd: the alias list included by namefiles=2E >=09 > patterns: > optional=2E hardcoded spam regexes -- horribly out > of date, probably not useful any more for fighting > spam=2E If you want to get the same effect, you can > probably do better with a pipeto; I'd like to > delete support entirely=2E >=09 > pipeto=2Ebayes: > optional: an example of how to send email to our > bayesian spam filter=2E upas/bayes needs documentation=2E >=09 > pipeto=2Elib: > not config: a set of utility scripts that the =2Erc > files include=2E Move to /mail/rc? >=09 > prof=2Embox: > prof=2Espam: > optional? not entirely sure what these are for=2E > Seems to be some sort of state tracking for spam > filtering? Anyone? >=09 > If it's state tracking, see notes on classify=2Ere >=09 > qmail: > optional? another admin tool? can't find anything > that calls this directly in upas or /mail/lib=2E >=09 > remotemail: > mandatory: used for sending email=2E >=09 > rewrite: > mandatory: used for rerouting email=2E >=09 > rewrite=2Edirect: > rewrite=2Egateway: > example: copy to rewrite and edit >=09 > setup=2Ebayes: > optional, stupid: sets up files that the bayesian > filter uses=2E The bayesian filter should just do > that itself if the files don't exist=2E Should > fix bayes and delete this=2E >=09 > smtpd=2Econf: > mandatory (for smtp servers): exactly what it says > on the tin, the smtp config=2E >=09 > validateaddress: > mandatory for smtpd: checks if the destination > of a received email is valid for this system=2E > maybe should turn it into an optional script, > and instead teach smtpd to check if a user > or alias exists directly=2E >=09 > validateattachment: > optional? mostly seems silly to have on by > default=2E >=09 > white=2Estarter: > example? an example of what whitelists look like, > probably not needed=2E > >With that, it seems like we could clean things up so that >/mail/lib defaults to containing: > > /mail/lib/rewrite=2Eexample > /mail/lib/remotemail > /mail/lib/ignore (todo, remove?) > >We can rewrite remotemail to default to routing based on >factotum and the from address, rather than needing a bunch >of config=2E Ideally, it'd be something like: > > # allow per-user overrides > if(test -f $home/lib/mail/remotemail) > exec $home/lib/mail/remotemail > if(test -f $home/lib//mail/sender) > from=3D`$nl{cat $home/lib/mail/sender > # scrape server, username from factotum, route based > # on that=2E > user=3D`$nl{awk '/=2E=2E=2Eserver=3D=2E=2E=2E/{print user}' /mnt/factotu= m/ctl} > user=3D`$nl{awk '/=2E=2E=2Eserver=3D=2E=2E=2E/{print server}' /mnt/facto= tum/ctl} > >I'm not sure how to get our domain into the >rewrite rules, so until we figure that out it'll have to >remain an example=2E > >For smtpd, it seems like we can have: > > /mail/lib/directmail=2Eexample/smtpd=2Econf > /mail/lib/directmail=2Eexample/validateaddress > /mail/lib/directmail=2Eexample/rewrite > /mail/lib/directmail=2Eexample/namefiles > /mail/lib/directmail=2Eexample/alias=2Elocal > >The rest can probably be put into other examples=2E > > /mail/lib/spam=2Eexample/=2E=2E=2E > /mail/lib/fishing=2Eexample/=2E=2E=2E > =2E=2E=2Eetc=2E=2E=2E > >The script stubs could either be inlined into /bin/upas/foo, >or put into: > > /mail/rc/*=2Erc > >and the admin scripts into > > /mail/util/$script > >I think this would make it easier to figure out what's going >on with upas configuration, and get a working system=2E > >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=2E strongly in favor of simplifying setup=2E whatever we're currently shippin= g is the remnants of what actually ran at the labs=2E all that configuratio= n (anti-spam, etc=2E) was theirs=2E i got all my own stuff working by readi= ng the man pages and trial and error=2E i thought incoming messages were piped through qmail somewhere along the l= ine=2E sl