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?
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.
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?
The difference is that the receiver knows the rules. Their ISP tells
them what their limits are, how how long they will hold mail. If they
go on vacation they can make appropriate arrangements. You've
replaced that with a system where the limits are different with each
of your correspondents, and furthermore, the sender now has to pay the
storage costs if some of their recipients are on vacation.
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.
And that points out the biggest flaw of the system. Not only have
you not
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.
what do you mean it won't chew up my bandwidth? Spammer sends notice
of email. I automatically download the spam. Where is this a win?
Putting back the context you deleted:
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.
If you're going to resort to tricks like deleting context to try and
"win" the debate, then this discussion will end soon.
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.
I'll agree that it's valuable to try and drive them to that point,
and that it will help. But I don't think that a) that will be
sufficient, and b) that a whole new system is necessary and c) that a
system that makes spam detection harder is a good idea.
Well, a) I'm not proposing that it's the only method needed for
eliminating spam 100%; b) isn't really a criticism of this proposal,
and I'll be more than happy to drop this idea if someone comes up with
a better one; and c) has yet to be shown, or even argued.
Regarding c), it seems to me that all the present-day spam-detection
methods can be used on the message as it's pulled from the source
server, as additional lines of defense if the spammer *does* manage to
find hosting. You can use all the present-day blacklist systems to
blacklist providers of spam hosting for e-mail pull.
mathew
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg