From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <891608626012563549e908139052de7d@collyer.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] spam
From: Geoff Collyer <geoff@collyer.net>
In-Reply-To: <7b9270241715642750a17cbd0d92533e@caldo.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Wed, 24 Sep 2003 14:49:45 -0700
Topicbox-Message-UUID: 47cfc260-eacc-11e9-9e20-41e7f4b1d025

> a disadvantage of this approach is that without more work it makes
> visible the names of all users on machine, details of their mail
> boxes, and the contents of its /mail/lib and /mail/queue* (not to
> mention /mail/tmp).

this would be true if we imported /mail, but my (working) example is:

> import -bp machine /mail/box

which reveals much less.

> one approach is to have a service that presents a mail-sending name
> space through which mail can be sent, and the name space can then be
> exported, with authentication.  it also insulates sender and recipient
> from detailed knowledge of current mbox conventions.

right, this is what i actually suggested as a Future Direction in the
RSMTP paper; `import /mail/box' is just a first-cut approximation that
requires no new code.  i don't think it's worth implementing the
synthetic mail-receiving file system until we've figured out how to
make the cross-domain authentication less manual.