Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#7267 closed bug (fixed)

No new mails are fetched from POP3 account

Reported by: taos Owned by: czeidler
Priority: normal Milestone: R1
Component: Servers/mail_daemon Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

Since major restructuring of mail server (using hrev40624 at the moment) POP3 accounts are broken: Mails can be sent via SMTP (if login type is set to ESMTP), but there are no incoming messages for POP3 accounts (at least, it doesn't work for my yahoo account). No error messages are displayed.

Change History (14)

comment:1 by luroh, 14 years ago

Component: - GeneralServers/mail_server
Owner: changed from nobody to czeidler
Status: newassigned

comment:2 by czeidler, 14 years ago

Please try to start the server from the terminal /system/servers/mail_daemon (first close the running one) and look at the output.

Did you trigger fetching from the menu? Also enable the status window in the preflet.

comment:3 by taos, 14 years ago

Still using hrev40774, status window is always enabled.

Terminal output after restarting mail_daemon:

/boot/system/servers> mail_daemon
POP3Protocol::POP3Protocol(BMailAccountSettings* settings)
account name abcdefg, id 1299083422, in 0x1804f470, out 0x18052410
POP3Protocol::POP3Protocol(BMailAccountSettings* settings)
account name hijklmn, id 1299083718, in 0x1804e880, out 0x18052218

After using the "Check mail now" button of the status window to fetch mail:

POP3Protocol::SyncMessages()
POP3Protocol::SyncMessages()
POP3 to download: 202

Unfortunately, there are no new mails downloaded and the status window shows "No new messages". As soon as the newest nightlies hit http://haiku-files.org/ I'm going to try again.

comment:4 by taos, 14 years ago

For hrev40806 it looks exactly the same (apart from the id numbers - after every upgrade I have to recreate my accounts because Incoming and Outcoming settings are no longer accessible).

comment:5 by czeidler, 14 years ago

Strange should be working. Is the incomming mail path set correctly? Whats your provider maybe I create a test account...

comment:6 by taos, 14 years ago

Incoming mails should be downloaded to /home/mail/in, new messages are left on server.

Provider: yahoo.com
e-mail adress xx.xx@​yahoo.com (of course, that's only an example)
login name xx.xx

pop3 server: pop.mail.yahoo.com
smtp server: smtp.mail.yahoo.com

Prior to restructuring of mail_daemon it was possible to create a working pop3 account with this information - I still have a working Haiku version (I guess from late January) installed on my netbook that can download mails from this account.

Last edited 14 years ago by taos (previous) (diff)

comment:7 by czeidler, 14 years ago

Hm strange just tried it with a fresh yahoo.com account and it works fine here. Any other stuff that could be different? If not I could commit a version with more debug output...

comment:8 by taos, 14 years ago

Tried again with hrev40913, I still can't download any new messages. Is there (apart from /home/config/settings/Mail) another location where mail settings are saved?

I also wonder why I have to recreate my account settings every time I upgrade to a new nightly. Is this intended?

comment:9 by czeidler, 14 years ago

Added some debug output in hrev40920 could you try again and post the terminal output? thanks.

What do you mean by recreate the account? you should be able to copy all files to the new image. But for debug you should create a new account in a fresh settings dir to ensure that there are no other errors.

comment:10 by taos, 14 years ago

I renamed my old mail settings directory from /home/config/settings/Mail to /home/config/settings/-Mail. After upgrading to the newest nightly (hrev40925) a new mail settings directory containing only ProviderInfo is created. I then recreated my mail accounts and started mail_daemon in terminal. If I try to download new mails I get this:

~> /system/servers/mail_daemon
POP3Protocol::POP3Protocol(BMailAccountSettings* settings)
account name Bugreport, id 1300040806, in 0x18053470, out 0x18052410
POP3Protocol::POP3Protocol(BMailAccountSettings* settings)
account name Mailinglist, id 1300040966, in 0x18052880, out 0x18052218
POP3Protocol::SyncMessages()
POP3Protocol::SyncMessages()
POP3: Messages to download: 251
POP3: Can't create file /boot/home/mail/in/Downloading file... uid: AMVuUtQAABF/TBPWzgsOBC1nf4Y

So, I renamed my Inbox and let mail_daemon create a new /home/mail/in directory. Unfortunately, I got exactly the same terminal output.

Do you think it could be a problem with a strangely formatted/named/etc mail on the server?

comment:11 by taos, 14 years ago

Being forced to recreate a mail account every time you're upgrading to a new nightly is described by humdinger in #7364. So I'll post everything regarding this issue in #7364 from now on.

comment:12 by czeidler, 14 years ago

Resolution: fixed
Status: assignedclosed

Ok the mail unique id contains a "/" thus the file can't be created. Hopefully fixed in hrev40935.

comment:13 by taos, 14 years ago

You were faster than me, I was about to add this comment:

After I removed most of the older mails from my inbox on the yahoo server I indeed suceeded in retrieving a number of mails (4/21, but they were not sorted by my e-mail filters in the corresponding folders).

Terminal output is now:

POP3Protocol::SyncMessages()
POP3: Messages to download: 21
POP3Protocol::Retrieve Note: message size is 6716, was expecting 6719, for message #0.  Could be a transmission error or a bad POP server implementation (does it remove escape codes when it counts size?).
POP3: Can't create file /boot/home/mail/in/Downloading file... uid: ANVuUtQAAG/8TXjxAwfzLi9xJnM

So, I suppose mail_daemon does definitely not like certain mails - but why?

I think I found an e-mail that was downloaded fine by the old mail_daemon but can't be retrieved by the new one. If you are interested I could look for strange formatting or special characters.

comment:14 by taos, 14 years ago

I can confirm that this bug is fixed in hrev40950. All mails are downloaded (but mail filters are ignored - I opened a new ticket #7374).

Note: See TracTickets for help on using tickets.