Re: [Dovecot] zlib_save per namespace/mailbox?
On Thu, Sep 22, 2011 at 8:44 AM, Lutz Preßler wrote: > the zlib_save question reminds me of a wish: > I think it's not possible to set zlib_save parameter per namespace (or even > mailbox). Per namespace would be something for the wish list to get rid of > the cron job method to compress archival mailboxes. > And maybe an option to add a "Z" flag to compressed maildir message files > as recommended in the wiki regarding compress crob job. +1 on this request. I have a slightly different use case -- I have both an dbox and Maildir. Incoming email goes to Maildir, but I archive off to dbox (using Thunderbird). After I archive my emails, compression seems like a reasonable choice. Any idea if this feature will be available at some point? Thanks, Ben
Re: [Dovecot] "pipe" plugin - is anyone interested (or using it)?
On Dec 5, 2007 7:29 AM, Nicolas Boullis <[EMAIL PROTECTED]> wrote:
> A few months ago, I sent a message to this list asking if people would
> be interested by a "pipe" plugin (see
> http://dovecot.org/pipermail/dovecot/2007-May/023005.html ). I received
> a few answers of people who told they were intersted.
>
> A few months later, I sent a new message announcing the availability of
> my work (see
> http://dovecot.org/pipermail/dovecot/2007-August/024805.html ).
>
> Since then, I have received no feedback...
>
> So, is anyone using this plugin? Is anyone using it?
Hi Nicolas-
I don't remember seeing either of your earlier messages (although I
admit to not always being able to closely follow the list despite
being a subscriber), but I do like your plugin. I haven't had a chance
to install and try it, but I'm adding it to my list of things to do.
I've struggled to come up with an easy-to-use solution for manual
classification of messages for end users, and ultimately sort of
pushed it aside, but this seems like an elegant and easy-to-use
solution.
Could you maybe explain how the configuration works in a little more
detail? For some reason I'm having a bit of trouble wrapping my head
around how this works:
(...)
namespace private {
separator = .
location = maildir:/var/mail/%u
inbox = yes
hidden = no
}
namespace public {
separator = .
prefix = learn.
location = maildir:/var/learn/%u
inbox = no
hidden = no
}
(...)
plugin {
(...)
pipe = /var/learn/%u/.spam:spamc -d some.host -L spam
pipe2 = /var/learn/%u/.ham:spamc -d some.host -L ham
(...)
}
Thanks,
Ben
Re: [Dovecot] APOP and CRAM-MD5 in checkpassword module
On 6/25/07, John Peacock <[EMAIL PROTECTED]> wrote: Ben Schumacher wrote: > I would like to see this, too. After digging through the code some, it > seems that the major sticking point is that dovecot would prefer to do > the CRAM-MD5 internally and therefore expects to have access to the > password in plaintext and doesn't pass the timestamp on to > checkpassword... There is no way to use CRAM-MD5 without having the password stored in plaintext locally; it is a design "feature" since the hash is calculated using a different server key every time. The problem is not that the passwords aren't stored locally in plaintext, it's that the mechanism for providing that information to dovecot is not there with checkpassword authentication. checkpassword expects to receive the 3 pieces of information it needs to perform this style of authentication -- username, hash and timestamp (or a "challenge string" -- which is generally a timestamp). This somewhat conflicts with dovecot's authentication system, which expects to have all the necessary authentication information internally and is not design (not willing?) to trust a checkpassword-style authentication mechanism to peform CRAM-MD5 authentication and therefore only offers PLAIN as an option to clients. Likely this change would require some tweaks to configuration as it would mean that dovecot would need to be configured to know which authentication mechanism the checkpassword system offered, but I still think it'd be a better situation than to simply not be able to use CRAM-MD5 if checkpassword is enabled. Cheers, Ben
Re: [Dovecot] APOP and CRAM-MD5 in checkpassword module
On 3/29/07, Max A. <[EMAIL PROTECTED]> wrote: > Still a bit more fixes. My coding TODO list is again empty. Whether it is possible to add APOP and CRAM-MD5 in the checkpassword-module? Original qmail-popup is able APOP, and smtp-auth patch (http://www.fehcom.de/qmail/smtpauth.html) can use CRAM-MD5, accordingly, vckpw from vpopmail understands both these of a method. Very much would be desirable, that these two methods were in dovecot (in chackpassword-module). I would like to see this, too. After digging through the code some, it seems that the major sticking point is that dovecot would prefer to do the CRAM-MD5 internally and therefore expects to have access to the password in plaintext and doesn't pass the timestamp on to checkpassword... Any chance this behavior could be altered/updated in the future? It's made migration from existing mail system difficult as I don't want to give up the security of CRAM-MD5 even for the benefits of dovecot, and reworking authentication scheme is a no-go at this point. Any help? Thanks, Ben
