On Thu, 20 Mar 2003 10:17:37 -0500, halloran parry
<hparry(_at_)andrew(_dot_)cmu(_dot_)edu> writes:
On 3/18/03, Matthew Richards posted an interesting idea of developing
a new email protocol that used a website based login system for every
message sent ([Asrg]try this on for size). The thread was never
picked up, and I had criticisms due to its potentially cumbersome
nature as far as sending legitimate mass emails was concerned.
However, if you're looking to make spamming extremely tedious, time
consuming, and difficult for the sender, I think it's worth revisiting
that thread.
That consumes the only resource that is gaining in cost each year.
I don't like that, but how about some notion of stamping? Each message
recieved must include a valid stamp. Stamps are only usable once.
Stamps are 96 bits, and thus may be represented as 17 ASCII base64
characters each. The two types are:
1. Stamps that encode a partial hash collision, of a sufficient
number of bits so that the MD5 hash of the stamp agrees with a
sufficient number of bits in the MD5 hash of the recipients email
address. The input to MD5 is 64 bits and forms 2/3 of the
stamp. The remaining 32 bits is a random nonce supplied by the
recipient.
2. Stamps may be random nonces created by the recipient. This
document does not discuss additional means to disburse stamps (such
as CAPTCHA's).
In both cases, the recipient is responsible for tracking the use of a
stamp to prevent double-spending.
All messages SHOULD include a stamp in order to be recieved.
1. Each sent message MUST include at least two fresh stamps for
each To, Cc, or Bcc recipient. The stamps must be valid for the
Reply-To address.
2. Stamps may also be generated through partial hash collision
requiring 10 Ghz*min of work.
There is a stamp-control protocol supporting the following messages:
1. QueryValidStamp: Given a set of stamps, report which stamps are
and are not valid for a recipient.
2. RequestStamp: A request of a sender for a roll of stamps. This
request must be forwarded to the user-agent who will decide whether
to allow or deny the user's request.
3. StampMissingBounce: A message was sent but not delivered because
no valid stamp attached. In this case, the user-agent is required
to create a hash-partial-collision stamp, then resend the
message. This bounce also includes a random nonce that must be used
for partial hash collisions.
4. RescindStamps: A request by the user agent to rescind a prior
set of granted stamps granted by RequestStamp.
**
I don't think it would seem to signifigantly hurt many current email
parties:
1. Resources per stamp are small; the amount of stamp text required
in an email would be little more than the amount currently required
for email addresses.
2. When sending an email, if the sender has a valid stamp for each
recipient, they use it and send the email. If not, they attempt to
send the message with no stamp. If they recieve a
StampMissingBounce for a messsage without a stamp, create a partial
hash collision stamp. If they recieve a StampMissingBounce for an
address with a stamp, then their understanding of valid and invalid
stamps is in error. They send a QueryValidStamp request to that
recipient to see which other stamps they hold for the recipient are
also invalid. They then repeat this step.
3. Robotic replies would not be harmed. Each email sent MUST
include two valid stamps suitable for automatic replies.
4. Mailing lists would also not be harmed, because the mailing list
manager could request stamps from the user in blocks of 1000, then
use them on the outgoing messages. When they run low, they send a
RequestStamp request to the user to give more stamps.
5. First-time senders would be impacted with a 3-30 minute CPU
bill, but not too badly.
6. I use nonces in the construction of stamps that may be timed out
by recipients.
---Flaws---
I've not discussed the seperation of interests between ISP's and
end-users, nor what protocol would be used to represent this
seperation.
I've not discussed when parties such as mailing lists strip stamps off
of messages. As stamps are not tied per-sender, they are
transferrable, so, for instance, stamps should not be put online.
One can still be spammed by RequestStamp messages, and ignorant users
may allow them. Fortunatly this can be half-solved; one attaches a
'report spam' button to an email client, which then sends a
RescindStamps to rescind all of the stamps in the given group.
Webmail and similar email-to-X gateways may be socked with the CPU bill.
-------
So, go ahead and shred it.
Scott
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg