headers
x-rar-im2000 | 16 Jan 2004 00:25
Picon
Picon

Macro payments through domain names?

Hi everyone,

This list has previously discussed micropayments for emails. I
recently had a related idea which I haven't seen discussed. How about
using the cost of buying top level domains as the base of more of a
macro payment system?

Here we go:
Put the hash (eg., md5) of a public pgp/gpg key used for signing
emails in a DNS entry derivable from the email address. Enforce the
DNS lookup to be in two steps. The first lookup returns the reference
to an external top level domain; the 'eMail Authorization Domain'
(mad). The second lookup is a TXT query towards this 'mad' which must
return the hash of the public key of the email signature (where the
public key and the signature data is included in the end of the email
as usual).

Now use a system of blacklists similar to how it works today, but for
sent spam, blacklist the involved 'mad' instead of the domain of the
sending email address. This makes a 'mad' used for spamming
"unusable" for further emailing, and someone will have to pay for a
new domain that isn't yet on the blacklists; but when doing so one
will be able to keep using the same email address as before (which is
important if some other user under your domain was responsible for
the spamming).

Spammers paying for their own 'mad's will have a hard time to make
profit, and will be traceable by whois data. Spammers using hacked
systems will really push people towards higher computer security
since such incidents now leads to a real monetary cost. However, the
(Continue reading)

Permalink | Reply | 2 comments |
headers
Marc Mengel | 16 Jan 2004 16:42
Favicon

Re: Macro payments through domain names?

x-rar-im2000 <at> theophys.kth.se wrote:

> Put the hash (eg., md5) of a public pgp/gpg key used for signing
> emails in a DNS entry derivable from the email address. Enforce the
> DNS lookup to be in two steps. The first lookup returns the reference
> to an external top level domain; the 'eMail Authorization Domain'
> (mad). The second lookup is a TXT query towards this 'mad' which must
> return the hash of the public key of the email signature (where the
> public key and the signature data is included in the end of the email
> as usual).
> 
> Now use a system of blacklists similar to how it works today, but for
> sent spam, blacklist the involved 'mad' instead of the domain of the
> sending email address. This makes a 'mad' used for spamming
> "unusable" for further emailing, and someone will have to pay for a
> new domain that isn't yet on the blacklists; but when doing so one
> will be able to keep using the same email address as before (which is
> important if some other user under your domain was responsible for
> the spamming).

I was thinking of something only a little different; you get to buy
(rent ?) a  key that's good for N emails/month.  This does mean that
a counting service would be needed, which would count reported email
receipts for each key.

Exceeding the purchased rate *automatically* blacklists the key for the rest 
of the hour/day/month -- so it provides throttling against even unintentional
excessive emailing.

That way, anyone who wants to run their own mail service can buy (rent?)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rickard Armiento | 19 Jan 2004 16:16
Picon
Picon

Re: Macro payments through domain names?


Rickard:
> [idea on how to make people bind their email address to an
> exchangable "email autorization top level domain" (a 'mad') which
> gets blacklisted as a punishment when spam is sent]

Marc:
> [suggests related micropayment idea by selling/renting of limitied
> use keys for email signing, where recepients reports use of key]

Yes, what you have described is a nice implementation of a more
traditional micropayment system. But the reason I suggested the quite
elaborate 'pay for domain name'-based scheme is that using
micropayments for email have issues that makes it hard for people to
adopt it. Let me explore the two approaches for some "known"
micropayment issues:

* People are very sceptical to pay, even micropayments, for something
that used to be free.
- Micropayments: Suddenly each sent mail starts costing money.
People "think greedy" and chose to stick with the old "free" system.
- Domain names: People can start by taking their organization domain
(eg., example.com) as their first 'mad' and thus continue to use
email for "free" until they are caught spamming (or someone hacks
their identity and spams).

* It is hard to introduce a pay-for service that don't really work
until a lot of people pay for it.
- Micropayments: People think "First when this gets wide acception it
will be worth paying for", which makes adoption hard.
(Continue reading)

Permalink | Reply | 0 comments |
headers
The Famous Brett Watson | 25 Jan 2004 06:47

IMC mail-ng

IM2000 readers may be interested in the creation of the "mail-ng" mailing list 
at the Internet Mail Consortium. The list is brand new -- not open to traffic 
at the time of writing.

  http://www.imc.org/mail-ng/index.html

<blockquote>

There seems to be more discussion these days about replacing SMTP and/or RFC 
2822 and/or POP/IMAP for a variety of reasons. The discussion seems to pop up 
on a few different lists and in a few different hallways, and it might be 
good to have a single list where folks can congregate. Thus, I have set up a 
mail-ng mailing list.

The first task probably is to determine what the next generation of mail 
should do, and how that is different than what SMTP/2822/POP-or-IMAP or 
instant messaging does. It is safe to say that we can ignore actual protocol 
proposals for many months (if not years) until we figure out what is needed. 
Once we do that, there are plenty of protocol people who can attack the 
decided-on requirements.

There is no expectation that there will be significant agreement on the list. 
It is likely that over time the discussion will split into camps of 
like-minded design goals. The list might then spawn different lists for the 
folks of the different camps (mail-ng-shoe, mail-ng-sandal, ...). The list is 
explicitly not yet meant to be an IETF working group yet (if at all), and is 
probably more akin to the IRTF. But at the beginning, it will most likely be 
talking, not research.

</blockquote>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Urivan Saaib | 25 Jan 2004 08:15
X-Face

Re: IMC mail-ng

> IM2000 readers may be interested in the creation of the "mail-ng" mailing list 
> at the Internet Mail Consortium. The list is brand new -- not open to traffic 
> at the time of writing.

I think this is a great idea (and really on time)

> <blockquote>
> There seems to be more discussion these days about replacing SMTP and/or RFC 
> 2822 and/or POP/IMAP for a variety of reasons. The discussion seems to pop up 
> on a few different lists and in a few different hallways, and it might be 
> good to have a single list where folks can congregate. Thus, I have set up a 
> mail-ng mailing list.

Just thinking on what can be made with the mix of ideas already expressed in
each of the already existing individual mailing list, either all of them
converge or not, could lead to a very well defined set of requirements for the
new generation of mail servers.

> The first task probably is to determine what the next generation of mail 
> should do, and how that is different than what SMTP/2822/POP-or-IMAP or 
> instant messaging does. It is safe to say that we can ignore actual protocol 
> proposals for many months (if not years) until we figure out what is needed. 
> Once we do that, there are plenty of protocol people who can attack the 
> decided-on requirements.

We could line up the common falls of the existing mail protocols, that would
give a general overview of the problems, then propose fixes for those, and then
add those requirements in order to support future problems based in the
existing technologies.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane