Re: Gmail pop3 failing since yesterday

Am 22.04.20 um 18:25 schrieb Tory S. Anderson:
> In my case, still using pop3, it turns out it was some invalid message (I still don't know what makes a message invalid). I fixed it by having getmail skip the breaking messages, which I found one-at-a-time. There were apparently 3 of them amid my 400-message backlog. Details blogged here: https://tech.toryanderson.com/2020/04/19/gmail-pop3-suddenly-broken-for-getmail/

Tory, you can fix your blog.

As you were told before, the server is broken, it is offering a message
(LIST and possibly UIDL) it isn't willing to hand out to getmail when it
tries to RETR.

POP3 is simplistic enough that further evaluation is not required. The
server can otherwise only refuse to hand out messages that the client
has deleted in the same session.
Report that to Google if possible, they may not reply personally but may
fix that bug over time.

Volker Wysk <[email protected]> writes:
> The server isn't necessarily broken. I've had this problem with a
> server (Dovecot) and TWO clients which both accessed the same mailbox.
> Both tried to download messages with IMAP IDLE, but it should be the
> same with POP3. It could happen that one downloaded and erased a
> message while the other wasn't done with the same message. It's a race
> condition. 

Volker and Tory, it is NOT AT ALL the same in IMAP4 as with POP3,
Volker, stop spreading guessed nonsense please.

IMAP 4 permits concurrent access (RFC-3501 section 5.2), POP3 EXPLICITLY
requires mailboxes to be locked for exclusive-access (RFC 1939 section
#4) and in that way differs considerably from IMAP4, quote from RFC 1939
below:

|    Once the POP3 server has determined through the use of any
|    authentication command that the client should be given access to the
|    appropriate maildrop, the POP3 server then acquires an exclusive-
|    access lock on the maildrop, as necessary to prevent messages from
|    being modified or removed before the session enters the UPDATE state.

where UPDATE state means "after receiving QUIT command from client".

> The problem went away when I deactivated one of the two listeners.
>
> The actual issue here is, that the IMAP protocol doesn't discriminate
> non-existent message-IDs from expired message-IDs.

Volker, that is not the issue either, and not a problem or whatever.

The IMAP4 server has ways to notify clients of messages that have been
removed, if the client isn't paying attention, that is not a shortcoming
of the IMAP protocol, but an implementation fault, which states when the
server may and must not send untagged EXPUNGE responses, and that the
client MUST record EXPUNGE responses. See RFC-3501 section 7.4.1 EXPUNGE
responses.

A message-ID is just transported content in IMAP, i. e. content, not
protocol beyond putting it in a particular place in an envelope response
that transports multiple headers in one answer. Again, see RFC-3501.