#187513 New version of mailsync doesn't work reliably

Package:
mailsync
Source:
mailsync
Description:
Synchronize IMAP mailboxes
Submitter:
Steve McIntyre
Date:
2021-09-22 04:29:53 UTC
Severity:
normal
#187513#5
Date:
2003-04-04 00:41:36 UTC
From:
To:
This is going to sound weird...

Summary: when I run mailsync from the command line, it works just fine
between my workstation and the mail server. If I run it from cron, it
doesn't.

The config I'm using:

==========================================================
store lump-inbox {
    server {lump/user=steve-mail/ssl/novalidate-cert}
    ref    {lump}
    pat    /var/spool/mail/steve
    passwd <password>
}

store local-inbox {
    pat    /var/spool/mail/steve
}

channel inbox local-inbox lump-inbox {
    msinfo .msinfo-inbox
}
==========================================================

Running from cron produces errors locally like:

[Trying IP address [10.13.0.1]]
Synchronizing stores "local-inbox" <-> "lump-inbox"...
Authorizing against {lump.mossbank.org.uk/imap}
 Store pattern doesn't match any selectable mailbox

and on the server end I see:

Apr  4 01:36:02 lump imapd[14177]: imaps SSL service init from 10.13.0.5
Apr  4 01:36:02 lump imapd[14177]: Authenticated user=steve-mail host=sledge.mossbank.org.uk [10.13.0.5]
Apr  4 01:36:02 lump imapd[14177]: Command stream end of file, while reading line user=steve-mail host=sledge.mossbank.org.uk [10.13.0.5]

If I run from the command line, it all works:

sledge:~$ mailsync inbox
Synchronizing stores "local-inbox" <-> "lump-inbox"...
Authorizing against {lump.mossbank.org.uk/imap}
/var/spool/mail/steve:
48 remain.
Mails expunged

and the server then sees:
Apr  4 01:38:40 lump imapd[14313]: imaps SSL service init from 10.13.0.5
Apr  4 01:38:40 lump imapd[14313]: Authenticated user=steve-mail host=sledge.mossbank.org.uk [10.13.0.5]
Apr  4 01:38:40 lump imapd[14313]: Logout user=steve-mail host=sledge.mossbank.org.uk [10.13.0.5]

If I downgrade to mailsync all works fine, both command line and
cron. Googling for the error message "Command stream end of file"
suggests that this might be an SSL issue of some sort.

Help!

#187513#10
Date:
2003-04-13 19:43:58 UTC
From:
To:
I've been trying to debug this further, and it's very puzzling. Still
using the same config as earlier. Running on the command line I see:

============================================================================================

sledge:~/debian/mailsync-5.1.0/src$ mailsync -v -d -dc inbox
 Parsing config...

        store
        lump-inbox
        {
        server
        {lump/user=steve-mail/ssl/novalidate-cert}
        ref
        {lump}
        pat
        /var/spool/mail/steve
        passwd
        ********
        }
        store
        local-inbox
        {
        pat
        /var/spool/mail/steve
        }
        channel
        inbox
        local-inbox
        lump-inbox
        {
        msinfo
        .msinfo-inbox
        }

 End parsing config. Config is OK

Synchronizing stores "local-inbox" <-> "lump-inbox"...
[Trying IP address [10.13.0.1]]
Authorizing against {lump.mossbank.org.uk/imap}
 Items in store "local-inbox":
  /var/spool/mail/steve, no inferiors, unmarked
 Delimiter for store "local-inbox" is '/'
Using driver unix for store local-inbox
 Items in store "lump-inbox":
  {lump.mossbank.org.uk:993/imap/ssl/novalidate-cert/readonly/user="steve-mail"}<no_mailbox>{lump}/var/spool/mail/steve, no inferiors, unmarked
Using driver imap for store lump-inbox
 Delimiter for store "lump-inbox" is '/'
 All seen mailboxes:
  in first store:
/var/spool/mail/steve   in second store:
/var/spool/mail/steve
 Reading lasttime of channel "inbox"
   Store local-inbox:
    /var/spool/mail/steve(28)

   Store lump-inbox:
    /var/spool/mail/steve(28)

/var/spool/mail/steve:  Fetching message id's in mailbox
"/var/spool/mail/steve"
[Reusing connection to lump.mossbank.org.uk/user="steve-mail"]
[[UNSEEN 28] first unseen message in /var/spool/mail/steve]
 Fetching message id's in mailbox
 "{lump.mossbank.org.uk:993/imap/ssl/novalidate-cert/user="steve-mail"}/var/spool/mail/steve"
 Removing messages from store "local-inbox"
 Removing messages from store "lump-inbox"
 Copying messages from store "local-inbox" to store "lump-inbox"
[Reusing connection to lump.mossbank.org.uk/user="steve-mail"]
[[UNSEEN 28] first unseen message in /var/spool/mail/steve]
 Copying messages from store "lump-inbox" to store "local-inbox"
[No messages deleted, so no update needed]

28 remain.
[No messages deleted, so no update needed]
[No messages deleted, so no update needed]
Mails expunged
[lump.mossbank.org.uk IMAP4rev1 server terminating connection]
[Expunged 1 messages]

============================================================================================

But when I run from cron using "mailsync -v -d -dc inbox":

[Trying IP address [10.13.0.1]]
 Parsing config...

        store
        lump-inbox
        {
        server
        {lump/user=steve-mail/ssl/novalidate-cert}
        ref
        {lump}
        pat
        /var/spool/mail/steve
        passwd
        ********
        }
        store
        local-inbox
        {
        pat
        /var/spool/mail/steve
        }
        channel
        inbox
        local-inbox
        lump-inbox
        {
        msinfo
        .msinfo-inbox
        }

 End parsing config. Config is OK

Synchronizing stores "local-inbox" <-> "lump-inbox"...
Authorizing against {lump.mossbank.org.uk/imap}
 Items in store "local-inbox":
 Store pattern doesn't match any selectable mailbox

============================================================================================

This exact configuration works fine with the version of mailsync in
woody. Has there been a change in the config format for the c-client
code or something? The error message doesn't really help...

It's _really_ confusing that things behave differently in cron and out
of cron...

#187513#15
Date:
2003-04-13 23:24:02 UTC
From:
To:
Hmmm. I'm still working on tracking this down. What I'm seeing makes
no sense. I've added debug into main() and Store::acquire_mail_list()
so I can track the program running. Normally from the command line I
now get:

sledge:~/debian/mailsync-5.1.0/src$ ./mailsync -d inbox
Startup
read_commandline_options
setup_channel_stores_and_mode
Synchronizing stores "local-inbox" <-> "lump-inbox"...
 Store A: "local-inbox":
 Store B: "lump-inbox":
Authorizing against {lump.mossbank.org.uk/imap}
 Items in store "local-inbox":
  /var/spool/mail/steve, no inferiors, marked
acquire_mail_list: found 1 mailboxes

but from cron I get:

acquire_mail_list: found 0 mailboxes
Startup
read_commandline_options
setup_channel_stores_and_mode
Synchronizing stores "local-inbox" <-> "lump-inbox"...
 Store A: "local-inbox":
 Store B: "lump-inbox":
Authorizing against {lump.mossbank.org.uk/imap}
 Items in store "local-inbox":
 Store pattern doesn't match any selectable mailbox

How on earth can acquire_mail_list() be called before any of the
command line and config file handling routines? This is really
weird...

#187513#20
Date:
2003-05-05 00:41:03 UTC
From:
To:
that she worked around it specifying /bin/csh as SHELL in the crontab.
And sure enough, mailsync is now happily syncing my emails ...

I thought that this may help to track down the problem.

Btw I use bash and dash and both had problems.

graziano

#187513#25
Date:
2003-05-18 06:07:57 UTC
From:
To:
3) libc-client. You told me that a previous version of mailsync
was working. Could you make a "ldd mailsync-old-version" see against
which libraries it is linked and rebuild the new mailsync against the
old libraries and see whether the same error occurs? It might be that
the "error" was introduced in a newer libc-client or in a new openssl.
Knowing this would help debugging the problem.
*t
-----------------------------------------------------------------------
     Tomas Pospisek
     sourcepole    -   Linux & Open Source Solutions
http://sourcepole.com
     Elestastrasse 18,  7310 Bad Ragaz,  Switzerland
     Tel:+41 (81) 330 77 13,  Fax:+41 (81) 330 77 12
------------------------------------------------------------------------

#187513#30
Date:
2003-05-19 16:42:32 UTC
From:
To:
I've been using the debian package for quite a bit, so the current
version is 5.1.1-2 and the ldd reads
libc-client.so.2003debian => /usr/lib/libc-client.so.2003debian (0x4001d000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x400d4000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x400e5000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x4013a000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0x4014b000)
libssl.so.0.9.7 => /usr/lib/i686/cmov/libssl.so.0.9.7 (0x4014e000)
libcrypto.so.0.9.7 => /usr/lib/i686/cmov/libcrypto.so.0.9.7 (0x4017d000)
libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x4026f000)
libm.so.6 => /lib/libm.so.6 (0x402b8000)
libc.so.6 => /lib/libc.so.6 (0x402d9000)
libpam.so.0 => /lib/libpam.so.0 (0x403e9000)
libdl.so.2 => /lib/libdl.so.2 (0x403f1000)
libresolv.so.2 => /lib/libresolv.so.2 (0x403f4000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

I don't remember what the older version but was the previous debian
version. Let me know if you need more informations.

graziano

#187513#35
Date:
2003-05-20 09:49:24 UTC
From:
To:
I can do that too, that's not a problem. The question is _who_ is
responsible for the behaveour: mailsync, libc-client or openssl. This
could be found out by compiling the new mailsync with:

* new c-client, new openssl
* old c-client, new openssl
* new c-client, old openssl
* old c-client, old openssl

and seeing which combination displays the faulty behaveour. Supposed that
my hypothesis is correct  one should be able to determine which component
is responsible for the behaveour.

It'd be nice if one of you could try that out.
*t

#187513#40
Date:
2003-05-20 10:01:02 UTC
From:
To:
I'll have a look when I get a chance, but it may take a few days. I've
moved over to using offlineimap instead recently...

#187513#45
Date:
2007-02-11 05:44:35 UTC
From:
To:
I saw that "mailsync doesn't work from cron" problem under Ubuntu
6.06, using mailsync 5.2.1-2build1; given that unstable has 5.2.2 and
it (and libc-client) has the exact same lines of code, the analysis
below applies there too...

Given a .mailsyncrc including

channel slurp imapmail localfile {
        msinfo  mailsync-mail.msinfo
}

(imapmail and localfile left out as irrelevant)

I put "strace mailsync -n slurp" in cron, and saw this:

21438 open("/var/mail/anonymous/mailsync-mail/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOENT (No such file or directory)
21438 open("/var/mail/anonymous", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOENT (No such file or directory)

"That's not right" :-)  Turns out that the execve line shows that cron
has a very limited environment - the only settings are

    SHELL, PATH, PWD, LANG, SHLVL, HOME, LANGUAGE, LOGNAME, and _

Note that this *doesn't* include USER; I can trigger the problem
directly by doing

   (unset USER; mailsync -n slurp)

Synchronizing stores "imapmail" <-> "localfile"...
Authorizing against {..../imap}
Error: Can't open mailbox mailsync-mail.msinfo: no such mailbox
Error: Couldn't open msinfo box mailsync-mail.msinfo.
       Aborting!

Adding an explicit USER=eichin to the crontab *worked*, so is a
plausible workaround.

Looking at the code...

mailsync-5.2.1/src/mailsync_main.cc line 93 (in main):
  // initialize c-client environment (~/.imparc etc.)
  env_init( getenv("USER"), getenv("HOME"));

uw-imap-2002edebian1/src/osdep/unix/env_unix.c line 656 (in env_init):
  /* myUserName must be set before dorc() call */
  myUserName = cpystr (user ? user : ANONYMOUSUSER);

Also, the comment describing env_init says:
 * Accepts: user name (NIL for anonymous)

I'd suggest that perhaps instead of getenv("USER") perhaps
getpwuid(geteuid()) is appropriate... or even something like
  getenv("USER") || getpwuid(geteuid())->pw_name
to allow the user to set $USER and fall back to getpwuid, rather than
doing the unintentional anonymous path.  The UW docs do talk about
customizing env_init, as an alternative:

http://www.washington.edu/imap/documentation/CONFIG.html

but it looks like that should be site-specific, not application
specific, and just passing something different to env_init is a better
fix.

			_Mark_ <eichin@thok.org>
			The Herd Of Kittens

#187513#50
Date:
2021-09-22 04:13:21 UTC
From:
To:
Hello,

Good morning,

We have gone through your samples from a partner and Here is our  Order
List. Please do bear in mind that we are very much in  need of this
order, quote your competitive prices.

Kindly send the Order confirmation.

Your early reply will be much appreciated.

Best Regards,

Maryanah Erwin.

PT FINDORA INTERNUSA

Jln Pahlawan 66 Kec. Arjawinangun

45162 CIREBON West-Java INDONESIA

tel : +62 231 357334

fax: +62 231 357260

email: marketing@findora.com