Re: "file:" URLs?

[Brian Stafford <brian stafford uklinux net>]

On Mon, 20 August 17:01 Toralf Lund wrote:

> > > I don't agree. I think one of the premises of NFS is that the user
> > > shouldn't have to worry about where a file is actually stored.
> > 
> > Yes but the text of RFC 1738 says "The file URL scheme is unusual in that
> > it does not specify an Internet protocol or access method for such files"
> > 
> > Balsa cannot therefore assume that NFS is the method used to retrieve the
> > file
> > (nor can you enforce that assumption).
>
> I'm not saying that it should. What I'm saying is that "localhost" access
> may have it's place because the files that are local from the application's
> viewpoint may actually be visible on multiple hosts, thanks to NFS (or
> SMB.)

Yes, but they can also point to any other file on the same host.  This gives
me a queasy feeling - I'm sure this is a security exploit one way or another.

I'd be a lot happier if the file urls pointed to a host and the path to that
file on the remote host.  This can always be mapped to the correct path by the
helper if NFS access is desired.

My point is that by insisting on the explicit host name, balsa can be sure
that it is passing the correct reference to the helper.  The message sender
can be sure they have sent the correct reference and the message recipient
can map the sender's reference to the correct one for the recipient's host.

What if the message sender makes the wrong assumption about the recipient's
mount point for a file system exported via NFS?  The recipient fails to get
the file, or worse still, the wrong file.

Localhost in file: urls has its place in a web browser but not, I feel, in
a mail client.

Actually, for the particular case of referring to NFS exported files, a NFS
URL would probably be better anyway .  NFS URLs are described in RFC 2224.

> > In any case, balsa does not interpret
> > the URL, the helper program does.
>
> Exactly, but this really means that there is no good reason not to have
> "highlight" code for _all_ URLs; the "dangerous" ones can (and should)
> always be disabled via the handler setup.

I figure that this is what would happen in practice since the URLs are
recognised by regular expressions ahead of any scheme specific processing.
I'd just like balsa to refuse to handle file URLs that implicitly or explicitly
reference localhost.  At the very least, there should be an option to enable
localhost referencing file urls.

> > Remember, internet messaging has different security implications to file
> > sharing.
> Definitely, but like I said, addressing these issues is perhaps the
> responsibility of the handler, or maybe even the MTA.

Not the MTA.  It cannot alter or process the content of a message without
violating RFC 2822.  In general actions like this cannot be handled properly
by an MTA.  M$ Exchange messes about with messages in transit and it causes
no end of problems in practice.

Brian