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

On Monday, Mar 31, 2003, at 23:11 US/Eastern, Chuq Von Rospach wrote:
> On Monday, March 31, 2003, at 07:22  PM, mathew wrote:
> > > Or if the network between us is down, or if the server is overloaded 
> > > because someone who didn't know any better something to everyone in 
> > > his address book 100 times.
> > If the network between us goes down, then the mail doesn't get 
> > delivered until the network goes up again. Just like if the network 
> > between the sender's SMTP server and my mail server goes down with 
> > the present system, the mail doesn't get delivered.
> But now, with MX records, when a connection comes up, the servers 
> coordinate delivery. As I understand it, the system you're proposing 
> is doing it at the client level, so updates only happen when the user 
> is asking for them. For an unstable connection, that reduces the 
> likelihood of successful delivery significantly.
Well, it may be significant in mathematical terms, but if it's changing 
the probability from 0.01% to 0.02% I think most people could live with 
it. That's why I think any arguments about reliability effects of push 
vs pull will need to involve some actual modeling and simulation.
> > If an idiot sends something 100x to everyone in his address book, 
> > that's unsolicited bulk e-mail, so the fact that I don't receive it 
> > is a feature.
> but it still causes network and server prolems, so dealing with the 
> side effects is necessary. Systems can't assume perfect conditions.
It's necessary now, too. There are any number of ways for enterprising 
idiots to cause server overload. That doesn't mean the protocols that 
allow them to do so are flawed.
> > >  What server (if any) keeps the message for future reference?
> > What server (if any) keeps my e-mail for future reference now?  None, 
> > that I know of.
> anyone currently on an IMAP server, or on POP with "leave on server" 
> turned on. So, would a user require to pull it and copy it to "my" 
> server, or does it stay on that server, like it would on a USENET or 
> IMAP server?
There are three possibilities:
1) Leave it on the remote server.
2) Move it to my local server.
3) Move it to my local machine.

1) is clearly bad, so I imagine 2 and 3 would be chosen.

> > >  What if it's a person who never deletes his e-mail?
> > Then his hard disk fills up.
> not if the email he's never deleting lives on your server, because 
> that's where it was accepted from and still stored.
Right, and this is a problem with current e-mail systems, hence it's 
not a problem specific to email pull.
> > >  Or reads it 1000 times (DOS attack?).
> > Yes, if he has a broken mail client that doesn't download and cache 
> > the mail, he might fetch it lots of times. Just like a broken web 
> > client might fetch the same image every time it's included on any web 
> > page on your site.
> okay, so you're seeing this as some client-driven version of a suck 
> feed. you could make it work, but it's not how I'd do it. You're 
> better off layering on what we already have, using some variation of 
> the ETRN command -- but then you still have to have some way to tell 
> the other side there's mail waiting to receive. so aren't we simply 
> setting up a system to send email to tell someone there's email being 
> sent?
Kind of, yes. The point is that the distributed hard-to-stop 
message--the "I have e-mail for you" message--cannot contain an 
advertisement, because it's just a unique identifier of some kind. To 
get the actual message requires that there be a verifiable route back 
to the originating messaging account. This provides us with several new 
ways to fight spam, including 1) cancelling spam en masse after it has 
been sent, and 2) shifting of the costs of spam onto the people who 
provide spammers with access (whether deliberately or accidentally).

mathew

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