I don't think I have explained the problem very well.
I am receiving emails fine when outlook is running.
When outlook is not running I, of course, would never expect to
receive emails to OL. That's obvious. But, I will receive emails to
my
email account (in my case, googlemail).
Now this is where the problem occurs. If i receive an email when my
outlook is closed, when i open outlook again, it does not retrieve
the
emails that were sent to me whilst outlook was closed... (even after
a
send and receive)
I am not too sure that the word 'poll' actually means. Though, I
have
always had an auto send and receive interval stated.
Hope this clarifies the problem.
Well, Gmail is still in beta status and been that way for something
like 2 years, or more, and I don't think it ever will be out of beta
because Google expends no resources in fixing problems with their POP3
*emulation* that were reported in Feb 2006. Gmail's emulation of POP3
sucks. Hopefully you also realize that they are playing with their
anti-spam quotas which has resulted in many users complaining of
getting "Sector 5" bounces for failed delivery (which means the user
violated some unspecified anti-spam quota referenced by their TOS).
And you do know, right, that you can only send to 500 recipients
maximum (not e-mails but *recipients*) per day from a Gmail account
but only to 100 recipients if using the POP3 emulation.
Normally it is the e-mail client that tracks which mails it has
downloaded by recording their message IDs. While an e-mail account is
defined, every e-mail is supposed to have a unique ID assigned to it
by that mail server during the lifetime of that e-mail account. The
mail server has no clue as to which are new and old e-mails. It only
knows which e-mails it has. It is up to the e-mail client to track
which ones have been yanked before (marked as old) and which ones in
the mailbox are new since the last visit (their message ID not yet
recorded so they are "new" but only to that instance of the e-mail
client). Gmail doesn't work that way.
I, too, have received e-mails in Gmail which are "new" (to the e-mail
client) but which the e-mail client doesn't yank to itself. When I
look in the troubleshooting logfile, I see that when the client issued
a LIST command to the POP3 server to get a list of e-mails that the
Gmail server send a null list. So the e-mail client doesn't get a
list of e-mails in the Gmail mailbox which means, to the e-mail
client, that there are no e-mails to be found there. Since Gmail is
returning an incorrect result to the LIST command, the e-mail client
ends the mail session because it was told there were no e-mails in
your Gmail mailbox. That's a ****up on Google's end.
I abandoned the flaky Gmail account a long time ago but still login
every couple of months to keep it active (in case Google ever decides
to fix their defective POP3 emulation, or instead actually provide a
real POP3 server). I'm not sure how to get Gmail to resync itself so
it begins reporting the list of e-mails it currently has in its
mailbox (whether they are new or old to the e-mail client connecting
to it). My guess is to move all current items out of Gmail's Inbox to
a user-defined alternate folder and hope that new ones coming into the
Gmail account get the item list updated that it *must* report to an
e-mail client in the LIST command.
Another problem with Gmail's *emulation* of POP3 is that it will
emulate the DELE command from the e-mail client although the e-mail
client never sent one. Normally a POP3 client will issue a LIST
command (to see if there are any items present at all in the mailbox),
a UID command (to get the message IDs of each item so the e-mail
client can compare with its prior list to determine which are missing
and the "new" items since its last visit), and then a RETR (retrieve)
command for each "new" item it has been told about. Then most POP3
clients issue a DELE command to remove the server copy since a local
copy exists. Sometimes the DELE could be right after each RETR
command or, like Outlook, it does all the RETR commands first and then
follows with a bunch of DELE commands (so if the mail session is
aborted before sending the DELE then Outlook doesn't updated its UID
list and they are all still up on the server and Outlook yanks them
all again so you get duplicates). If a user doesn't want their POP3
client to delete the server-side copy then they configure it to leave
the mails on the server - but that won't work with Gmail. If you use
a mail monitor to check for new mails, Gmail treats the TOP command
(which gets the first N lines of each item) the same as a RETR
command. The result is that Gmail treats TOP like a RETR and then
Gmail, in their miniscule wisdom, does a DELE so their POP3 server
won't show that item on the next visit. Because you saw a new mail
using the mail monitor, you revisit using your e-mail client which
then doesn't find that item anymore because of Gmail stupidly issuing
the equivalent of a DELE when the mail monitor never issued that
command (and it never issued a RETR, either).
And, true to Google's simple minds, they require the user to enable
ActiveX to use their webmail interface. A-holes they be.
POP3 emulation at Gmail sucks. It will continue to have problems
until they either fix it or replace it. They haven't fixed existing
problems in 2 years. I doubt much will change in another 2 years. I
gave up on them. You might want to start looking elsewhere for a
freebie e-mail account, too.
