Re: regarding ssl certificates
On 3/14/19 10:08 AM, Stephan von Krawczynski via dovecot wrote: Some facts for you, as obviously you have not understood what a CA is worth that is compromised by either hackers or "authorities". If you want to know more, read articles about closing of CA DigiNotar, like: https://en.wikipedia.org/wiki/DigiNotar I am well aware of what happens when a CA is compromised and man-in-the-middle attacks become possible. Your initial mail implied that the user's own keys would be compromised. Running your own CA is quite useless for asserting one's identity to random other mail servers as you'd have to get them all to trust you as a CA, with exactly the same problems as any other CA, with anonymity tacked on. DNSSEC would be wonderful if it was commonly supported, but we ain't there yet. The point is that a cert from any currently recognized cert authority is *operationally* better than a snakeoil cert. The practical impact of your initial advice is "don't run a mail server". Also, secrets don't last -- nobody trusts anything that came from DigiNotar. That will happen to any CA caught issuing bogus certs, regardless for whom. Then read US export laws concerning security devices. Then judge your US-issued certs... Totally orthogonal to the problem of mutual trust for mail handling.
Re: regarding ssl certificates
On 3/14/19 7:40 AM, Stephan von Krawczynski via dovecot wrote: Sorry I have to write this, but this is again pointing people in a fake security direction. You should be sorry, because you are wrong. The only valid authority for a certificate is the party using it. Any third party with unknown participants cannot be a "Certificate Authority" in its true sense. This is why you should see "Let's Encrypt" simply as a cheap way to fake security. It is a US entity, which means it _must_ hand out all necessary keys to fake certificates to the US authorities _by law_. Certificate authorities, including Let's Encrypt, operate on Certificate Signing Requests, not Private Keys. Some CAs do offer private key generation in their services for the user's convenience, but it is not recommended (obviously) and in no way required. Getting a CA to sign a CSR in no way exposes keys to that CA, and therefore not to any government. While there are weakness in the CA trust system, they aren't anything related to replacing a snakeoil cert with one from Let's Encrypt. [rest of ignorant rant trimmed] Phil
Re: Migrate Mail Data from Dovecot to Dovecot
On 2/17/19 4:00 AM, Odhiambo Washington via dovecot wrote: I have built a new server (FreeBSD-12) running dovecot-2.3.4. My old server (FreeBSD-9.3) is running dovecot-2.3.4 as well. The configurations are 1:1 identical. The are about 250 users on this server, all virtual. They are mostly POP3 users, but they do "leave a copy of message on the server" for set various number of days. Now, to migrate the mail data, can I simply rsync the mail directories between the old and the new server? Would that create a pitfall?? What is the recommended method? Consider re-posting your question in a NEW message, not a reply to another, unrelated thread. The type of people who are likely to know the answer are also likely to use threaded mail-readers, and will therefore not see your message. Phil
Re: Upgrade to 2.3.1 has failed
Andy, This is just rude. You have been told multiple times that the less-than symbol is required to read the certificate from the file. Otherwise, the filename is parsed as if it is the certificate itself. Which yields garbage. If dovecot can't read that file, it is *not* dovecot's fault. You are simply not going to succeed until *you* figure out what security differences you have in your new installation. So dovecot can read the files. Every single attempt to connect via openssh depends on dovecot reading your certificate and key files. They are pointless exercises until dovecot actually loads your files. Focus on the real problem if you wish to fix your service. On 12/15/18 5:12 PM, C. Andrews Lavarre wrote: > Alexander, Thanks, as described before, if I include the "<" then > Dovecot fails to start at all. > > Thank you again for your time. I have forwarded my latest to Aki to the > group. Regards, Phil
Re: Mailing list address harvested for spamming
On 12/2/18 5:58 PM, Noel Butler wrote: > Lots of posts around about this, all self serving :) > > There may of course be an RFC floating around, but I admit to never > having bothered to look, because good netizens reply to list, lists are > public, they are for the masses - the membership - the subscriber base, > never seen the point in replying privately to a list post, since the > answer deprives the list membership of, the answer, so you avoid getting > 1500 people ask the same damn question. Reply-to-all is a requirement for public mailing lists that do not require posters to be members. Like everything at kernel.org. Failing to reply-to-all will exclude non-members, and will get you deserved abuse on such lists. Other lists have other policies and/or conventions. What's so hard about following the conventions of the lists you participate on? Especially if requested by the list owner? Phil
Re: distuguish between different domains
On 09/28/2015 10:18 AM, Marco Fretz wrote: > On 28.09.2015 10:48, Andreas Meyer wrote: >> For my understanding it should not be possible to connect to server >> server.aaa.de with an address line u...@bbb.de and dovecot serves >> the mailbox of that user. > the dovecot service does not care about the server dns name. the dns > name resolves to the IP address on the client (roundcube) and the client > connects to the server. if the same dovecot instance listens to all / > both IP address, client will end up on this dovecot instance and all > valid user-password combinations are authorized. that's the way it has > to be, otherwise virtual / mass virtual domain hosting would not be > possible as you cannot spawn 1000 instances on the same machine (ok, in > theory you could do that :D) No, it's only impossible if you are using passdb or otherwise authenticating against real users of the system. If you are using virtual users (SQL, LDAP, etc.), you can include the domain name in the auth lookups. Phil
Re: [Dovecot] Dovecot with sasl/imaps/postfix and thunderbird
On 03/13/2013 01:51 AM, Stan Hoeppner wrote: On 3/13/2013 12:00 AM, Alex wrote: I just verified that TB (17.0.4) won't do STARTTLS on TCP 143 without first accepting the self signed cert. I'm really hoping someone can help me to clarify more specifically what's going on here. You've already clarified it. You simply can't do account auto configuration with a self signed cert, at least not with a vanilla TB setup. The only possible solution I can think of would be to preload the user profile with the certificate. I don't know how you'd do this. I think you have some research ahead of you. It's relatively easy. On first starting TB with no account, cancel the wizard. The use Edit - Preferences or ≡ - Options... - Options... to get to TB's configuration pages. There, use Advanced - Certificates - View Certificates - Servers and finally Import... After you've imported the needed cert, you can re-open the wizard with Create new account. You can also use this method to import a self-signed certificate authority if you want to run your own signing operation. Phil
Re: [Dovecot] Anyone else seeing lots of random duplicate messages???
On 09/04/2012 12:40 PM, Charles Marcus wrote: On 2012-09-04 12:37 PM, Charles Marcus cmar...@media-brokers.com wrote: Almost every message I'm getting through this list is duplicated, down to the same exact message-ID... Anyone else seeing this? Even this one was duplicated... Not here :-) Phil
Re: [Dovecot] Providing shared folders with multiple backend servers
On 01/09/2012 08:38 AM, Stan Hoeppner wrote: On 1/8/2012 3:07 PM, Sven Hartge wrote: [...] (Are my words making any sense? I got the feeling I'm writing German with English words and nobody is really understanding anything ...) You're making perfect sense, and frankly, if not for the .de TLD in your email address, I'd have thought you were an American. Your written English is probably better than mine, and it's my only language. To be fair to the Brits, I speak/write American English. ;) Concur. My American ear is also perfectly happy. I'm guessing no one else has interest in this thread, or maybe simply lost interest as the replies have been lengthy, and not wholly Dovecot related. I accept some blame for that. I've been following this thread with great interest, but no advice to offer. The content is entirely appropriate, and appreciated. Don't be embarrassed by your enthusiasm, Stan. Sven, a follow-up report when you have it all working as desired would also be appreciated (and appropriate). Thanks, Phil
Re: [Dovecot] Virtual Servers
Hi Daniel, On 06/27/2011 02:40 PM, Daniel L. Miller wrote: Maybe a little off-topic - but I hope not too much. Looking for some insight on setting up Dovecot under a virtual server. In particular, I use VirtualBox - and at the moment, Ubuntu Linux. Initial questions on configuration: Caching. It seems to me - and I'm probably wrong - that running a Linux in a VM on a Linux host, there would be a duplication of caching. That is, the host server has a file cache - and the VM, which is otherwise a standard Linux installation, is also going to try to cache its files. This strikes me as a duplication of effort and waste of RAM. Is this something I should devote any time to thinking about and trying to minimize? If so, how? In the storage configuration of your VM, where you select the type of interface to emulate, there's a checkbox for using the Host's I/O cache. Mail storage. My current mail store is a RAID-10, using the mdbox format. I wish to continue storing the mail on raw disks - not place the mail inside a virtual disk. Accordingly, the VM needs to reach the mail outside the VM environment - which according to conventional wisdom means NFS. My initial testing shows NFS results in a dramatically reduced performance for Dovecot. Given that this NFS access is going to be exclusively for Dovecot, and I'm only running a single server, are there any NFS or Dovecot tweaks I should implement? Is there an alternative connectivity for the VirtualBox environment I should explore? If you can set aside entire block devices for use in the VM, you can create a vmdk that performs a 1:1 mapping from the virtualized disk to the given block device. The block device will be partitionable inside the VM, even if it is a partition itself. If you need to, you can access those partitions from the host with the partx or kpartx utilities (with the VM shut down, of course). The command you want is VBoxManage internalcommands createrawvmdk On the other hand, if the host and the guest need simultaneous access, you will need some form of network filesystem. HTH, Phil
Re: [Dovecot] Change passwd backend over cron: what happens if changes while reading?
Hi Denny, On 06/22/2011 07:19 AM, Denny Schierz wrote: I want to use two backends für DoveCot. One generated file from the LDAP tree, and the real LDAP. The first backend is generated from a cronjob thats reads the whole ldap server and converts them into a DoveCot passwd file. OK. I red in the Wiki, if the user password isn't correct, than DoveCot asks the second backend (LDAP). Is this correct? Because, the the user can change his password, but Cron generates only every hour the file. So the password in the passwd-file isn't correct, until Cron runs again. I don't know this. The second, what happens, if Dovecot reads the file and in the same moment, Cron generate the new file? Does he change to the second backend? Or do I (the user) get an error? I do know this. If the cron job is writing directly to the passwd file, you will have opportunities where dovecot can see a partial file. I don't know what will happen for sure in this case, but you might trigger rare bugs. You should make your cron job write to a temporary new file, close it, then rename it to the correct name. This will atomically replace the old version with the update. If dovecot has the file open when you do this, it will carry on with the prior copy (delete will be deferred until the file is closed). Dovecot will see the changes the next time it opens the file. cu denny HTH, Phil
Re: [Dovecot] On-delivery deduplication?
On 06/08/2011 05:58 PM, Tom Hendrikx wrote: [...] The point is that when you set the headers correctly on your message, a reply from someone on your message will not generate a duplicate in the first place, thereby eliminating your problem even before it exists :) To add a data point, this message was a reply-to-all in Thunderbird 3.1.10. It included Tom's address, ignoring the reply-to: header. Considering Thunderbird's popularity, just using a reply-to: header won't solve the duplicate message problem. This is especially true on open mail lists, like those at kernel.org, where reply-to-all is expected of participants. Phil
Re: [Dovecot] [OT] On-delivery deduplication?
On 06/08/2011 07:05 PM, Tom Hendrikx wrote: On 09/06/11 00:47, Phil Turmel wrote: On 06/08/2011 05:58 PM, Tom Hendrikx wrote: [...] The point is that when you set the headers correctly on your message, a reply from someone on your message will not generate a duplicate in the first place, thereby eliminating your problem even before it exists :) To add a data point, this message was a reply-to-all in Thunderbird 3.1.10. It included Tom's address, ignoring the reply-to: header. Actually I only set the reply-to header (by hand) on the message in which I said that I did that, and not on the second one, because I am lazy and there is no tb plugin to make my life easier. Please try again on the correct message. I checked before I sent, and sure enough, it's there. Maybe Timo has set the list to add it. This one of yours has it, too. Considering Thunderbird's popularity, just using a reply-to: header won't solve the duplicate message problem. This is especially true on open mail lists, like those at kernel.org, where reply-to-all is expected of participants. I use Thunderbird too, and I did test what I documented. To be sure, please check the headers of both messages. Checked. I don't use this practice often (depends on the ml, and the ppl on it), but some time ago the duplicate issue irritated me enough to spend a good thought at what the real problem was. Just shared my results, especially since they are apparently non-obvious :) But maybe we're getting a bit off-topic. After all this is a list about dovecot and IMAP-related stuff. True enough. I'll stop here. Phil
