ietf-asrg
[Top] [All Lists]

RE: [Asrg] 6. Proposals - Let pull mail replace push mail

2003-09-29 17:32:20
There are times (like times of civil oppression) where I may not want a
means
of tracking e'mail back to me...less I find the secret police at my door. I
suspect
that this will lead them right to me. I also noticed that you are encrypting
and
decrypting along the way...this can be quite a drain on resources at 100
msg/sec
which is what some e'mail systems need to run at...there is also the little
goodie
that in some countries the mere encrypting of mail is a state crime -- again
those
"protocol" officials will show up at your door. Breaking the forward model
of e'mail
may have consequences that need careful thought with regard to protecting
the
ability of those that need e'mail as a voice of opposition to continue to
use it.

-- Bruce
  -----Original Message-----
  From: asrg-admin(_at_)ietf(_dot_)org 
[mailto:asrg-admin(_at_)ietf(_dot_)org]On Behalf Of Dag
Kihlman
  Sent: Tuesday, September 30, 2003 4:26 PM
  To: asrg(_at_)ietf(_dot_)org
  Subject: [Asrg] 6. Proposals - Let pull mail replace push mail


  SMTP is a push mail system, a great thing if you are a commander in a
nuclear war, if you want to infect computers with viruses or if you want to
send a couple of million mails about magic pills. Just throw the mail out on
the Internet and let the recipients take all administrative costs.

  Today the Internet and computers are fast enough for a pull system. In
short my proposal is the introduction of a new kind of mail program and mail
system based on pull technology. Of course this is a drastic step but I
think a drastic step is much better than numerous patches to a system ideal
for misuse. I realise that the reader will be very sceptical and see
numerous problems, but I hope that I have foreseen most problems and
hopefully the most sever objections will be answered in this proposal.

  I will present my proposal while describing a mail from A to B.

  When A sends a mail it goes to the mailserver owned by A's Internet
Service Provider where the mail is stored. A's mail client interacts with
the ISP's mailserver and A can see any mail that has not reached the
recipient. If the mail was sent by a virus or by a hacker A will be able to
discover the intrusion and remove the mail. This means that viruses and
hackers will not be able to hide and viruses can be stoped, which means that
viruses' ability to multiply is greatly reduced.

  As soon as A's ISP's mailserver (mailserver A) receives the mail a
notification is sent to B's ISP's mailserver (mailserver B). Mailserver B
replies with a random encryption key and Mailserver A encryptes the mail,
stores it and delets the encryption key.

  The notofication message from Mailserver A contains Mailserver A's
IP-address, a mail identification number, a password, A's name and email
address and the mail subject. Each piece of information is too short to be
used for profitable spamming and it will be sent in UTF-8 format making it
easy to scan and validate.

  When B connects to Mailserver B the mailserver will pass the notification
to B's mail client together with the encryption key. B can filter the
notification. When the mail is opened B's mail client connects to Mailserver
A using the IP-address, the mail id and the password in the notification.
Since the IP-address must be valid any other certificate or verification is
unnecessary. When the mail is received the encryption key is used to decrypt
it and a new filtering can be made.

  As soon as the mail is delivered it will be removed from Mailserver A. If
B wants to share the mail among several computers B must save it on
Mailserver B.

  From a programmer's point of view my proposal is no difficult task. The
problem is that it is a huge revolution in the way mails are treated.
However it can co-exist with SMTP for a while since a mailserver which
supports the new system will be able to store a SMTP mail and create a
notification on the fly. It is also possible for a mailserver to detect what
kind of mail client the receiver has. If the mailclient does not support the
new system the mailserver can pass the message the old way.

  I hope that I have not troubled you with an unrealistic suggestion and I
am eager to hear any comments.