Dan White | 1 Jul 2012 23:37
Gravatar

Re: lmtp user lmtp_admins or admins on murder front-end system

On 06/29/12 18:13 -0700, Stephen Ingram wrote:
>I'm trying to test an lmtp connection from the MTA using lmtptest. I'm
>connecting to a murder frontend system which then lmtpproxy's to the
>backend.
>
>On the frontend system I have:
>
>lmtp_admins: lmtp-kerberos-principal
>
>On the backend system I have:
>
>lmtp_admins: lmtp-kerberos-principal
>
>Every time I try to connect using lmtptest -m GSSAPI
>frontend.system.com I get: badlogin: x.x.x.x GSSAPI SASL(-13):
>authentication failure: only admins may authenticate.
>
>When I switch the frontend configuration to:
>
>admins: lmtp-kerberos-principal
>
>everything works. I'm trying to limit admin access as much as
>possible. While the backend is still protected, the proxy is not. Is
>this possible to do or is it not a concern any way since it's only a
>frontend proxy?

Verify that the service name listed in /etc/cyrus.conf is 'lmtp'. If not,
you'll need to adjust 'lmtp_admins' to match.

--

-- 
(Continue reading)

Greg Banks | 2 Jul 2012 10:46
Gravatar

Re: Cyrus 2.4 IMAP SEARCH

G'day,

As I'm looking at the Cyrus search code for other reasons, I thought I'd
field this one.

On Fri, Jun 29, 2012, at 12:57 PM, David Carter wrote:
> 
> RFC 3501, section 6.4.4 "SEARCH Command" says:
> 
>     In all search keys that use strings, a message matches the key if
>     the string is a substring of the field.  The matching is
>     case-insensitive.
> 
> and I guess "" is strictly speaking a substring of all other strings.
>

Ah, the good old days when RFCs could be written assuming one language,
four timezones and one hemisphere and everybody Just Knew What You
Meant.  As far as I can see there is absolutely no definition of either
"substring" or "case-insensitive" in RFC3501 or any of the documents it
references.

These days however we have Unicode and in particular RFC 5051 which
tells us how to handle text when sorting and searching.  That document
references RFC 4790, section 4.2.3 of which has a useful working
definition of what a comparator's substring operation can do, including
this

>   A string is a substring of itself.  The empty string is a substring of all strings.

(Continue reading)

steffo76 | 2 Jul 2012 15:26
Picon
Picon

Error decompressing data

Hi list,

I am having trouble with Apple Mail on iPhone and cyrus imapd. In telemetry logging I see the following:

3 OK Completed^M
<1341234999<4 COMPRESS DEFLATE^M
>1341234999>4 OK DEFLATE active^M
>1341235140>* BYE Error decompressing data^M

In my maillog I can see the following

Jul  2 15:24:06 server imap[32304]: zlib inflate error: -3 invalid distance too far back

This is cyrus imapd 2.4.12. Any hints how to resolve this ?

Thanks,
Stephan
----
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 | 4 Jul 2012 09:03
Gravatar

Re: Error decompressing data


On Mon, Jul 2, 2012, at 03:26 PM, steffo76 <at> gmx.de wrote:
> Hi list,
> 
> I am having trouble with Apple Mail on iPhone and cyrus imapd. In telemetry logging I see the following:
> 
> 3 OK Completed^M
> <1341234999<4 COMPRESS DEFLATE^M
> >1341234999>4 OK DEFLATE active^M
> >1341235140>* BYE Error decompressing data^M
> 
> In my maillog I can see the following
> 
> Jul  2 15:24:06 server imap[32304]: zlib inflate error: -3 invalid distance too far back
> 
> This is cyrus imapd 2.4.12. Any hints how to resolve this ?

Workaround:

suppress_capabilities: COMPRESS=DEFLATE

Is this every time, or just sometimes?  It looks like there's a bug in the zlib
usage somewhere along the line.

Bron ( or a bogus virus scanner fiddling the data stream )
--

-- 
  Bron Gondwana
  brong <at> fastmail.fm

----
(Continue reading)

Favicon

Re: How to be sure that I can remove a mailbox partition


On 28/06/2012 1:26, Andrew Morgan wrote:
> On Wed, 27 Jun 2012, Javier Sánchez-Arévalo Díaz wrote:
>
>> I have a email server with two local partitions for mailboxes 
>> ("default" and "part2"). Recently these partitions became almost full 
>> so I decided create a new partition over a NFS mountpoint and migrate 
>> all the mailboxes to this new partition ("part3").
>>
>> The target is to move all  the mailboxes to "part3" in order to leave 
>> "default" and "part2" completely empty. Once this is done I want to 
>> stop using them ("default" and "part2") and remove physically the 
>> hardisks where they are in order to plug new bigger disks.
>>
>> After moving all the mailboxes to "part3" everything is working fine 
>> but, before removing "default" and "part2", I would like to make a 
>> question:
>>
>> The question is. How I can be completely sure that I can do it safely?
>>
>> I have done the next tests but I would prefer to ask to experts like 
>> you before doing It. Its a production server with almost 20000 
>> mailboxes:
>>
>>
>> // list of partitions
>>
>> pcocol01:~ # cat /etc/imapd.conf | grep -i part
>> partition-default: /buzonesdir
>> partition-part2: /mnt/aux
(Continue reading)

Stephan | 6 Jul 2012 22:32
Picon
Picon

Re: Error decompressing data

Am 04.07.2012 09:03, schrieb Bron Gondwana:
>
>
> On Mon, Jul 2, 2012, at 03:26 PM, steffo76 <at> gmx.de wrote:
>> Hi list,
>>
>> I am having trouble with Apple Mail on iPhone and cyrus imapd. In telemetry logging I see the following:
>>
>> 3 OK Completed^M
>> <1341234999<4 COMPRESS DEFLATE^M
>>> 1341234999>4 OK DEFLATE active^M
>>> 1341235140>* BYE Error decompressing data^M
>>
>> In my maillog I can see the following
>>
>> Jul  2 15:24:06 server imap[32304]: zlib inflate error: -3 invalid distance too far back
>>
>> This is cyrus imapd 2.4.12. Any hints how to resolve this ?
>
> Workaround:
>
> suppress_capabilities: COMPRESS=DEFLATE
>
> Is this every time, or just sometimes?  It looks like there's a bug in the zlib
> usage somewhere along the line.
>
> Bron ( or a bogus virus scanner fiddling the data stream )

It was actually caused by the used imap proxy. After switching to 
another one it started working again.
(Continue reading)

Patrick Boutilier | 6 Jul 2012 23:05
Picon
Favicon

Re: Error decompressing data


Stephan <steffo76 <at> gmx.de> wrote:

>Am 04.07.2012 09:03, schrieb Bron Gondwana:
>>
>>
>> On Mon, Jul 2, 2012, at 03:26 PM, steffo76 <at> gmx.de wrote:
>>> Hi list,
>>>
>>> I am having trouble with Apple Mail on iPhone and cyrus imapd. In
>telemetry logging I see the following:
>>>
>>> 3 OK Completed^M
>>> <1341234999<4 COMPRESS DEFLATE^M
>>>> 1341234999>4 OK DEFLATE active^M
>>>> 1341235140>* BYE Error decompressing data^M
>>>
>>> In my maillog I can see the following
>>>
>>> Jul  2 15:24:06 server imap[32304]: zlib inflate error: -3 invalid
>distance too far back
>>>
>>> This is cyrus imapd 2.4.12. Any hints how to resolve this ?
>>
>> Workaround:
>>
>> suppress_capabilities: COMPRESS=DEFLATE
>>
>> Is this every time, or just sometimes?  It looks like there's a bug
>in the zlib
(Continue reading)

Mark Nipper | 16 Jul 2012 20:29

IOERROR: locking index ... Unknown code ____ 255

	I'm running cyrus from the Debian/testing repository
which is currently at 2.4.16 (2.4.16-1 on the Debian side).  I'm
seeing this problem where messages aren't being correctly handled
by sieve.  I have a bunch of logwatch messages flooding in from
different systems around the same time every morning.  Most of
them end up in the correct folder, but a decent number of them
slip into my INBOX every day.  I don't think it's related to the
32 or 64-bit hash problem that I found in searching for
information about these errors messages.

	Anyway, my sieve rule looks like this:
---
if allof (header :contains "from" "utexas.edu", header :contains "subject" "logwatch for") {fileinto
"INBOX/utexas/laitsadmin/lw"; stop;}

And the error messages coming from cyrus/lmtpunix look like:
---
Jul 16 04:04:05 king cyrus/lmtpunix[17285]: IOERROR: locking index for
user.nipsy <at> bitgnome^net.utexas.laitsadmin.lw: Unknown code ____ 255
Jul 16 04:04:05 king cyrus/lmtpunix[17285]: IOERROR: locking index
user.nipsy <at> bitgnome^net.utexas.laitsadmin.lw: System I/O error
Jul 16 04:04:05 king cyrus/lmtpunix[17285]: sieve runtime error for nipsy <at> bitgnome^net id
<201207160902.q6G922jq012497 <at> image-lab-server.psy.utexas.edu>: Fileinto: System I/O error
Jul 16 04:04:06 king cyrus/lmtpunix[17285]: Delivered:
<201207160902.q6G922jq012497 <at> image-lab-server.psy.utexas.edu> to mailbox: user.nipsy <at> bitgnome^net
Jul 16 04:04:07 king cyrus/lmtpunix[17285]: USAGE nipsy <at> bitgnome^net user: 0.000000 sys: 0.004000

And here are two messages coming in right around the same time
which are delivered without any problems to the correct folder:
---
(Continue reading)

Bron Gondwana | 16 Jul 2012 23:26
Gravatar

Re: IOERROR: locking index ... Unknown code ____ 255

On Mon, Jul 16, 2012, at 01:29 PM, Mark Nipper wrote:
> Jul 16 04:03:14 king cyrus/lmtpunix[17822]: Delivered:
<201207160902.q6G925Fu018045 <at> topcat.laits.utexas.edu> to mailbox: user.nipsy <at> bitgnome^net.utexas.laitsadmin.lw
> Jul 16 04:04:37 king cyrus/lmtpunix[17868]: Delivered:
<201207160902.q6G922EO025278 <at> vm-cake.la.utexas.edu> to mailbox: user.nipsy <at> bitgnome^net.utexas.laitsadmin.lw

Thanks Mark - can you tell us what's in your mailboxes.db for nipsy <at> bitgnome.net?
You may very well have a bug - even those successful deliveries look wrong - I
would expect to be seeing user/nipsy/utexas/laitsadmin/lw <at> bitgnome.net or
bitgnome.net!user.nipsy.utexas.laitsadmin.lw

It's more likely that this configuration is buggy, since we don't run unixhs at
FastMail, so I haven't used it as much.

Bron.
--

-- 
  Bron Gondwana
  brong <at> fastmail.fm

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

Mark Nipper | 16 Jul 2012 23:38

Re: IOERROR: locking index ... Unknown code ____ 255

On 16 Jul 2012, Bron Gondwana wrote:
> On Mon, Jul 16, 2012, at 01:29 PM, Mark Nipper wrote:
> > Jul 16 04:03:14 king cyrus/lmtpunix[17822]: Delivered:
<201207160902.q6G925Fu018045 <at> topcat.laits.utexas.edu> to mailbox: user.nipsy <at> bitgnome^net.utexas.laitsadmin.lw
> > Jul 16 04:04:37 king cyrus/lmtpunix[17868]: Delivered:
<201207160902.q6G922EO025278 <at> vm-cake.la.utexas.edu> to mailbox: user.nipsy <at> bitgnome^net.utexas.laitsadmin.lw
> 
> Thanks Mark - can you tell us what's in your mailboxes.db for nipsy <at> bitgnome.net?
> You may very well have a bug - even those successful deliveries look wrong - I
> would expect to be seeing user/nipsy/utexas/laitsadmin/lw <at> bitgnome.net or
> bitgnome.net!user.nipsy.utexas.laitsadmin.lw
> 
> It's more likely that this configuration is buggy, since we don't run unixhs at
> FastMail, so I haven't used it as much.

	So, running (let me know if this isn't right):
---
cyr_dbtool /var/lib/cyrus/mailboxes.db skiplist show | grep nipsy <at> bitgnome.net

shows me things like:
---
user.nipsy <at> bitgnome^net	0 default nipsy <at> bitgnome.net	lrswipcda	admin	lrswipcda	
user.nipsy <at> bitgnome^net.Deleted Items	0 default nipsy <at> bitgnome.net	lrswipcda	admin	lrswipcda	
user.nipsy <at> bitgnome^net.Drafts	0 default nipsy <at> bitgnome.net	lrswipcda	admin	lrswipcda	
user.nipsy <at> bitgnome^net.Junk	0 default nipsy <at> bitgnome.net	lrswipcda	admin	lrswipcda	
user.nipsy <at> bitgnome^net.Sent	0 default nipsy <at> bitgnome.net	lrswipcda	admin	lrswipcda	
user.nipsy <at> bitgnome^net.Sent Items	0 default nipsy <at> bitgnome.net	lrswipcda	admin	lrswipcda	
user.nipsy <at> bitgnome^net.Trash	0 default nipsy <at> bitgnome.net	lrswipcda	admin	lrswipcda	
user.nipsy <at> bitgnome^net.bitgnome	0 default nipsy <at> bitgnome.net	lrswipcda	admin	lrswipcda	
user.nipsy <at> bitgnome^net.cyrus.info	0 default nipsy <at> bitgnome.net	lrswipcda	admin	lrswipcda	
(Continue reading)


Gmane