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

On Wednesday, Apr 2, 2003, at 10:28 US/Eastern, Kee Hinckley wrote:
> At 5:56 PM -0500 4/1/03, mathew wrote:
> > On Tuesday, Apr 1, 2003, at 11:28 US/Eastern, Kee Hinckley wrote:
> > > At 10:05 PM -0500 3/31/03, mathew wrote:
> > > > 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
> > > No, because SMTP already takes care of that with store/forward and 
> > > retry.
> > How does that deliver mail to a POP3 server that's down?
> It holds it until the server comes up?  But that's pretty much a 
> non-existant problem.  Delivery to a POP server is typically done by 
> having the SMTP server either run a program, or stuff a file 
> somewhere.  Neither requires the POP server to be running.
I meant "server" as in physical machine, not "daemon" as in piece of 
software. And the point is, both systems are equally useless if the 
software or the machine is broken, and both recover as soon as the 
software or machine goes up again.
> Yes.  You've mentioned that and I've kind of ignored that.  The 
> thought of everyone polling their all of their regularly 
> correspondents is incredibly scary.  Currently incoming mail comes 
> when it comes--very efficient.  The polling (the one inefficient 
> piece) is limited in cost because it is a) local and b) gets lots of 
> messages from lots of different locations.  In your model I have to 
> poll lots of distant machines (not to mention remember how to find 
> them, but I guess you'd make that implicit in the email address 
> somehow).  Now how often do I do that?
It's a tradeoff, like most technical decisions. The automatic polling 
frequency could be anything from every second to never. It's a detail 
to be discussed--whether it's worth it, given the downtime expected 
from messaging servers. My guess is it won't be worth it, but you 
seemed to feel otherwise, that messaging servers would be too 
unreliable to depend on.
> > Well, yeah. Making the sender pay the costs of the mail he sends is 
> > the whole point of the thing. That's one of the things that's really 
> > bad about spam, after all.
> No, actually that's not one of the things that is bad about spam. 
> What's bad about spam is the cost to the receiver.
There is going to be a cost to sending e-mail. Saying that the cost is 
not paid by the sender is the same as saying it's paid by the receiver, 
as someone has to pay for the network connection and disk space.
>   One of the things that might decrease the cost to the receiver is 
> putting a cost on the sender.  That does *not* mean that what is wrong 
> with the system is that the sender doesn't pay.
On the contrary, I think that that *is* one of the things that's wrong 
with the system. I think if the sender had to pay we'd see a lot less 
spam. After all, I get a lot less paper junk mail than I get e-mail 
spam.
> > > 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.
> > If you can't fetch it because the spammer has an overloaded server, 
> > which you admit he's sure to have, then you don't see it and it 
> > doesn't fill up your bandwidth.
> But my client sits there, for days on end, attempting to get that 
> email, because it doesn't know whether it's from a spammer or from a 
> flakey ISP.
If you set your timeout to days, yes. And who would do that?

>   It sits there tieing up resources, slowing down attempts to fetch 
> other email....
What kind of resource load is an open idle TCP/IP connection on any 
remotely modern desktop computer?
> I've already stated that I don't believe that any system that requires 
> an all-new architecture, and provides negative incentive for adoption 
> in the early stages, will have any chance of adoption.
I stated that too. On March 12th I wrote:

> > However, I'm not going to write it up, because it has the same 
> > problem as Jason's: there's no clear route from here to there.  It 
> > requires e-mail to be sent via a fundamentally different protocol, 
> > rather than SMTP. There's no gain for early adopters, just expense 
> > and a limited audience.
> > It strikes me that there might be a way to get such a thing rolled 
> > out, however. Just don't call it e-mail.
I don't see any method as *assuring* that spam will be stopped. I think 
that's an unreasonable criterion to set.

mathew

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