Thanks for the suggestions. I'm still having trouble - more info follows. I hate to say this, because I know what it means: It all worked OK before... but before what? I changed to https, I probably upgraded SM, I probably updated EIMS. I don't know exactly when the issue started happening, and I can't easily roll things back to see what broke. Anyway, here's more. Paul Lesniewski wrote: >> Users are having trouble reading messages when the sender has requested a >> read receipt. The javascript alert from SM asking whether to send a >> receipt now keeps coming up (after a delay of a second or so) when the >> user clicks "OK". The receipts are being delivered. but SM never moves on >> to display the message. > > Perhaps your IMAP server does not support this. You can tell by > enabling the "info" plugin, then going to Options==>IMAP Server > information and clicking submit (only the SELECT command should be > checked). The result will need a "PERMANENTFLAGS" line with > "$MDNSent" in it. You can also test this by logging in by hand to > your IMAP server by telnetting to it and issuing these commands: > The response to the test (sent from Options > IMAP Server) included these lines: * FLAGS (\Deleted \Seen \Recent \Answered \Flagged \Draft $MDNSent) * OK [PERMANENTFLAGS (\Deleted \Seen \Answered \Flagged \Draft $MDNSent)] OK > If you need to disable this feature, turn off $default_use_mdn in the > configuration file or use conf.pl ==> 4. General Options ==> 8. Allow > use of receipts Certainly an option but not ideal - read receipts are mostly an annoyance (we have a few folks who insist on using them all the time) but sometimes it's important to know when one was requested and have the opportunity to acknowledge it. > >> When the user finally clicks "Cancel," the email message they were trying >> to read is usually not displayed correctly: the page is completely empty >> below the (default) grey bar containing the "Message List" "Delete" etc. >> links. On rare occasions the message is displayed OK, but I haven't been >> able to discern a pattern. What does SM do if I click "Cancel" (don't send a receipt) the first time the alert pops up? Does it try to reset the message flag, or does it do that only if I click "OK"? >> I don't think we had this problem until we started using https:, but I >> don't know why that would cause it. > > It shouldn't, but if you can test that, I can look at what you find. This morning I tested using standard http: and still had the same problem. Would it be helpful if I created a test mailbox, sent a message with a receipt request to it, and took a packet dump of the traffic between the SM and IMAP servers while trying to read the message? I don't know the IMAP protocol so I'm not sure I'd know what to look for. Many thanks, Jim ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ----- squirrelmail-users mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-users@xxxxxxxxxxxxxxxxxxxxx List archives: http://news.gmane.org/gmane.mail.squirrelmail.user List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
