Re: [9front] /mail/lib: cleanup proposal

[ori@eigenstate.org]

>> > 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?