tahoe-lafs/trac-2024-07-25

maildir inlet #151

New issue

Closed

opened 2007-09-27 19:02:20 +00:00 by warner · 4 comments

warner commented

2007-09-27 19:02:20 +00:00

Owner

Peter mentioned yesterday that one of google's offerings lets you upload
files by emailing them (as attachments) to some special email address.

I'm thinking this would be cool to have in Tahoe. The way I'd do this is to
say that if the node notices a maildir-shaped directory named 'inlet' in its
basedir (meaning that it sees three directories: inlet/{new,cur,tmp}), it
will poll or use inotify or something to watch for new messages in new/ .
When one appears, it will pull a command out of the Subject: line. A subject
of 'add DIRURI' would cause it to locate all of the attached files, upload
them to the mesh, then add their filenames to the designated directory.

For our testnet, the inlet address could be something like
'testnet@allmydata.org'. or 'testnet-inlet@allmydata.org'.

Doing it this way exposes the DIRURI to anyone who can intercept the mail, of
course. Putting the authority in the subject line (as opposed to the
destination address, like 'testnet-add-DIRURI@allmydata.org') reduces the
exposure somewhat, since destination addresses are usually logged by all
intermediate MTAs, while subjects (and bodies) are usually not.

I'm thinking that the node should never ever send email, so the user who
sends this email will not get email-based notification of success. Instead
they should poll the directory to watch for their files to appear.

Peter mentioned yesterday that one of google's offerings lets you upload files by emailing them (as attachments) to some special email address. I'm thinking this would be cool to have in Tahoe. The way I'd do this is to say that if the node notices a maildir-shaped directory named 'inlet' in its basedir (meaning that it sees three directories: inlet/{new,cur,tmp}), it will poll or use inotify or something to watch for new messages in new/ . When one appears, it will pull a command out of the Subject: line. A subject of 'add DIRURI' would cause it to locate all of the attached files, upload them to the mesh, then add their filenames to the designated directory. For our testnet, the inlet address could be something like 'testnet@allmydata.org'. or 'testnet-inlet@allmydata.org'. Doing it this way exposes the DIRURI to anyone who can intercept the mail, of course. Putting the authority in the subject line (as opposed to the destination address, like 'testnet-add-DIRURI@allmydata.org') reduces the exposure somewhat, since destination addresses are usually logged by all intermediate MTAs, while subjects (and bodies) are usually not. I'm thinking that the node should never ever send email, so the user who sends this email will not get email-based notification of success. Instead they should poll the directory to watch for their files to appear.

tahoe-lafs added the

labels 2007-09-27 19:02:20 +00:00

tahoe-lafs added this to the eventually milestone 2007-09-27 19:02:20 +00:00

tahoe-lafs modified the milestone from eventually to undecided

2008-06-01 20:58:32 +00:00

davidsarah commented

2010-02-11 01:00:48 +00:00

Author

Owner

If the mail need not be encrypted, then this seems less secure than existing frontends. If it does need to be encrypted, then it seems like a lot of work for little or no gain in usability compared to other frontends. Suggest wontfix.

warner commented

2010-02-11 18:09:53 +00:00

Author

Owner

It would certainly be less secure. The original idea was to make it easy for e.g. allmydata customers to add files to their directories, similar to what some other services do (dropio? box.net? I forget). I'd leave it on the back burner, and see if we get some users searching/asking for it.

davidsarah commented

2011-05-21 15:16:28 +00:00

Author

Owner

I don't think we should add frontends that are significantly less secure than the existing ones. E-mail is mostly unencrypted and sent over untrusted channels, so it doesn't fit Tahoe's security requirements for a frontend protocol.

zooko commented

2011-05-21 16:09:46 +00:00

Author

Owner

Let's close this as wontfix. We can always re-open it if someone comes up with a compelling use case or a huge BitCoin bounty or something. :-)

Let's close this as `wontfix`. We can always re-open it if someone comes up with a compelling use case or a huge BitCoin bounty or something. :-)

tahoe-lafs added the

wontfix

label 2011-05-21 16:09:46 +00:00

zooko closed this issue

2011-05-21 16:09:46 +00:00