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

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.
> > And besides, you still need to send them the notification that they 
> > have a message.
> Not necessarily, if they're a regular correspondent of mine.
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?  I get mail from my father 
once or twice a week.  Should I poll once a week?  That would really 
annoy him when he sends me a support question.  In fact, if I don't 
responds to those within a few hours he generally calls.  Okay, so 
I'll poll him ever four hours.  So now his server goes from having 
two transactions per week with me to having 42 transactions per week. 
Now multiply that out by all your correspondents.  Not good.
> 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.  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.
> > > 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.
> 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.  It sits there tieing up resources, slowing down attempts 
to fetch other email....
> If you're going to resort to tricks like deleting context to try and 
> "win" the debate, then this discussion will end soon.
I did not, and do not, consider that that context changes anything.

> >  You are assuming that the spam will dry up because they can't find 
> > a hosting provider?
> Uh... if they can't find anyone to host their messages for days at a 
> time, and take the bandwidth hit of delivering those messages to 
> their millions of of victims, then they won't be able to deliver 
> their spam, yes. Seems pretty obvious to me.
Sorry, I was ambiguous.  Yes, it will dry up if they can't find a 
host.  However I see no reason why they won't be able to find a host.
I have issues with some of your further responses as well, but 
there's not real point.  To sum up my feelings on the proposal.
1. It doesn't definitely get rid of spam (as sender-pays might).  You 
agree to that.
2. It replaces the entire system.

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.  One 
that has those problems *and* provides no assurance that it will stop 
spam is even less likely to be adopted.
--
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
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