Re: Timing out while trying to connect to gmail. Config?

Charles Cazabon <[email protected]>
Newsgroups gmane.mail.getmail.user
Message-ID <[email protected]>
Mauricio Tavares <[email protected]> wrote:
> 
> [mailsucker@backupmail ~]$ du -sh mail/gmail/*
> 1.4G    mail/gmail/raubvogel
> [mailsucker@backupmail ~]$
> 
> So, I guess we are back to network issues?

Yes and no.  Keep in mind that there's a certain amount of overhead involved
in IMAP (or POP) protocols, so retrieving X bytes of mail won't just count as
X bytes towards a limit on IMAP traffic - it'll be somewhat higher.

And if they cut you off hard when you hit the quota (I'm not clear on how they
handle hitting quota), that will kill that getmail session, causing any
messages it had retrieved in that session to be retrieved the next time you
run getmail, using up more of the quota.

If your network connections to Gmail are pretty solid - they don't die
*except* when you hit this daily traffic limit - then I would recommend you
retrieve your backlog by running getmail once daily with max_bytes_per_session
set somewhat lower than the IMAP quota - say 20% less as a good starting
point.  Then run getmail once a day like that (with read_all=False) until
you've caught up and retrieved all your mail, then you can switch to polling
more frequently than once a day.

If your connections are not rock solid and die often enough to make it likely
to happen during one of these "big dump" runs, then you'll need to set your
maximum messages or bytes much lower and run getmail multiple times a day,
stopping when you hit the quota.  And then again, switch to polling more
frequently after you've caught up.

Is that, and the reasons for it, clear?

Charles
-- 
-----------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at:               http://pyropus.ca/software/
-----------------------------------------------------------------------
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.