Re: IDN

2017-05-12 Thread Per Olof Ljungmark 
Thank you for your reply - I meant exactly what I wrote - is it up to the 
delivery agent only (Postfix/lmpt in our  case) to decide whether to accept a 
sender with 8bit characters in the address and if it does will cyrus digest it. 
Thanks /per

On 12 May 2017 21:45:07 GMT+02:00, "Niels Dettenbach (Syndicat.com)" 
 wrote:
>> 
>> Am 12.05.2017 um 19:39 schrieb Per olof Ljungmark
>:
>> 
>> Does Cyrus Imap support IDN (International Domain Names) as sender
>address or is it just the delivery agent that takes care of this?
>Not sure, what you mean in detail.
>
>We successfully receive mail from IDN domain senders over EXIM / Cyrus,
>while it is typically not a good idea to have any IDN domain in an
>email address (lack of "standardization" / compatibility). But I’m not
>sure how reliable this works.
>
>> Like, for instance, über or gösta.
>> 
>> Then of course is the question if there is support for 8bit mailbox
>names as well.
>For that what i have seen - not really.
>
>In the past we recommended our users to avoid using i.e. german Umlauts
>within folder names, even if they seems to get „converted“ by cyrus in
>a working or even proper manner - there will be problems with several
>IMAP clients not liking this, which still have problems with that on
>their side…
>
>
>
>hth a bit
>cheerioh,
>
>
>Niels Dettenbach

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: IDN

2017-05-12 Thread Niels Dettenbach (Syndicat.com) via Info-cyrus 
> 
> Am 12.05.2017 um 19:39 schrieb Per olof Ljungmark :
> 
> Does Cyrus Imap support IDN (International Domain Names) as sender address or 
> is it just the delivery agent that takes care of this?
Not sure, what you mean in detail.

We successfully receive mail from IDN domain senders over EXIM / Cyrus, while 
it is typically not a good idea to have any IDN domain in an email address 
(lack of "standardization" / compatibility). But I’m not sure how reliable this 
works.

> Like, for instance, über or gösta.
> 
> Then of course is the question if there is support for 8bit mailbox names as 
> well.
For that what i have seen - not really.

In the past we recommended our users to avoid using i.e. german Umlauts within 
folder names, even if they seems to get „converted“ by cyrus in a working or 
even proper manner - there will be problems with several IMAP clients not 
liking this, which still have problems with that on their side…



hth a bit
cheerioh,


Niels Dettenbach


signature.asc
Description: Message signed with OpenPGP

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

IDN

2017-05-12 Thread Per olof Ljungmark 

Hi,

Simple question:

Does Cyrus Imap support IDN (International Domain Names) as sender 
address or is it just the delivery agent that takes care of this?


Like, for instance, über or gösta.

Then of course is the question if there is support for 8bit mailbox 
names as well.


Thanks,

//per


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 problems

2017-05-12 Thread Eric Cunningham 

Yes, file 148 is completely corrupted.


On 5/12/17 9:16 AM, Bron Gondwana wrote:

Just read the 148 file and see if there is corruption.  I suspect that's the 
cause.

Bron

On Fri, 12 May 2017, at 23:09, Eric Cunningham wrote:

I have snapshot backups of that account, that particular message and the
various cyrus db files.  What can I provide for review?


On 5/11/17 7:38 PM, Bron Gondwana wrote:

It looked like the '148.' file was corrupted in some way.  I assume you've 
deleted all the evidence now, so we can't see how!  Oh well :(

Bron.

On Fri, 12 May 2017, at 04:55, Eric Cunningham wrote:

Just to close the loop on this, once the corrupted cdm-lit account on my
copy server successfully reconstructed, the backlog of replication has
completed successfully and is now caught up.

-Eric

On 05/11/2017 02:20 PM, Eric Cunningham wrote:

-G didn't seem to help, but I tried a "reconstruct -f -r" command
without having previously deleted all occurrences of the cyrus.* files
and it was then successful.



On 05/11/2017 01:44 PM, Patrick Boutilier wrote:

Try a -G with reconstruct?

-G Force  re-parsing  of the underlying message (checks GUID
correctness).  Reconstruct with -G should fix all possible individual
message issues, including corrupted data files.


On 05/11/2017 02:37 PM, Eric Cunningham wrote:

I have to walk this back.  In looking slightly further back in my
logfiles, before every instance of a failure to sync some folder, I
see a common error reported prior to every "bailing out! Bad
protocol" error - "IOERROR: GUID mismatch
/var/spool/cyrus/mail/c/user/cdm-lit/Sent/148."

May 11 12:44:09 imap1 sync_client[48590]: IOERROR: GUID mismatch
/var/spool/cyrus/mail/c/user/cdm-lit/Sent/148.
May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
response to MAILBOX (end of file reached)
May 11 12:44:22 imap1 sync_client[48590]: do_folders(): update
failed: user.cdm-lit.Sent 'Bad protocol'
May 11 12:44:22 imap1 sync_client[48590]: sync_mailboxes: doing 1000
May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
response to MAILBOXES (end of file reached)
May 11 12:44:22 imap1 sync_client[48590]: sync_mailboxes: doing 1000
May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
response to MAILBOXES (end of file reached)
May 11 12:44:22 imap1 sync_client[48590]: sync_mailboxes: doing 1000
May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
response to MAILBOXES (end of file reached)
May 11 12:44:22 imap1 sync_client[48590]: sync_mailboxes: doing 1000
May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
response to MAILBOXES (end of file reached)
May 11 12:44:22 imap1 sync_client[48590]: sync_mailboxes: doing 1000
May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
response to MAILBOXES (end of file reached)
May 11 12:44:22 imap1 sync_client[48590]: sync_mailboxes: doing 1000
May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
response to MAILBOXES (end of file reached)
May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
response to MAILBOXES (end of file reached)
May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
response to UNMAILBOX (end of file reached)
May 11 12:44:22 imap1 sync_client[48590]: folder_delete(): failed:
user.guest-student-coordinator.Trash.Aarflot 'Bad protocol'
May 11 12:44:22 imap1 sync_client[48590]: Error in do_sync(): bailing
out! Bad protocol
May 11 12:44:22 imap1 sync_client[48590]: Processing sync log file
/var/spool/CyrusDB-Sieve/cyrusdb/sync/log-run failed: Bad protocol

When I recontructed this cdm-lit account, it ran successfully on my
master host, but fails on my copy host:

[cyrus@imap2 ~]$ reconstruct -f -r user.cdm-lit
user.cdm-lit
user.cdm-lit.Sea Trail 2013
user.cdm-lit.Sent uid 1 found - adding
user.cdm-lit.Sent uid 2 found - adding
user.cdm-lit.Sent uid 3 found - adding
user.cdm-lit.Sent uid 4 found - adding

user.cdm-lit.Sent uid 146 found - adding
user.cdm-lit.Sent uid 147 found - adding
user.cdm-lit.Sent uid 148 found - adding
fatal error: Internal error: assertion failed: imap/mailbox.c: 2847:
record->size

Since I couldn't get a successful reconstruct on this account, I
deleted it and recreated it from my master host.  However, I'm still
unable to get a successful reconstruct with "failed to read index
header" for every subfolder and "fatal error: Internal error:
assertion failed: imap/mailbox.c: 2847: record->size"

Any ideas on how to correct this so I can see if I can then get past
the replication error?

Thanks!

-Eric


On 05/11/2017 11:46 AM, Eric Cunningham wrote:

Thanks Bron, but that doesn't seem to work for me, unless I'm
missing something.

I ran reconstructs for this account on both my master and copy hosts:

[cyrus@imap1 ~]$ reconstruct -f -r user.scramer
user.scramer
user.scramer.Archive
user.scramer.Archives
user.scramer.Archives.2004
...
user.scramer.Trash.IS Networking and Operations
user.scramer.Trash.IS Security
user.scramer.Trash.IS Servers

Re: sync_client problems

2017-05-12 Thread Bron Gondwana 
Just read the 148 file and see if there is corruption.  I suspect that's the 
cause.

Bron

On Fri, 12 May 2017, at 23:09, Eric Cunningham wrote:
> I have snapshot backups of that account, that particular message and the 
> various cyrus db files.  What can I provide for review?
> 
> 
> On 5/11/17 7:38 PM, Bron Gondwana wrote:
> > It looked like the '148.' file was corrupted in some way.  I assume you've 
> > deleted all the evidence now, so we can't see how!  Oh well :(
> >
> > Bron.
> >
> > On Fri, 12 May 2017, at 04:55, Eric Cunningham wrote:
> >> Just to close the loop on this, once the corrupted cdm-lit account on my
> >> copy server successfully reconstructed, the backlog of replication has
> >> completed successfully and is now caught up.
> >>
> >> -Eric
> >>
> >> On 05/11/2017 02:20 PM, Eric Cunningham wrote:
> >>> -G didn't seem to help, but I tried a "reconstruct -f -r" command
> >>> without having previously deleted all occurrences of the cyrus.* files
> >>> and it was then successful.
> >>>
> >>>
> >>>
> >>> On 05/11/2017 01:44 PM, Patrick Boutilier wrote:
>  Try a -G with reconstruct?
> 
>  -G Force  re-parsing  of the underlying message (checks GUID
>  correctness).  Reconstruct with -G should fix all possible individual
>  message issues, including corrupted data files.
> 
> 
>  On 05/11/2017 02:37 PM, Eric Cunningham wrote:
> > I have to walk this back.  In looking slightly further back in my
> > logfiles, before every instance of a failure to sync some folder, I
> > see a common error reported prior to every "bailing out! Bad
> > protocol" error - "IOERROR: GUID mismatch
> > /var/spool/cyrus/mail/c/user/cdm-lit/Sent/148."
> >
> > May 11 12:44:09 imap1 sync_client[48590]: IOERROR: GUID mismatch
> > /var/spool/cyrus/mail/c/user/cdm-lit/Sent/148.
> > May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
> > response to MAILBOX (end of file reached)
> > May 11 12:44:22 imap1 sync_client[48590]: do_folders(): update
> > failed: user.cdm-lit.Sent 'Bad protocol'
> > May 11 12:44:22 imap1 sync_client[48590]: sync_mailboxes: doing 1000
> > May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
> > response to MAILBOXES (end of file reached)
> > May 11 12:44:22 imap1 sync_client[48590]: sync_mailboxes: doing 1000
> > May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
> > response to MAILBOXES (end of file reached)
> > May 11 12:44:22 imap1 sync_client[48590]: sync_mailboxes: doing 1000
> > May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
> > response to MAILBOXES (end of file reached)
> > May 11 12:44:22 imap1 sync_client[48590]: sync_mailboxes: doing 1000
> > May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
> > response to MAILBOXES (end of file reached)
> > May 11 12:44:22 imap1 sync_client[48590]: sync_mailboxes: doing 1000
> > May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
> > response to MAILBOXES (end of file reached)
> > May 11 12:44:22 imap1 sync_client[48590]: sync_mailboxes: doing 1000
> > May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
> > response to MAILBOXES (end of file reached)
> > May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
> > response to MAILBOXES (end of file reached)
> > May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
> > response to UNMAILBOX (end of file reached)
> > May 11 12:44:22 imap1 sync_client[48590]: folder_delete(): failed:
> > user.guest-student-coordinator.Trash.Aarflot 'Bad protocol'
> > May 11 12:44:22 imap1 sync_client[48590]: Error in do_sync(): bailing
> > out! Bad protocol
> > May 11 12:44:22 imap1 sync_client[48590]: Processing sync log file
> > /var/spool/CyrusDB-Sieve/cyrusdb/sync/log-run failed: Bad protocol
> >
> > When I recontructed this cdm-lit account, it ran successfully on my
> > master host, but fails on my copy host:
> >
> > [cyrus@imap2 ~]$ reconstruct -f -r user.cdm-lit
> > user.cdm-lit
> > user.cdm-lit.Sea Trail 2013
> > user.cdm-lit.Sent uid 1 found - adding
> > user.cdm-lit.Sent uid 2 found - adding
> > user.cdm-lit.Sent uid 3 found - adding
> > user.cdm-lit.Sent uid 4 found - adding
> > 
> > user.cdm-lit.Sent uid 146 found - adding
> > user.cdm-lit.Sent uid 147 found - adding
> > user.cdm-lit.Sent uid 148 found - adding
> > fatal error: Internal error: assertion failed: imap/mailbox.c: 2847:
> > record->size
> >
> > Since I couldn't get a successful reconstruct on this account, I
> > deleted it and recreated it from my master host.  However, I'm still
> > unable to get a successful reconstruct with "failed to read index
> > header" for every subfolder and "fatal error: Internal error:
> > assertion failed: imap/mailbox.c: 2847:

Re: sync_client problems

2017-05-12 Thread Eric Cunningham 
I have snapshot backups of that account, that particular message and the 
various cyrus db files.  What can I provide for review?



On 5/11/17 7:38 PM, Bron Gondwana wrote:

It looked like the '148.' file was corrupted in some way.  I assume you've 
deleted all the evidence now, so we can't see how!  Oh well :(

Bron.

On Fri, 12 May 2017, at 04:55, Eric Cunningham wrote:

Just to close the loop on this, once the corrupted cdm-lit account on my
copy server successfully reconstructed, the backlog of replication has
completed successfully and is now caught up.

-Eric

On 05/11/2017 02:20 PM, Eric Cunningham wrote:

-G didn't seem to help, but I tried a "reconstruct -f -r" command
without having previously deleted all occurrences of the cyrus.* files
and it was then successful.



On 05/11/2017 01:44 PM, Patrick Boutilier wrote:

Try a -G with reconstruct?

-G Force  re-parsing  of the underlying message (checks GUID
correctness).  Reconstruct with -G should fix all possible individual
message issues, including corrupted data files.


On 05/11/2017 02:37 PM, Eric Cunningham wrote:

I have to walk this back.  In looking slightly further back in my
logfiles, before every instance of a failure to sync some folder, I
see a common error reported prior to every "bailing out! Bad
protocol" error - "IOERROR: GUID mismatch
/var/spool/cyrus/mail/c/user/cdm-lit/Sent/148."

May 11 12:44:09 imap1 sync_client[48590]: IOERROR: GUID mismatch
/var/spool/cyrus/mail/c/user/cdm-lit/Sent/148.
May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
response to MAILBOX (end of file reached)
May 11 12:44:22 imap1 sync_client[48590]: do_folders(): update
failed: user.cdm-lit.Sent 'Bad protocol'
May 11 12:44:22 imap1 sync_client[48590]: sync_mailboxes: doing 1000
May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
response to MAILBOXES (end of file reached)
May 11 12:44:22 imap1 sync_client[48590]: sync_mailboxes: doing 1000
May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
response to MAILBOXES (end of file reached)
May 11 12:44:22 imap1 sync_client[48590]: sync_mailboxes: doing 1000
May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
response to MAILBOXES (end of file reached)
May 11 12:44:22 imap1 sync_client[48590]: sync_mailboxes: doing 1000
May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
response to MAILBOXES (end of file reached)
May 11 12:44:22 imap1 sync_client[48590]: sync_mailboxes: doing 1000
May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
response to MAILBOXES (end of file reached)
May 11 12:44:22 imap1 sync_client[48590]: sync_mailboxes: doing 1000
May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
response to MAILBOXES (end of file reached)
May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
response to MAILBOXES (end of file reached)
May 11 12:44:22 imap1 sync_client[48590]: IOERROR: zero length
response to UNMAILBOX (end of file reached)
May 11 12:44:22 imap1 sync_client[48590]: folder_delete(): failed:
user.guest-student-coordinator.Trash.Aarflot 'Bad protocol'
May 11 12:44:22 imap1 sync_client[48590]: Error in do_sync(): bailing
out! Bad protocol
May 11 12:44:22 imap1 sync_client[48590]: Processing sync log file
/var/spool/CyrusDB-Sieve/cyrusdb/sync/log-run failed: Bad protocol

When I recontructed this cdm-lit account, it ran successfully on my
master host, but fails on my copy host:

[cyrus@imap2 ~]$ reconstruct -f -r user.cdm-lit
user.cdm-lit
user.cdm-lit.Sea Trail 2013
user.cdm-lit.Sent uid 1 found - adding
user.cdm-lit.Sent uid 2 found - adding
user.cdm-lit.Sent uid 3 found - adding
user.cdm-lit.Sent uid 4 found - adding

user.cdm-lit.Sent uid 146 found - adding
user.cdm-lit.Sent uid 147 found - adding
user.cdm-lit.Sent uid 148 found - adding
fatal error: Internal error: assertion failed: imap/mailbox.c: 2847:
record->size

Since I couldn't get a successful reconstruct on this account, I
deleted it and recreated it from my master host.  However, I'm still
unable to get a successful reconstruct with "failed to read index
header" for every subfolder and "fatal error: Internal error:
assertion failed: imap/mailbox.c: 2847: record->size"

Any ideas on how to correct this so I can see if I can then get past
the replication error?

Thanks!

-Eric


On 05/11/2017 11:46 AM, Eric Cunningham wrote:

Thanks Bron, but that doesn't seem to work for me, unless I'm
missing something.

I ran reconstructs for this account on both my master and copy hosts:

[cyrus@imap1 ~]$ reconstruct -f -r user.scramer
user.scramer
user.scramer.Archive
user.scramer.Archives
user.scramer.Archives.2004
...
user.scramer.Trash.IS Networking and Operations
user.scramer.Trash.IS Security
user.scramer.Trash.IS Servers
user.scramer.Trash.IS Staff
user.scramer.Trash.IS Surveys
...


[cyrus@imap2 ~]$ reconstruct -f -r user.scramer
user.scramer
user.scramer.Archive
user.scramer.Archives
user.scramer.Archives.2004
...
user.scramer.Trash.IS Networking