Opened 11 years ago

Closed 9 years ago

#9269 closed bug (fixed)

POP mail does not fetch any mail from GMail (other providers ok)

Reported by: Kev Owned by: axeld
Priority: normal Milestone: R1/beta1
Component: Servers/mail_daemon Version: R1/alpha4.1
Keywords: Cc:
Blocked By: #8293 Blocking: #11292
Platform: x86

Description

1) Install Alpha 4.1 on a blank partition. 2) Set up the mail daemon with Gmail. 3) Send yourself an e-mail. 4) On webmail I can see that the e-mail sent successfully from Haiku, but even a half hour later, forcing a check from Haiku, it does not download any mail (nor does it give an error.)

This is on a Thinkpad X41.

Change History (21)

comment:1 by axeld, 11 years ago

Is that with POP3 or IMAP?

comment:2 by humdinger, 11 years ago

I've been seeing that for months. I think I have verified with older alpha images (from a time I used the mail_daemon with GMail (POP3) successfully), that it won't fetch any more mail from GMail either. My other POP3 account at GMX works OK.
I first thought it might be a mis-formatted mail that trips the daemon up, but since it persists after deleting a few mails at the time these issues first cropped up, I think it's some change at Google's end. I could have sworn I filed a ticket for that...
I now use Beam to fetch mail (SMTP to GMail still works with mail_daemon), which isn't really my cup of tea...

comment:3 by anevilyak, 11 years ago

Priority: blockernormal

comment:4 by axeld, 11 years ago

Owner: changed from czeidler to axeld
Status: newin-progress

I'll look into that in my IMAP branch, too.

comment:5 by axeld, 11 years ago

I guess the POP3 account is configured to leave the mail on the server?

comment:6 by humdinger, 11 years ago

Me? Yes. :)

comment:7 by pplude, 11 years ago

Replicated bug on hrev45186 nightly from 1/21/2013. Gmail will not connect on POP, is enabled on web, and the Mail Daemon is looking for the server at port 995. No mail is being received, and interestingly enough there is no error message. Other POP accounts are working OK.

It does appear to be on Google's end. Using IMAP is a doable workaround, and no other mail service seems to be having this specific issue.

comment:8 by Kev, 11 years ago

Perhaps it is, but if so, shouldn't there be some sort of error message? Gmail's a common enough provider that I'd think you'd want it working out-of-the-box, or at least telling you that it can't.

comment:9 by axeld, 11 years ago

You did notice that this bug is still open, did you? :-)

comment:10 by Kev, 11 years ago

Oh, sorry :-) For some reason the "on Google's end" stuck in my mind more than the open status or the "bug" label. It's just you folks are more helpful than most organizations I come in contact with in life--often I have to go out of my way and prove that something needs attention with the gov't and corps...

comment:11 by Kev, 10 years ago

BTW though Gmail's IMAP also does not work on Haiku as of hrev46447. I miss the ease of mailing in BeOS/Haiku...maybe it's time to switch mail providers.

comment:12 by richienyhus, 9 years ago

Now that the mail refab branch is merged into trunk, could someone check to see if it is still happening?

comment:13 by pulkomandy, 9 years ago

Summary: POP mail does not fetch any mail despite new mail on the serverPOP mail does not fetch any mail from GMail (other providers ok)

comment:14 by jessicah, 9 years ago

FWIW, I had similar issues with IMAP and GMail. Disabling IPv6 completely in my build resolved this issue for me... perhaps this is also the case here.

comment:15 by pulkomandy, 9 years ago

Blocked By: 8293 added

Indeed, that seems to be the case. Marking this ticket as blocked by #8293 then.

comment:16 by pulkomandy, 9 years ago

Blocking: 11292 added

comment:17 by pulkomandy, 9 years ago

Please confirm that it works correctly now that #8293 is fixed.

comment:18 by jessicah, 9 years ago

Doesn't work for me here. I also removed the ipv6 and related modules from my image to confirm, and when clicking on "Configure IMAP Folders" in the E-mail preferences, I get the following error:

Could not connect to server "imap.gmail.com": Address family not supported by protocol family

Looks like #8293 is not actually fixed. Running strace isn't helpful, the only output I get when trying to connect is "Connect", and no typical syscall output. Also, do we have a command similar to nslookup? I can't seem to find anything >_<

In fact, I would consider the situation as worse than before. Previously, if ipv6 was removed from the image, I could at least get IMAP to work. Now it just complains that there's no ipv6 and continues to fail.

Last edited 9 years ago by jessicah (previous) (diff)

comment:19 by pulkomandy, 9 years ago

nslookup is not available as far as I know. I usually use telnet to test DNS resolution, as it will print the IPs it tries (and it does try IPv4 when IPv6 fails).

Note that you do need the system/settings/network/ports file for the resolution to work (I will fix that today).

comment:20 by pulkomandy, 9 years ago

Please try hrev49401 or later. telnet will still try the ipv6 address first because it does not use the AI_ADDRCONFIG flag, but anything using that flag (or using BNetworkAddressResolver) should work now.

comment:21 by pulkomandy, 9 years ago

Resolution: fixed
Status: in-progressclosed
POP3Protocol::Retrieve Note: message size is 5329102, was expecting 3693, for message #12.  Could be a transmission error or a bad POP server implementation (does it remove escape codes when it counts size?).
POP3Protocol::Retrieve Note: message size is 268507, was expecting 3693, for message #17.  Could be a transmission error or a bad POP server implementation (does it remove escape codes when it counts size?).
POP3Protocol::Retrieve Note: message size is 268065, was expecting 3693, for message #19.  Could be a transmission error or a bad POP server implementation (does it remove escape codes when it counts size?).
POP3Protocol::Retrieve Note: message size is 2578, was expecting 3693, for message #20.  Could be a transmission error or a bad POP server implementation (does it remove escape codes when it counts size?).
POP3Protocol::Retrieve Note: message size is 4049, was expecting 3693, for message #21.  Could be a transmission error or a bad POP server implementation (does it remove escape codes when it counts size?).
POP3Protocol::Retrieve Note: message size is 3132, was expecting 3693, for message #22.  Could be a transmission error or a bad POP server implementation (does it remove escape codes when it counts size?).
POP3Protocol::Retrieve Note: message size is 5449, was expecting 3693, for message #23.  Could be a transmission error or a bad POP server implementation (does it remove escape codes when it counts size?).
POP3Protocol::Retrieve Note: message size is 3645, was expecting 3693, for message #24.  Could be a transmission error or a bad POP server implementation (does it remove escape codes when it counts size?).
POP3Protocol::Retrieve Note: message size is 5749, was expecting 3693, for message #25.  Could be a transmission error or a bad POP server implementation (does it remove escape codes when it counts size?).
POP3Protocol::Retrieve Note: message size is 4022, was expecting 2032, for message #33.  Could be a transmission error or a bad POP server implementation (does it remove escape codes when it counts size?).
POP3Protocol::Retrieve Note: message size is 1823, was expecting 1039, for message #36.  Could be a transmission error or a bad POP server implementation (does it remove escape codes when it counts size?).

But downloads are working ok now, closing the ticket.

Note: See TracTickets for help on using tickets.