El 2013-04-26 17:27, Mike Cardwell escribió:
* on the Fri, Apr 26, 2013 at 04:41:22PM +0200, Jan Kundr?t wrote:
RESENT because I sent from the wrong email address. Please delete my
other email rather than letting it through if it's in a moderation
queue. If you see this email after allowing it through, don't worry
about it.
Yes, this is perfectly acceptable behaviour for SMTP also.
This bug concerns me: https://projects.flaska.net/issues/623
"The SMTP code does not invoke STARTTLS unless explicitly
configured by
the user. It would be great to do this when e.g. the server
advertizes
STARTTLS and does not offer a supported AUTH method."
I don't think you should opportunistically use STARTTLS in this
way.
It isn't clear to me why it's OK for IMAP to work like that, but not
for SMTP. Bug #623 is to make the SMTP client work exactly like the
IMAP one.
I don't think the spec or any recommendations for either SMTP or IMAP
say that clients should opportunistically upgrade their connection.
It
just allows servers to advertise different authentication methods
depending on whether or not SSL is in use. Which makes sense, because
some authentication methods are safe over unencrypted connections and
some aren't.
So... Imagine you visit an untrusted network after configuring up
Trojita in this manner. A MITM could modify the contents of the
servers EHLO response to remove "STARTTLS" from the list of
supported
extensions, and add unsafe authentication methods (PLAIN/LOGIN)
into
the response at the same time, which would cause Trojita to perform
the authentication in an insecure manner rather than upgrading to
an
encrypted channel first.
You're right, there's definitely a vulnerability here, both in the
current IMAP implementation and in the planned change to the ESMTP
one. Perhaps it would make sense to silently modify the user's
settings during a first succesfull connect when the code decided to
"upgrade" to STARTTLS without being told so by the user?
That sounds like a good idea to me.
This won't help when the user is MITMed during the first connect,
but I don't see what we can do here anyway (except making STARTTLS
active by default, which is probably a good idea).
Defaulting to secure is always a good idea IMHO. And if you can warn
users when they're doing something that isn't safe, that's even
better.
Just another related thought. It would be nice if Trojita "noticed"
that STARTTLS was available, and warned the user that they're not
taking advantage of it (if they aren't). This could be a one off
warning, and wouldn't necessarily happen at initial configuration
time. Imagine for example, your mail provider decides to start
offering SSL six months after you configure up Trojita to use them.
That's a great idea; I agree that the settings UI can be made more
robust and intuitive, and providing helpful suggestions on how to
achieve the most secure connection method would definitely apply.
Do I have to mention that patches are very, very welcome? :)
To be perfectly honest, I've not actually even installed Trojita yet
my self. I read a comment somewhere (Hacker News I think) stating
that you might be getting PGP support at some point (A GSoC project
maybe?), so subscribed so I could follow development.
My server encrypts all of my incoming email with my public PGP key,
which means I can't really use Trojita as my normal day to day
client until it has PGP support. I will certainly install it at
some point soon though, just to see if I can break it ;)
Thanks for your responsed. I like trojita but I can't send mail with
smtp...Attach the screenshot:
http://imageshack.us/photo/my-images/163/screenshot1ixk.png/
http://imageshack.us/photo/my-images/546/screenshot2noj.png/
Thanks for all.
