On Mon, Jun 10, 2024 at 09:45:37AM +0200, Henrik Frisk wrote:
So sorry this dragged out.
well, _i_ am in no hurry ...
I would be so happy if you have the time to take
a look at these files attached which are the logs from mbsync and
DavMail.
somewhat guessing here, but this seems to be a ge
On Thu, May 16, 2024 at 12:18:36PM +0200, Henrik Frisk wrote:
Despite my best efforts, trying the things suggested here and a bunch
of
other stuff to do with the configuration of davmail and mbsync I can't get
this to work. I guess my main question to this list is if this is a davmail
problem or
Den tis 16 apr. 2024 kl 21:13 skrev Henrik Frisk :
>
>
> Den mån 15 apr. 2024 kl 12:19 skrev Bence Ferdinandy >:
>
>>
>> On Sun Apr 14, 2024 at 12:08, Henrik Frisk wrote:
>> >
>> > Hi, posted this a couple of weeks abo and received a sugesstion from
>> Bence
>> > to remove the PassCmd which I r
Den mån 15 apr. 2024 kl 12:19 skrev Bence Ferdinandy :
>
> On Sun Apr 14, 2024 at 12:08, Henrik Frisk wrote:
> >
> > Hi, posted this a couple of weeks abo and received a sugesstion from
> Bence
> > to remove the PassCmd which I replaced with Pass "". This didn't resolve
> > the issue however, th
On Sun Apr 14, 2024 at 12:08, Henrik Frisk wrote:
>
> Hi, posted this a couple of weeks abo and received a sugesstion from Bence
> to remove the PassCmd which I replaced with Pass "". This didn't resolve
> the issue however, that I get socket errors. The basic connection through
> Davmail works
Den mån 1 apr. 2024 kl 19:26 skrev Bence Ferdinandy :
> Hey,
>
> 2024. ápr. 1. 18:55:44 Henrik Frisk :
>
> > Hi,
> >
> > I just changed my setup using davmail for syncing and sending my work
> > email
> > which just changed to 2F authentication. Sending works fine but I can'
> > seem
> > to get mb
Den mån 1 apr. 2024 kl 18:54 skrev Henrik Frisk :
> Hi,
>
> I just changed my setup using davmail for syncing and sending my work
> email which just changed to 2F authentication. Sending works fine but I
> can' seem to get mbsynch to want to sync:
>
> This is the error I'm getting:
>
> Socket erro
Hey,
2024. ápr. 1. 18:55:44 Henrik Frisk :
Hi,
I just changed my setup using davmail for syncing and sending my work
email
which just changed to 2F authentication. Sending works fine but I can'
seem
to get mbsynch to want to sync:
This is the error I'm getting:
Socket error on 127.0.0.1 (
Result of bisect:
859b7dd7f2dc5d8396488700e0ab35d207188ed9 is the first bad commit
commit 859b7dd7f2dc5d8396488700e0ab35d207188ed9
Author: Oswald Buddenhagen
Date: Thu Jun 9 13:32:16 2022 +0200
try to avoid extra syscalls when reading sockets
so far we shifted down the buffered data o
On Wed Jan 10, 2024 at 12:22, Oswald Buddenhagen via isync-devel
wrote:
> this doesn't look like a data incompatibility, so clearing won't do
> anything useful.
> try running with -D to see whether it's doing something obviously
> stupid. the next level would be strace'ing it.
> anyway, my firs
On Wed, Jan 10, 2024 at 09:59:07AM +0100, Bence Ferdinandy wrote:
On Thu Aug 17, 2023 at 14:45, Oswald Buddenhagen
wrote:
On Thu, Aug 17, 2023 at 07:59:09AM -0400, brittanderson--- via isync-devel
wrote:
>The error has reoccured. It is:
>
>Socket error: receive buffer full. Probably protocol
Hi all,
On Thu Aug 17, 2023 at 14:45, Oswald Buddenhagen
wrote:
> On Thu, Aug 17, 2023 at 07:59:09AM -0400, brittanderson--- via isync-devel
> wrote:
> >The error has reoccured. It is:
> >
> >Socket error: receive buffer full. Probably protocol error.
I also ran into this error with davmail.
On Fri, Aug 18, 2023 at 08:37:52AM -0400, brittanderson--- via isync-devel
wrote:
Thank you for the follow-up. I just had another message that provoked
this error. This one from protonmail, so it is not a microsoft exchange
specific issues, and I do not use davmail for the protonmail account.
Thank you for the follow-up. I just had another message that provoked
this error. This one from protonmail, so it is not a microsoft exchange
specific issues, and I do not use davmail for the protonmail account.
I did notice that this email had 12 (twelve) embedded images. Perhaps
this is somehow
On Thu, Aug 17, 2023 at 07:59:09AM -0400, brittanderson--- via isync-devel
wrote:
The error has reoccured. It is:
Socket error: receive buffer full. Probably protocol error.
hmm, this might in fact be one of the two regressions that prevent me
from releasing 1.5.0 - i honestly don't remember,
The error has reoccured. It is:
Socket error: receive buffer full. Probably protocol error.
running =mbsync -D university=
Gives an output that includes this snippet:
#+Begin_quote
N: Called get_uidnext, ret=1273
-> log: F 1 1273 (save UIDNEXT of near side)
-> log: # 192877 0 yMXnDcoTZKtm (new
On Tue, Aug 15, 2023 at 02:31:11PM -0400, brittanderson--- via isync-devel
wrote:
Oswald Buddenhagen writes:
the two sides have different uids. the ones appearing in the imap
stream don't match the local mailboxes. the complete output contains
the local (or more precisely, near-side) uids as w
Oswald Buddenhagen writes:
> which "fetch" issue in particular are you referring to?
IMAP error: bogus FETCH response
This is mentioned in several mails on the list, and I believe there is
one that says you have a fix in master, but were waiting to release
because of two regressions.
When I
On Tue, Aug 15, 2023 at 10:47:12AM -0400, Britt Anderson via isync-devel wrote:
Because of the "fetch" issue I upgraded from 1.4.4 to master,
which "fetch" issue in particular are you referring to?
which was been running well when I got a non-zero exit code because of
socket error with a stat
On 2022-07-03 at 00:42 -07, Oswald Buddenhagen
wrote:
> On Sat, Jul 02, 2022 at 06:57:41AM -0700, Ken Mankoff wrote:
>>Socket error: secure connect to imap.gmail.com (74.125.20.109:993):
>>error:0ABF:SSL routines::no protocols available
>>
> i suppose you have SSLVersions set and didn't adj
On Sat, Jul 02, 2022 at 06:57:41AM -0700, Ken Mankoff wrote:
Socket error: secure connect to imap.gmail.com (74.125.20.109:993):
error:0ABF:SSL routines::no protocols available
i suppose you have SSLVersions set and didn't adjust it to include
anything recent.
git master contains a concept
On Tue, Mar 23, 2021 at 03:48:58PM +0100, Oswald Buddenhagen wrote:
> On Mon, Mar 22, 2021 at 11:19:24PM +0100, Joel Granados wrote:
> > On Thu, Mar 18, 2021 at 11:03:00PM +0100, Oswald Buddenhagen wrote:
> > > On Thu, Mar 18, 2021 at 09:09:53PM +0100, Joel Granados wrote:
> > > > I indeed went ba
On Mon, Mar 22, 2021 at 11:19:24PM +0100, Joel Granados wrote:
On Thu, Mar 18, 2021 at 11:03:00PM +0100, Oswald Buddenhagen wrote:
On Thu, Mar 18, 2021 at 09:09:53PM +0100, Joel Granados wrote:
> I indeed went back to my original comment and restarted from there. I
> notcied that there is a link
Hello
On Thu, Mar 18, 2021 at 11:03:00PM +0100, Oswald Buddenhagen wrote:
> On Thu, Mar 18, 2021 at 09:09:53PM +0100, Joel Granados wrote:
> > I indeed went back to my original comment and restarted from there. I
> > notcied that there is a link that is created when openssl is installed
> > in de
On Thu, Mar 18, 2021 at 09:09:53PM +0100, Joel Granados wrote:
I indeed went back to my original comment and restarted from there. I
notcied that there is a link that is created when openssl is installed
in debian bullseye /lib/ssl/openssl.cnf -> /etc/ssl/openssl.cnf.
fwiw, it's /usr/lib/ssl/op
I indeed went back to my original comment and restarted from there. I
notcied that there is a link that is created when openssl is installed
in debian bullseye /lib/ssl/openssl.cnf -> /etc/ssl/openssl.cnf.
If I change the name of this link, mbsync (the one installed by debian)
works again.
I'm not
On Fri, Mar 12, 2021 at 09:29:06AM +0100, Joel Granados wrote:
The systems are actually quite different (I forgot to mention it).
well, that kind of defeats the configuration difference based approach.
but that working second system seems to be a side track anyway. you
started out with this:
On Fri, Mar 12, 2021 at 09:29:06AM +0100, Joel Granados wrote:
> This is good to know (not to focus too much on the resolv thing). The
> systems are actually quite different (I forgot to mention it).
Try a fresh Debian installation (container, hosting, etc).
It can confirm mbsync works fine on D
On Thu, Mar 11, 2021 at 03:23:59PM +0100, Oswald Buddenhagen wrote:
> On Thu, Mar 11, 2021 at 02:11:53PM +0100, Joel Granados wrote:
> > /lib -> usr/lib
> > /lib32 -> usr/lib32
> > /lib64 -> usr/lib64
> > /libx32 -> usr/libx32
> > /usr/lib
> > /usr/lib32
> > /usr/lib64
> > /usr/libx32
> >
> ok, th
On Thu, Mar 11, 2021 at 02:11:53PM +0100, Joel Granados wrote:
/lib -> usr/lib
/lib32 -> usr/lib32
/lib64 -> usr/lib64
/libx32 -> usr/libx32
/usr/lib
/usr/lib32
/usr/lib64
/usr/libx32
ok, the system simply aliases /lib* to /usr/lib* (i think that's the new
debian policy), so the "duplicate" fil
On Mon, Mar 08, 2021 at 11:22:31PM +0100, Oswald Buddenhagen wrote:
> On Mon, Mar 08, 2021 at 09:30:07PM +0100, Joel Granados wrote:
> > Clearly there are several links for the libraries on the box that does
> > not work,
> >
> yeah, that seems like a likely problem source.
>
> > question is. How
On Mon, Mar 08, 2021 at 09:30:07PM +0100, Joel Granados wrote:
Clearly there are several links for the libraries on the box that does
not work,
yeah, that seems like a likely problem source.
question is. How can I work around this without fiddling around with my
systems configuration?
that
Hello Oswald
Thx for the response and sorry for taking so long to get back.
On Fri, Feb 05, 2021 at 10:44:12PM +0100, Oswald Buddenhagen wrote:
> On Fri, Feb 05, 2021 at 10:03:46PM +0100, Joel Granados wrote:
> > Any ideas?
> >
> not really. check with ldd what mbsync is linking in both cases.
>
On Fri, Feb 05, 2021 at 10:03:46PM +0100, Joel Granados wrote:
Any ideas?
not really. check with ldd what mbsync is linking in both cases.
ls -l these libraries; i wouldn't be surprised if symlinks are involved.
you could use ltrace to see if there is a difference (also strace, but
that's a lo
On Tue, Feb 11, 2020 at 02:49:40PM +, fwoodh...@doctors.org.uk wrote:
I would be very grateful for any pointers.
use the 1.3 branch from git, that should give you clearer ssl errors.
anyway, the output from openssl suggests that the tunnel is botched.
maybe you forwarded to somewhere els
On Thu, Aug 01, 2019 at 06:12:28PM +0530, Pankaj Jangid wrote:
> Is this of any use? ->
>
it doesn't tell us anything except that no reply came when one was
expected.
that's why i suggested strace - then you'll see whether there is
*actually* no reply, or mbsync just doesn't see it due to some bu
On Thu, Aug 01, 2019 at 01:56:51AM +0530, Pankaj Jangid wrote:
> On Wed, Jul 31, 2019 at 09:26:46PM +0200, Oswald Buddenhagen wrote:
> > there is nothing wrong in that log - the error is within the message
> > from the cron job. you're being recursive. ^^
> >
> Oh! yes. I sent the wrong logs. But
On Wed, Jul 31, 2019 at 09:26:46PM +0200, Oswald Buddenhagen wrote:
> there is nothing wrong in that log - the error is within the message
> from the cron job. you're being recursive. ^^
>
Oh! yes. I sent the wrong logs. But I am continuously getting errors
in the cron mail. Let me check for more
On Wed, Jul 31, 2019 at 11:01:10PM +0530, Pankaj Jangid wrote:
> Is this because of the MaxMessage limit in my configuration file?
>
that would be *really* weird. as in, i don't think so.
> >>> 9 UID FETCH 11410 (BODY.PEEK[])
> * 8492 FETCH (UID 11410 BODY[] {1185}
> =
> [stuff here]
> Su
On Wed, Jul 31, 2019 at 05:00:19PM +0530, Pankaj Jangid wrote:
> I'll post in this thread again, with diagnostics using '-DN', if the
> problem re-occurs.
>
Again got the error. Attached file has the relevant part of log
messages. I have used '-DN' option. Is this because of the MaxMessage
limit i
On Wed, Jul 31, 2019 at 01:06:13PM +0200, Oswald Buddenhagen wrote:
> On Wed, Jul 31, 2019 at 03:36:16PM +0530, Pankaj Jangid wrote:
> > Socket error on imap.gmail.com (74.125.24.108:993): timeout.
> >
> that might be a case for strace.
> you may also try mbsync's -Dn (and -DN) options.
> it would
On Wed, Jul 31, 2019 at 03:36:16PM +0530, Pankaj Jangid wrote:
> Socket error on imap.gmail.com (74.125.24.108:993): timeout.
>
that might be a case for strace.
you may also try mbsync's -Dn (and -DN) options.
it would also be possible to use Tunnel with openssl s_client -quiet
-connect to bypass
42 matches
Mail list logo
