maemo.org Bugzilla – Bug 3387
Modest doesn't fetch GMX IMAP mail (issuing LIST "" instead of LIST "*")
Last modified: 2010-05-10 15:18:10 UTC
You need to log in before you can comment on or make changes to this bug.
SOFTWARE VERSION: OS2008 Feature Upgrade v. 4.2008.23-14 clean flash update, no data has been restored from backup STEPS TO REPRODUCE THE PROBLEM: 1) email account created (German "GMX" provider with IMAP support) 2) verified that all settings are correct 3) trying to fetch IMAP mails and folders 4) device connects to internet EXPECTED OUTCOME: as experienced with last OS 2008 release 4.0 mailbox folder should appear ACTUAL OUTCOME: one time I got a message "Certificate untrusted, allow?", after that nothing happened right nothing is happening at all, neither will I get folders or inbox email nor there is a error message. Loadapplet shows cpu is working for a short time. Modest shows "Last update: never" REPRODUCIBILITY: tested with another IMAP mailbox provider (German "web.de", this works fine) "GMX" does have a folder "Gelöschte Objekte", "Web.de" doesn't have any folders with "Ö", "Ü", or "Ä" in the name. Unfortunately I don't have any other mail accounts to test this. EXTRA SOFTWARE INSTALLED: eightyone statusbarclock loadapplet OTHER COMMENTS:
Thanks for reporting this. starting from the commandline ('modest showui') might give some valuable output - please post it here. What are the exact settings to reproduce this? Are you using SSL or TLS in the settings?
(In reply to comment #1) > Thanks for reporting this. > starting from the commandline ('modest showui') might give some valuable > output - please post it here. > > What are the exact settings to reproduce this? Are you using SSL or TLS in the > settings? > Settings: Incoming: imap.gmx.net (no secure connection, port 143) Outgoing: mail.gmx.net (secure authentication: login) Neither using TSL nor SSL for connection. 'modest showui' doesn´t show anything, only thing happening is modest starting.
But you can fetch your GMX mail by using IMAP on another computer?
Yes, I can fetch mails with my Nokia Communicator 9500 and Nokia 770 and prior to Diablo, with my N800 running OS2008 4.0. So the settings are correct.
(In reply to comment #2) > > starting from the commandline ('modest showui') might give some valuable > > output - please post it here. [...] > 'modest showui' doesn´t show anything, only thing happening is modest > starting. I think this should be: /usr/bin/maemo-summoner /usr/bin/modest.launch showui Otherwise it's launched using already running maemo-launcher daemon (which output goes to /dev/null).
Thank you for the information, here is the output: BusyBox v1.6.1 (2008-05-22 10:32:35 EEST) Built-in shell (ash) Enter 'help' for a list of built-in commands. ~ $ /usr/bin/maemo-summoner /usr/bin/modest.launch showui maemo-summoner: summoning '/usr/bin/modest.launch' modest[2399]: GLIB DEBUG default - mission_control_get_presence_actual: MC not running. modest[2399]: GLIB DEBUG ConIc - con_ic_connection_send_event(0x42c08, b6137d6a-ca2d-4cba-8bd8-a31164cb034a, WLAN_INFRA, 0) modest[2399]: GLIB DEBUG default - on_connection_event: emiting is_online (true) modest[2399]: GLIB DEBUG default - conic_emit_status: emitting status (0x1658c0, true) in 1000 ms modest[2399]: GLIB DEBUG default - conic_emit_status_idle: destroying 0x1658c0 (idle) modest[2399]: GLIB DEBUG default - conic_emit_status_idle: emitted tny-device-connection-changed signal modest[2399]: GLIB DEBUG default - conic_emit_status_destroy: destroying status info (0x1658c0) modest[2399]: GLIB DEBUG default - conic_emit_status_destroy: destroyed 0x1658c0 modest[2399]: GLIB CRITICAL ** default - file modest-tny-account-store.c: line 1149 (modest_tny_account_store_alert): should not be reached modest[2399]: GLIB WARNING ** Gdk - gdkdrawable-x11.c:878 drawable is not a pixmap or window modest[2399]: GLIB WARNING ** Gdk - gdkdrawable-x11.c:878 drawable is not a pixmap or window
*** Bug 3431 has been marked as a duplicate of this bug. ***
Confirming as per duplicate. This line looks suspicious: modest[2399]: GLIB CRITICAL ** default - file modest-tny-account-store.c: line 1149 (modest_tny_account_store_alert): should not be reached You're not using a GPRS connection by any chance? :-D Could you maybe provide a syslog (also see http://maemo.org/development/documentation/man_pages/hcidump.html )? It may include more info, e.g. an errorcode (at least this was helpful to track down Gmail IMAP bugs).
No, no GPRS connection at all, I'd be glad it's so easy ;-) Can you tell me which command line switches you need from hcidump?
(In reply to comment #9) > Can you tell me which command line switches you need from hcidump? Whoops, completely wrong link, garrr.... http://maemo.org/development/tools/doc/diablo/syslog/ should be right, hcidump does not make sense here. :-)
Well, now I need some help because as a linux newbie (even though I'm a windows system administrator) I need help how to start an configure the daemon. Unfortunately the manpages weren't able to help me. What I did up to now: Entered "Red pill mode" and installed syslogkd package
I can confirm the problem with a T-Online and a Runbox IMAP account. Neither unencrypted nor SSL configurations work. syslog just reports: modest[2907]: GLIB CRITICAL ** default - file modest-tny-account-store.c: line 1149 (modest_tny_account_store_alert): should not be reached
(In reply to comment #11) > I need help how to start an configure the daemon. Starting? Basically it's just http://maemo.org/development/tools/doc/diablo/syslog/ :-)
(In reply to comment #11) > Entered "Red pill mode" and installed syslogkd package Btw. it's better to uninstall syslog after it's not any anymore needed and remove the log files it saves under /var/log/. Syslog slows down the device a bit, but larger issue is the size and frequent writing of the logs.
Created an attachment (id=855) [details] syslog by reporter Most interesting line seems to be Aug 4 18:17:19 Nokia-N800-23-14 modest[1794]: GLIB CRITICAL ** default - modest_folder_view_select_first_inbox_or_local: assertion `self && MODEST_IS_FOLDER_VIEW(self)' failed
Could we get a test account in that server? That way we could test it properly.
Unfortunately a GMX account (gmx.de) to use imap protocol is not free, but a runbox account has a 30 day trial period, maybe that will help because Florian Müller has the same problem on a runmap account.
After applying 4.2008.30-2 update, seems to be same error. I'm going to check tomorrow if any new error messages will be shown.
What is runbox/runmap? Any URL?
Look at Comment #12. It's another webmailer, address is runbox.com
In short: I've tracked this down, could connect to Runbox.com IMAP Inbox. Long version: I have created a trial user named maemodebug (and the password might be quite similar) on runbox.com. According to http://doc.runbox.com/twiki/bin/view/RunboxHelp/IMAP I set the following preferences in Modest: Incoming account type = IMAP4 Incoming server: imap.runbox.com Secure Connection: Normal (TLS) This will set the port to 143 and I don't receive mail (sending works). Runbox FAQ says to use port 993 for TLS/SSL, but that also didn't help to get my mail. Then I tried to connect to Runbox IMAP on my home computer (running Evolution 2.22.3.1) by choosing TLS. I got the error "STARTTLS not supported" (why doesn't modest throw an error message?). So after choosing SSL instead of TLS, i got asked to accept the certificate and after that i could access the IMAP Inbox. Now back to Modest (latest updated version 4.2008.30-2): After setting "Secure Connection: SSL (IMAP4S)" and Port 993 I can access the IMAP Inbox on Runbox.com. I think this is a bug in the Runbox documentation and tend to close this as INVALID. Runbox users please contact Runbox to get that fixed. Anybody able to play the same game with GMX IMAP to see if it works? Please tell us your exact security settings and please confirm that you do use the latest released update version of Modest. Thanks.
(In reply to comment #21) > Anybody able to play the same game with GMX IMAP to see if it works? > Please tell us your exact security settings and please confirm that you do use > the latest released update version of Modest. Thanks. I run the latest version of Modest (at least I looked for software updates yesterday and there weren't any), and I am still not able to connect to GMX. I cycled through all possible security settings (no security, TLS, SSL, secure authentication), and the only response I get is either nothing at all or "username and password wrong" (which they certainly are not). So for me nothing changed in Modest's behaviour.
(In reply to comment #21) > I think this is a bug in the Runbox documentation and tend to close this as > INVALID. Runbox users please contact Runbox to get that fixed. Doesn't work for me. I re-flashed the device and updated to 4.2008.30-2. All attempts failed: with and without SSL, connection to imap.runbox.com and secure.runbox.com, different email addresses.
Hmm. Pity. Can you please start an X Terminal window and type the following commands: export "CAMEL_DEBUG"="all" to enable the debug mode of the mail library and after that run /usr/bin/maemo-summoner /usr/bin/modest.launch showui > log 2>&1 This will start Modest. Please try to connect to the IMAP server. Close Modest and attach the logfile named "log" here (please check for confidential data before attached).
(In reply to comment #24) > Can you please start an X Terminal window and type the following commands: > export "CAMEL_DEBUG"="all" > to enable the debug mode of the mail library and after that run > /usr/bin/maemo-summoner /usr/bin/modest.launch showui > log 2>&1 That results in a segmentation fault.
Created an attachment (id=882) [details] Debug log file
(From update of attachment 882 [details]) Resolving the hostname eventually works but it takes a while.
(In reply to comment #25) > > export "CAMEL_DEBUG"="all" > > /usr/bin/maemo-summoner /usr/bin/modest.launch showui > log 2>&1 > That results in a segmentation fault. only if you forget the "/usr/bin/maemo-summoner" part here :)
It works! I changed the nameserver in /etc/resolv.conf from 127.0.0.1 to the DNS server of my ISP and the IMAP server hostname could be resolved in a fraction of a second. Modest could connect to the IMAP server and started downloading my emails. I reset /etc/resolv.conf and replace in the account settings the IMAP server hostname with its IP. That works too and is my workaround for now. Any ideas why resolving the hostname takes so long? Why does Modest not wait or show at least an error message? Thanks everybody for your time and effort!
(In reply to comment #29) > I changed the nameserver in /etc/resolv.conf from 127.0.0.1 to the DNS server > of my ISP and the IMAP server hostname could be resolved in a fraction of a > second. Modest could connect to the IMAP server and started downloading my > emails. > > I reset /etc/resolv.conf and replace in the account settings the IMAP server > hostname with its IP. That works too and is my workaround for now. > > Any ideas why resolving the hostname takes so long? I don't know that much about networking, but I think the reason why /etc/resolv.conf has 127.0.0.1 as DNS address is that this way the device changes between networks (phone, wlan...) are transparent to the apps. You could try checking with "strace"[1] what "dnsmasq" does when it's being asked to resolve host name, for example like this: strace -p $(pidof dnsmasq) 2> dnsmasq.log & strace -e trace=network ping maemo.org 2> ping.log And then check what ping does when /etc/resolv.conf points directly to your ISP DNS. [1] see http://maemo.org/development/tools/
Created an attachment (id=887) [details] Debug log file Unfortunately, entering the mail provider's IP instead of the hostname did not work for me. I included the log file, which looks pretty much like the one posted in comment #6. Additionaly, I re-created the mail account while writing the log, which did not help either.
It doesn't work for me either entering the ip address instead of the hostname, GMX mailbox. I'm going to supply you with a logfile as soon as possible.
@ Stefan, Christian: > I included the log file Please make sure that you really set CAMEL_DEBUG as described when providing a log. There's no output at all after launching Modest, but there must be output when trying to access the server, see for example comment 26. @Sergio: modest[1392]: GLIB CRITICAL ** default - file modest-tny-account-store.c: line 1156 (modest_tny_account_store_alert): should not be reached Is that a known issue?
(In reply to comment #33) > @ Stefan, Christian: > > I included the log file > Please make sure that you really set CAMEL_DEBUG as described when providing a > log. There's no output at all after launching Modest, but there must be output > when trying to access the server, see for example comment 26. > > @Sergio: > modest[1392]: GLIB CRITICAL ** default - file modest-tny-account-store.c: > line 1156 (modest_tny_account_store_alert): should not be reached > Is that a known issue? > Yes, that's not really a problem in Modest, we shouldn't use a critical for that, it's just an unmanaged error code.
(In reply to comment #32) > It doesn't work for me either entering the ip address instead of the hostname, > GMX mailbox. I'm going to supply you with a logfile as soon as possible. *ping* :) As I said, I can't reproduce this unfortunately...
I do can reproduce it. It seems that it's the same problem than bug 3668, because the error I get is the same modest[7228]: GLIB WARNING ** default - err: You cancelled when you had to enter a password I'd mark as duplicate or at least a dependency
I have the exact same behaviour with GMX email. I've updated to the latest feature update 4.2008.36-5, that didn't help.
Can someone please re-test this with 4.2008.36-5 and add a comment? Also see bug 3668.
Same problem occurs with OS2008 feature upgrade 4.2008.36-5.
Sergio: If it's really the same issue, then bug 3668 has not been fixed yet...
Could it be possible to get some account for testing in that GMX server? Otherwise it will be really difficult to debug that problem.
I've sold my soul and got a 30 days trial GMX ProMail test account that provides GMX IMAP access. Everybody cross your fingers that I get out of that contract again without paying, otherwise I should invoice Nokia. ;-)
Ok I found the issue, tinymail is issuing LIST "" while it should be LIST "*" as evolution does. I'll try to find out why
Has there been any progress? The latest feature update 5.2008.43-7 does not fix this ...
(In reply to comment #44) > Has there been any progress? The latest feature update 5.2008.43-7 does not fix > this ... This bug report includes the line "Status: NEW" so it's quite obvious that the last update has not fixed this yet. Also week 43 was way before Sergio found out the reason for this in December.
(In reply to comment #23) > (In reply to comment #21) > > > I think this is a bug in the Runbox documentation and tend to close this as > > INVALID. Runbox users please contact Runbox to get that fixed. > > Doesn't work for me. I re-flashed the device and updated to 4.2008.30-2. All > attempts failed: with and without SSL, connection to imap.runbox.com and > secure.runbox.com, different email addresses. Runbox works perfectly at least with current code developed for Fremantle. I don't know if it works as well with the latest feature upgrade for Diablo. I'll try now with GMX. Could anyone provide a test account?
Assigning to me BTW
Hi guys, I've just checked that after some changes we added to tinymail namespaces management we can now read GMX IMAP mail. It's already committed to tinymail's trunk. If you find brave enough you can build tinymail packages for yourselves. I don't know if Nokia is planning to release another update, but if people want I can build the tinymail packages and place them in a public place for downloading.
setting a "definitely fixed in" target milestone then.
(In reply to comment #48) > I don't know if Nokia is planning to release another update, but if people want > I can build the tinymail packages and place them in a public place for > downloading. A bugfix for Diablo 5.2008.43-7 would be great since so far it's impossible to use some IMAP servers, in particular GMX. I would appreciate if it was easy to install via the package-manager.
Setting Target Milestone to Fremantle SDK beta.
(In reply to comment #48) > > I don't know if Nokia is planning to release another update, but if people want > I can build the tinymail packages and place them in a public place for > downloading. > Yeah, the people want 8) Is this new build available?
(In reply to comment #52) > > Yeah, the people want 8) > Is this new build available? > This worked for me: http://forums.internettablettalk.com/showpost.php?&p=305443&postcount=21
(In reply to comment #48) > I've just checked that after some changes we added to tinymail namespaces > management we can now read GMX IMAP mail. > > It's already committed to tinymail's trunk. If you find brave enough you can > build tinymail packages for yourselves. Do you know if Diablo modest will work with tinymail trunk? Otherwise, pointers to the specific changesets that fix this would be welcome :-) (In reply to comment #53) > This worked for me: > http://forums.internettablettalk.com/showpost.php?&p=305443&postcount=21 It shouldn't - the only difference from the official Diablo package is <https://bugs.maemo.org/attachment.cgi?id=1275&action=view>, nothing to do with LIST & namespaces.
(In reply to comment #54) > Do you know if Diablo modest will work with tinymail trunk? To answer my own question: yes, with a couple of changes (due to the old Diablo glib): - configure with --disable-demoui (debian/rules.maemo) - s/g_strcmp0/strcmp/ in libtinymail-camel/tny-camel-store-account.c:folder_opened() The packages themselves are a bit too large to attach here (~1MB, not counting -dev & -dbg), but if anyone wants to test with the GMX server email me and I'll send you a copy.
Maybe I spoke to soon. It seems to work fine generally, but once mail retrieval is initiated (manually or periodic) it gets stuck with the status bar in the "Retrieving" state. Oh well.
*** Bug 5710 has been marked as a duplicate of this bug. ***
Reopening, as the log attached to bug 5710 shows LIST and LSUB requests being sent with an empty mailbox name. For LIST that has special meaning (RFC3501 6.3.8): An empty ("" string) mailbox name argument is a special request to return the hierarchy delimiter and the root name of the name given in the reference. and for LSUB it doesn't make sense.
*** Bug 7651 has been marked as a duplicate of this bug. ***
*** Bug 7894 has been marked as a duplicate of this bug. ***
I asked Nokia for an IMAP account but as POP is delivered as default it seems that they don't have much interest on that. If anybody wants to share their credentials with me for testing purpouses just send me an email.
just FYI: Maemo5 on N900 works great with GMX IMAP. I've heard of a possible backport of Maemo5 to N810. This might fix the problem.
hi, any reason why this bug is deemed "low priority"? i can see several duplicates below which would indicate that this issue affects a lot of people and many IMAP servers without apparent workaround. I would vote at least medium...
(In reply to comment #62) > just FYI: Maemo5 on N900 works great with GMX IMAP. I've heard of a possible > backport of Maemo5 to N810. This might fix the problem. > Andre are you sure about that? Note that when you select GMX as a provider, we use the POP server.
*** Bug 8334 has been marked as a duplicate of this bug. ***
Since the only info modest has at that stage is the CAPABILITY response, and the one in bug 8334 is nearly as minimal as it can be, the common pattern is probably the lack of some capability. Looking at all the relevant reported logs, likely suspects are NAMESPACE and LIST-EXTENDED.
(In reply to comment #66) > Since the only info modest has at that stage is the CAPABILITY response, and > the one in bug 8334 is nearly as minimal as it can be, the common pattern is > probably the lack of some capability. Looking at all the relevant reported > logs, likely suspects are NAMESPACE and LIST-EXTENDED. > The guy who leads the Oracle Beehive mobility team works in the office next to me. He told me that Nokia and Oracle have some kind of partnership, and there is a test server set up already that has a few generic 'nokia0N' accounts on it. Of course it doesn't sound like there are any official Nokia employees working on this - so I'm not sure that helps. If I'm wrong and there are Nokia employees here, let me know and I can hook 'em up. If not, I might be able to get him to create a new account for someone to use - if so, let me know who the best person to create the account for is...
(In reply to comment #67) > (In reply to comment #66) > > Since the only info modest has at that stage is the CAPABILITY response, and > > the one in bug 8334 is nearly as minimal as it can be, the common pattern is > > probably the lack of some capability. Looking at all the relevant reported > > logs, likely suspects are NAMESPACE and LIST-EXTENDED. > > > > The guy who leads the Oracle Beehive mobility team works in the office next to > me. He told me that Nokia and Oracle have some kind of partnership, and there > is a test server set up already that has a few generic 'nokia0N' accounts on > it. > > Of course it doesn't sound like there are any official Nokia employees working > on this - so I'm not sure that helps. If I'm wrong and there are Nokia > employees here, let me know and I can hook 'em up. > > If not, I might be able to get him to create a new account for someone to use - > if so, let me know who the best person to create the account for is... I'm not a Nokian so don't have a clue about what you're talking about. If you're going to ask for an account then do it for me please.
(In reply to comment #68) > > I'm not a Nokian so don't have a clue about what you're talking about. If > you're going to ask for an account then do it for me please. > Unfortunately it sounds like it might not be as easy as I thought to get the account set up. Fortunately, I discovered that the same server does have an ActiveSync component also, and I was able to configure MfE to work with it, which seems so far to work fine. Getting this fix is now a much lower priority for me - I'm happy using MfE to get at my work email. Feel free to close this if it was only reopened on my account.
As far as Oracle Beehive is concerned a test account can be obtained from: http://www.oracle.com/dm/beehive/index.html The problem is easy to reproduce. I am using an N900 PR1.1.
(In reply to comment #66) I do have same problem as described by Warren in Bug 8334, but with Server imap.o2online.de (seemingly not Oracle beehive): --- received: * OK O3SIS UMA Proxy IMAP4 Server 7.0.0 sending : A00000 CAPABILITY received: * CAPABILITY IMAP4rev1 STARTTLS received: A00000 OK CAPABILITY completed sending : A00001 LOGIN xxx xxx received: A00001 OK LOGIN completed sending : A00002 CAPABILITY received: * CAPABILITY IMAP4rev1 received: A00002 OK CAPABILITY completed sending : A00003 LIST "" "" received: * LIST (\Noselect) "/" "" received: A00003 OK LIST completed sending : A00004 LSUB "" "" received: A00004 BAD arguments invalid sending : A00005 LOGOUT received: * BYE IMAP4rev1 Server logging out --- product info maemo 5 version 2.2009.51.1 (BTW: Warren has 2.2009.51.1-1.002 - did I miss anything?) Using this IMAP account for years now with lots of different clients. Never had any difficulties. Since I have an unused O2-SIM-card (and hence an email address at o2online.de) I could offer test account for it. I would really much appreciate if this bug could be solved finally.
(In reply to comment #71) > (In reply to comment #66) > I do have same problem as described by Warren in Bug 8334, but with Server > imap.o2online.de (seemingly not Oracle beehive): > --- > received: * OK O3SIS UMA Proxy IMAP4 Server 7.0.0 > sending : A00000 CAPABILITY > received: * CAPABILITY IMAP4rev1 STARTTLS > received: A00000 OK CAPABILITY completed > sending : A00001 LOGIN xxx xxx > received: A00001 OK LOGIN completed > sending : A00002 CAPABILITY > received: * CAPABILITY IMAP4rev1 > received: A00002 OK CAPABILITY completed > sending : A00003 LIST "" "" > received: * LIST (\Noselect) "/" "" > received: A00003 OK LIST completed > sending : A00004 LSUB "" "" > received: A00004 BAD arguments invalid > sending : A00005 LOGOUT > received: * BYE IMAP4rev1 Server logging out > --- > > product info > maemo 5 > version 2.2009.51.1 > > (BTW: Warren has 2.2009.51.1-1.002 - did I miss anything?) > > Using this IMAP account for years now with lots of different clients. Never had > any difficulties. > > Since I have an unused O2-SIM-card (and hence an email address at o2online.de) > I could offer test account for it. > > I would really much appreciate if this bug could be solved finally. You're lucky :-) as I have just fixed this issue, I'm just checking that everything is fine and I'll commit the fix after that. I'd appreciate very much that test account to check that the bug is indeed fixed
Thats good news, Sergio. Sent test account data to your igalia mail.
(In reply to comment #73) > Thats good news, Sergio. Sent test account data to your igalia mail. > Thx Ulle, I can confirm you that the fix also solves your problem.
I have just committed the long awaited fix for this bug. Thank you all for your patience. Fixed in tinymail: releases/modest/modest-3-2: r4148 - r4149 trunk: r4146 - r4147 This fix will be shipped with the new sw update for the N900. For those of you that feel brave enough you can always build packages *BUT* note that installing new packages will *BREAK* your next system update. I strongly recommend to wait for the official update. In the mean time you can use the trick of setting a rule that copies emails from inbox in another folder (it's nasty I know but it works)
(In reply to comment #75) > This fix will be shipped with the new sw update for the N900. Setting TM accordingly, and while I'm generating bugmail may I say thanks to all the people who supplied logs and/or test accounts and especially to Sergio for sharing progress (including relevant commits) here. This is exactly what bug 630 is about :-)
(In reply to comment #75) > I have just committed the long awaited fix for this bug. Thank you all for your > patience. > > Fixed in tinymail: > releases/modest/modest-3-2: r4148 - r4149 > trunk: r4146 - r4147 > > This fix will be shipped with the new sw update for the N900. For those of you > that feel brave enough you can always build packages *BUT* note that installing > new packages will *BREAK* your next system update. I strongly recommend to wait > for the official update. In the mean time you can use the trick of setting a > rule that copies emails from inbox in another folder (it's nasty I know but it > works) I will look at it to provide PR1.1 package with fix by my system-upgrades repository.
(In reply to comment #77) > > I will look at it to provide PR1.1 package with fix by my system-upgrades > repository. > Some stupid questions: - How can I try the "system-upgrades" fix? - would it break the coming normal update? - Any idea when this fix is coming out as a regular Maemo update/fix? (sorry for all the questions, I'm a "Maemo newbie")
(In reply to comment #64) > > just FYI: Maemo5 on N900 works great with GMX IMAP. I've heard of a possible > > backport of Maemo5 to N810. This might fix the problem. > > Andre are you sure about that? Note that when you select GMX as a provider, we > use the POP server. Sergio, yes, it works on the N900. Just used manual setup to configure IMAP with imap.gmx.net.
(In reply to comment #78) > Some stupid questions: > - How can I try the "system-upgrades" fix? http://talk.maemo.org/showthread.php?p=480227#post480227 > - would it break the coming normal update? No. > - Any idea when this fix is coming out as a regular Maemo update/fix? In PR 1.2 it should be fixed.
Sorry to say that, but I tried modest with the fix in Marcins repository and still get the same behaviour. Nothing changed for me. process 5077: arguments to dbus_bus_request_name() were incorrect, assertion "_dbus_check_is_valid_bus_name (name)" failed in file dbus-bus.c line 1070. This is normally a bug in some application using the D-Bus library. received: * OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION STARTTLS] Courier-IMAP ready. Copyright 1998-2008 Double Precision, Inc. See COPYING for distribution information. sending : B00000 CAPABILITY received: * CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION STARTTLS received: B00000 OK CAPABILITY completed received: * OK server ready. Unauthorized Access Prohibited. sending : A00000 CAPABILITY sending : B00001 LOGIN xxx xxx received: B00001 OK connected to proxy server. sending : B00002 CAPABILITY received: * CAPABILITY IMAP4REV1 IDLE AUTH=PLAIN received: A00000 OK CAPABILITY completed received: * CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION received: B00002 OK CAPABILITY completed sending : A00001 LOGIN xxx xxx sending : B00003 NAMESPACE received: * OK server ready. Unauthorized Access Prohibited. sending : C00000 CAPABILITY received: * NAMESPACE (("INBOX." ".")) NIL (("#shared." ".")("shared." ".")) received: B00003 OK NAMESPACE completed. received: A00001 OK LOGIN completed sending : A00002 CAPABILITY received: * CAPABILITY IMAP4REV1 IDLE AUTH=DIGEST-MD5 AUTH=PLAIN AUTH=CRAM-MD5 received: C00000 OK CAPABILITY completed received: * CAPABILITY IMAP4REV1 IDLE AUTH=PLAIN received: A00002 OK CAPABILITY completed sending : A00003 LIST "" "" sending : C00001 LOGIN xxx xxx received: * LIST (\NoSelect) "/" "" received: A00003 OK LIST completed sending : A00004 LSUB "" "" received: A00004 NO LSUB failed: Invalid folder name sending : A00005 LOGOUT received: C00001 OK LOGIN completed sending : C00002 CAPABILITY received: * CAPABILITY IMAP4REV1 IDLE AUTH=DIGEST-MD5 AUTH=PLAIN AUTH=CRAM-MD5 received: C00002 OK CAPABILITY completed sending : C00003 LIST "" "" received: * BYE Oracle Beehive IMAP server terminating connection received: * LIST (\NoSelect) "/" "" received: C00003 OK LIST completed sending : C00004 LSUB "" "" received: C00004 NO LSUB failed: Invalid folder name sending : C00005 LOGOUT sending : B00004 LOGOUT
(In reply to comment #81) > Sorry to say that, but I tried modest with the fix in Marcins repository and > still get the same behaviour. Nothing changed for me. Sorry, but I did not had a time to check is this fix apply to 3.1 branch.
I tried some servers with same namespaces than yours and it works. Maybe Marcin's packages were not correctly generated or something. Can you provide a test account ?
@Sergio I have send you an email. (In reply to comment #83) > I tried some servers with same namespaces than yours and it works. Maybe > Marcin's packages were not correctly generated or something. > > Can you provide a test account ? >
Sorry I didn't remember that you were using Oracle Beehive. I have several test accounts and I can confirm that it's working fine with the current code. As I said the packages you used seem not to have the fixes. (In reply to comment #84) > @Sergio > > I have send you an email. > > (In reply to comment #83) > > I tried some servers with same namespaces than yours and it works. Maybe > > Marcin's packages were not correctly generated or something. > > > > Can you provide a test account ? > > >
With new Maemo 5 update 3.2 nothing has changed to me. Same problem as in comment #71 . Current product info Maemo 5 Version 3.2010.02-8 Quite disappointing ...
(In reply to comment #86) > With new Maemo 5 update 3.2 nothing has changed to me. Yes, the fix is not included in PR1.1.1, otherwise I would have reset the Target Milestone (and please don't call this "3.2", no idea who came up with it, but it's completely wrong)...
(In reply to comment #86) > With new Maemo 5 update 3.2 nothing has changed to me. Same problem as in > comment #71 . > > Current product info > Maemo 5 > Version 3.2010.02-8 > > Quite disappointing ... Ulle we fixed the issue upstream. We don't have control of what Nokia releases, and AFAIK this 02-8 release is just a very minor release before the PR1.2 one
Setting explicit PR1.2 milestone (so it's clearer in which public release the fix will be available to users). Sorry for the bugmail noise (you can filter on this message).
*** Bug 10147 has been marked as a duplicate of this bug. ***