Internet DRAFT - draft-kruithof-spam-reducing
draft-kruithof-spam-reducing
Network Working Group W. Kruithof
Internet-Draft Unix-AG Universitaet Hannover
Expires: July 8, 2005 January 7, 2005
Spam reducing protocol
draft-kruithof-spam-reducing-03.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 8, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
A highly spam resistant protocol is shown, which could be implemented
for negligible costs. Accepted email's do the sender not cost money,
not accepted ones do. A decentralized server for keeping track of
money and information is needed. The protocol, in which encryption
naturally appears and can be used transparently aside of the existing
mail protocol, allows to freely distribute your emailadress. The
protocol avoids the micro payment problem.
Kruithof Expires July 8, 2005 [Page 1]
Internet-Draft Spam reducing protocol January 2005
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction and overview . . . . . . . . . . . . . . . . . . 4
3. Overview of the protocol . . . . . . . . . . . . . . . . . . . 6
4. Technical remarks on the protocol . . . . . . . . . . . . . . 9
5. Practical problems/issues in applying the protocol . . . . . . 10
6. Financial aspects . . . . . . . . . . . . . . . . . . . . . . 11
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 16
Kruithof Expires July 8, 2005 [Page 2]
Internet-Draft Spam reducing protocol January 2005
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The key word "ELEMENT" means element of, "ORG" means organization,
"AND", "IF", "THAN", "REQUEST(S)", "COST", "ACCEPT", "REJECT", "BY",
and "CONNECT" stand for their logic meaning. The key word "GETKEY"
means download the key, "TIMEOUT" a specified time value. The term
"COMPANY(IES)" is used for a ISP which is ELEMENT ORG. The
organization means agreement on the practical implementation of the
protocol, and should decide whether certain COMPANIES fulfill the
conditions.
Kruithof Expires July 8, 2005 [Page 3]
Internet-Draft Spam reducing protocol January 2005
2. Introduction and overview
Nowadays, spam is dealt with by using white- and blacklists and spam
filters. It is to be expected that the spam problem will not
satisfactory be solved by these solutions. Neither is guaranteed
that receivers will not get spam, nor that non-spam email's always
pass the anti-spam solutions.
The essence of the proposed protocol: if a telephone number costs one
euro per minute, you will not call them without a very good reason.
Suppose you are in a room with thousand other people. Everybody is
talking to you, because talking to you is free. In such a situation
you are unable to effectively pick out the things that are important
to you. But what if talking to you is not free, and someone has to
show good faith? Say you charge one euro and promise to give it back
if the information was important. This way, only people with
important information will want to talk to you, knowing it will not
cost them a penny. People with non-important information will not be
bothering you, for they risk losing money.
This document proposes a spam resistant protocol that ensures that a
minimum amount of spam will be read by the receiver. The second
advantage is that a sender will know for sure whether the receiver
has received the message. The basic principle is that a sender has
to pay for getting a way of communicating via encrypted communication
with the receiver. In case of accepting (more specifically: not
rejecting) the message the money is booked back to the sender, if
not, the money is booked to the server of the COMPANY. If for
example a spammer earns 0.0025 eurocent by each sent email, setting a
price of 0.10 cents for your mailbox will work. Bill Gates may want
to set his account to 500 euro.
As a remark, the micro payment problem, usually found in epostage, is
avoided by spreading the accounting of data on a decentralized
server, which could be in practice a piece of additional software run
on the normal SMTP server. Only users of mailboxes who pay
(in)directly can use the service. Misuse by other people/viruses is
reduced by introducing hard and soft limits on using the deposit.
Most disadvantages found in epostage are shown to disappear for the
proposed protocol.
The protocol in this draft could just be the push developers need to
implement a protocol stacked on top of the smtp/pop protocol which is
spam resistant. This document will put the system to the test to see
if it can cope with the requirements that such a system should meet.
The draft does not go deeply into the implementation, but shows the
theoretical foundation. This makes sense, but should be seen in
context. This document will also discuss some practical problems.
Kruithof Expires July 8, 2005 [Page 4]
Internet-Draft Spam reducing protocol January 2005
The term 'spam' is used in this document to refer to unsolicited or
unwanted email messages. This document does not attempt to define
what exactly constitutes spam.
Kruithof Expires July 8, 2005 [Page 5]
Internet-Draft Spam reducing protocol January 2005
3. Overview of the protocol
Suppose Alice wants to send an email to Bob, whose email address she
knows. She can just send the email, but she wants to make sure that
it will not disappear in Bob his spam folder causing the message to
be forgotten or even deleted directly.
For successful communication both Alice and Bob MUST have a
(in)directly paid email account. The large ISP's MUST work together
to make use of this protocol. In the database of each participating
COMPANY for each email address of that COMPANY SHALL be seen how many
it costs to send an email to the receiving party. This SHOULD also
be done by client software. OPTIONAL is searching in the database.
Alice MUST pay the amount of money that is set by Bob for downloading
from the server the public key of Bob. Alice her email address MUST
be associated with this public key on the server by the database.
Alice SHOULD upload before her public key, which is accessible by Bob
if he accepts her email, and which is not accessible if he rejects
the email. This private-public key pair MAY be real time generated
on the server and could be send encrypted to Bob if Alice pays, or
the client SHOULD upload several public keys. It SHOULD also be
possible to specify hard (changed by sending a letter to the COMPANY)
and soft (software changeable) limits, otherwise viruses e.g. could
initiate unwanted transactions.
The protocol can be an extension to the normal SMTP protocol.
Suppose Alice has the mail address alice@alice.com, Bob has
bob@bob.com. Now the ISP's has to be in the organization which have
an agreement about the specified mail protocol, and also apply it to
their mail servers. Both Alice and Bob need to have a paid mail
account, directly or indirectly. Indirectly by for example hiring an
ADSL line. The financial part will be discussed later on. Now Alice
wants to send a mail to Bob, via the new protocol. Alice's client
authenticated connects over an encrypted connection to the mail
server, which checks first: alice ELEMENT ORG, and sends IF bob.com
ELEMENT ORG AND IF bob@bob.com ELEMENT THAN REQUEST COST bob@bob.com
and saves this cost in costbob. Alice.com caches this value, costbob
also, and denies all request from alice handling Bob if Alice has not
enough deposit, or zero deposit (the cost has always to be greater
than a fixed value, which is specified in the protocol and changes
with the year to correct for inflation), to pay the key of Bob for a
fixed time (TIMEOUT value). Alice can read now in her mail client,
before composing the message how many it costs. She writes her
email, now her client sends again: IF bob.com ELEMENT ORG AND IF
bob@bob.com ELEMENT AND COST bob@bob.com EQUAL costbob THAN GETKEY
bob@bob.com. Now alice.com connects to bob.com, downloads the key to
alice.com, and delivers it to alice. Alice.com now saves costbob.
Kruithof Expires July 8, 2005 [Page 6]
Internet-Draft Spam reducing protocol January 2005
Now, and this is the weakness for which the organization is needed,
alice.com MUST book off costbob on alice deposit at alice.com. In
the protocol, as seen, a delay (the same TIMEOUT which is mentioned
before) is needed between paying a key and the right to pay for his
key, because Bob could have changed his value in the meantime.
Now the receiving part. Bob's client connects over an encrypted
connection authenticated to the mail server, which checks first: bob
ELEMENT ORG, downloads the list of connections of bob. Now the
client downloads the email's. If the connection is accepted, the
email is always put through. If a new connection occurs, the mail is
put through with a flag of new connection. If Bob accepts/reject the
message, bob's client connects again: ACCEPT alice@alice.com. The
server checks: IF alice ELEMENT ORG AND IF bob ELEMENT ORG AND IF bob
REQUESTS THAN CONNECT bob.com, requests: ACCEPT/REJECT
alice@alice.com BY bob@bob.com. Bob.com now checks: IF alice ELEMENT
ORG AND IF bob ELEMENT ORG THAN ACCEPT/REJECT costbob.
If Alice sends her email to Bob, this MUST be encrypted with the
public key of Bob for which she paid. Bob his email client receives
the email, and MUST check whether the email is encrypted. if so, his
clients MUST connect to the server to get the public key, with which
the email is encrypted. This SHOULD be done by matching the senders
email address, otherwise Bob has to try every private key on the
encrypted message. If the email address matches, a public key of
Alice SHOULD also be transferred to Bob, to complete the safe
communication. If the email is not encrypted, it SHALL be lead
further in the 'normal' email processing (spam filters etc), which
shows the transparency of the new protocol aside of the normal email
protocol.
Now Bob knows which private key he has to use to decrypt the email
message. If not, the email can be lead further in the normal system.
It still could be a normal encrypted message if no matching email
address is found in the database. If the receiver does not
explicitly reject the email, the cost MUST be booked back. OPTIONAL
is accepting email from Alice email address n times. The connection
is now established, because Alice MAY setup her client software to
accept always encrypted emails from email addresses for which she
paid to get the public key. If the receiver does not accept the
message, which SHALL be done by the receiver explicitly, the money is
neither booked back to the sender, neither booked to the receiver.
It SHALL be booked to the COMPANY his account.
For each new connection (new person or new email address) a new
public-key/private key pair SHOULD be generated. This is for just in
case a public key of Bob gets out in the open to people who Bob does
not want to know his email address. As soon as a connection is made,
Kruithof Expires July 8, 2005 [Page 7]
Internet-Draft Spam reducing protocol January 2005
the used private key with each email address SHOULD be saved by
client software, so that in the future the server is not needed
again. In case of a 'one-time' key pair, the public key SHOULD be
deleted from the server by the client or even the server.
Bob can reject the email, which is why spam will not be sent.
Advertisements will only be sent if the COMPANY really thinks it will
gain more than they lose. Of course, this will be the case in the
equilibrium situation; Bob wants his 'to pay' to stay as low as
possible, but just not low enough for companies which think they can
cope with the costs.
In practice, Bob MAY setup an email address for which he will
exclusively use the new protocol. Each email which is not encrypted
MAY be bounced with a message how to send an email which will be
guaranteed be delivered (in the sense of coming through anti-spam
solutions). Now Bob MAY freely distribute this email address in the
Internet.
Kruithof Expires July 8, 2005 [Page 8]
Internet-Draft Spam reducing protocol January 2005
4. Technical remarks on the protocol
Of course there are some technical issues that need to be dealt with
in order to approve the protocol for usability.
As can be logically derived, the heart of the protocol is full-proof.
Using a private-public key pair in such a way can indeed take care of
unwanted communication. Nevertheless there could be requirements
that may damage the usability of this protocol.
First of all, servers containing the databases should be globalized
in order to minimize access times. This is of course not a problem
in todays world. More of a problem could be the need for realtime
synchronization among servers. It can not be that if one server is
unavailable, the user is not able to read his email. Though the same
can happen with your pop-server, the real problem lies in sending
email's. It MUST NOT happen that, due to the need of knowing the
costs of sending, an email can not be sent because a server is down.
Therefore there MUST always be a complete functional server
available.
Secondly the weakness that can cause money to get lost. If a server
is compromised accounts can be altered causing money to be lost. As
a problem that happens once or twice this is moretheless acceptable.
But if even the design of the protocol does not satisfactory handles
this problem the protocol will not stand and its standard will not
hold. A possible solution can be found in the sollution of the first
problem; multiple servers that are realtime synchronized. If an
attack or system crash causes an account to be altered by in a
non-regular way, the realtime synchronization can be used as a fault
masking voter using majority vote. This is widely used in hardware
to mask errors that occur due to unforeseen and unpredictable errors
that are simply there in nature, making it reliable enough to cope
with a hacker compromising a system. As email is a massively used
tool this might not be practical considering traffic and cpu
intensitivity of a majority voting system. On the other hand, the
system is only used in initiating connections, not handling the email
traffic itself. More research is needed at this point, but at least
this shows that the weakness of money loss can be solved.
Thirdly there is the issue of hackers. If a system prevents spam
from being spread and also handles a lot of money, there is the
all-time great risk of hackers. The entire spam community could go
after the creditmail servers.
Kruithof Expires July 8, 2005 [Page 9]
Internet-Draft Spam reducing protocol January 2005
5. Practical problems/issues in applying the protocol
The solution of massive mailinglists etc. can of course be found in
the regular email protocol. These companies could require that the
email address you want your mail on, also accepts unencrypted
messages.
Because money is used as factor to decide whether a communication
channel is initiated or not, problems may arise in the equilibrium
state considering different countries. The payment SHOULD require to
pay an equivalent in dollars or euro. Because of the differences in
GNP (Gross National Product) this could lead to (dis)advantages in
different countries.
An interesting effect may be the advertisement business, which will
be sent even though the sender has to pay for example 10 eurocents.
The receiver than knows, that the content may be interesting for him.
So, it is possible to receive (changeable) paid advertisement.
Kruithof Expires July 8, 2005 [Page 10]
Internet-Draft Spam reducing protocol January 2005
6. Financial aspects
An indication how the financial part of the protocol would look like.
It has to be clear, that only email accounts which have a connection
with money/control on the user can be used in the protocol. In
practice, all COMPANIES could for example give standard 10 euro
credit per month to customers, who hire an (A)DSL line and get a
emailaccount 'for free'. But also accept universities in ORG, if
they give the same amount of money per month to their university
students. If they want more credit, they could buy more from their
COMPANY or university. This is just an example, that it has to be
possible to find a nice solution to this problem, which has to be
economically researched.
As encrypting software for example PGP (GPG) could be used.
It should be financially possible to realize the introduction of an
additional piece of server software for SMTP servers. If the
protocol is studied, it can be expected that the overhead on the
servers will not be that much. An increasing amount of spam is more
expensive probable.
Kruithof Expires July 8, 2005 [Page 11]
Internet-Draft Spam reducing protocol January 2005
7. Conclusion
The protocol as such is a simple, flexible and effective way of
minimizing spam in a very natural way. Nonetheless, a lot of
research has to be done in the field of economics and in how easy it
is to implement. Maybe this protocol will eventually just be used in
businesses. After all, they are the ones in most desperate need of
getting rid of spam.
Kruithof Expires July 8, 2005 [Page 12]
Internet-Draft Spam reducing protocol January 2005
8. Security Considerations
This section handles the case a server has been compromised and why
various SHOULDs lead to a system in which also compromising of this
server does not affect all the communication, it only requires the
resetting of the communication channels. The weakness is the
possibility of loosing money if the server is compromised.
Essential is the database of each COMPANY, which is used for keeping
track of the virtual money. Public-private keys SHOULD be generated
by the clients, because it avoids generating 'bad keys' in case of
errors/misuse of the server software. One-time key-pairs SHOULD be
used, because if Alice accidentally or intentionally leaks the key to
someone else, Bob can delete this key-pair. Also SHOULD the key-pair
be generated by the client, so that only the client has the private
key. This avoids when the server is compromised the spread of
private keys to the public. The public key SHOULD be in case of
One-time-key-pair be deleted on the server if Alice has paid for the
key. Than a compromised server cannot spread this public key
anymore.
Following the protocol, in case of receiving the mail from the mail
server by the receiver, the mail address of the sender is earlier
known, than the message is arriving, because the public key has to be
downloaded, and than the mail address is known to the server. Access
to the central server is decrease dramatically if the receiver first
downloads from the server the list of emailadresses which have paid
to get one public key of him. The client SHOULD download first the
list of known connection, and later on check whether new connections
are added. Then the receiver downloads the mail messages. Following
the protocol, it can be expected than spammers will send enormous
amounts of encrypted messages, and hope that the server will be down
due to many checks on the sender. This will not happen because the
client will check locally whether the sender is on the list.
If the spammer has forged the email address this will not work,
unless he has the correct public key of the receiver. The receiver
will first try to decrypt the message, the client software can check
whether the decrypted text is right (just by requiring that the first
byte of the message has to be a certain string (one byte satisfies
actually)). If it is not encrypted by the public key, it is
discarded. The receiver does not see anything of this, and in this
way it is not a problem.
If it is discovered that the server is compromised, in case of all
the SHOULDs in this section are followed, the communication channel
can be reset by sending to each connection a new public key, with
encrypting with the old key. This communication cannot be read in
Kruithof Expires July 8, 2005 [Page 13]
Internet-Draft Spam reducing protocol January 2005
each case, and after establishing the new connection, all the old
keys, which MAY be in the hands of third parties, MUST thrown away.
Now we have to see what spammers would do. They can not request the
whole time for a certain address, because TIMEOUT is used. They have
to do the request from a mailaccount which is in the organization.
If the account is stolen, we have a problem, we may setup a hard
limit on how much per month can be spent, and a soft limit which can
be changed. If it is a virus, probably also the soft limit cannot be
changed.
The weakness which is left is the book keeping data server part. In
case of compromising this part, money can be lost.
Kruithof Expires July 8, 2005 [Page 14]
Internet-Draft Spam reducing protocol January 2005
9. Acknowledgments
The author would like to thank several people for many helpful
comments and suggestions, including Anne Franssens (NL, University of
Twente, Computer Science).
10 References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Author's Address
Wilbert Kruithof
Unix AG Universitaet Hannover
Welfengarten 1
30167 Hannover
Germany
Phone: +495 11 7623226
EMail: wilbert@stud.uni-hannover.de
Kruithof Expires July 8, 2005 [Page 15]
Internet-Draft Spam reducing protocol January 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kruithof Expires July 8, 2005 [Page 16]
