upasfs, startupasfs – mail file server

upas/fs [ –f mailbox ] [ –bnps ] [ –m mntpoint ]


Fs is a user level file system that reads mailboxes and presents them as a file system. A user normally starts fs in his/her profile after starting plumber(4) and before starting a window system, such as rio(1) or acme(1). The file system is used by nedmail and acme(1)'s mail reader to parse messages. Fs also generates plumbing messages used by biff and faces(1) to provide mail announcements.

Startupasfs is a shell script suitable for use in one's profile. It runs fs –s for the invoking user if none is already running, and always mounts the user's posted fs on /mail/fs.

The mailbox itself becomes a directory under /mail/fs. Each message in the mailbox becomes a numbered directory in the mailbox directory, and each attachment becomes a numbered directory in the message directory. Since an attachment may itself be a mail message, this structure can recurse ad nauseam.

Each message and attachment directory contains the files:
body            the message minus the RFC822 style headers
cc              the address(es) from the CC: header
date            the date in the message, or if none, the time of delivery
digest          an SHA1 digest of the message contents
disposition     inline or file
a name to use to file an attachment
from            the from address in the From: header, or if none, the address on the envelope.
header          the RFC822 headers
info            described below, essentially a summary of the header info
inreplyto       contents of the in–reply–to: header
mimeheader      the mime headers
raw             the undecoded MIME message
rawbody         the undecoded message body
rawheader       the undecoded message header
replyto         the address to send any replies to.
subject         the contents of the subject line
to              the address(es) from the To: line.
type            the MIME content type
unixheader      the envelope header from the mailbox

The info file contains the following information, one item per line. Lists of addresses are single–space separated.

sender address
recipient addresses
cc addresses
reply address
envelope date
MIME content type
MIME disposition
SHA1 digest
bcc addresses
in–reply–to: contents
RFC822 date
message senders
message id
number of lines in body

Deleting message directories causes the message to be removed from the mailbox.

The mailbox is reread and the structure updated whenever the mailbox changes. Message directories are not renumbered.

The file /mail/fs/ctl is used to direct fs to open/close new mailboxes or to delete groups of messages atomically. The messages that can be written to this file are:
open path mboxname        opens a new mailbox. path is the file to open, and mboxname is the name that appears under /mail/fs.
close mboxname           close mboxname. The close takes affect only after all files open under /mail/fs/mboxname have been closed.
delete mboxname number ...   Delete the messages with the given numbers from mboxname.

The options are:
use file as the mailbox instead of the default, /mail/box/username/mbox.
b   stands for biffing. Each time new mail is received, a message is printed to standard output containing the sender address, subject, and number of bytes. It is intended for people telnetting in who want mail announcements.
n   Don't open a mailbox initially. Overridden by –f.
p   turn off plumbing. Unless this is specified, fs sends a message to the plumb port, seemail, from source mailfs for each message received or deleted. The message contains the attributes sender=<contents of from file>, filetype=mail, mailtype=deleted or new, and length=<message length
in bytes>.
The contents of the message is the full path name of the directory representing the message.
s   causes fs to post itself in /srv with a name of the form /srv/upasfs.user.
m   specifies a mount point other than /mail/fs.

Fs will exit once all references to its directory have disappeared.

Fs interprets mailbox file names of the form /proto/host/user to mean access an account on host using the given protocol. Authentication is delegated to factotum(4). The final /user may be omitted, in which case the user name is gleaned from the key held by factotum. The following protocols are supported:

pop       cleartext POP with password authentication
apop      cleartext POP with challenge–response (APOP) authentication
TLS–encrypted POP with password authentication
TLS–encrypted POP with challenge–response (APOP) authentication
imap      cleartext IMAP
imaps     TLS–encrypted IMAP

The two IMAP protocols allow an optional fourth field specifying a mailbox name, for example /imap/server/user/stored.

Poptls and apoptls connect to port 110 in plaintext and start TLS using the POP STLS command. Pops and apops connect to port 995 and start TLS before initiating the POP conversation. Imaps connects to port 993 and starts TLS before initiating the IMAP conversation. There should probably be an imaptls protocol as well. (Imaptls would connect to port 143 in plaintext and start TLS using the IMAP STARTTLS command. (That's the nice thing about standards--there's so many to choose from.))

/mail/box/*              mail directories
/mail/box/*/mbox          mailbox files
/mail/box/*/L.reading     mutual exclusion lock for multiple mbox readers
/mail/box/*/L.mbox        mutual exclusion lock for altering mbox


aliasmail(8), faces(1), filter(1), mail(1), marshal(1), mlmgr(1), nedmail(1), qer(8), rewrite(6), send(8)

Upasfs seems to get confused by multiple clients (e.g., imap4d in pop3(8)) sharing a single upasfs instance, despite each client mounting that instance separately. Opening different mailboxes in the various clients seems to trigger it.
Copyright © 2024 Plan 9 Foundation