Re: Converting unixhierarchysep from "." to "/": experiences?
Jason Fesler said: >> in a mailbox name. If a server decided to use 'a' as the separator >> character, then the same would apply. FWIW, you can tell Cyrus to use >> '/' as the separator by enabling the unixhierarchysep option in >> imapd.conf. > > Has anyone reported any client issues by changing this setting? > SquirrelMail I can fudge the configs on easily; pine users, I know I can't > change (and I know their configs are typically hard set). What about the > various GUIs? Anyone have experience with converting from "." to "/"? > Make sure you also adapt the special folders to INBOX/Sent, INBOX/Trash, INBOX/Drafts. conf.pl is the tool to use. Marc Groot Koerkamp.
Re: Could not complete request over quota errors
Rob Siemborski said: > On Thu, 31 Jul 2003, Marc Groot Koerkamp wrote: > >> What happens when I create a sub of inbox. What quota does apply to that >> sub or does the sub has no quota? >> >> according the rfc: >>Each mailbox has zero or more implementation-defined named "quota >>roots". Each quota root has zero or more resource limits. All >>mailboxes that share the same named quota root share the resource >>limits of the quota root. >> >> that make me think that INBOX and INBOX.Trash share the same named quota >> and therefor raising the quota on inbox.Trash doesn't help. (I could be >> wrong, I never used quotas) > > No, some implementations might inheret, others might override (that is, a > new quota root would override all previous roots). Cyrus does the later. > Ok thnx for the clarification. I'll start experimenting with it. >> But to come back to the QUOTA idea. It's probably not a good idea. Much >> better would be to write an RFC for IMAP MOVE. But that's discussed >> before >> if I'm correct. > > IMAP MOVE is very difficult in IMAP for a variety of reasons. One is > transactionality, One is preservation of UIDs (which is important if you > want to undo a move). > > Here's a previous thread: > > http://www.washington.edu/imap/listarch/current/msg00629.html > OK, I forget the move idea. So we are back to where we started. The client should notify the user that it needs to empty Trash first or offer permanent delete by setting the flag and expunge the individual message by using it's uid (in case of UIDPLUS) Regards, Marc Groot Koerkamp.
Re: Could not complete request over quota errors
Andrew Morgan said: > > > On Wed, 30 Jul 2003, Marc Groot Koerkamp wrote: > >> Andre Nicholson said: >> > I run into this problem **all of the time** with my users. What's >> > happening, if you use >> > a Trash folder, is that the message is first /copied/ to the Trash >> folder >> > and then if >> > successful the original message is deleted. Why isn't it just moved?? >> Is >> > it SquirrelMail >> > or Cyrus that's the cause? >> >> It's IMAP. RFC 3501 does not support the move command so we have to copy >> the message. Of course we could fake it by doing client side move which >> means buffer the message in mem or temporarely write it do file, delete, >> expunge, and append the message in our buffer to the Trash folder but >> that sounds not save to me. >> >> Cyrus supports the quota extension so maybe we can in the future check >> quota before we move messages to trash and do some proper error handling >> but don't excpect it on short notice. In the future SM 2 version we also >> have ALERT information and probably we should display it to the user >> because the ALERT message regarding QUOTA will be present when 90 % of >> the >> quota is exceeded (if I'm correct). >> >> Ideal situation would be that the QUOTA extension is rewritten in order >> to >> set individual QUOTA on children mailboxes of QUOTAROOT so you can set >> the >> INBOX.Trash QUOTA to unlimited and still have QUOTA enabled on INBOX and >> the other children mailboxes. But that's not part of RFC 2087. Maybe a >> nice job for cyrus to come with a new RFC for this :) > > So why not just set a really large quota on the Trash folder? You could > do something like: > > setquota user.testuser STORAGE 102400 > setquota user.testuser.Trash STORAGE 1024000 > > That would give the user a 100MB quota for normal mail and a 1GB quota for > their Trash folder. > > Or am I missing something? :) > > Andy > What happens when I create a sub of inbox. What quota does apply to that sub or does the sub has no quota? according the rfc: Each mailbox has zero or more implementation-defined named "quota roots". Each quota root has zero or more resource limits. All mailboxes that share the same named quota root share the resource limits of the quota root. that make me think that INBOX and INBOX.Trash share the same named quota and therefor raising the quota on inbox.Trash doesn't help. (I could be wrong, I never used quotas) But to come back to the QUOTA idea. It's probably not a good idea. Much better would be to write an RFC for IMAP MOVE. But that's discussed before if I'm correct. Marc.
Re: Could not complete request over quota errors
Andre Nicholson said: > I run into this problem **all of the time** with my users. What's > happening, if you use > a Trash folder, is that the message is first /copied/ to the Trash folder > and then if > successful the original message is deleted. Why isn't it just moved?? Is > it SquirrelMail > or Cyrus that's the cause? It's IMAP. RFC 3501 does not support the move command so we have to copy the message. Of course we could fake it by doing client side move which means buffer the message in mem or temporarely write it do file, delete, expunge, and append the message in our buffer to the Trash folder but that sounds not save to me. Cyrus supports the quota extension so maybe we can in the future check quota before we move messages to trash and do some proper error handling but don't excpect it on short notice. In the future SM 2 version we also have ALERT information and probably we should display it to the user because the ALERT message regarding QUOTA will be present when 90 % of the quota is exceeded (if I'm correct). Ideal situation would be that the QUOTA extension is rewritten in order to set individual QUOTA on children mailboxes of QUOTAROOT so you can set the INBOX.Trash QUOTA to unlimited and still have QUOTA enabled on INBOX and the other children mailboxes. But that's not part of RFC 2087. Maybe a nice job for cyrus to come with a new RFC for this :) Regards, Marc Groot Koerkamp. > > Having SM, or any other client for that matter, not use Trash folder isn't > a prime > solution as nearly every user that's used e-mail is used to the concept of > "delete moves > messages to Trash folder, it's emptied every night automatically but if I > made a mistake > I can get my message back before then." > > I once saw a patch for SM that would fix this, but it's for a very older > version and I > haven't tried it: > http://sourceforge.net/tracker/?group_id=311&atid=300311&func=detail&aid=646386 > > What I've wanted to do is to remove quotas on just the Trash folder, but I > haven't been > able to figure it out -- it's emptied automatically anyway on my setup. > > Andre > >> On Wed, 30 Jul 2003, joe ritter wrote: >> >>> Could not complete request. >>> Reason Given: Over quota >>> >>> This is an odd catch 22 situation. I wanted to see if >>> anybody had experienced this before and what they >>> were able to do to fix this. >> >> You need to not use a trash mailbox, which doesn't work terribly well >> with >> quotas in the basic implementation that doesn't account for them. >> Really, if clients insist on using Trash mailboxes, the UI should ask >> "should I just delete the message" if there isn't enough space like the >> Windows Recycle Bin does. >> >> Squirrelmail, though, has an option to just not use trash mailboxes. >> >> -Rob >> >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 >> Research Systems Programmer * /usr/contributed Gatekeeper >> >> >> > >
Re: Fatal error: word too long
Erik Steffl said: >I got the following error: > > Jul 17 08:51:48 jojda cyrus/imapd[7560]: open: user erik opened In.~ SPAM > ~ > Jul 17 08:51:50 jojda cyrus/imapd[7878]: Fatal error: word too long > Jul 17 08:51:50 jojda cyrus/master[301]: process 7878 exited, status 75 > Jul 17 08:53:43 jojda cyrus/master[7908]: about to exec > /usr/lib/cyrus/bin/imapd > Jul 17 08:53:43 jojda cyrus/imaps[7908]: executed > Jul 17 08:53:43 jojda cyrus/imapd[7908]: accepted connection > >any ideas about what does it mean? > Yes, it happens when you send a query that's to long. I.e. a very large msgs_id string in combination with FETCH or STORE. The imap-client you are using should split up those imap-queries and use smaller message sets. Marc Groot Koerkamp. >I also got some other errors, not sure if they are related (Could not > shut down filedescriptor 0: Bad file descriptor) but from MUA (Mozilla) > it all looks ok - mail is being delivered (not sure if every single > email is delivered), marked seen etc. > >TIA > > erik > >
Re: INBOX has \NoSelect flag
Ken Murchison said: > > > Marc Groot Koerkamp wrote: > >> Hello, >> >> There is something I do not understand about cyrus (2.1.14). >> >> When you_unsubscribe_to the inbox the LIST response contains the INBOX >> with the \NoSelect flag. > > What is the exact LIST command that is being sent? > A001 LIST "" "INBOX" Marc. > >> That's the response one of our SquirrelMail developers got. >> >> IMHO that's not right and a bug. With Cyrus 2.1.11 it doesn't happen. >> >> Can somebody confirm it's a cyrus bug? >> >> Regards, >> >> Marc Groot Koerkamp. >> >> PS: could it be that messages containing.unsubscribe. are filtered out? >> This is the 5th time I try to send this message and the previous ones >> never reached the list. >> >> >> >> >> >> > > -- > Kenneth Murchison Oceana Matrix Ltd. > Software Engineer 21 Princeton Place > 716-662-8973 x26 Orchard Park, NY 14127 > --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp > >
INBOX has \NoSelect flag
Hello, There is something I do not understand about cyrus (2.1.14). When you_unsubscribe_to the inbox the LIST response contains the INBOX with the \NoSelect flag. That's the response one of our SquirrelMail developers got. IMHO that's not right and a bug. With Cyrus 2.1.11 it doesn't happen. Can somebody confirm it's a cyrus bug? Regards, Marc Groot Koerkamp. PS: could it be that messages containing.unsubscribe. are filtered out? This is the 5th time I try to send this message and the previous ones never reached the list.
Re: SSL wrapped sieve support (ala "imaps") for timsieved [LONG]
Scott Russell zei: > On Wed, Jun 18, 2003 at 02:08:09PM +0200, Sebastian Hagedorn wrote: >> Thanks a lot! I forwarded them to the maintainer of Smartsieve. He thinks >> that they should work with Smartsieve as well ... > > Cool. It would be better if someone would handle rewriting the mhash functions needed in pure PHP to eliminate the need of building mhash into php. Last I checked mhash didn't come standard with the distros PHP releases. > The avelsieve plugin (version 9.2) for SquirrelMail does support CRAM-MD5 and DIGEST-MD5 support and doesn't need the mhash module from php. (probably calls hmac_md5 function from functions/auth.php inside SquirrelMail source) It makes use of the same methods we use in SquirrelMail to support CRAM-MD5 Authentication and DIGEST-MD5 authentication against imap-servers without mhash support :). So it is possible to calculate your own hmac_digest with php. Regards, Marc Groot Koerkamp.
Notify to perlscript
Hello, With cyrus 2.0.16 I adapted the suplied perlscript for notification with samba messages to clients (smbclient -M ...). Somehow I cannot get this configuration working again with Cyrus 2.1.11. The log is complaining about the wrong protocol (probably something todo with 'udp') and the available mechanism are not sufficient for what I want. Can somebody confirm that it's not possible and if not, are there plans for adding more notification mechanism? Regards, Marc Groot Koerkamp.
