Confirming the working state!

Just one question to foobar/arcean: the deb size and also the lib sizes differ in the file posted above and the one from cssu-repo.
Any idea/explanation?
I took the one from official cssu repo.

For non-CSSU users: please do not try to install the cssu deb package, it may cause serious problems. If needed I may prepare a workaround like here.

--
but now I again need to reset all my accounts from
IMAP on STARTTLS [setting: Normal (TLS)] -which I just did- back to
IMAP on SSL/TLS [setting: SSL]

Maybe thumb-related problem in scratchbox?
More about issue: http://maemo.org/community/maemo-use..._installation/

Hello,

Just changed the title of the thread to "[SOLVED] Modest cannot receive/send via SSL/TLS" as suggested by peterleinchen.

But frankly I don't know how to get the fix.... I mean is it in the repos or will it be?

It depends!
Whether you are on CSSU or not.

If on CSSU then just grab this deb (or later versions) and download it to MyDocs. Then get root and execute following command:
Done.

If not on CSSU (but running stock PR1.3[.1]) then use the attached tar.gz, download to MyDocs and execute following commands (just like here):

All credits to foobar!

Just some thoughts:

Since both SSL2 and SSL3 are insecure (if not obsolete) what would it take to disable them altogether. With the proposed fix it is made to work, but it leaves some questions.

For instance, if the provider offers both SSLv3 and TLS which one will be choosen. The first in the list or the best? Does it matter if it reads

#define SSL_FLAGS (CAMEL_TCP_STREAM_SSL_ENABLE_SSL2 | CAMEL_TCP_STREAM_SSL_ENABLE_SSL3 | CAMEL_TCP_STREAM_SSL_ENABLE_TLS)

or

#define SSL_FLAGS (CAMEL_TCP_STREAM_SSL_ENABLE_TLS | CAMEL_TCP_STREAM_SSL_ENABLE_SSL2 | CAMEL_TCP_STREAM_SSL_ENABLE_SSL3)

??

The best will be chosen if things are not completely fubar'd inside NSS (the crypto lib tinymail uses).

The order in the #define doesn't matter.
Disabling SSL3 now would lock a lot of people out of their mail servers again, so while it would be beneficial from a security point of view, it would not help with the problem at hand.

See also:

Don't they teach math at school anymore?
Repeat after me: addition is commutative!

-- add.
As @peterleinchen rightly pointed out, ORing is not really ADDing (that would be XORing). However for cases where the things being added do not overlap (in the binary sense of the word), ORing is, for all purposes, the same as ADDing.

So for the sake of completeness:
Repeat after me: disjunction is commutative!

(I know, it sounds much much worse.)

I'm using CSSU but not the devel repository. So I do not have libglib2.0-0 (>= 2.24.0). And I do not want to install the files manually via tar.gz.

Because the files in the tar.gz by peterleinchen are the same as in the CSSU devel package, I simply modified the deb to depend on libglib2.0-0 (>= 2.20.0). For me it works.

I cannot add the modified deb here because I am not allowed to attach files > 488 kB. And the deb is > 600 kB.

I uploaded it there:
http://packages.der-he.de/austausch/...ssu7_armel.deb

It should work for all CSSU and PR1.3(.1) users.

Just for restoring my reputation:
I know those rules already and I know how to apply them

A computer might implement checking the conditions in a different way though.
It might check all conditions for truth and state the result afterwards.
Or it might be implemented to do something like an IF-ELSEIF-ELSE chain would do, meaning if it hits first it sticks to it. Why should a computer test more than one condition if the "true"-outcome has already been reached?

I have seen such implementations before. This of course saves CPU cycles noticably only for large numbers of repetitions. It all depends on the implementation of the checking routine.

And this I have learned AFTER school in university lectures about algorithms and data structures )