[Spambayes] Two Stage Plan

Gary Robinson grobinson at transpose.com
Wed Dec 18 17:50:43 EST 2002


>> this application.
> 
> You can only shrink it that small if you give up tracability.
> Otherwise you need things like the datetime, sender/receiver,
> and unique identifiers... minimum of about a hundred bytes
> once indexes are added, etc.  More if you use non-binary
> formats or wrap stuff in XML or something stupid (but popular!).

True, but I still don't see it as an issue. The email addresses would be on
file at the vendor and could be represented in each transaction as 5 byte
(max) binary numbers. 8 if you don't want to be fancy to save space. I can't
see this going to more than 50 bytes...

If it did get to be an issue, which again I do NOT think it is due to the
cost of storage today and even further decreased cost of storage tomorrow,
then tracability COULD be given up, perhaps -- worth considering. We're
talking about $.01 transactions here. If worse came to worse and something
went askew with one, it simply would not be worth fixing. This is something
that needs to be thought about more IF the storage this was an issue, which
again, i don't think it is.

Let's forget about the fact that individuals can by 100gig hard drives for
$100 or something these days. Suppose we are talking about secure online
storage. From Apple, you can get a secure, backed up 1gig online drive for <
$400 per year. That would handle, easily, 10 million of these transactions
(100 bytes per transaction). That's $0.00004 per transaction for storage.

Physical storage for this is negligable.

The actual CPU time of the updates would possibly be a bigger factor, but
really don't think it would be much more. If you disagree we could look into
it further. 

> 
> If you only bill once a year, then you start running into
> problems tracking down mid-level fraud (because the customers
> won't alert you to problems until they see the bill, and by
> then the trail has most likely gone cold).
> 
> Small-scale fraud is just a cost of business, and large-scale
> fraud you'll notice yourself.

Fraud is a factor with most financial transactions, but microsoft would be
guaranteeing this service (the delivery of an email) and there would not be
fraud in that question as far as I can see. (I.e. ms would not defraud users
about whether an email was delivered.)

Again this becomes more complicated if it this is done via cooperating email
client vendors, but I don't think that changes the dynamic in a major way.



> 
>> 5. Authentication. Again only done in the loading of the account, and
>> depending on whether it's part of a larger software rental package, may be
>> being done anyway.
> 
> If you only do authentication at account load time, then you
> run into problems with spammers masquerading as other users.
> Return-address forgery is already a problem... it'll get
> worse as real money gets attached to it.

Encrypted Passwords, etc. Clearly there would be challenges in making
everything secure. MS will have already done that as part of its
subscription services but some kind of consortium would have to do it from
scratch.

It would be interesting to try to quantify that in some way. Any ideas?



> 
>> 6. Retrieval costs -- outside audits. I think this probably goes away too
>> for the reasons above but you'd have to spell it out more for me to be sure.
> 
> No, outside audits don't go away.  Anyone who handles large
> amounts of money (and this would be a large amount of money,
> even at only a penny per email) gets their accounting practices
> scrutinized.  I'll grant that MS is already under such scrutiny,
> but being a broker as well as a vendor adds a whole other dimension
> to the mess.


OK, right, the central organization, whether MS or a consortium, would have
to handle audits. 

For MS, auditing this would probably be folded into overall audits in such a
way that it wouldn't be a major factor. it could be more of one for an
independent consortium. How do we quantify this?

Gary




> 
> - Alex
> 




More information about the Spambayes mailing list