[Dovecot] Maildir++ quota inconsistency
I've found what I think is an inconsistency in the Maildir quota implementation. According to the Maildir++ quota specification at:
http://www.inter7.com/courierimap/README.maildirquota.html
Maildir++ quota can be specified as maximum size, or maximum number of messages, or even both. The size specification is supposed to be in bytes. So I could use '10000000S' to set a quota of around 10MB.
Now, the Exim MTA has an independent Maildir++ quota implementation, and it follows the specification, so if I set the quota in Exim to 10000000, it will work perfectly with sqwebmail and courier-imap. However, it doesn't play well with Dovecot, because Dovecot chooses to interpret the quota as kilobytes, rather than bytes. An example:
If I set the quota to 10240 in Dovecot, it creates a maildirsize file with the value 10240000 in it. If I then set the quota to 10M in Exim, Exim calculates that as 10485760. It detects that the value in the maildirsize file is wrong, and recreates the file with a quota of 10485760 bytes.
Exim's behaviour is consistent with the courier family of packages, as well as the specification, so I'm venturing to say that Dovecot's implementation is slightly non-standard, and should be fixed so that the quota setting is interpreted as bytes, and not as kilobytes, to avoid a situation like the above.
-- Anand
On Thursday 31 August 2006 15:25, Anand Buddhdev took the opportunity to say:
I've found what I think is an inconsistency in the Maildir quota implementation. According to the Maildir++ quota specification at:
http://www.inter7.com/courierimap/README.maildirquota.html
Maildir++ quota can be specified as maximum size, or maximum number of messages, or even both. The size specification is supposed to be in bytes. So I could use '10000000S' to set a quota of around 10MB.
Now, the Exim MTA has an independent Maildir++ quota implementation, and it follows the specification, so if I set the quota in Exim to 10000000, it will work perfectly with sqwebmail and courier-imap. However, it doesn't play well with Dovecot, because Dovecot chooses to interpret the quota as kilobytes, rather than bytes. An example:
If I set the quota to 10240 in Dovecot, it creates a maildirsize file with the value 10240000 in it. If I then set the quota to 10M in Exim, Exim calculates that as 10485760. It detects that the value in the maildirsize file is wrong, and recreates the file with a quota of 10485760 bytes.
Exim's behaviour is consistent with the courier family of packages, as well as the specification, so I'm venturing to say that Dovecot's implementation is slightly non-standard, and should be fixed so that the quota setting is interpreted as bytes, and not as kilobytes, to avoid a situation like the above.
I'm not sure I understand you. Both Dovecot and Exim interpret the contents of maildirsize correctly, don't they? The problem seems to be that the quota set in Dovecot's configuration doesn't match the quota set in Exim's configuration. You can always get them to match up by setting the quota in bytes in Exim, but it would have to be a multiple of 1000 bytes (1 kB). So you want to be able to specify the quota in bytes in Dovecot as well, so that you can use any number, and, in particular, Exim's K and M shorthands (which, unfortunately, mean kibibytes and mebibytes, respectively) in its configuration file?
Aside from this, I wonder if Exim really should change the quota specified in a maildirsize file, and not just use it as the default value for a newly-created maildir. Isn't the maildirsize file the best central place to store per-user quotas?
-- Magnus Holmgren holmgren@lysator.liu.se (No Cc of list mail needed, thanks)
On Thursday 31 August 2006 17:00, Magnus Holmgren wrote:
Exim's behaviour is consistent with the courier family of packages, as well as the specification, so I'm venturing to say that Dovecot's implementation is slightly non-standard, and should be fixed so that the quota setting is interpreted as bytes, and not as kilobytes, to avoid a situation like the above.
I'm not sure I understand you. Both Dovecot and Exim interpret the contents of maildirsize correctly, don't they? The problem seems to
Yes, Exim and Dovecot both interpret the contents of maildirsize properly. It's how they create the file which is different.
be that the quota set in Dovecot's configuration doesn't match the quota set in Exim's configuration. You can always get them to match up by setting the quota in bytes in Exim, but it would have to be a multiple of 1000 bytes (1 kB). So you want to be able to specify the quota in bytes in Dovecot as well, so that you can use any number, and, in particular, Exim's K and M shorthands (which, unfortunately, mean kibibytes and mebibytes, respectively) in its configuration file?
Yes, well, Exim is highly configurable, so I can make it do anything with the quota figures. But the issue is this:
I have my user accounts in a mysql database. In the quota column, if I store the value '275', Dovecot interprets that as 275 kB, and if Dovecot was the first to create the maildirsize file, it will write '275000S' into the file. Exim on the other hand, will interpret that quota as 275 bytes. Of course, with Exim, I can work all kinds of magic, and append '000' to the value it gets back from the query. I could also just append a 'K' to the value Exim gets back from the query, but then Exim multiplies the value by 1024, and not 1000.
Aside from this, I wonder if Exim really should change the quota specified in a maildirsize file, and not just use it as the default value for a newly-created maildir. Isn't the maildirsize file the best central place to store per-user quotas?
Actually, I believe that Exim is doing the right thing. I quote the Maildir++ quota specification:
"The first line contains a copy of the quota definition as used by the system's mail server. Each application that uses the maildir must know what it's quota is. Instead of configuring each application with the quota logic, and making sure that every application's quota definition for the same maildir is exactly the same, the quota specification used by the system mail server is saved as the first line of the maildirsize file. All other application that enforce the maildir quota simply read the first line of maildirsize."
I interpret that to mean that the maildirsize file's contents should be dependent upon what the MTA dictates (in this case Exim). Courier MTA behaves similarly, overwriting the maildirsize file if its opinion of the quota is different from what's in the file. This is a good thing, because I can change a user's quota by modifying a value in the mysql database, for example. The next time Exim or Courier does a delivery, it will update the file with the new quota.
Anyway, like I said, Exim is so flexible, that it can do anything, and I can make it work with Dovecot's interpretation of quotas very easily. All I'm saying is that Dovecot's interpretation of the quota as kilobytes instead of bytes is not consistent with the specification or with 2 known implementations (Courier and Exim), and it might be a good idea to correct it now, before release 1.0 comes out. Who knows what kind of interoperability problems this might cause in the future, especially if more applications begin supporting Maildir++ quotas.
Timo, what's your opinion?
-- Anand
Anand Buddhdev wrote:
But the issue is this:
I have my user accounts in a mysql database. In the quota column, if I store the value '275', Dovecot interprets that as 275 kB, and if Dovecot was the first to create the maildirsize file, it will write '275000S' into the file. Exim on the other hand, will interpret that quota as 275 bytes. Of course, with Exim, I can work all kinds of magic, and append '000' to the value it gets back from the query.
This is nearly the problem which gave me a bloody nose trying to use dovecot lda for the first time a few days ago.
I have my setup in a postgres db and had quota up and running with maildrop or postfix + vda-patch without any problems before. Both of these possibilities are compatible to one another concerning the actual quota values and do it the same way using bytes as your Exim as I understand. So usage of courier/postfix+vda/Exim and for sure some others on the same set of quota data should be no problem at all. All interchangeable. No problems up till now.
Now I tried dovecot lda (using dirsize for starters, because mainly I used postfix+vda which doesn't need courier-style maildirsize-files) and suddenly my users had a quota of 50000 GB storage instead of 50 GB. Not really that funny.
Ok, no problem with postgres. So I set up a new view for dovecot with a suitable division to cut down the numbers for dovecot. Slightly ugly but does the trick.
But then it got really ugly. All accounts with unlimited quota were locked and all mail for them bounced. Surprisingly there is an even more malicious incompatibility to all other programs using quota: dovecot takes values of '0' for quota literally as zero. All the others take it for unlimited quota. Nice surprise. Most definitely not funny.
Sadly, I had to dump dovecot lda after this unpleasant experience till it behaves at least a little bit more like all the others.
Marcus
On Thu, 2006-08-31 at 21:57 +0200, Anand Buddhdev wrote:
Anyway, like I said, Exim is so flexible, that it can do anything, and I can make it work with Dovecot's interpretation of quotas very easily. All I'm saying is that Dovecot's interpretation of the quota as kilobytes instead of bytes is not consistent with the specification or with 2 known implementations (Courier and Exim), and it might be a good idea to correct it now, before release 1.0 comes out. Who knows what kind of interoperability problems this might cause in the future, especially if more applications begin supporting Maildir++ quotas.
Timo, what's your opinion?
I don't really see the problem. With Dovecot the quota format must be in such a special format ("maildir:storage=1024") that you can't use just one number field from SQL directly anyway.
And this is all internal Dovecot configuration and the same thing is done even if the quota backend isn't Maildir++, so Maildir++ spec is irrelevant here.
participants (4)
-
Anand Buddhdev
-
Magnus Holmgren
-
Marcus Jodorf
-
Timo Sirainen