At 11:08 AM +0200 10/1/03, Dag Kihlman wrote:
> 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
If it blocks spammers and viruses.
> 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
Again. ISPs can and some do limit the number of outgoing messages
now. Pull is not required.
> 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.
The point is that I must be connected to the internet, and I must be
able to connect to the sending machine, in order to read email. To
take an obvious example. You run a web site with registered users.
You are moving to a new ISP and will be down for two days. You send
email to all your users, then you go down. None of your users can
read the email.
> 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.
But we aren't talking Sweden. We are talking the entire world.
Large web providers deal with this by distributing their content on
replicated servers around the world. To make email as reliable as
the web (which isn't saying much), you would have to do the same with
mail servers.
> 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.
I'm sure that's what Verisign said when they added a wildcard A
record to the root servers. That doesn't make it a good idea.
> >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.
That isn't a programming problem. It's an architectural problem.
You've designed a system that loses all the benefits of store and
forward and assumes that all receivers have full internet access to
all senders. The real world doesn't work that way. Please read the
archives--this has all been covered before.
Yes pull works well for some things (primarily broadcast-only
announcements like news). No, it's not a replacement for email.
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
True.
> 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.
My point is that spammers already keep servers running for days--both
their web servers and their email servers. These servers are
scattered around the world, consisting of compromised machines, open
relays and virus-infected machines. It easily takes several days to
get one of these machines shut down, and many are never shut down.
So you haven't introduced any problem that they don't already know
how to deal with.
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
It can be done if the user's email is configured unsafely. More and
more email vendors are changing the default options so that remote
graphics are *not* displayed automatically. Your system eliminates
that possibility.
--
Kee Hinckley
http://www.messagefire.com/ Next Generation Spam Defense
http://commons.somewhere.com/buzz/ Writings on Technology and Society
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg