1995-01-07 - Re: Data Haven problems

Header Data

From: root <root@einstein.ssz.com>
To: dfloyd@io.com
Message Hash: 8769096604a1888e4ab0d09685c5c3ded5713e90218ef0dc6e48b56233513891
Message ID: <199501071606.KAA00541@einstein.ssz.com>
Reply To: <199501071710.LAA21334@pentagon.io.com>
UTC Datetime: 1995-01-07 17:21:03 UTC
Raw Date: Sat, 7 Jan 95 09:21:03 PST

Raw message

From: root <root@einstein.ssz.com>
Date: Sat, 7 Jan 95 09:21:03 PST
To: dfloyd@io.com
Subject: Re: Data Haven problems
In-Reply-To: <199501071710.LAA21334@pentagon.io.com>
Message-ID: <199501071606.KAA00541@einstein.ssz.com>
MIME-Version: 1.0
Content-Type: text


> 
> 
> While programming my data haven code, I am wondering how to guard against
> spamming the data haven parser.  It is trivial to mount a denial of
> service attack by repeatedly mailing large files. which will fill up the 
> quota or filesystem of the data haven host, and if you have mail on a 
> root partition, will cause hangs or crashes.
>
If there is no cost associated with the haven and there are no account
limitations (ie anyone can get an account) then I don't see a means to do
it reliably. However, if you work up a fee based scheme such that you 
charge per M then it is trivial. If the data is larger than the account
balance it bounces. By limiting the availability of accounts you can make
it less enticeing for users to spam the haven because they are hurting
themselves. And it is assumed that since the accounts are limited  that 
there is an assumed web of trust working.

> Any ideas on how to guard against mailbombs, and to confirm to the sender
> that their files are stored successfully?  Perhaps do a mailing with
> a test command that validates the existance of the file, and sends a
> reply back wether the file is okay or not, or would this result in a
> possible security hole?
>
It seems to me that a message should come back only if there is a problem.
 
> As to the code, this will have to be my second rewrite as I am going to
> do it in perl code, rather than C...  last rewrite was from a daemon to
> a program activated by a .forward file.
> 
> Lastly, instead of postage (like a remailer would get), how hard would it
> be to implement "rent" where if the "rent" is not paid, and a grace period
> has elapsed the file would be trashed.  All this while preserving the
> anonymity of the sender and the data haven site.
>
This form of dating files is pretty commen in bbs systems where if a user
doesn't log in for say 30 days the account and its contents are deleted.
To do this doesn't even require knowing anything about the user  other than
how long the files have been there versus how long they are supposed to be
there.

 




Thread