Dealing with broken authentication methods

[StR]

Kostya,

Please forgive me for infringing in the area of your expertise. It is most likely that you have thought about this, but I would through in a thought just in case.

I've seen that in the recent half a year, "incidents" similar to the recent shaw.ca problem have happened with a several different providers. This suggests that it is a recurring type of situations.
In this recent development build (1.5.7-32-dev2.3.2) you've introduced a workaround for one provider, but it will happen again with another provider some time soon. Also, at some point this provider might have it fixed.

So, here is the thought:
Would it be possible/resonable to build a generic workaround with roughly the following scenario:
Aquamail tries the first authentication method. If an error occurs, (or some particular type of error, if it can be differentiated), Aquamail tries to reconnect and use the next type of authentication method. (Just making sure it is not an infinite loop if none work for some reason.)

Am I missing something fundamental in this scenario? Does it break something?
Or is it just difficult (or resource-expensive) to implement correctly?

[Kostya Vasilyev]

I've thought about it and then what happens is -- some mail servers will drop the network connection if you try a second auth command. So it'll still fail, and the error message is going to be wrong.

What I should probably do is -- only use CRAM-MD5 if it's explicitly selected by the user.

That's what I do for IMAP, where CRAM-MD5 is broken much much more often.

With SMTP, it actually does work sometimes, so the logic is to use it if advertised. Needs to be "only if user explicitly asked for it".

[StR]

I've thought about it and then what happens is -- some mail servers will drop the network connection if you try a second auth command. So it'll still fail, and the error message is going to be wrong.

[...]

How about closing the existing connection and making a new connection instead, while carrying the "state" over to it, so that a different method is used?

You can even have a persistent flag set upon N repeated errors with a method, and then rechecking once in a while. (A sort of simple AI, a learning machine.)

[Kostya Vasilyev]

I'm sure there is a way to make it really messy (and buggy) with all kinds of state machines, exponential back-offs, retry counts, warning messages in yellow and then error messages in red, but...

I'd rather keep it simple.

Since these cases are clearly server configuration bugs, I just want to get past them as quickly and easily as possible.

Besides, there is probably only about a dozen users who know and care about CRAM-MD5, and they will most likely email me about it, and then I'll be able to explain how to use it again.