ietf-asrg
[Top] [All Lists]

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

2003-09-30 02:08:37
----- Original Message ----- 
From: "Kee Hinckley" <nazgul(_at_)somewhere(_dot_)com>
To: "Dag Kihlman" <dag(_dot_)kihlman(_at_)htu(_dot_)se>
Cc: <asrg(_at_)ietf(_dot_)org>
Sent: Tuesday, September 30, 2003 2:31 AM
Subject: Re: [Asrg] 6. Proposals - Let pull mail replace push mail


At 1:25 AM +0200 10/1/03, Dag Kihlman wrote:
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

Please search the archives.  This has been discussed before.
1. It greatly increases the traffic on the internet.
If you mean more connections that is true, but if you make a calculation
you will find that the increased traffic is nill and nothing compared with
the
traffic caused by spammers, viruses not to mention radio listners and
video viewers. Compared with this traffic the traffic argument is not really
a big thing. Historically the argument is valid but it is getting less and
less
interesting.

2. It greatly increases the ISP disk storage requirements.
True and wrong at the same time. It moves the storage from one server
to another. To some degree the size will grow but the ISPs will protect
themselves by putting a limit on the number and total size of outgoing
mails.
Ordinary users probably will only be able to store a couple of
hundred mails. This has the positive effect that if you hack an ordinary
user you will not get much value out of it. Especially since the user may
remove your spam messges. The hackers must turn to companies but they
will have other means of blocking and discovering hackers.

3. It removes the store-and-forward advantage of current email.
This argument is a puzzle to me. Any mail could be forwarded... The
notification could also be forwarded.

4. It assumes that point B can always reach point A.
This is quite true, but hey I have an Internet bank at that also assumes
I can reach it. If not I retry. At least here in Sweden the Internet is
stable enough.

5. It is less reliable.
In some aspects yes but a system perfect for spammers and
virus designes is not really reliable either. It depends on what
aspects you want to be reliable.

There's absolutely nothing preventing ISPs from scanning outgoing
email right now.  You don't need a pull system to do that.  It can be
done currently without an architectural change, either by filtering
outbound port 25 connections, or by  forcing ISP users to use the
ISPs outbound mail server.  But this has nothing to do with spam.
My suggestion has nothing to do with scanning. I neither prevent it
or demand it.

And when A is CNN and sends and CNN news alert to 100,000 people, A's
mail server will encrypt 100,000 copies of the message, and store
them all on the server for how long?
It is up to CNN. Their programmers will find ways to deal with this problem
as you very well know.

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.

Sending it UTF-8 is irrelevant to the scanning.  And a single subject
and an email address is most certainly sufficient for some spam.
I've gotten spam that had nothing more than that.
Yes, you are quite right and I really was not clear enough. I meant
that the subject should not be able to contain a picture impossible to
scan.

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

Ummm.  Pass it to my client?  Would that be the client on my cell
phone, my blackberry, my pager, or the UUCP connection to a place in
the boonies.  Mail clients connect to the internet periodically.
You'll have to queue the notification somewhere.
No problem for a programmer.

 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.

This is where we hit the unreliable part I mentioned before.
Your objections are against my proposal and you do not really give it a
chance by comparing it with current system. It is possible to eavesdrop
on mail communication today. Those who can eavesdrop on current
traffic will be able to eavesdrop in my system too. The hair raising bit in
my suggestion is probably that they can read passwords and encryption
keys, but they will be unique for each mail. The only gain the eavsdropper
will have is that he or she gets the means to read the mail, but since the
eavsdropper can do it with current system the security issue has not changed
at all. As you well know the best thing to stop eavesdropping is to
encrypt the mail before it is sent and that you will still be able to do.

I remembered one of the other things I'd forgotten.  Pull systems
don't change the spam equation at all.  Logically you've created a
need for a remote server in order to get the spam.  Most spam
currently needs a remote server for delivery.  It's called a web
site.  If spammers think they can keep the web site running long
enough to get the point of the spam across, there's no particular
reason they won't be able to keep the new mail server running just as
long.
I am not sure if I misunderstand you or you misunderstand me. So I
will try to explain what I mean instead of answering something I maybe
misunderstand. What I mean is that a spammer either will have to have a
mail server of his own. It requires an IP address and those are handed
out in an orderly fashion in a hierarchal way. To deliver spam in a
pull system you will have to keep the mailserver running for hours. In a
push system ten minutes will be heaven for a spammer. Anyway an ISP
ought not accept mails from a local unknown mailserver. The only
real option for a spammer is to hack a company or something and
such users will be better able to fight hacking and viruses.

Additionally, you've provided a wonderful tool to the spammers.
They'll know exactly which addresses their spam got delivered to.
Because your system gives them a direct mapping between email
addresses and IP addresses, and a way of knowing exactly when you
fetched the email.
Again you do not compare my system with current system. If a spammer
wants to know if and when a mail has been read it can be done today
since many mail programs allow html formatted mails with pictures and
the URL of the picture contains a key telling who opened the mail. Of
course you and I prevent this but we should advocate a mail system
which is safe enough not only for you and me but also for users
unaware of the problems.

I maintain that it is wrong to maintain a system where spammers and
viruses are able to hit and run. It is better to have a system where
spammers
and viruses will reveal themselves at the source where they effectivly can
be
fought.

/DK


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg