Bernd Wurst wrote: > Hi. > > On Wednesday 14 May 2008, Aidas Kasparas wrote: >> I do not have arguments why courier should not fallback in 454 cases >> [remember "be liberal at what you accept" internet principle?]. > > Well, let's go the other way: We talk about TLS encryption. This is an > encryption, something about security and privacy. > When I send mail, I want to have every connection encrypted that is not > inside > a local network. All internet-transfers of personal/confident data should be > encrypted. > > It's too bad already that some hosts don't offer TLS at all, but the hosts of > my regular peers all do and I know that. So I can send mail encrypted even if > my PGP-setup cannot be used (because the other side does not have PGP or > something like that).
How much of your SMTP traffic is TLS protected? How much of small ISP's SMTP traffic is typically TLS protected? > > If courier would silently fall back to non-encrypted transfer whenever a > temporary failure occures (overload, error in check of > certificate/man-in-the-middle-attack), this would be a terrible loss of trust > in this encryption and it would not be worth anything any more. > > Let me say again: We are talking about privacy. It should be deterministic if > messages are transferred encrypted or not. I completely agree with you that for domains where admin have requested TLS, courier should not fallback to plain ESMTP if it can not get TLS working. But, can we at this moment in time to mandate TLS for all the ESMTP servers in the internet (which advertize TLS support; with handful of exceptions)? I tried to enable TLS on my servers several months ago, but had to step back very quickly because that generated too much problems. -- Aidas Kasparas IT administrator GM Consult Group, UAB ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
