On Jun 6, 2006, at 3:56 PM, David Nicol wrote:
On 6/6/06, Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
a http server with directory indexing turned off and files given
hard-to-guess long names and a policy of tarpitting peers that
repeatedly attempt to access nonexistent files can scale using
standard load-balancing techniques, for what that's worth.
Consider the numbers involved. While a header only message may be a
bit quicker to send, retaining these messages for the next 4 weeks to
permit MUA access to the data dramatically increases the number of
messages that are made accessible. A large ESP might send 100,000
messages per minute. A transmit-side retention scheme running at
that scale would then need access to 4 G objects. This is something
a typical Unix filesystem can handle. On the other hand, a content
addressable system split between headers and body should dramatically
reduce the amount of storage needed to archive this outbound data by
eliminating all redundant copies. This scheme also needs to age and
archive this information at a rate of 100,000 per minute. While
special applications could be created to replicate these features,
these would be normal features of this type of CAS storage system.
Little to no extra work is needed to do all the right things. While
this may seem like added complexity, this approach should
significantly reduce the amount of information retained while still
ensuring complete records. A reduction of copies also helps with
filtering.
By having the unique token used to access the information, there is
also an accurate record as to when the message was received. The
recipient would have a SHA256 hash of the body to assure accurate
delivery as well, that can also be retried when needed. When used
for commerce, this would provide better transparency while also being
able to ensure greater privacy when needed. This seems to offer some
real benefits for the typical corporate enterprise.
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg