Hello all.
Just about to migrate from courier to dovecot, and figured I would as
well try and get
this working so I could use non plaintext mechanisms as well.
I would like to offer at least: plain login digest-md5 cram-md5
and maybe more
Everything works but this and have a testdb in sql with p
constantly fails and %m is always empty according to sql logs.
auth-worker is given the information about mechanism, so seems like the
%m just isnt used?
Any ideas?
/Roger
Timo Sirainen wrote:
> On Tue, 2008-08-26 at 13:42 +0800, R A wrote:
>
>> Is there any variable I can use
Works like a charm now!!
Just a thought though, as you have to store the password in the form
{CRAM-MD5}x to actually get that and not the default_pass_sheme
would it not be better to have an 'extra' field that could override
default_pass scheme
if it existed instead?
That way it would a
Hello again.
Just thought I'd ask and see if it would be possible to get this
sometime in the future:
TLS and SSL connection information in a variable like %c today, but more
exhaustive.
For example I can from postfix get a log like:
postfix/smtpd[432]: Anonymous TLS connection established from x
Hi
This sounds to me like the failing Outlook clients might fall over to
CRAM-MD5
and you need to use the %m to map out the method sasl uses to return the
right
password.
Then you need to either use the source packet from ubuntu intrepid
and apply this patch
http://hg.dovecot.org/dovecot-1.1/rev/
Hello
The most recent debianized dovecot I know of is in the ubuntu intrepid
tree. You can download their source packages and compile on any debian
platform and get fairly up to date packages. Think they were up to 1.1.2
last I saw.
-Roger
Christopher J. Buckley wrote:
Diego,
Ok. I did
Romer Ventura wrote:
> Hello,
>
> I was wondering is I could use MySQL as storage only..? Meaning that no
> user information, other than the obvious email address associated with an
> specific email so that each email can be showed to the right user, will be
> stored in a MySQL database instead
Seth Mattinen wrote:
>
> Multiple master in MySQL is still more of a hack. Also, performance
> for billion-row SQL tables is rather poor for something interactive
> like clicking on a message in IMAP and expecting it to pop up right away.
>
> I'm looking forward to master-master replication. Not SQ
