. It is quite a low bandwidth operation (probably less than 1K bytes) to
poll
a POP server for email
It's not the bandwidth - it's the fact that there are these annoying things
called
"timeouts". For *each* server that isn't reachable, you get to wait a
minute or
so - suddenly those 150 checks are taking quite some time. And the queuing
theory
of 150 sites with intermittent connectivity doing a push to your POP server is
different than what you see when you try to do 150 pulls....
First, you are using a baseline of 150 in your example, which is attuned
perhaps to your power use given you stated that you manage 6,000 mailing lists.
I doubt the average user would subscribe to more than 10 on a regular basis.
Second, there is a way of dealing with timeouts on the client side, it is
called multithreading. Multithreading (for those readers who might not know,
if any) is a fundamental programming concept that all internet clients (and all
computer programs and operating systems) depend on. Thus the culmulative delay
is not O(n), it is more like Max(n).
Thirdly, with your queuing point, you are making the mistake of assuming that
the majority of email received is *legitimate* bulk email. I assert this is
far from the case for the majority of people. Any way, for the power cases
like yours, what is the big deal with setting your email client to run for a
few minutes each day, while you go browse some research at google.com or fill
your coffee cup? Is your personal paradigm of immediacy for legitimate bulk
email a good priority for the internet as a whole, when the very nature of
email itself is being doomed by spam?
But of course, if you actually *tried* this, you'd understand it...
Please stop the personalized attacks and stick to the facts.
the same messages over and over again. This would either require a
special modification
to the POP server and require each user to login with a unique user name.
Hey.. what did I tell you? Everybody needs a login of their own...
Er...you conveniently ignored the "or" that followed the "either":
-----I wrote (and you ignored)-----
Or better, users' email clients can be made smarter because there is a UIDL
command in both POP3 and IMAP4. This unique identifier can be used by the
email client to only download messages which are new to that user. One would
assume that POP servers could also remove messages older than say 1 month or so
(configurable by the administrator).
And as a side benefit, there would be no way for someone to subscribe me to a
list without my permission, as can be done by sniffing an authentication
email
for Majordomo.
If your confirmation mail is being sniffed, you have *BIGGER* issues.
Again you conveniently ignored the overall point which followed.
-----I wrote (and you ignored)-----
And no way for someone to subscribe me to a list that has no public
instructions for subscribing or unsubscribing (i.e. spam in guise of business
email).
That seems to be a BIG problem that many people have these days, probably even
yourself.
The flags can either be stored
at the POP server
and then give each user a unique login id,
Hey.. there's that unique login again.
Er...you conveniently ignored the "or" that followed the "either":
-----I wrote (and you ignored)-----
, or more realistically just let email clients manage their own flags using
UIDL.
No only 6000 POP accounts. See above how email clients can handle the
detection of new messages using UIDL. And you only need one anonymous login
and no password (just configure the POP server to accept any login and
password).
And I tell *MY* UIDL from Keith Moore's UIDL from Vernon Schreyer's UIDL how?
Yes your email client can keep track of which UIDL's it has already downloaded.
Keith's email client can keep track of his. Vernon his.
Ironically you mention Vernon (is that a hint?), because if I remember
correctly he runs the DCC and recently had a similar unexplained overtly
negative reaction recently when I tried to contact him regarding some
improvements to DCC. I suppose it is possible that your negative responses
here may be explained by similar vested interest with him. Maybe, but in
fairness I won't immediately assume the worst ethics of you.
BTW, in case you think my anti-spam business depends on this proposal, that
would be false assumption. Actually one of the key advantages of my anti-spam
algorithm (the automatic white listing of legitimate bulk email) would be
rendered unnecessary if this proposal was put into effect.
Have you actually *TRIED* to use more than 100 POP accounts under any
current
mail software?
I will respond with similarly rhetorical question. Did you try to use
Netscape 2 on most current web pages? Why make any application RFC if there
can be no progress in applications?
There's a difference - I'm not proposing a new scheme of doing things that
involves a change to 500 million users.
They all had to upgrade their browsers.
So I submit to you that if this idea
is too hard to use with the current version of Outlook, it is a *non starter*
as a practical matter.
If Microsoft likes the proposal, it won't matter what you or I think :)
There are many RFCs that are not implemented by Outlook. That doesn't stop
people from trying innovate and then let the chips fall where they will.
I think that current version of Outlook could be used as is for bulk of users
(who only have a few legitimate bulk email needs), except that old messages
would get continually redownloaded. But fortunately Outlook supports plugins,
so it should be fairly trivial to add the UIDL tracking to Outlook, even if
Microsoft refused to.
50, even 5000, is not statistically bulk on internet scale. Is it not
possible (or likely) to write laws without exclusions? Do you think Hosts,
ISPs, and anti-spam software would not account for this statistical
phenomenon?
Only problem is that many spammers are *already* only dropping 40-50 copies
of a note at a site at a time, specifically to work around that - then the
rest of the
spamming recipients at your site get a different version with a different
From: line
and a different source IP address.
So you are indeed heavily involved with the DCC! Yes I know that is a weakness
in the way the DCC measures bulk, but that is irrelevant to the point above.
I submit to you that if you didn't realize this was happening, you may not
be qualified
to be suggesting proposals to counter it....
If I did not realize it was happening, then I would not have created
http://AntiViotic.com . I'd be using the DCC instead. I also wouldn't have
approached Vernon about improving the DCC (only to be turned away in nasty
tone).
(Hint - if spammers weren't doing this, it would be trivial to block them,
and we'd
not be HAVING this discussion, right? ;)
As I said above, I actually have a business incentive not to make this
proposal. But I felt it needed to be made. My conscience and desire to do
important work is stronger than my desire for profit.
I wish you would remove the personalized attacks in your posts and stick to a
discussion of facts.
No. As I said above, they would only need to provide one POP account for
this mailing list.
And as I pointed out, you'll need to create 30,000, because one account doesn't
allow you to keep track of who has already seen what messages. And no, you're
*NOT* allowed to just say "everybody can fetch all the UIDLs and we'll just tag
them with the subscriber ID" - go read and *UNDERSTAND* section 6.2 of RFC2298
in order to understand why.
You did not understand the concept. The per user UIDL tracking is stored in
the email client, not in the POP server.
You might also want to go re-read the ASRG mailing list archives, your proposal
(and variants thereof) has been kicked down the beach like a dead whale
multiple times already.
Well apparently not enough, since you are claiming to be fully knowledgeable
about those posts, and you are not able to provide good refuting logic to my
proposal yet.
If you would like to refer me to some specific threads (with links please),
then I will be happy to read them and adjust my comments here or even withdraw
the proposal if I find it is warranted.
Shelby Moore
http://AntiViotic.com