similar to: help with quantification of high density region

Exactly - I removed then with find . -name "dovecot.index*" -type f -delete There is no need to restart dovecot. IMAP client will be forced to resync all the emails from the server. > Le 28 nov. 2018 ? 23:20, JCA <1.41421 at gmail.com <mailto:1.41421 at gmail.com>> a ?crit : > > Thanks. Assuming that the IMAP mail directory for the account affected is under

Thanks. Unfortunately, that made no difference. On Fri, Nov 30, 2018 at 1:20 PM Thomas Durand <tom at rezoo.org> wrote: > Exactly - I removed then with > *find* . -name "dovecot.index*" -type f -delete > > There is no need to restart dovecot. IMAP client will be forced to resync > all the emails from the server. > > > Le 28 nov. 2018 ? 23:20, JCA

$ ssh -Q HostKeyAlgorithms Unsupported query "HostKeyAlgorithms" $ ssh -V OpenSSH_7.4p1, OpenSSL 1.0.2u 20 Dec 2019 On Mon, Mar 2, 2020 at 2:24 PM Christian Hesse <list at eworm.de> wrote: > Luveh Keraph <1.41421 at gmail.com> on Mon, 2020/03/02 14:07: > > When I do ssh -Q key, where ssh is the OpenSSH 7.4p1 client, I get the > > following output: > >

Thanks; I did not think of that. I have just run a few basic tests with both rsync and OpenSSH in their default settings, when it comes to compression. SSH compression seems to have a very slight edge. However, I surmise that, given the number of knobs available on both sides (OpenSSH, in particular) one can tinker with settings almost endlessly in either side, probably being able to end up with

Thanks. Assuming that the IMAP mail directory for the account affected is under /home/xyz/mail, are you talking about the contents of the index directory, excluding the log file therein? On Wed, Nov 28, 2018 at 2:29 PM Thomas Durand <tom at rezoo.org> wrote: > Hi, > > I had the similar messages after an upgrade then downgrade. I was able to > fix by removing all indexes files.

Hi, I had the similar messages after an upgrade then downgrade. I was able to fix by removing all indexes files. Thomas > Le 28 nov. 2018 ? 22:02, JCA <1.41421 at gmail.com> a ?crit : > > This happening when my Thunderbird client is trying to establish a connection with a Dovecot server. Some background first: > > 1) I am running Thunderbird 6.20.1 from a Linux

When I do ssh -Q key, where ssh is the OpenSSH 7.4p1 client, I get the following output: ssh-ed25519 ssh-ed25519-cert-v01 at openssh.com ssh-rsa ssh-dss ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 ssh-rsa-cert-v01 at openssh.com ssh-dss-cert-v01 at openssh.com ecdsa-sha2-nistp256-cert-v01 at openssh.com ecdsa-sha2-nistp384-cert-v01 at openssh.com ecdsa-sha2-nistp521-cert-v01 at

Rsync supports the capability of compressing data before sending. So does OpenSSH. It would be probably be a waste of resources and time to enable both compression capabilities at the same time, but it is not clear to me whether, in general, it makes better sense to enable rsync compression or SSH compression. My first thought would be that SSH compression might yield better results, on the

This happening when my Thunderbird client is trying to establish a connection with a Dovecot server. Some background first: 1) I am running Thunderbird 6.20.1 from a Linux client. 2) Other clients (e.g. Maildroid in my Android phone) do not have any issues. 3) The Dovecot software is version 2.2.9, running in a Linux server. 4) This may be the root of the problem: at some point, the

I am using the OpenSSH client (version 5.2p1) in a Linux box L to interact with an embedded SSH server S. When carrying out a recursive transfer from S to L by means of the scp command issued in L (S does not support sftp) the client occasionally prints out a "lost connection" error message at the very end of the transfer. After some debugging I found out that the error message (as

What is the algorithm adopted by OpenSSH when it comes to deciding when to adjust the size of window? I would have thought that one'd better adjust the window size as soon as it has fallen below the maximum packet size. What worries me is a potential deadlock, in which one party does not send anything, because the window is too small for its next window space-consuming packet, while the other

In SSHv2, the data that consumes window space is that sent in the channel data and channel data extended messages. My question is, how is the data that consumes window space reckoned? One would have thought that it is the total length of the message itself, but the standard seems to imply that only the data contained in the data string field in the messages above is to be taken into account. That

Let's say, for concreteness, that I have a box A running an OpenSSH client, and a box B running an SSH server, which may or may not be OpenSSH. Looking in the OpenSSH code, I got the impression (this may be wrong; please let me know if it is) that on receiving a packet that consumes window space, A would check out whether or not its current window has to be adjusted. If it does then it

OpenSSH clients (in all releases I have been able to test with, including 4.7p1) when talking protocol version 2 seem to be sending SSH_MSG_CHANNEL_REQUEST messages with the want_reply field set to 0. This leads to a problem when the server they interact with does not support the service being requested. If the channel request is for, say, command execution, and the server does not support

I am trying to make sense of the way in which OpenSSH computes window size, so far without much success :-( My understanding is that when a client specifies a window size N at the beginning of a session, it is letting the server know that it (the server) can send, on a given channel, up to N bytes worth of data that consumes window space (essentially the payload of SSH_MSG_CHANNEL_DATA and one

A couple of weeks ago I made an inquiry on window computation details that has so far gone unanswered - unsurprisingly so, I now realize, for it was way too involved. Let me try again with a simplified version, in the hope that some nice OpenSSH developer could please provide an answer. What is the rationale underpinning the sending of a window adjust packet, as implemented in channels.c? Until

I am testing with a 5.4p1 client and have noticed, on the server side, that sometimes an SSH_MSG_DISCONNECT message is received with the following 28-byte long payload: 0x00 0x00 0x00 0x0b Reason: SSH_DISCONNECT_BY_APPLICATION 0x00 0x00 0x00 0x14 Description string length: 20 bytes 0x64 0x69 0x73 0x63 0x6f 0x6e 0x6e 0x65

I have noticed that OpenSSH clients (at least version 5.1p1) occasionally send an RSA signature during the handshake phase such that if the RSA key pair used to generate it happens to be associated to an N-byte long modulus, the signature is N - 1 bytes long. My question is, Is this behavior correct? I mean, an RSA signature is an unstructured byte string, and therefore any leading zeros should be

I understand that recent versions of OpenSSH have support for X.509 certificates, in the sense that OpenSSH clients can extract the relevant information from such certificates and use it in order to carry out the usual public key-based authentication. Having a quick look into the SSH RFCs, it would seem that this is the only way in which OpenSSH supports X.509-based authentication. That is, it

I have been using OpenSSH clients against a number of embedded SSH servers with no problem up till now. Starting with version 6.4p1 password authentication has stopped working against such servers. What happens is that the client enters an infinite loop during the authentication phase. I built OpenSSH 5.9p1 and 6.4p1 in a Linux box so that the client prints out to the screen all of the SSH