On 27/Oct/11 13:45, Matus UHLAR - fantomas wrote: > On 15.08.11 15:02, Sam Varshavchik wrote: >> There are several possibilities. If the STARTTLS command itself >> fails, it's an SMTP error no difference then any other SMTP error, >> and will be either permanent or transient depending on its numerical >> code. If the STARTTLS command succeeds, but TLS negotiation fails, >> its a permanent error. But in either case there is really no fallback >> path. > > There would be a fallback path, if courier returned and reported tempfail > in such case: we could set up esmtproutes for such host that would > disable using starttls there, and the mail would get delivered.
Better yet, Courier could add the server to some "starttls-ignorant" file containing a list of servers that improperly advertize TLS support. Keeping unsent messages in a queue until a 5xx reply or timeout is just normal. I think ESMTP_USE_STARTTLS could safely default to 1 if such a mechanism were implemented. >> For practical purposes TLS for SMTP is fundamentally broken. Many TLS >> servers simply use self-signed certs, making TLS fundamentally >> useless as means for effective encryption. > > Many does not mean all - those who use certificates signed by trusted > authorities are safe. And we can still configure other certificates as > trusted. We don't need to actually trust the certificate if all what is wanted is to encrypt the channel for privacy. -- ------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
