On 04/18/2011 07:13 PM, JD wrote:
Could very well be a harmless bug.
I was also wondering if the bug is caused by the client request
being broadcast to all 3 gmail servers, and one of them quickly
responds, and one or both of the other 2, which are apparently
not notified that the response has been sent, will send their
reply to a session which has already closed.
Any google mail admins on this list?? :)
if in your case a another server (also google's property) is sending the
RST, it's different situation from mine, to be sure runs "tcppdump -i
eth0 port 995 -n" in a terminal and download your email via thunderbird,
if you see two different pop server ip address, well in my limited
testing I only was one server.
maybe in your logs have three servers written because in one day one ip
addresss was resolved by your dns server, after sometimes the dns cache
expired and resolved another ip address
now maybe linux isn't closing properly the session, so google is sending
the RST, but having two bugs in different programs (fetchmail and
thunderbird) is more unlikely which only a bug in google'spop server.
also that packet isn't marked NEW, ESTABLISHED or RELATED, but INVALID
I'm not sure if a stock Linux install DROP or REJECT the INVALID
packets, but maybe don't log them so the problem isn't more known
between the users of gmail pop3s servers, many prefer imap. I use imap
but only in my own servers.
Gabriel