Cyrus IMAP 3.0.7 released

2018-05-17 Thread ellie timoney
The Cyrus team is proud to announce the immediate availability of a new version 
of Cyrus IMAP: 3.0.7

This release fixes an infinite-loop issue that was introduced in 3.0.6 
(https://github.com/cyrusimap/cyrus-imapd/issues/2350).  We recommend all 3.0.6 
users upgrade to 3.0.7 at their first convenience.

Download URLs:

https://www.cyrusimap.org/releases/cyrus-imapd-3.0.7.tar.gz
https://www.cyrusimap.org/releases/cyrus-imapd-3.0.7.tar.gz.sig

ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-3.0.7.tar.gz
ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-3.0.7.tar.gz.sig

Please consult the release notes and upgrade documentation before upgrading to 
3.0.7:

https://www.cyrusimap.org/imap/download/release-notes/3.0/x/3.0.7.html
https://www.cyrusimap.org/imap/download/upgrade.html

And join us on Github at https://github.com/cyrusimap/cyrus-imapd to report 
issues, join in the deliberations of new features for the next Cyrus IMAP 
release, and to contribute to the documentation.

On behalf of the Cyrus team,

Kind regards,

ellie timoney

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus


Re: sync_client crash with sieve

2018-05-17 Thread Bron Gondwana
It sounds like the sieve file might be incorrect in some way?  Either it
doesn't parse with the current version of sievec, or it's got the wrong
permissions, or even the wrong naming.  On our servers we have:
websieve.script
websievebc
defaultbc -> websievebc

As managed by having timsieved save a script called "webscript".

If you have sieve scripts which aren't correctly laid out to how Cyrus
expects, that could maybe cause sync to abort because it doesn't know
how to replicate that layout.
Bron.


On Fri, May 18, 2018, at 01:57, Albert Shih wrote:
> Hi,
> 
> I've got some issue with sync_client (first run, before rolling sync).> 
> When I launch
> 
>   sync_client -A
> 
> the synchronization start and after some time crash. I activate
> the verbose> mode, and It seem sync_client crash over some sieve file.
> 
> So I not sure, but I pretty sure, everytime I got a sieve file for
> the user> (in /var/imap/sieve) the sync crash.
> 
> Any idea ?
> 
> Regards
> --
> Albert SHIH
> DIO bâtiment 15
> Observatoire de Paris
> xmpp: j...@obspm.fr
> Heure local/Local time:
> Thu May 17 17:51:04 CEST 2018
> 
> Cyrus Home Page: http://www.cyrusimap.org/
> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/> To 
> Unsubscribe:
> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  br...@fastmailteam.com



Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: Xapian/Cyrus/Thunderbird

2018-05-17 Thread Albert Shih
Le 14/05/2018 à 14:35:21+0200, Sebastian Hagedorn a écrit
> > On Fri, May 11, 2018, at 14:25, Sebastian Hagedorn wrote:
> >> --On 11. Mai 2018 um 13:32:29 +0200 Robert Stepanek
> >>   wrote:
> >> > For non-FUZZY text SEARCH, Cyrus attempts to match the string on its
> >> > own [1].
> >>
> >> That sounds strange to me, because Cyrus 2.4 and earlier don't support
> >> FUZZY, and there the SQUAT index was used, if present. Only messages
> >> that  were added after the last squatter run were searched directly. Why
> >> would  that have changed?
> >
> > Right, it hasn't. SQUAT is still the backend for non-FUZZY text search.
>
> But search_engine is either squat or xapian. That would mean that one would
> have to run squatter with two separate configurations in order to cover
> both search types. That's at the very least counterintuitive ...

Sorry to ask some stupid question, but in the case I choose xapian with
only one configuration, does that mean the search is ... what neither SQUAT or
XAPIAN if the client don't use FUZZY SEARCH ?

>
> I thought Xapian was added to improve all IMAP BODY searches, but I guess
> the only reason was to enable IMAP FUZZY searches. In my opinion this needs
> to be stated explicitly in the documentation, if that's the way it will be

agree;-)

Regards.

--
Albert SHIH
DIO bâtiment 15
Observatoire de Paris
xmpp: j...@obspm.fr
Heure local/Local time:
Thu May 17 22:11:13 CEST 2018

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus


Re: Moving from cIMAP-2.3.16 to 3.0.5

2018-05-17 Thread Savvas Karagiannidis
Hi James,
Users' subscription files are normally saved in /var/imap/user in
directories based on the user's initial. Search for username.sub files in
there. Seen status used to be in there too in username.seen files but that
changed in more recent versions, where seen status information is stored
inside the cyrus.index file for each mailbox.

For the users' subscription information just copy the .sub files in the
same directory structure.
For the seen status information try copying the .seen files too. Migrating
that information used to be an automatic procedure in version 2.4, the
first time the user logged in but not sure if it still applies to 3.x..

Regards,
Savvas Karagiannidis


On Thu, May 17, 2018, 22:25 James B. Byrne via Info-cyrus <
info-cyrus@lists.andrew.cmu.edu> wrote:

> I have managed to move the 2.3.16 mailstore and mailboxes.db to the
> 3.0.5 host and reconstructed the mailboxes using  'reconstruct -f -r
> -G -V max user/*'  Connections between squirrelmail and the new
> service appear to be working fine.  However, I have a couple of
> glitches and I would like to know if there is anything I can do to
> eliminate them before thae actual switchover, scheduled for this
> Saturday.
>
> 1.  All of the use folders are unsubscribed following the reconstruct.
>
> 2.  All of the messages show as unread following the reconstruct.
>
> Is there any way to avoid these consequences of transfer and reconstruct?
>
> --
> ***  e-Mail is NOT a SECURE channel  ***
> Do NOT transmit sensitive data via e-Mail
>  Do NOT open attachments nor follow links sent by e-Mail
>
> James B. Byrnemailto:byrn...@harte-lyne.ca
> Harte & Lyne Limited  http://www.harte-lyne.ca
> 9 Brockley Drive
> 
>   vox: +1 905 561 1241
> Hamilton, Ontario fax: +1 905 561 0757
> Canada  L8E 3C3
>
> 
> Cyrus Home Page: http://www.cyrusimap.org/
> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
> To Unsubscribe:
> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
>

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: Moving from cIMAP-2.3.16 to 3.0.5

2018-05-17 Thread James B. Byrne via Info-cyrus
I have managed to move the 2.3.16 mailstore and mailboxes.db to the
3.0.5 host and reconstructed the mailboxes using  'reconstruct -f -r
-G -V max user/*'  Connections between squirrelmail and the new
service appear to be working fine.  However, I have a couple of
glitches and I would like to know if there is anything I can do to
eliminate them before thae actual switchover, scheduled for this
Saturday.

1.  All of the use folders are unsubscribed following the reconstruct.

2.  All of the messages show as unread following the reconstruct.

Is there any way to avoid these consequences of transfer and reconstruct?

-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3


Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus


sync_client crash with sieve

2018-05-17 Thread Albert Shih
Hi,

I've got some issue with sync_client (first run, before rolling sync).

When I launch

  sync_client -A

the synchronization start and after some time crash. I activate the verbose
mode, and It seem sync_client crash over some sieve file.

So I not sure, but I pretty sure, everytime I got a sieve file for the user
(in /var/imap/sieve) the sync crash.

Any idea ?

Regards
--
Albert SHIH
DIO bâtiment 15
Observatoire de Paris
xmpp: j...@obspm.fr
Heure local/Local time:
Thu May 17 17:51:04 CEST 2018

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus