[chrismorgan]

Well, IMAP rather than POP3. I don’t think there’s a single legitimate reason to use POP3 any more (or has been for at least a decade).

The fetch approach has some significant caveats.

Firstly, it introduces something like 5–10 minutes of latency before you receive messages compared with forwarding, so it’s not suitable for every purpose. If you’re accessing via the webmail, forcing a refresh may trigger remote fetches too, if you know to expect something.

Secondly, if you leave messages on the server, there’s an undocumented limit at which point it will stop fetching mail, probably without notifying you. Back in early I think it was 2015, I went for a couple of weeks before I realised I wasn’t getting any email to what had been my primary address for six or so years (there were still just enough things going to my @gmail.com address that I didn’t notice), and on investigation, it told me that it refused to fetch from a mailbox containing more than 50,000 messages.

(Qualifier: I haven’t touched Gmail for five years (I now use Fastmail), so parts of this could be obsolete or altered.)

[knorker]

> Well, IMAP rather than POP3.

I set this up a couple of weeks ago. I think Gmail only allows pop3 for email fetching, because I just couldn't get it to even try connecting to my IMAP. pop worked great though.

The settings even lists "POP Server", not "Server", even if you choose port 143 or 993

> I don’t think there’s a single legitimate reason to use POP3 any more

Well, pop was designed as a "download the messages" protocol, IMAP as a "keep messages on the server" protocol, right?

So while it doesn't prevent IMAP, pop is actually a better mapping in intent.

Pop is clear about what "the email" is. IMAP opens questions like "so… all email? Or just INBOX, or what?". And while it's not mandatory to delete the emails from the server with pop, it becomes even more of a complex question with IMAP.

The choice of pop3 very strongly implies answers to all of these questions, with no surprises.

Are there downsides to pop here that I'm not considering?

[chrismorgan]

The main one I had in mind was POP3’s behaviour around deletion; my recollection is that if you don’t want it to work that way (and I think you might prefer not to in general, so you can be confident of having your own copy of everything), you run into practical performance, bandwidth and processing limits much sooner, because messages don’t have any external identity, so the receiver has to download everything every time to check if it’s seen it before. And you can’t just say “well only look at messages in this folder”—POP3 sees all, and that’s a problem.

But y’know what, I’m going to retract my comment for the case where you don’t want to keep a copy of anything. For most places, POP3 is generally unsuitable, but for this specific type of destructive server-to-server fetching, it’s reasonable.

[KMnO4]

> and on investigation, it told me that it refused to fetch from a mailbox containing more than 50,000 messages.

Ironically, you would not have this problem with POP3.

[chrismorgan]

… because POP3 isn’t able to leave messages on the server, it’s such a coarse instrument.

You can instruct IMAP fetches to delete too, and that’ll avoid this problem. Better would be to move emails into a new mailbox after fetching them, so that you don’t need to see them again but they’re still there, but I don’t know if anything supports that concept.

[knorker]

> Better would be to move emails into a new mailbox after fetching them, so that you don’t need to see them again but they’re still there, but I don’t know if anything supports that concept.

The best way to do this, in my opinion, is to tee the emails to another mailbox as they come in, not as they get pulled from the inbox.

[chrismorgan]

Yeah, that’ll have much better support.

[yuubi]

POP3 defines separate retrieve and delete requests. Some servers lose messages when you retrieve them, but I've only seen that misbehavior on major ISPs.