[Dovecot] Processing sent items
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 How does dovecot handle sent items and is it possible to process them befor they get saved in the sent item folder? My scenario is that I'm running postifx + dovecot with all incoming and outgoing mail passed to a script that encrypts the mail with the public key of the recipient. The only place now that has unencrypted mail sitting on the server is the sent items, I'd like to fix that. What would be the best way to proceed here? - -- Encrypt everything. Public key: https://www.secryption.com/BruceMarkey.asc I believe that any violation of privacy is nothing good. Lech Walesa -BEGIN PGP SIGNATURE- Version: OpenPGP.js v.1.20130420 Comment: http://openpgpjs.org wsFcBAEBCAAQBQJSR+odCRDIVcS4Lgc6WAAAIOYP/AqT3HWNbZZnoRXgeq27 n8id40wWemf+IgXGEe1fCTX7d/x+Zinj7bZw5EVq8WlLDxwpOhJGDNUAfA2+ 2z+6J7H0dAHk8rSJZqZfNaGWQQhY3ZehwJnojGJnM5ORuHHH/9WsY91jq26u 4Bzg54tUo+aIoWJHLWlVdqiDjJsW4n536UaHcKlVQx0JCe1byt4eXAmJP9dh Dc9YkP3lKUdW9oxgusJRLOxGfaN++nIFHSBDV6wGp0gEdCuzkgphdEFMnUX9 mD1dwPrDMlEmqHkiyHFH9RGGFvHRaTmdREW8eX9vnHp2PBXthbqd3RKWs7Q4 FmnfoS18inSbTM9Cp79HgQBMKBu66/qtdI6q5q45An9lmQAGf2ElvApSj8b+ ZI5GklVGSyrkxwRTOSRij57SDcRexNhlHg1jsDwSFvNjW5CzH0cB+mVU98eB TqfbIPKvGuqKzpdgf7SNJhZXmmkRrtsL/pI3xCheaZVh34Jxx6N/mP01pDEv d4IrajaTS+0mv6cM4z5f6k62YypHNB9fSTTjIKIqAvLgWMyQIFdjd9BQ1PQK pPiu+btbhhb4RgKa3LFSTp2xJVZlKXd2bqTaRkv63eUgF9NUIr3RYM98I75z mMnxfR5QDZIS6s5tlmZXF7zvCzXoRj30xEp8IsTMrfA4GzLpfAVsJaSUZlSo j5I3 =5Tw/ -END PGP SIGNATURE-
Re: [Dovecot] How to authenticate against SQL DB with custom-ciphered passwords?
Thanks a lot for your answers! Unfortunately I didn't have a chance to sit down and implement the thing yet, but after looking through the Dovecot code I have some additional questions. Please see inline below. On Fri, Sep 27, 2013 at 10:13 PM, Timo Sirainen t...@iki.fi wrote: On 26.9.2013, at 10.01, Nicolay Vizovitin vizovi...@gmail.com wrote: I'm about to start developing authentication/password-scheme module for Dovecot. So I would like to get some advice before actually committing to doing things in particular way. Hope somebody will be able to help me :) For the record, I am currently targeting latest stable Dovecot version 2.2.5. I have an SQL DB with mail users' authentication data. Passwords are stored either encrypted via system crypt(3) or ciphered with some custom algorithm (think something symmetrical like AES, so passwords can be decrypted into plain form). I want to use this DB as both userdb and passdb backend. The issue, of course, is with ciphered passwords support. 1) Is it feasible to just implement a new password scheme for ciphered passwords support and still use stock passdb driver in Dovecot for SQL DB access? Plugins can implement new password schemes. http://dovecot.org/patches/password-scheme-lmpass.c is an example, although I'm not sure if it compiles with v2.2. So that passwords in this scheme would be treated as PLAIN (in a sense that both cleartext and shared secret authentication methods would work). You could do that in a slightly ugly way by setting password_generate=plain_generate(), so password_scheme_is_alias() returns TRUE for that. OK, I figured I had to use something like that. However, after looking through the code I don't think it'll work with shared-secret authentication mechanisms. Looking at struct password_scheme definition: int (*password_verify)(const char *plaintext, const char *user, const unsigned char *raw_password, size_t size, const char **error_r); void (*password_generate)(const char *plaintext, const char *user, const unsigned char **raw_password_r, size_t *size_r); password_generate would have to be equal to plain_generate(). So I'm left with password_verify, but its signature implies that it is called only when plaintext password is available from client, which is not the case with shared-secret mechanisms. A simple question to verify my hypothesis: would PLAIN-TRUNC password scheme work with CRAM-MD5 authentication? My understanding of CRAM-MD5 and what PLAIN-TRUNC does tells me it cannot work even in theory. Something tells me that I rather need a new password encoding than just a password scheme. Yet there is no way to extend password encodings, as far as I can tell (at least from looking at password_decode()). So I guess I can't use new password scheme to solve my problem without patching Dovecot, can I? 2) Provided I implement custom password scheme for ciphered passwords, what is the best way to be capable to perform authentication against both ciphered and encrypted passwords? Ciphered and encrypted passwords are stored in different fields of SQL table (one of them is NULL when the other one is set). a) Do I define two passdb clauses with their own default_pass_scheme (equal to my new scheme or CRYPT for encrypted passwords) and use fallback to effectively check both of them? b) Do I modify SQL query so that it prefixes existing password with correct scheme (I'm not sure this will be easy enough to do)? By ciphered I understand you mean encrypted, and by encrypted you mean hashed.. Scheme prefix would work, mysql and postgresql have complex enough string manipulation functions to make this possible I think. Well, yes, I meant exactly that. :) 3) Is it mandatory to provide password generation routine for custom password scheme? When it will be used? doveadm pw command would use it for example. But as mentioned, you should set it to plain_generate. 4) Maybe it's better to just implement a plugin that serves as both userdb and passdb driver (in other words a kind of generic authentication module)? What are advantages and disadvantages of each method - custom password scheme + stock SQL driver VS. custom userdb and passdb driver? Fortunately, I already have all the required credentials lookup and verification code. So in any case the question is only in figuring out suitable Dovecot APIs and integrating the existing code. Implementing yet another sql passdb sounds like quite a lot of work. I guess it is. But I'd rather trade more work now for more maintainability later (if implementing passdb would help). I don't really want to patch Dovecot as future changes may render the patch incompatible. I could invest some time into the patch provided there is a chance it would get
Re: [Dovecot] Processing sent items
On 29.9.2013, at 11.51, Bruce Markey br...@secryption.com wrote: How does dovecot handle sent items and is it possible to process them befor they get saved in the sent item folder? My scenario is that I'm running postifx + dovecot with all incoming and outgoing mail passed to a script that encrypts the mail with the public key of the recipient. The only place now that has unencrypted mail sitting on the server is the sent items, I'd like to fix that. What would be the best way to proceed here? http://dovecot.org/patches/2.2/mail-filter.tar.gz is a start, but like its README says it can't quite handle modifications of mail contents, but should be possible with some smallish changes.
Re: [Dovecot] Processing sent items
Thanks Timo, I'll give that a look. -- Encrypt everything. Public key: https://www.secryption.com/BruceMarkey.asc I believe that any violation of privacy is nothing good. Lech Walesa
Re: [Dovecot] Using MailDir but local messages still save in mbox format
On Sat, Sep 28, 2013 at 04:26:03PM +0200, Axel Luttgens wrote: Le 27 sept. 2013 à 09:35, Mike Edwards a écrit : I think I just fixed the problem but I am not sure if I did it the right way.. It seems that it is postfix that did it, not dovecot. I found this in the log for every local message... Sep 26 11:10:10 zeus postfix/local[14565]: 9B0294AA15E: to=vm...@my.domain.com, orig_to=vmail, relay=local, delay=9, delays=9/0.01/0/0.02, dsn=2.0.0, status=sent (delivered to mailbox) So, I went to the postfix master.cf and commented out this line... #local unix - n n - - local Was that the correct way to do it? Hello Mike, You probably have cured the symptoms... ;-) I doubt it. The correct way to not route mail to local(8) is to take the domain in question out of mydestination. With no local transport available, but a domain is still listed in mydestination, Postfix will probably just complain about transport not available. Your cron command has very likely been built for making use of the sendmail command. When facing a naked recipient address such as vmail, Postfix' sendmail will look for an alias, then for a system user bearing that name. No, this is wrong. Where did you see this? A bare localpart address without domain has @$myorigin appended. See postconf.5.html#append_at_myorigin for details. The munged @domain shown above is Mike's $myorigin, and it is listed in his $mydestination. There's probably no alias for vmail, but you clearly have a system user named vmail; so, sendmail will proceed with a local delivery for user vmail. Nitpicking here, but sendmail does not do the delivery, only the acceptance and enqueueing. The now-commented local checks the alias_maps and does the delivery. So, you could for example define an alias: vmail: yourself@your.virtual.domain since you're potentially more interested than user vmail in the messages emitted by the cron job. This won't work if local_transport points to a service which is undefined. Or add such a line to your crontab: MAIL=yourself@your.virtual.domain so as to override the default recipient, ie the user the job runs as. Probably a better idea, but that feature is not available in all known cron implementations. Mike should check his own crontab(1) manual. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Panic: file mail-storage.c: line 834 (mailbox_verify_name): assertion failed
On 28.9.2013, at 18.11, Kamil Andrusz w...@mniam.net wrote:
Sep 28 16:57:21 shwurzbung dovecot: imap(wizz): Panic: file mail-storage.c:
line 834 (mailbox_verify_name): assertion failed: (strncmp(vname, ns-prefix,
ns-prefix_len-1) == 0)
namespace {
hidden = yes
inbox = yes
list = no
location = mbox:~/mail:INBOX=/var/mail/%u
prefix = inbox/
type = private
}
Don't use prefix=inbox/. Either use INBOX/ or something completely different. I
think the proper fix here is to just fail to run with this configuration.
