Re: [Dovecot] Patch Adding BASE64-PLAIN Password Scheme
On Sat, 12 May 2007 21:58:30 +0300
Timo Sirainen <[EMAIL PROTECTED]> wrote:
> On Sun, 2007-05-13 at 00:34 +0800, imacat wrote:
> > 1. I do not know if adding base64_decode() in
> > passwd_file_save_results() in src/auth/passdb-passwd-file.c is
> > appropriate.
> This isn't needed. The generic scheme handling code should have made it
> work everywhere.
In fact, no. (At least as far as I can tell.) The plain text
passwords are used in many places later on, including generating other
password formats directly. In some places it is saved into cache, and
in some places it is restored from cache. I do not know if it shall be
decoded before generating other MD5 password hashes, before generating
APOP hash, before plain text comparison, or any other places. But
"scheme" is not available in some of these places that I have no clue to
decode it.
> > +static bool base64_plain_verify(const char *plaintext, const char
> > *password,
> > +const char *user __attr_unused__)
> > + base64_encode(password, strlen(password), str);
> This is a bit wrong. plaintext is in the user-given password in
> plaintext, and password is the base64 encoded password. Here you're
> base64ing a password that's already base64d. That's probably why you
> added the code to passdb-passwd-file.c, the code in there is working
> right.
Oh. Thank you. This is where I need comments.
But, no. Base on the result of code trace, base64_plain_verify()
was never called with APOP. This makes sense that, APOP does not
compare user-supplied cresidential information with the saved
cresidential information directly with strcmp().
The same goes that, when verifying plain text passwords with
PLAIN.B64 password scheme, it may fail since the password is already
decoded in passwd_file_save_results().
> > + { "BASE64-PLAIN", base64_plain_verify, base64_plain_generate },
> I'm going to use PLAIN.B64 and PLAIN.BASE64 in Dovecot v1.1, so if you
> might want to use that name already for your passwords so one day you
> don't have to patch Dovecot anymore. :)
I shall follow it. Thank you for clarifying this.
The revised patch is below, with fixes to src/auth/passdb-sql.c
added, in the hope that it helps. (I found that only passwd-file and
SQL password databases need this.) Please tell me if you need any
information, or if I can be of any help.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
diff -u -r dovecot-1.0.0.orig/src/auth/passdb.c dovecot-1.0.0/src/auth/passdb.c
- --- dovecot-1.0.0.orig/src/auth/passdb.c 2007-02-15 19:48:37.0
+0800
+++ dovecot-1.0.0/src/auth/passdb.c 2007-05-13 11:19:46.0 +0800
@@ -63,6 +63,8 @@
case PASSDB_CREDENTIALS_PLAINTEXT:
if (strcasecmp(wanted_scheme, "CLEARTEXT") == 0)
return wanted_scheme;
+ if (strcasecmp(wanted_scheme, "PLAIN.B64") == 0)
+ return wanted_scheme;
return "PLAIN";
case PASSDB_CREDENTIALS_CRYPT:
return "CRYPT";
@@ -98,7 +100,8 @@
scheme);
if (strcasecmp(scheme, wanted_scheme) != 0) {
if (strcasecmp(scheme, "PLAIN") != 0 &&
- - strcasecmp(scheme, "CLEARTEXT") != 0) {
+ strcasecmp(scheme, "CLEARTEXT") != 0 &&
+ strcasecmp(scheme, "PLAIN.B64") != 0) {
auth_request_log_info(auth_request, "password",
"Requested %s scheme, but we have only %s",
wanted_scheme, scheme);
diff -u -r dovecot-1.0.0.orig/src/auth/passdb-passwd-file.c
dovecot-1.0.0/src/auth/passdb-passwd-file.c
- --- dovecot-1.0.0.orig/src/auth/passdb-passwd-file.c 2007-03-25
01:10:24.0 +0800
+++ dovecot-1.0.0/src/auth/passdb-passwd-file.c 2007-05-13 11:22:13.0
+0800
@@ -10,6 +10,8 @@
#include "passdb.h"
#include "password-scheme.h"
#include "db-passwd-file.h"
+#include "base64.h"
+#include "buffer.h"
#define PASSWD_FILE_CACHE_KEY "%u"
#define PASSWD_FILE_DEFAULT_SCHEME "CRYPT"
@@ -30,9 +32,19 @@
const char *key, *value;
string_t *str;
char **p;
+ buffer_t *buf;
+ size_t size, password_len;
*crypted_pass_r = pu->password;
*scheme_r = password_get_scheme(crypted_pass_r);
+ /* decode the Base64-encoded plain passwords. */
+ if (*scheme_r != NULL && *crypted_pass_r != NULL &&
strcasecmp(*scheme_r, "PLAIN.B64") == 0) {
+ password_len = strlen(*crypted_pass_r);
+ buf = buffer_create_static_hard(pool_datastack_create(),
+
MAX_BASE64_DECODED_SIZE(password_len));
+ base64_decode(*crypted_pass_r, password_len, NULL, buf);
+ *crypted_pass_r = buffer_get_data(buf, &size);
+ }
if (*scheme_r == NULL)
*scheme_r = request->passdb->passd
Re: [Dovecot] Conflict -> Dovecot + Maildrop (maildirsize)
Timo Sirainen wrote:
On Wed, 2007-05-09 at 10:23 -0300, Roberto Gonzalez Azevedo wrote:
'maildirsize' with dovecot:
"
1099511627776S
585847701 102542
5504023 959
"
In both examples the quota is 1GB (1073741824S).
And now ? Does anybody known how to fix that ?
Looks like you're trying to tell the quota in bytes to Dovecot. Dovecot
wants it to be in kilobytes in its configuration file / userdb (it still
writes it in bytes to maildirsize, as you can see above it writes 1GB *
1024 value in there).
Ok, but it ('Looks like you're trying to tell the quota in bytes to
Dovecot')
isn't the problem, yet ;). I'll try to figure out the problem.
Example:
Some user has 1GB quota, and has 512MB used. When an e-mails arrives
maildrop recalculates the quota (513MB). Then, using dovecot, the user
deletes some e-mails and, now, 'maildirsize' is overwritten, but in a
different
pattern, so there's an inconsistency with the new 'maildirsize'. It
isn't 511MB
or less, it starts from beginning (1MB). A 'new' 'maildirsize' file.
That's the problem. Does somebody known how to fix it ?
Thanks.
--
Roberto Gonzalez Azevedo
Rio de Janeiro, Brazil
Re: [Dovecot] SASL using different auth database?
On May 11, 2007, at 11:50 AM, Timo Sirainen wrote: If you can assign two IPs to the server, one for SMTP, and one for POP/IMAP, and you can use a SQL backend, you could craft your db schema and queries to pull the appropriate password based on the local IP of the connection. I know this isn't exactly what you were looking for, but I figured I would throw it out there anyway. Probably an easier way to do that is to use %s which expands to smtp, imap or pop3. That sounds like what I'd want to do. I will hit the documentation for the specifics. Thanks to all who replied! -Dave -- Dave McGuire Port Charlotte, FL
[Dovecot] Mailbox creation with Spam
Hi all, I got dovecot working, but I would like to know when and what creates the mailbox (cur, new, trash, etc ). I noticed that when a client connects for the first time that mailbox is created or when a mail arrives for the first time (i think). I would like to give each mailbox a Spam folder, and possibly doing this automatically. Is this possible with some dovecot setting and not via scripting. Thanks master
Re: [Dovecot] Patch Adding BASE64-PLAIN Password Scheme (was: APOP Clear Text)
On Sun, 2007-05-13 at 00:34 +0800, imacat wrote:
> Hi. Here is a simple patch that adds the BASE64-PLAIN password
> scheme. It may not be very clean.
>
> 1. I do not know if adding base64_decode() in
> passwd_file_save_results() in src/auth/passdb-passwd-file.c is
> appropriate.
This isn't needed. The generic scheme handling code should have made it
work everywhere.
> @@ -98,7 +100,8 @@
> scheme);
> if (strcasecmp(scheme, wanted_scheme) != 0) {
> if (strcasecmp(scheme, "PLAIN") != 0 &&
> - - strcasecmp(scheme, "CLEARTEXT") != 0) {
> + strcasecmp(scheme, "CLEARTEXT") != 0 &&
> + strcasecmp(scheme, "BASE64-PLAIN") != 0) {
This is ok, although it makes me think if there should be some kind of a
password_scheme_is_plaintext() function.
> +static bool base64_plain_verify(const char *plaintext, const char *password,
> + const char *user __attr_unused__)
> +{
> + string_t *str;
> +
> + str = t_str_new(MAX_BASE64_ENCODED_SIZE(strlen(password)+1));
> + base64_encode(password, strlen(password), str);
> + return strcmp(plaintext, str_c(str)) == 0;
> +}
This is a bit wrong. plaintext is in the user-given password in
plaintext, and password is the base64 encoded password. Here you're
base64ing a password that's already base64d. That's probably why you
added the code to passdb-passwd-file.c, the code in there is working
right.
> + { "BASE64-PLAIN", base64_plain_verify, base64_plain_generate },
I'm going to use PLAIN.B64 and PLAIN.BASE64 in Dovecot v1.1, so if you
might want to use that name already for your passwords so one day you
don't have to patch Dovecot anymore. :)
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] v1.1 plans
Could the below be added to the list, too, if time allows? * Add more comments in the source files. Add comments before each subroutine illustrating: 1. the purpose of the subroutine, 2. the arguments of the subroutine, and 3. the return value of the subroutine. Add some comments before if-else conditional statements about what and why. So that people can read, hack and help on the source more easily. It really kills me to find out where to work to add the BASE64-PLAIN password scheme, although the result is actually not very difficult. There is just too little illustration in the source. I understand that given the current large amount of the source, this may not be easy to accomplish. But it would be better if this can be gradually done. Tue, 17 Apr 2007 21:46:33 +0300 Timo Sirainen <[EMAIL PROTECTED]> wrote: -- Best regards, imacat ^_*' <[EMAIL PROTECTED]> PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt <> News: http://www.wov.idv.tw/ Tavern IMACAT's: http://www.imacat.idv.tw/ TLUG List Manager: http://lists.linux.org.tw/cgi-bin/mailman/listinfo/tlug pgps9qXz8Kff7.pgp Description: PGP signature
[Dovecot] Patch Adding BASE64-PLAIN Password Scheme (was: APOP Clear Text)
On Sat, 12 May 2007 01:25:45 +0800
imacat <[EMAIL PROTECTED]> wrote:
> > > 2. I would like to use APOP in addition to SSL/TLS. Currently
> > > Dovecot saves APOP passwords as clear text. I understand this. But is
> > > it possible to have some sort of encoding, for example, Base64? Just to
> > If you really need this now you could also modify the sources yourself.
> > It should be pretty easy to add a new plain.b64 scheme to
> > src/auth/password-scheme.c (could also be implemented as a plugin)
Hi. Here is a simple patch that adds the BASE64-PLAIN password
scheme. It may not be very clean.
1. I do not know if adding base64_decode() in
passwd_file_save_results() in src/auth/passdb-passwd-file.c is
appropriate.
2. It only work with the Passwd-file password database. Other
password databases (like SQL) is not tested.
However, it works fine. Hope that it helps. Please tell me if you
need any more information. Thank you.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
diff -u -r dovecot-1.0.0.orig/src/auth/passdb.c dovecot-1.0.0/src/auth/passdb.c
- --- dovecot-1.0.0.orig/src/auth/passdb.c 2007-02-15 19:48:37.0
+0800
+++ dovecot-1.0.0/src/auth/passdb.c 2007-05-13 00:04:15.0 +0800
@@ -63,6 +63,8 @@
case PASSDB_CREDENTIALS_PLAINTEXT:
if (strcasecmp(wanted_scheme, "CLEARTEXT") == 0)
return wanted_scheme;
+ if (strcasecmp(wanted_scheme, "BASE64-PLAIN") == 0)
+ return wanted_scheme;
return "PLAIN";
case PASSDB_CREDENTIALS_CRYPT:
return "CRYPT";
@@ -98,7 +100,8 @@
scheme);
if (strcasecmp(scheme, wanted_scheme) != 0) {
if (strcasecmp(scheme, "PLAIN") != 0 &&
- - strcasecmp(scheme, "CLEARTEXT") != 0) {
+ strcasecmp(scheme, "CLEARTEXT") != 0 &&
+ strcasecmp(scheme, "BASE64-PLAIN") != 0) {
auth_request_log_info(auth_request, "password",
"Requested %s scheme, but we have only %s",
wanted_scheme, scheme);
diff -u -r dovecot-1.0.0.orig/src/auth/passdb-passwd-file.c
dovecot-1.0.0/src/auth/passdb-passwd-file.c
- --- dovecot-1.0.0.orig/src/auth/passdb-passwd-file.c 2007-03-25
01:10:24.0 +0800
+++ dovecot-1.0.0/src/auth/passdb-passwd-file.c 2007-05-13 00:04:41.0
+0800
@@ -10,6 +10,8 @@
#include "passdb.h"
#include "password-scheme.h"
#include "db-passwd-file.h"
+#include "base64.h"
+#include "buffer.h"
#define PASSWD_FILE_CACHE_KEY "%u"
#define PASSWD_FILE_DEFAULT_SCHEME "CRYPT"
@@ -30,9 +32,18 @@
const char *key, *value;
string_t *str;
char **p;
+ buffer_t *buf;
+ size_t size, password_len;
*crypted_pass_r = pu->password;
*scheme_r = password_get_scheme(crypted_pass_r);
+ if (*scheme_r != NULL && *crypted_pass_r != NULL &&
strcasecmp(*scheme_r, "BASE64-PLAIN") == 0) {
+ password_len = strlen(*crypted_pass_r);
+ buf = buffer_create_static_hard(pool_datastack_create(),
+
MAX_BASE64_DECODED_SIZE(password_len));
+ base64_decode(*crypted_pass_r, password_len, NULL, buf);
+ *crypted_pass_r = buffer_get_data(buf, &size);
+ }
if (*scheme_r == NULL)
*scheme_r = request->passdb->passdb->default_pass_scheme;
diff -u -r dovecot-1.0.0.orig/src/auth/password-scheme.c
dovecot-1.0.0/src/auth/password-scheme.c
- --- dovecot-1.0.0.orig/src/auth/password-scheme.c 2007-02-22
22:32:11.0 +0800
+++ dovecot-1.0.0/src/auth/password-scheme.c2007-05-13 00:04:15.0
+0800
@@ -312,6 +312,26 @@
return plaintext;
}
+static bool base64_plain_verify(const char *plaintext, const char *password,
+const char *user __attr_unused__)
+{
+ string_t *str;
+
+ str = t_str_new(MAX_BASE64_ENCODED_SIZE(strlen(password)+1));
+ base64_encode(password, strlen(password), str);
+ return strcmp(plaintext, str_c(str)) == 0;
+}
+
+static const char *base64_plain_generate(const char *plaintext,
+ const char *user __attr_unused__)
+{
+ string_t *str;
+
+ str = t_str_new(MAX_BASE64_ENCODED_SIZE(strlen(plaintext)+1));
+ base64_encode(plaintext, strlen(plaintext), str);
+ return str_c(str);
+}
+
static bool cram_md5_verify(const char *plaintext, const char *password,
const char *user __attr_unused__)
{
@@ -469,6 +489,7 @@
{ "SMD5", smd5_verify, smd5_generate },
{ "SSHA", ssha_verify, ssha_generate },
{ "PLAIN", plain_verify, plain_generate },
+ { "BASE64-PLAIN", base64_plain_verify, base64_plain_generate },
{ "CLEARTEXT", plain_verify, plain_generate },
{ "CRAM
Re: [Dovecot] logging IMAP size?
On Saturday, May 12 at 03:28 AM, quoth Armijn Hemel: I work for a small hosting company. We host websites and people's mail on a shared hosting server. Mail is accessed through POP3 or IMAP. I need to be able to measure the IMAP size for accounting, since people pay for the bandwidth and I need to be able to justify it in my reports :-) It can already be done with POP3, where there is a "size" value: dovecot: May 07 09:11:54 Info: POP3([EMAIL PROTECTED]): Disconnected: Logged out top=0/0, retr=2/29469, del=2/2, size=29433 I think you're looking for this: http://www.dovecot.org/list/dovecot/2007-March/020478.html ~Kyle -- Testing can show the presence of errors, but not their absence. -- E. W. Dijkstra pgp6y6g113W73.pgp Description: PGP signature
[Dovecot] dbox redesign
I don't think anyone uses dbox currently, so the whole format could still be redesigned. So I was thinking about doing two major changes: 1. Rely on index files a lot more. The flags are already stored in index files, so there's no need to waste I/O updating them to dbox files all the time. They could still be updated (if indexes get deleted, the flags aren't all gone), but less often. 2. Require fcntl() locking. Currently dbox uses dotlocks which is slow. Cydir could be a good alternative also once index file code is made a bit more robust. Perhaps I could implement single instance attachments for cydir too.. Locking === The current dbox "index" file would be gone. It's pretty useless. Replace it with a whole new index file. Or perhaps it should be called "locks" file or something. The locks file would contain records: . So something like: 1 4645a60f 0 2 N 3 D That would mean that the first file is locked by some process, either for appending or expunging. The 2nd and 3rd files aren't locked. New messages can't be appended to 2nd file anymore. 3rd file is already deleted and this record needs to be removed when rewriting the file. Locking a dbox file for either appends or expunges is done like: 1. See if timestamp is zero - If not, see if it's older than .. let's say a day or so .. a) Yes: Continue to 2. b) No: Assume the file is locked 2. Do fcntl() byte range lock over the record line in the locks file. - If it failed, the record is locked 3. Write the timestamp. 4. Compare stat() and fstat() inodes to see if the file was rebuilt - If yes, reopen the file and goto 1 5. File is now locked. Do the append/expunge. 6. Write timestamp to zero. 7. Unlock the byte range. If a file is locked, append will try another file and expunge will mark the message as expunged instead of actually expunging it yet. Note that the locks file is read without locking. This is safe because data is never moved within the file, and it doesn't matter if the timestamp isn't read correctly always. The timestamp check is only an optimization. Actually I'm not sure if it would be better not to have the timestamp at all. Deleted records will stay in the file until the file is rebuilt. If a deleted record is noticed in the file, the process tries to lock the whole locks file. If it succeeds, it proceeds with writing the non-deleted records to a temporary file and rename()ing it over the locks file. Appending = 1. Find the first file in the locks file that has appendable=0 - If no such file was found, go to "create a new file" logic as described below 2. Lock the file record 3. Verify from the file's headers that this file can actually be appended to - If messages have been expunged from a dbox file, it can't be safely appended to anymore. - Other reasons include eg. configurable max. file size and daily rotations 4. Write the mail 5. Lock locks file's header 6. Get the UID from "next uid" field and update it 7. Unlock the header 8. Unlock the file record 9. Update index file Create a new file logic: 1. Create a temporary file 2. Write the messages there 3. Lock locks file's header (including fstat() / stat() rebuild check) 4. See what the latest file ID is in the file 5. rename() temp fail to msg. 6. Lock locks file for the range of the to-be-written record below 7. Write the new record to locks file 8. Go to step 6 in the original append logic Syncing / expunging === If locks file's header's "next uid" doesn't match the one currently in index file, the appending crashed between steps 6 and 9. Find the new message(s) and append them to index file. If the locks file is completely gone , rebuild it by going through all the msg.* files in the directory. If "expunge counter" (see below) doesn't match in locks file's header vs. index file header, go through all the msg.* files to see if a message exists in multiple files. If found, remove the duplicates. Typically neither of the above happens, so the only thing to do here is to write changes from index file to dbox files. This may mean flag changes once in a while, but most importantly expunges will always be synced. Initially figure out what files require expunging. Try to create a single lock range that includes all of them. If there are non-zero lock timestamps in that range, create multiple ranges. If a file couldn't be locked, the expunge is done by updating expunge-flag in the file. This can be done without locking (see below for flag updates). If a file was successfully locked, the expunging is done by: 1. Update "expunge offset" in file header to the offset of the first expunged message. If expunge offset is non-zero, the file is treated as non-appendable. Also when rebuilding and finding the same message from multiple files, this field is used to figure out which file should be truncated. 2. Copy the rest of the non-expunged messages to a new temporary file and add the file to locks file using
Re: [Dovecot] Problems with BEFORE searches.
On Fri, 2007-05-11 at 16:16 -0600, Trever L. Adams wrote: > I suggest you add it before you close the connection. I've changed my script to take options: [EMAIL PROTECTED]:~$ cleanspam Usage: cleanspam [--expunge] days --expunge: expunge mail after marking older ones deleted --seen: delete only mail marked as seen (read) days: mark mails older than deleted (can be fractional) The old URL is still valid, maybe I'll link it from my projects page too. johannes signature.asc Description: This is a digitally signed message part
Re: [Dovecot] logging IMAP size?
Hi Timo, > > is there a way to somehow log the size of an IMAP session with Dovecot? > > With POP3 there is this pop3 format string I can set in dovecot.conf, > > but I don't see an equivalent for IMAP. > > > > If so, are there any plans to add this functionality? > > IMAP has multiple mailboxes, so I don't see how this could work in any > useful way. It could of course log just INBOX's size, but since the > client wouldn't necessarily even open the INBOX that would be just extra > work for nothing but a log line. > > What do you need it for anyway? I work for a small hosting company. We host websites and people's mail on a shared hosting server. Mail is accessed through POP3 or IMAP. I need to be able to measure the IMAP size for accounting, since people pay for the bandwidth and I need to be able to justify it in my reports :-) It can already be done with POP3, where there is a "size" value: dovecot: May 07 09:11:54 Info: POP3([EMAIL PROTECTED]): Disconnected: Logged out top=0/0, retr=2/29469, del=2/2, size=29433 armijn -- - [EMAIL PROTECTED] | http://www.uulug.nl/ | UULug: Utrecht Linux Users Group -
