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

On Friday, Apr 4, 2003, at 02:04 US/Eastern, Kee Hinckley wrote:
> At 10:06 PM -0500 4/3/03, mathew wrote:
> > Umm, yes, and outside of the special case where you're sending e-mail 
> > across a corporate network, most e-mail today involves machines 
> > controlled by different entities separated by a large amount of 
> > internet under control of neither of them. So what is your point?
> It's store and forward--so I don't see the network glitches.  On a 
> pull system I do.
OK, so you'd rather have mail silently fail to arrive, than know that 
there's an ongoing delivery problem. It didn't occur to me that that 
was what you were arguing for.
> > Someone (possibly you) already mentioned this as a problem, and I 
> > already pointed out how easy it is to do connection limiting. By IP 
> > would probably
> That doesn't limit the polls.  It just means that instead of aborting 
> them with "no mail" I abort them with "come back later".  And if they 
> are well behaved, maybe they'll listen to when I tell them to come 
> back.
And if they're not, you ban them. Again, these problems have already 
been encountered and solved on the web.
> > > > > > > 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?
> > > Anyone who didn't want to lose email?
> > Tell me, what's your POP3 or IMAP timeout set to? What's your HTTP 
> > timeout set to?
> > Didn't think so.
> Wrong timeout.  We're talking about delivering email.
Right, and if your POP server is down or overloaded, your mail won't 
get delivered, unless your POP timeout is really really high.
>   The correct question is, "What's the default timeout currently for 
> most email servers before they give up trying to send email."  The 
> typical answer is four days.
That's the limit on retries, not the connection timeout. If you think 
sendmail sits there with a connection waiting to open for four days, 
you're severely deluded.
Remember the context--you were complaining about your client having to 
keep your dialup session connected continuously for days at a time:
> > > > > > > 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.
The retry limit doesn't mean your client sits online for days polling 
and polling non-stop. A smart client will use exponential backoff. Even 
a dumb client will only poll as often as your current e-mail client 
polls for POP or IMAP mail.

mathew

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