Re: [Asrg] email pull (was RE: Authentication )

On Saturday, Mar 29, 2003, at 22:48 US/Eastern, Kee Hinckley wrote:
> At 7:27 PM -0500 3/29/03, mathew wrote:
> > So does conventional e-mail. With current e-mail systems, I fail to 
> > get the mail if my messaging server (at my ISP) is down. With e-mail 
> > pull, I fail to get the mail if the sender's messaging server (at his 
> > ISP) is down. In addition, I won't get mail from people I don't know 
> > that I need to poll unless my messaging server at my ISP is up. A 
> > small tradeoff in reliability, but one I think I'd take to cut spam.
> Currently you have a single point of failure that is close to you on 
> the network.  It's down infrequently, and when it is, you simply wait 
> and it comes up.
If we assume that most messaging servers are down infrequently, then I 
still don't see the problem. If one sender's messaging server is down, 
I don't get his mail until his server comes back up.
> With pull you are relying on the availability of dozens, hundreds or 
> even thousands (depending on how much email you get) of different 
> servers scattered across the world.  You go from a situation where all 
> of your email is there most of the time, to one where some of your 
> email is never there most of the time.
Well, the web is like that, and people find it reliable enough to be 
useful.
The question is how the reliability of a pull-based system would 
compare to the reliability of the current system. Don't forget that 
although email pull would degrade my ability to receive mail from users 
whose messaging servers are badly maintained, it would *increase* my 
ability to *send* mail to those same users, because once they were 
regular correspondents of mine their software would still be able to 
poll my reliable server even when their ISP's broken server was down.
I suspect some simulations would need to be done to work out whether 
the overall outcome would be better or worse, and how much better or 
worse it would be.
> > I mean, the web often requires that both my ISP and the appropriate 
> > web site have their servers operational when I want to read a web 
> > page. Yet people still use the web.
> Different expectations of service, and different scale.  I get mail 
> from far more servers than I surf in a given day.
Maybe you should try an RSS feed reader. :-)

> > > - it requires storing outgoing email for an indefinite amount of time
> > The current system requires storing incoming e-mail for an indefinite 
> > amount of time.
> Nope.  Only until the end user picks it up.
Uh, that's an indefinite amount of time. I might not log in to collect 
my mail for several months.
In both the current setup and e-mail pull, the server holding the mail 
can stop holding it once the recipient has downloaded it. What's the 
difference?
> > > - it completely the destroys the go-online, fetch, go-offline model
> > Not really. It just means that my mail client would go online, fetch 
> > my e-mail from a dozen different systems instead of just one, then 
> > disconnect.
> No. You go online.  Get a list of different email systems, decide 
> which ones you  want to fetch, and then go online again to fetch them.
If the decision process is fast enough--and it probably will be--then 
you just have a dual-threaded e-mail client.  Most offline newsreaders 
work that way--download the headers, autoselect a bunch of articles on 
the fly, and download those articles, then disconnect. All in one cycle.
> And that points out the biggest flaw of the system.  Not only have you 
> not stopped the spammers (sure, they need to find a host somewhere, or 
> lots of hosts, but that's not that big a deal).  But you've made it 
> *way* harder for me to tell whether something is spam. The initial 
> "you have mail" message doesn't provide enough information.  I can no 
> longer use content filters on it.  Instead I have to go try and fetch 
> it.  The spammer is sure to have an overloaded server, so now I'm not 
> only going to try and fetch it--but try multiple times!
Which is a big problem why? It's not going to chew up your bandwidth, 
you can set retrieval timeouts as short as you want to limit your 
dialup session to, and the CPU and disk overhead of failing to make a 
connection is minimal. I'd make that payoff to get rid of most spam.

mathew

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