On 27-12-14 18:56, Thomas Raschbacher wrote:
also it might be good to create a CVE:
http://www.cvedetails.com/product/3284/Dbmail-Dbmail.html?vendor_id=1941
I have no idea where to even begin doing that. Looks like a complete
nightmare.
--
On 2014-12-20 22:20, Paul J Stevens wrote:
Ok.
Good news: dbmail-3.1 is not affected. Apparently the problem only
occurs in 3.2.0 and 3.2.1. It's definitely a regression.
Bad news: if you use 3.2, you should apply the patch I pushed
yesterday.
The workaround offers no real protection, as
On 2014-12-20 22:20, Paul J Stevens wrote:
Ok.
Good news: dbmail-3.1 is not affected. Apparently the problem only
occurs in 3.2.0 and 3.2.1. It's definitely a regression.
Bad news: if you use 3.2, you should apply the patch I pushed
yesterday.
The workaround offers no real protection, as
On 19-12-14 22:55, Paul J Stevens wrote:
You should disable CRAM-MD5 in dbmail.conf if you store password encrypted.
ehh.. how? by setting 'capability'?
___
DBmail mailing list
DBmail@dbmail.org
On 19-12-14 22:55, Paul J Stevens wrote:
You should disable CRAM-MD5 in dbmail.conf if you store password
encrypted.
ehh.. how? by setting 'capability'?
Hi Casper,
Yes, overwrite capability with the string you get after login, and remote
CRAM-MD5.
Yes, overwrite capability with the string you get after login, and
remote CRAM-MD5.
Remote = remove :)
___
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
Ok.
Good news: dbmail-3.1 is not affected. Apparently the problem only
occurs in 3.2.0 and 3.2.1. It's definitely a regression.
Bad news: if you use 3.2, you should apply the patch I pushed yesterday.
The workaround offers no real protection, as Caspar correctly surmised.
On 20-12-14
Hi all,
It was brought to my attention that dbmail currently authenticates any
user with any password if the client issues an CRAM-MD5 authentication
exchange, while the user - which does need to exist - has it's password
stored in an encrypted format.
This affects all versions supporting
