Re: Dovecot and Letsencrypt certs
On Wed, 13 Sep 2017, Luigi Rosa wrote: > Robert Wolf wrote on 13/09/2017 10:26: > > > are you sure? What is the refresh time? Instantly or with some delay? Have > > you > > tested what happens if I install new key, but I delay installing correct > > certificate? Does postfix keep the old key+cert or stop using any cert > > because > > the new key is not correct for the current(old) certificate? > > > > On my postfix 2.9.6 on debian wheezy 7 and postfix 2.11.3 on debian jessie 8 > > I > > have to reload postfix. Postfix can use the same key+cert even if I deleted > > these files. > > Two days ago Viktor Dukhovni wrote on Postfix ML: > > /* > If you run certbot often enough to renew well in advance of expiration, > reloads of Postfix are unnecessary, and just needlessly interrupt orderly > processing of email by the queue manager. Usually the new certificate will > be automatically in use within "$max_idle * $max_use" seconds, and typically > sooner, because processes either idle out quickly or reach the re-use limit > quickly, handling $max_use connections that are exactly $max_idle apart is > rather unlikely By default that's 1 seconds or just under 3 hours. > */ Hi Luigi, you are right! The smtpd process really start using new certificate+key after this timeout (tested with max_use=1). OK, I thought it works similar as rsync daemon: the config file is read on new connection, because it starts new process. Similarly, the postfix master process starts the smtpd processes and they read config and cert+key again. It's clear now. Still, I prefer to do reload if required and not wait until some timeout expires. And e.g. getssl client can check, if the certificate was correctly installed. And for this check it needs to run "reload". And I prefer reload cert+key manually instead of automatically to be sure, WHEN it will be done. So I am ok with dovecot to load cert+key on start and reload:-) Regards, Robert.
Re: Dovecot and Letsencrypt certs
On Tue, 12 Sep 2017, Daniel Miller wrote: > And remove that "postfix reload" command - Postfix doesn't require explicit > reloading. It'll pickup the changed cert automagically. > > Daniel Hoi Daniel, are you sure? What is the refresh time? Instantly or with some delay? Have you tested what happens if I install new key, but I delay installing correct certificate? Does postfix keep the old key+cert or stop using any cert because the new key is not correct for the current(old) certificate? On my postfix 2.9.6 on debian wheezy 7 and postfix 2.11.3 on debian jessie 8 I have to reload postfix. Postfix can use the same key+cert even if I deleted these files. Reagrds, Robert.
Re: Dovecot - Postfix Calender Synchronisation
On Thu, 24 Aug 2017, Rupert Gallagher wrote: > Re: dependencies > > - db: why? just use the ical and vcard files! They are files, they are in a > directory, they can be used like dovecot uses eml files! No need for > postgresql or mysql. *** Usually, the DB server is one host, Webclient is other host, IMAP server (or cluster) are other hosts, SMTP Server(-s) is other host. All these Servers need access same data on one place. Yes, you can use IMAP to store contacts and events, as e.g. Kerio, Groupwise, and probably some other do and then write some interface server to convert data from IMAP to HTTP. But many vcard and vcal servers store the data in DB (AFAIK SOGo.nu stores these in DB). Btw, dovecot can use SOLR/Lucene for indexing too. Dovecot does use local index files too, but probably if you have really many emails, then you want really indexing server (which can run on different hardware). Why? Because of searching. DB creates indexes and can search fast. Maybe for 100 items is searching on FS and in DB same fast, but with more and more items, FS will be slower. You know probably, how the vcard and vcal looks like (if not, please see one). This is a text. Everything is text. Even dates are text. You cannot search in these files e.g. "if event starts after 2017/8/25". You have to read every file, parse the dates and then can you compare. If you convert these vcal into DB, into correct fields, you can search faster the in FS. And the searching does not mean only if use want find something. The server must search for alarms, to do free/busy search, etc. > - webmail: why? We use dovecot!!! *** Webmail is client, dovecot is server. Do you have only dovecot? No client? Then why do you need dovecot at all, if none reads the emails? No, really, you need some client. Webmail is easy to use, Webbrowser is everywhere. I use alpine, but for BFU is webmail the best. OK, let's say the client for contacts and events could be thunderbird. Calender is intergrated in TB and it does use HTTP. E.g. even if the calender items are stored in Kerio in a maildir-like folder invisible over IMAP, the communication between TB client and Kerio servers runs over HTTP for vcal. SOGO AddOn for contacts for Thunderbird use HTTP too (it works even with Kerio). All these clients and server for ical and contacts use caldav and carddav (DAV over HTTP). Nobody writes server (or client), that use IMAP, because these is no client (or server) which synchronize vcal or vcard over IMAP. > - apache web: why? we use nginx. *** This should not matter, if you know, how to configure nginx to provide same functionality as apache. You can use your favourite webserver, as long as it supports the requirements of the app. E.g. if the vcard/vcal application is written in PHP, then the webserver must be able to run PHP. > - linux: why? we use other unix systems. *** because the programmers develop it on linux and have tested it on linux. For most things, you can use other unix too. Sometimes, it is possible to run it even on Windows, e.g. apache, nginx, php, perl, mysql, ... these run on Windows too. > - python: why? it takes 140MB all by itself, *** It must be written in some prg lang. Someone can C, then he writes it in C - but then, the same libraries must be installed or the developer must compile for every different system with different libraries. Python, Perl, PHP and other interpreted languages are compiled on the fly on the currently running system. Developer can simply pack original source code and this will run on every platform. Therefore, many people use interpreted langs to let their apps run on many platform without many special "IFs" and without compiling for X different platforms. > it is an interpreter (slow) *** I would not expect really big speed difference between good written python code and C code for some vcard/vcal server. > it is a security hazard *** I would say, there could be more security errors (buffer overflow etc) in C code, than in python code. > we would have to install it on purpose and sanbox it in a virtual machine! So > we have to install a vm manager. *** As I say, the most secure server is switched off server and disconnected from LAN and power. You have to choose between security, functionality and complexity. Either you provide only smtp+imap server or you want provide more features (webclient, vcal/vcard, ...) and then you need more software. For a few users could be no problem to have really some small/light server, which stores all data as files on local disk. But I think the programmers of such vcard/vcal servers think about to be able handle big number of users and big amount of data. Therefore they expect some real DB. More feature == more requirements. Regards, Robert Wolf.
Re: pop 110/995, imap 143/993 ?
On Tue, 22 Aug 2017, Ivan Warren wrote: > Le 8/22/2017 à 10:03 AM, Robert Wolf a écrit : > > > > WRONG!!! The email is stored plain-text on the first server and then it can > > be > > sent to other few MX servers over plain-text connection. I.e. encrypted > > connection does not protect emails, but the authentication credentials. > > > > > Indeed. > > Encrypted (SSL/TLS) SMTP/IMAP/POP3 sessions only server 1 purpose : To encrypt > authentication. Once a message is sent through a MTA, there is no guarantee of > privacy whatsoever. > > End to End privacy can only be achieved through actual e-mail signing and > encryption (PGP, S/MIME) (but only the message body is encrypted, not the > headers). Hello Ivan yes, headers are not encrypted in plain-text SMTP, the same way as TCP and IP and DNS Requests are not encrypted. One can only hide behind some anonymization system (TOR, Proxy, VPN for TCP, IP, DNS) or some non-presonal mail system to anonymize mail headers to not be able to connect real persones with mail sender/recipient. Regards, Robert.
Re: pop 110/995, imap 143/993 ?
On Tue, 22 Aug 2017, Aki Tuomi wrote: > else (NOT LOCALHOST) and you can see it says LOGINDISABLED unless you > have enabled something like cram-md5. Hi, exactly, this is the reason, why plain-text is still needed. You don't need encryption for authentication, if you have secure authentication. Without knowing original password, the MITM cannot generate correct hash for login, so the connection can be plain-text. Of cource, if you then download your emails, the MITM can still read these emails too, if these emails are plain-text (not encrypted using e.g. SMIME or GPG). But he cannot misuse your login. Regards, Robert Wolf.
Re: pop 110/995, imap 143/993 ?
On Mon, 21 Aug 2017, Gary wrote: > If I read this correctly, starttls will fail due to the MITM attack. That is > the client knows security has been compromised. Using SSL/TLS, the MITM can > use SSL stripping. Since most Postifx conf use "may" for security, the > message would go though unencrypted. Correct??? Hi, many people think, the email is encrypted (secured), because it is sent through encrypted submission connection to client's smtp/submission server. I know some case, where one users sends credit card numbers over encrypted channel to SMTP server and he thinks the card numbers are protected! WRONG!!! The email is stored plain-text on the first server and then it can be sent to other few MX servers over plain-text connection. I.e. encrypted connection does not protect emails, but the authentication credentials. Users should know, that they have to encrypt the email itself, if they want protect it. Regards, Robert Wolf.
Re: pop 110/995, imap 143/993 ?
On Mon, 21 Aug 2017, Sebastian Arcus wrote: > On 21/08/17 13:39, Robert Wolf wrote: > > > > On Mon, 21 Aug 2017, Sebastian Arcus wrote: > > > > > > > > On 21/08/17 10:37, Gedalya wrote: > > > > On 08/21/2017 07:28 AM, voy...@sbt.net.au wrote: > > > > > is there a 'preferred way'? should I tell users to use 143 over 993 ? > > > > > or > > > > > 993 over 143? or? > > > > There is no concrete answer. There are various opinions and feelings > > > > about > > > > this. > > > > The opinion againt 993/995 is that these are not standard ports, > > > > > > Out of curiosity, is there a source for this? It's the first time I hear > > > that > > > 993/995 are not standard ports - and searching on the Internet, I can't > > > find > > > any evidence to back it up? Also, pretty much all email software has been > > > using them for the past 20 years or so. It seems like a curiously high > > > rate of > > > adoption for a non-standard :-) > > > > > > Hello, > > > > IMHO the "not standard ports" is meant as "old, useless ports now". > > So in short, ports 993/995 are IANA officially approved, and thus "standard". > Further to this, they are in use by the vast majority of email providers, and > as far as I can tell, there are no functional or security disadvantages to > using SSL over 993/995 - instead of STARTTLS over 110/143. Hello Sebastian, > there are no functional disadvantages *** As I have written, only if some protocol can be used in just plain-text mode, then the SSL ports generate additional encryption load. CPU is probably no problem today, but I have seen some slower SSL connection on higher latence network. I am not SSL profi, but it looks like there is some ACK in SSL after some "SSL packet" which makes slower connection on high latency network, because SSL must wait for packet ACK. In plain-text connection, TCP requires ACK too, but TCP can open big window and send many data at once and wait only for the last ACK. > there are no security disadvantages *** Exactly, there is really no security disadvantage to use SSL ports, the encryption is same, resp. there is security advantage to use SSL ports to be sure that every communication is encrypted from start and client cannot send anything plaintext. Regards, Robert Wolf.
Re: pop 110/995, imap 143/993 ?
On Mon, 21 Aug 2017, Sebastian Arcus wrote: > > On 21/08/17 10:37, Gedalya wrote: > > On 08/21/2017 07:28 AM, voy...@sbt.net.au wrote: > > > is there a 'preferred way'? should I tell users to use 143 over 993 ? or > > > 993 over 143? or? > > There is no concrete answer. There are various opinions and feelings about > > this. > > The opinion againt 993/995 is that these are not standard ports, > > Out of curiosity, is there a source for this? It's the first time I hear that > 993/995 are not standard ports - and searching on the Internet, I can't find > any evidence to back it up? Also, pretty much all email software has been > using them for the past 20 years or so. It seems like a curiously high rate of > adoption for a non-standard :-) Hello, IMHO the "not standard ports" is meant as "old, useless ports now". AFAIK at the begining there were only plain-text ports 80, 389, 110, 143, 25, 5222 (XMPP) etc without any encryption. Then SSL was implemented on ports 443, 636, 993, 995, 465, 5223 etc. Later, the STARTTLS feature has been introduced and servers and clients has implemented STARTTLS sometime. Since STARTTLS is used in most clients and servers nowdays, there is no need for SSL port. There is even RFC 2817 for STARTTLS in HTTP. So IMHO all SSL ports are meant to be old, useless now, some Jabber clients describe SSL encryption on port 5223 as "legacy". Pros of STARTTLS is, that you CAN start encryption, if you need it. E.g. for SMTP or LDAP you can use plain text connections without expensive encryption for normal mail transfer (MX-MX) or for searching (LDAP), and client can start encryption, if needed for username+password or cert authentication (SMTP submit or LDAP edit with auth). Of cource for IMAP+POP you have to authenticate everytime, i.e. you need encryption everytime. Pros of SSL port is, you now everytime exactly, that your connection is encrypted, so your password is never sent over plain-text channel. Some servers (services) can be configured to fail correct login, if the login is made through plain-text channel. This is good, because MITM cannot instantly see, if the password is correct or not, but the password goes already plain-text and MITM can test it on secure connection later. Regards, Robert Wolf.
