-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> By shouting at people you won't get more help. If you offer to pay Paul > for a feature you need, or ask very friendly, maybe he'd implement it > quickly. Just last week he implemented IPv6 support within a short time. Sorry Maybe i am very overstressed because working day and night to get the new mailserver running, implementing a webinterface fpr dbmail/postfix with > 10.0000 lines of code in few weeks because i have only two weeks left to get my work done before a big medical operation on my right eye without knowing what happens in the future :-( Additional my non-programming-english is not the best (especially when tired) and sometimes it makes me simple crazy if i can not announce something in a way it get right understood - sorry for that! The problems shortly after testing day and night with new accounts and thunderbird hitted like a chill in my heart seeing all go down instead of relax and look at at hard piece of work > On the other hand, Paul, having secure methods directly implemented > would really be nice. Just because the *MD5 methods require plaintext > pwds doesn't mean it shouldn't be implemented. It should just be > disabled by those having encrypted pwds. (/me having cleartext pwds, so > could use the feature now *g*). As far as I could read from your words, > it should be easy to implement? i do not know how this works in c/c++ and i am lucky to get three pataches into my rpmbuild-environment which was hardly needed, but as i see that horde uses tls/cram-md5 for smtp as for imap and one small php-script from a freelancer since yesterday uses also cram-md5 on the dovecot proxy i guess it should not be the big deal get this supported in the mailserver - Of course i like the dovecot-proxy-solution too but its hard to find a software solving this if any websearch shows how to get it work with postfix/sasl against the dbmail-database, as said -> quite useless as long as the plaintext-password is going over the same connection for check mails https://bugzilla.redhat.com/show_bug.cgi?id=515056 Dovecat-Patch from last night to allow percent And changing one line in demail-auth query to make possible user % or @ in username - - "SELECT user_idnr FROM %susers WHERE lower(userid) = lower('%s')", + "SELECT user_idnr FROM %susers WHERE lower(userid) = lower(replace('%s','\%','@'))", I do not understand really the history whe we using this for many customers, has something todo with some broken outlook-installations and it is really not easy to get tjis away as long 50% of customers uses their mailaddress as username (defined so in the database) and the other half using % instead @, it gets very hard if parts of the two groups can not connect because the client is using cram-md5/digest-md5 thinking "yesterday this servername supported and it has today too". I know a good client should look what the server says he supports and select the best available mechanism (like horde webmail seems to do), but as long we live not in a perfect world this will not happen :-( -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkqB9GUACgkQhmBjz394AnluCQCfWxgH1L21+1New9+BtLHwoqGR je0An0ReGnW5LdWRahm9OCIC7jxZPjkR =cSsU -----END PGP SIGNATURE----- _______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
