Deleting

[Jim S]

No big deal, but when I delete an email in Outlook 2010 the header pane
clears, but the message remains visible until I change folder.
Fault or not?

 

[Jim S]

That's what happens when you connect to IMAP accounts. Items aren't
deleted from the server until your client chooses to Purge them. You
delete, they get red-lined to show they are flagged for deletion, but
they don't get deleted from the server until you actually purge them.
Remember that IMAP is to keep in-sync your client- and server-side
folders.

Outlook can be configured to send a Purge when you change focus. Or you
could send one manually.

http://answers.microsoft.com/en-us/...ook-2010/0fd74efb-add9-4a4b-9505-c161365f5904
http://social.technet.microsoft.com...o/thread/2a0dc04a-b0e7-48a2-8740-9f662a2b486d

Not on IMAP

 

[VanguardLH]

Not on IMAP

And what does that extremely terse reply supposed to mean?

That you think the articles didn't discuss IMAP. Yes, they do.

That IMAP somehow works just like POP? Wrong. The default config for
POP is to RETR+DELE (retrieve and delete). The default config for IMAP
is to FETCH (retrieve) and the DELETE is issued separately sometime
later. The EXPUNGE can be issued immediately after the DELETE or
sometime later. Items deleted for an IMAP account are merely *marked*
or flagged for deletion. They don't actually get deleted until the
e-mail client sends a purge command (expunge) to the e-mail server.

Read:

http://en.wikipedia.org/wiki/Imap
"E-mail clients using IMAP generally leave messages on the server until
the user explicitly deletes them."

RFC 5301 - Internet Message Access Protocol (IMAP) v4.1
ftp://ftp.rfc-editor.org/in-notes/rfc3501.txt
Section 6.3.4 - DELETE command
That merely *flags* the message as deleted so it cannot be retrieved
again at a later time. It's a flag, not an action (to delete). You
have to follow with an Expunge command. In fact, you can search your
mailbox for delete-flagged items. Obviously if they physically no
longer existed then they could not be listed, but they ARE listed as
"DELETED = Message with the \Deleted flag set for removal later by the
EXPUNGE command."
Section 6.4.3 - EXPUNGE command
"The EXPUNGE command permanently removes all messages that have the
\Deleted flag set from the currently selected mailbox." This actually
physically removes the item from the mailbox on the e-mail server.

For some e-mail clients, they can be configured to do a real delete at
the server (i.e., send it the DELETE command) when:
1. The user manually issues a Purge function in the e-mail client.
2. The user changes focus to another folder (from one where items were
delete *flagged*).
3. The user deletes an item in the Deleted Items folder.

DELEte for POP removes the item from the mailbox on the server. DELETE
for IMAP merely flags the item (so it cannot be reaccessed again) for
physical deletion by a later EXPUNGE. POP and IMAP accounts are quite
different in the protocol used to access and manage them and in their
behaviors.

http://office.microsoft.com/en-us/outlook-help/purge-imap-items-marked-for-deletion-HP010080420.aspx

 

[Jim S]

And what does that extremely terse reply supposed to mean?

That you think the articles didn't discuss IMAP. Yes, they do.

That IMAP somehow works just like POP? Wrong. The default config for
POP is to RETR+DELE (retrieve and delete). The default config for IMAP
is to FETCH (retrieve) and the DELETE is issued separately sometime
later. The EXPUNGE can be issued immediately after the DELETE or
sometime later. Items deleted for an IMAP account are merely *marked*
or flagged for deletion. They don't actually get deleted until the
e-mail client sends a purge command (expunge) to the e-mail server.

Read:

http://en.wikipedia.org/wiki/Imap
"E-mail clients using IMAP generally leave messages on the server until
the user explicitly deletes them."

RFC 5301 - Internet Message Access Protocol (IMAP) v4.1
ftp://ftp.rfc-editor.org/in-notes/rfc3501.txt
Section 6.3.4 - DELETE command
That merely *flags* the message as deleted so it cannot be retrieved
again at a later time. It's a flag, not an action (to delete). You
have to follow with an Expunge command. In fact, you can search your
mailbox for delete-flagged items. Obviously if they physically no
longer existed then they could not be listed, but they ARE listed as
"DELETED = Message with the \Deleted flag set for removal later by the
EXPUNGE command."
Section 6.4.3 - EXPUNGE command
"The EXPUNGE command permanently removes all messages that have the
\Deleted flag set from the currently selected mailbox." This actually
physically removes the item from the mailbox on the e-mail server.

For some e-mail clients, they can be configured to do a real delete at
the server (i.e., send it the DELETE command) when:
1. The user manually issues a Purge function in the e-mail client.
2. The user changes focus to another folder (from one where items were
delete *flagged*).
3. The user deletes an item in the Deleted Items folder.

DELEte for POP removes the item from the mailbox on the server. DELETE
for IMAP merely flags the item (so it cannot be reaccessed again) for
physical deletion by a later EXPUNGE. POP and IMAP accounts are quite
different in the protocol used to access and manage them and in their
behaviors.

http://office.microsoft.com/en-us/outlook-help/purge-imap-items-marked-for-deletion-HP010080420.aspx

Sorry.
I meant that I am not on IMAP only POP.
However my server uses a variant of Google mail but I shouldn't think that
that matters.
I think it only happens when it's the final email in the Inbox.

 

[VanguardLH]

I meant that I am not on IMAP only POP. However my server uses a
variant of Google mail but I shouldn't think that that matters. I
think it only happens when it's the final email in the Inbox.

Google does NOT comply with e-mail standards either for POP or IMAP.
They comply just enough to be mostly compatible with most e-mail setups;
however, for example, if you use an e-mail monitor that issues a "TOP n"
command (to just retrieve headers and the first n lines of an e-mail),
Gmail treats it like it is a RETRieve command instead which can cause
problems when your e-mail client tries to retrieve that same e-mail at a
later time (this was a problem for several years at Gmail and I haven't
had the initiative to see if they ever bothered to fix it). Also,
unlike POP which does RETR+DELE or can be configured to do just RETR
(and do the DELE sometime later), Gmail has you configure that behavior
at their server in your account settings. Doesn't matter what the
e-mail client does. The server-side Gmail settings overrides the POP
commands sent by your e-mail client. For example, if you tell Gmail for
its POP setup to delete after retrieve, it doesn't matter that your
e-mail client only sent the RETR command (and no following DELE
command). So Google's variation of POP and IMAP should really be
labelled as gPOP and gIMAP. Google oriented their webmail around web
access and the features they put into it and then tried to wrap POP and
IMAP around that existing functionality rather than actually provide
true POP and IMAP mail servers.

I wouldn't try using Gmail as a sterling example of how POP and IMAP are
supposed to work. Google doesn't follow the RFC standards for those
e-mail protocols other than just enough to make their setup work in most
cases with typical setups for POP and IMAP e-mail clients. There are
other abnormalities with Gmail, like Gmail will automatically block
(with no choice by you to override) any e-mails sent to you by you
(i.e., where you e-mail yourself). There's also that goofiness of using
tags to emulate folders in place of using real folders in the mailbox.

Did you enable POP access in your Gmail account (server-side setting)?
Did you disable IMAP access in your Gmail account? What did you select
as the option when you retrieve e-mails when POP access is enabled?
I only enable POP access (IMAP access is disabled). For POP access, I
configure Gmail's server-side setting to "When messages are accessed
with POP [delete Gmail's copy]" as this comes closest to how POP works
by default configuration in local e-mail clients (although I'd really
prefer that Gmail honor the RETR command with no implied DELE and wait
until my local e-mail client actually sent the DELE command).

And with Google playing around with the behaviors of Gmail, that doesn't
prevent them with screwing around with their service. Despite removing
the "beta" label on their service (which took them 5 years and mostly
due to user and marketing pressure), and because it doesn't fully comply
with POP and IMAP standards, it is still a beta service. They can
change it anytime they want to alter their already off-kilter gPOP and
gIMAP protocols. Is this a recent problem in change of behavior or has
it been a lingering problem for a long time? How long have you been
using this Gmail account?

I don't know what you mean by "a variant of Google mail" since Google
mail isn't fully standards compliant in the first place. I doubt Google
is offering their suite e-mail server programs that comprises their
webmail service to non-Google e-mail providers. I'm not sure anyone
would want their, um, "stuff". You sure this "variation" isn't just a
proxy to Gmail, like some schools offering "free for life" school e-mail
accounts (with their domain) that are really using Gmail as the real
e-mail provider?

 

[Jim S]

<snip>

Did you enable POP access in your Gmail account (server-side setting)? Yes
Did you disable IMAP access in your Gmail account?

Yes
What did you select as the option when you retrieve e-mails when POP
access is enabled?

I only enable POP access (IMAP access is disabled). For POP access, I
configure Gmail's server-side setting to "When messages are accessed
with POP [delete Gmail's copy]" as this comes closest to how POP works
by default configuration in local e-mail clients (although I'd really
prefer that Gmail honor the RETR command with no implied DELE and wait
until my local e-mail client actually sent the DELE command).

I'm confused by that one. In the webmail settings on 'Google' (see later) I
leave it as 'keep in mailbox' - mainly because I had experience of losing
Windows including Outlook and was saved by all my mail still being on the
web'.

And with Google playing around with the behaviors of Gmail, that doesn't
prevent them with screwing around with their service. Despite removing
the "beta" label on their service (which took them 5 years and mostly
due to user and marketing pressure), and because it doesn't fully comply
with POP and IMAP standards, it is still a beta service. They can
change it anytime they want to alter their already off-kilter gPOP and
gIMAP protocols. Is this a recent problem in change of behavior or has
it been a lingering problem for a long time?

I've only noticed it recently.
How long have you been using this Gmail account? Couple of years, I
suppose.

I don't know what you mean by "a variant of Google mail" since Google
mail isn't fully standards compliant in the first place.

I don't know where you are, but here in the UK both Virgin Media and SKY
use Google to host there email service.
I doubt Google is offering their suite e-mail server programs that
comprises their

webmail service to non-Google e-mail providers. I'm not sure anyone
would want their, um, "stuff". You sure this "variation" isn't just a
proxy to Gmail, like some schools offering "free for life" school e-mail
accounts (with their domain) that are really using Gmail as the real
e-mail provider?

Having said all you have said I still figure the problem is in Outlook.
However it seems to have righted itself this morning.

 

[VanguardLH]

Yes

Since you're using only one method to access your Gmail account (POP)
then you should only enable that method and disable the other one
(IMAP). You said you configured Outlook to use POP to access your
Gmail account.

I don't know where you are, but here in the UK both Virgin Media and
SKY use Google to host there email service.

Other ISPs use Yahoo Mail for e-mail services. That isn't a "variant"
as you describe. That's just an ISP too cheap or ignorant to operate
their own e-mail services and paying someone else for that who can do
it cheaper and more reliably than they can. Your ISP contracted with
Gmail to provide their e-mail services, just like ISPs may contract with
NSPs (e.g., Giganews and Highwinds) to provide newsgroups.

Having said all you have said I still figure the problem is in
Outlook. However it seems to have righted itself this morning.

But you haven't changed any configuration of Outlook or the security
programs or other software on your host, did you? Google makes
changes, things break and require maintenance, so more likely the
hiccup was on Google's end and is now fixed. With Gmail, Yahoo Mail,
and Hotmail, you have to give them 4-24 hours to right themselves. No
point in wasting time on your end on something you can't control.