Hi, >>> * ssl_only really does two separate things: >> >>> 1. It forces SSL for *fetching* configs. >>> 2. It forces SSL or STARTTLS in the *resulting* configuration when >>> *guessing* the config. >> >>> Is this confusing? >> >> Anything else would look strongly inconsistent to me, at least in the >> threat model I think we're considering. So I don't find it confusing. >> >> OTOH, I don't understand what exactly "*resulting*" means above, so >> I may very well be entirely confused wrt. how ssl_only behaves in >> GuessConfig city.
> With resulting I just meant the fetched config after it has been parsed. Ok. And what do you mean by "it forces ... in the resulting", then? Refusing to save and/or use non-SSL parts? Forcibly turn SSL on (StartTLS? SSL?), regardless of the fetched configuration? >> OTOH, I would find it great if we could make it clear to them what >> risk they are taking. How hard would it be to implement this? (This >> would be a low-priority enhancement: I don't think our current >> Claws Mail setup has anything to say against SSL.) > Turned out to be easier than I initially thought (thanks, exceptions!). :) >> In any case, the current situation makes the "Only use secure >> protocols" checkbox a wrong statement, isn't it? > You're right. Implemented (PATCH 6/6). Ok. > Since we have no icedove repo to push to Oops, sorry, I mentionned we should get one the other day, but I did not actually ask for it. Going to do this soon. > I post my current work here A Git bundle would be more useful in case anyone wants to seriously have a look / improve / suggest. $ git help bundle Cheers! -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | We're dreaming of something else. | Something more clandestine, something happier. _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
