When connecting to an IMAP server with an account that
already is connected Squirrelmail 1.4.2 logs in as
"readonly". There is no indication that this is
happening. The only way to tell is that a delete of a
message has no effect.
Squirrelmail 1.4.2
Php 4.3.4
OS FreeBSD 4.7
Logged In: YES
user_id=620333
Never heard of an IMAP server forcing a client into readonly
mode... Does it notify SM that it's in readonly mode? If
so, I'd be interested to see where in the RFCs it states
anything about a readonly mode.
As another note, SM connects, then disconnects after it has
done its work. So if you click on a folder, it opens the
folder, grabs the list, disconnects... Same with deleting a
message. If your IMAP server is not reporting that the mail
was not (or could not be) deleted, then there is little SM
can actually do about it, you have a miss-behaving IMAP
server. As another note, SM has been known to have the odd
cache issues when it comes to deleting mails. Check to see
if your IMAP server supports server side sorting, if it
does, enable it in the config.pl, and should see it go away
if that is the issue.
Logged In: YES
user_id=773624
Here are some more details. My primary email reader is
Mozilla 1.6 via IMAP. It is connected to my server and
working fine. If I use "pine" the
server while Mozilla is connected here is what I see from pine:
- opening "INBOX"
- Trying to get lock from process xxxx
- Folder is open by another process, access is readonly
- Folder "INBOX" opened with xxx messages READONLY
Would you like a pointer to the pine code?
Logged In: YES
user_id=620333
I think you might be confusing what pine is doing... Are you
accessing pine on the same server as the mail is stored on?
What IMAP server are you using? Are you SURE pine is using
IMAP, and not trying to access the files directly?
I've seen the messages you documented before, when I was
attempting to access the folder locally, while another
client had it open via IMAP... the IMAP server does a flock
on the file, and as such, pine cannot lock it for
updating... This does NOT mean your IMAP server supports a
READONLY mode.
As a note, you didn't document anything about your IMAP
setup, but from a guess that you're getting flock problems,
I'd guess uw-imap.
Logged In: YES
user_id=476981
SquirrelMail doesn't respect the info transmitted during a
select. That's the problem. At this moment there isn't a
quick fix. We will fix this in the future.
Logged In: YES
user_id=620333
I'm sceptical, but I'd like a test done... Login with your
normal IMAP application, then from another location (maybe
the webserver, or the imap server directly), login to IMAP
again, but use TELNET... To do that, do the following:
telnet serverip 143
A01 LOGIN "user" "pass"
A02 SELECT "INBOX"
[Report any messages you see after the A02 line]
A03 LOGOUT
I would be interested to see what happens.
Logged In: YES
user_id=773624
Here ya go:
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
* OK [CAPABILITY IMAP4REV1 X-NETSCAPE LOGIN-REFERRALS
STARTTLS AUTH=LOGIN] localhost [127.0.0.1] IMAP4rev1
2003.339 at Thu, 13 May 2004 19:12:23 +0000 (GMT)
A01 LOGIN "xxx" "xxx"
A01 OK [CAPABILITY IMAP4REV1 X-NETSCAPE IDLE NAMESPACE
MAILBOX-REFERRALS BINARY UNSELECT SCAN SORT
THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] User
xxx authenticated
A02 SELECT "INBOX"
* NO Trying to get mailbox lock from process 17101
* NO Mailbox is open by another process, access is readonly
* 413 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1050430353] UID validity status
* OK [UIDNEXT 2240] Predicted next UID
* FLAGS (Junk NonJunk $Forwarded $Label1 $Label2 $Label3
$Label4 $Label5 $MDNSent \Answered \Flagged \Deleted \Draft
\Seen)
* OK [PERMANENTFLAGS ()] Permanent flags
* OK [UNSEEN 43] first unseen message in /var/mail/xxx
A02 OK [READ-ONLY] SELECT completed
A03 LOGOUT
* BYE localhost IMAP4rev1 server terminating connection
A03 OK LOGOUT completed
Connection closed by foreign host.
Logged In: YES
user_id=476981
Yesterday I fixed SquirrelMail 1.5.1 CVS for this. You might
want to check that out.
Logged In: YES
user_id=285765
Marc, any chances that this is backported to 1.4.4 or is
that too difficult?
Logged In: YES
user_id=285765
I've looked at it and it's quite an invasive change to do to
1.4.x (because the neccessary infrastructure is missing).
It's fixed in 1.5.0. I propose to leave it as wontfix for
current stable. That means I'll close this bug unless
someone objects.
Logged In: YES
user_id=285765
No objections, closed.