create new tag
, view all tags
Just compiling a list of potentially useful utilities for email, for Linux or Windows.

See AboutThesePages.


Accessing WebMail via pop


Gmail has a built-in "pseudo" pop client that you can use to get mail to a pop (i.e., traditional) email client. I say pseudo because there are a few quirks. Might not get this right from memory, but, in general, an email can only be accessed once via email (iirc, it is marked read after being fetched via pop). Some of the consequences:

  • your (pop) email client doesn't have to (and in fact can't) delete emails after downloading them via pop
  • until they are deleted by other means (manually on the web, or by "expiring" after an (iirc, adjustable) time period, you can arrange to resend them (via pop) by accessing them on the web and marking them unread
  • at least twice I had an occurrence (some time ago now) where something, somehow, marked all the emails that I had previously accessed via pop as unread, and all those (thousands) of emails were retransmitted to me. I can't recall what caused it (and may be mis-remembering some significant details (like maybe I did something to cause the problem).

Update: Lost Messages in Gmail (via pop3)

UPDATE, 20100419: I've updated the link below as I moved the thread to a new location. I might move it again.

CURRENT STATUS:--bkennelly responded to the thread with information that:

  • the operation of the google protocol is not quite as I remembered it, and thus it should be unlikely to lose messages by this mechanism
  • still, he is aware that other people report messages lost via POP, but he (at least) has not determined the mechanism by which it happens
  • he has run tests where (iiuc) he ran a "manual" pop session, then interrupted the session by pulling his Internet cable, and the messages were not lost, they remained available and were downloaded (available for download) in the next pop3 session
  • I've run similar tests, although (so far) I haven't bothered to interrupt the sessions by disconnecting my Internet cable, instead I've just ended the sessions by pressing c instead of sending QUIT (first). In those tests, I have not lost any messages (they all remained available for downloading in the next pop3 session)
  • at this point I'm not sure what to think--in the past, most of the messages sent to me and lost I never found--I know I looked for them in the (Google) spam "folder", but don't recall whether I looked in the deleted messages for them. This time, when I found the missing message in the deleted section (and had convinced myself it hadn't been downloaded and accidentally stored somewhere else), I assumed the problem was a result of the way I understood the Google pop3 protocol was implemented. Now I don't know what to think--I'm still certain the message never got to my kmail client--so what happened?
  • maybe I should revise the thread over on google to state the tentative conclusion at the top of the page (something like, "Google's implementation of the pop3 protocol is not as I understood it (maybe it was at one time?), so much of this may be irrelevant--still, there is a method of testing described here that may help you if you have similar problem, and there seems to be some real problem, as there is a mechanism by which messages transmitted from Google to a local email client are occasionally lost, with the lost message showing up "marked for deletion"".
  • hmm, maybe I'll send that as a final post in the thread (subject to anybody else adding something else)--I would think about moving the thread one final time to put the summary above at the top, but it would look rather "hokey" as I cannot (afaik) regenerate the posts from bkennelly (other than by quoting them)--but they'd show up as coming from me--so, I'll start by adding this summary as a (tentatively) final post to that thread.
  • in my askRhk notes, I found some old URLs linked to google topics that may have been relevant back when I first signed up to Google and realized this potential problem--those URLs seem to be dead--either they've been removed or they contained some characters beyond the normal ASCII character set that were lost in the course of pasting them to the askRhk file via nedit. I won't go looking for those again atm. That is rather frustrating if they have been deleted, especially if I contributed to the information on those URLs and it explained the problem as I saw it when I first signed up with Google mail.

UPDATE: I have posed the issue to Google at I am losing messages because Gmail's implementation of the pop3 protocol is not fully compliant

Currently (ca. 20100413) I'm having some trouble losing emails--I don't get them in my email client (kmail), but they are marked as sent (i.e., moved to the deleted emails status) on the Gmail server. I thought I had some old notes about a discrepancy between the pop3 protocol and Gmail's implementation of the pop3 protocol, but, atm I can't find any such notes. Looking around, I found the following in RFC 1939.

Just based on my vague recollections, I think this was the heart of the difference--I think Gmail marks emails for deletion (and moves them to the deleted email status) before the client issues a QUIT, and, thus, in the normal course of events, they are not resent with the next pop3 download. Read the excerpts below to see that emails should not be deleted until the client issues a QUIT, which signifies that the client has received the email and "successfully ... stored" it.

The recent "RECENT:" modification added to Gmail does not really help with the situation (at least not for occasional missed emails)--I don't want to re-receive 30 days of emails in an effort to guarantee that I haven't missed any... .

      One special case of a site policy is that messages may only be
      downloaded once from the server, and are deleted after this has
      been accomplished.  This could be implemented in POP3 server
      software by the following mechanism: "following a POP3 login by a
      client which was ended by a QUIT, delete all messages downloaded
      during the session with the RETR command".  It is important not to
      delete messages in the event of abnormal connection termination
      (ie, if no QUIT was received from the client) because the client
      may not have successfully received or stored the messages.
      Servers implementing a download-and-delete policy may also wish to
      disable or limit the optional TOP command, since it could be used
      as an alternate mechanism to download entire messages.

I believe the same intent existed even in the older versions of the pop3 standard, e.g. rfc 1081. The wording there talks about marking messages for deletion until the UPDATE state of a sessionn, entered after the client sends QUIT. It is only then that messages are actually deleted.

The UPDATE State

   When the client issues the QUIT command from the TRANSACTION state,
   the POP3 session enters the UPDATE state.  (Note that if the client
   issues the QUIT command from the AUTHORIZATION state, the POP3
   session terminates but does NOT enter the UPDATE state.)

               Arguments: none
               Restrictions: none

                 The POP3 server removes all messages marked as deleted
                 from the maildrop.  It then releases the
                 exclusive-access lock on the maildrop and replies as
                 to the success of
                 these operations.  The TCP connection is then closed.


  • FetchYahoo and a different link--gets around Yahoo's recent change in policy to charge for accessing Yahoo mail via fetchmail/pop -- puts mail in a local mail spool. There are also programs here to set up a popserver for such mail so that other machines (on a LAN?) can access the mail via pop. FetchYahoo is written in Perl.

Thanks, Anita Lewis--they both seem useful so I left (moved) them both there-- RandyKramer - 27 Aug 2006 (DeleteThisLine)


(Please add if you have information.)


  • RandyKramer - 02 May 2002
  • AnitaLewis - 24 Aug 2006
  • <If you edit this page, add your name here, move this to the next line>

Page Ratings

Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r8 - 2010-04-19 - RandyKramer
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by PerlCopyright 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding WikiLearn? WebBottomBar">Send feedback
See TWiki's New Look