Jesse Guardiani <[EMAIL PROTECTED]> writes: > Ah. So the whole Cram-Md5 IMAP issue is a Python library limitation, > not a tmda-ofmipd thing. I get it now.
No, this is not correct. The limitation is in how CRAM-MD5 itself works. For reference, read http://www.faqs.org/rfcs/rfc2195.html During SMTP auth, the client password is converted into a hexdigest before transmission. Thus, tmda-ofmipd never receives the password in clear text, and thus can't verify it against an external source like an IMAP server. However, given the username and a local password file (like /etc/tofmipd), tmda-ofmipd can lookup the users password, recalculate the hexdigest, and then compare that to the digest it received from the client. The FAQ implies that it might be possible to pass the CRAM-MD5 token all the way down to the IMAP server in the absence of the username/password pair. This will not work, again because of how CRAM-MD5 works. The "token" is based not only upon the password, but also the unique timestamp that the server initially provided. So, the token from the first exchange between the MUA and tmda-ofmipd will not work between tmda-ofmipd and the IMAP server---tmda-ofmipd would need the username/password pair to complete the challenge which it doesn't have. Does this make sense? This issue is not very straightforward, but understanding how CRAM-MD5 works (by reading RFC 2195) will help quite a bit. David, do you want to correct the FAQ entry? _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
