Hi, * Matthias Andree [07-03-18 03:06:21 +0100] wrote:
Rocco Rutte <pdmef@xxxxxxx> writes:
APOP IMHO should never be considered a secure way of authentication, it's just more secure than sending plain passwords over the wire. But yes, since the RfC says the "timestamp" must be syntacially valid message-id and mutt doesn't check it, there's some room of improvement.
I've just added rfc822valid.c to fetchmail's SVN[1] (GNU GPL), which is a dangerously dedicated hand-written RD-parser to validate a token (const unsigned char *) against rfc-822's msg-id syntax and returns 0 for invalid and 1 for valid.
It doesn't handle NUL characters yet, since fetchmail stomps over them anyways when downloading from the net. If NUL-proofing is desirable, we need to extend the API by a length argument and revise some functions.
I was looking at some mutt code for this issue and other issues that report broken threading upon invalid message-ids. It seems that mutt happily accepts the following syntax: '<.*>' which is just plain wrong.
I looked at rfc822.c to try to reuse address parsing for parsing message-ids but failed since I didn't have much time and the quote is quite complex.
Even though adopting your code for mutt would be quite easy, I'm not yet sure what to do in case of validation errors.
Say we get '<foobar>' during APOP authentication; should be really reject that and report failed authentication? If a message has '<foobar>' as message-id and others have it in their References: header, should we really ignore it and break threading?
bye, Rocco -- :wq!