headers
Marc Patermann | 1 Dec 2011 11:51
Picon

Re: Virus Scanning moved imap files

Shelley,

Shelley Waltz schrieb (30.11.2011 19:16 Uhr):

> Yes, I  looked into this on-access scanner.  What I was thinking was
> more like the postfix amavisd model, where the incoming goes through
> a filter before arriving at inbox.   Is there a way to do this with
> sieve - send mail to a filter?
IMHO Sieve neither works if you manipulate the mailbox by IMAP, but when 
the message is injected by LMTP e.a. /from the outside/.

[To compare with postfix: amavis normally does not interact with 
inner-posfix actions like moving a mail from one queue to another, but 
when the mail arrives from outside.]

But have a look at what Dave just suggested.

Marc
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Permalink | Reply | 0 comments |
headers
Andrew Morgan | 6 Dec 2011 23:48

Re: 2.3 to 2.4 Murder upgrade

On Fri, 14 Oct 2011, Dave McMurtrie wrote:

> On Oct 14, 2011, at 7:16 PM, Andrew Morgan <morgan <at> orst.edu> wrote:
>
>> I finally have some time to work on upgrading our Cyrus Murder
>> installation from 2.3.16 to 2.4.12.  We have 3 backends, 3 frontends, and
>> a mupdate master, all separate systems.
>>
>> When I upgraded from 2.2 to 2.3, I had to upgrade the backends first.
>> Otherwise, the 2.3 frontends would issue commands that the 2.2 backends
>> didn't know yet.  I see the following note in the install-upgrade guide:
>>
>> Upgrading from 2.4.5
>>
>>     New config option: suppress_capabilities, which takes a space
>> separated list of capabilities which will NOT be given in any imap
>> capability response. This can be used on frontends to not display
>> capabilities that older backends don't have, so clients don't get confused
>>
>>
>> This leads me to believe that I should upgrade the backends to 2.4 first.
>> Is that true?  Has anyone done a Murder upgrade from 2.3 to 2.4 and can
>> tell me what order they upgraded the hosts?
>>
>
> Yes, you'll want to upgrade the frontends first and suppress the new 
> capabilities on the frontends that the old backends aren't yet aware of.

Hmmm, how do I know which capabilities to suppress?  Should I just compare 
the CAPABILITY response from a 2.3 and a 2.4 server?
(Continue reading)

Permalink | Reply | 6 comments |
headers
Dave McMurtrie | 7 Dec 2011 00:23
Picon

Re: 2.3 to 2.4 Murder upgrade

On 12/06/2011 05:48 PM, Andrew Morgan wrote:
> On Fri, 14 Oct 2011, Dave McMurtrie wrote:
...snipped...
>>> Upgrading from 2.4.5
>>>
>>> New config option: suppress_capabilities, which takes a space
>>> separated list of capabilities which will NOT be given in any imap
>>> capability response. This can be used on frontends to not display
>>> capabilities that older backends don't have, so clients don't get
>>> confused
>>>
>>>
>>> This leads me to believe that I should upgrade the backends to 2.4
>>> first.
>>> Is that true? Has anyone done a Murder upgrade from 2.3 to 2.4 and can
>>> tell me what order they upgraded the hosts?
>>>
>>
>> Yes, you'll want to upgrade the frontends first and suppress the new
>> capabilities on the frontends that the old backends aren't yet aware of.

I should have mentioned the reason why we did the frontends first for 
the benefit of anyone else who is searching for this information.  You 
need to do the frontends first because as of 2.4, the backends will 
(correctly) return the NoSelect flag for any remote folders that you're 
subscribed to in an LSUB response.  This is most common with shared 
folders, where the shared folder may not be on the same backend as the 
user's Inbox.  The 2.4 frontends will know to scrub the NoSelect flag in 
this case.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Blake Hudson | 8 Dec 2011 00:03

logwatch - log summary

I see some mention back in 2004 on this list about preliminary logwatch script creation for Cyrus. It looks like there's nothing official (couldn't find mention of logwatch in the cyrusimap.org site, didn't see anything in the latest release tar.gz) and no logwatch script for Cyrus is included with my distribution's RPM package (CentOS).

I did find this dated version written by Sebastian Hagedorn <Hagedorn <at> uni-koeln.de> for an older version of Cyrus and Logwatch. As some of the Cyrus logging has changed, and logwatch file formats and locations may have changed over time, I would expect a little bit of effort might be needed to get this script working on a modern install.

Is anyone currently using logwatch with Cyrus? Does anyone use another tool to summarize the logs for stats like the number of connections, (failed) logins, authentication mechanisms, deliveries, duplicates, etc?

Thanks in advance,
--Blake
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Permalink | Reply | 0 comments |
headers
Andrew Morgan | 8 Dec 2011 19:00

Re: 2.3 to 2.4 Murder upgrade

On Tue, 6 Dec 2011, Dave McMurtrie wrote:

> On 12/06/2011 05:48 PM, Andrew Morgan wrote:
>> On Fri, 14 Oct 2011, Dave McMurtrie wrote:
> ...snipped...
>>>> Upgrading from 2.4.5
>>>> 
>>>> New config option: suppress_capabilities, which takes a space
>>>> separated list of capabilities which will NOT be given in any imap
>>>> capability response. This can be used on frontends to not display
>>>> capabilities that older backends don't have, so clients don't get
>>>> confused
>>>> 
>>>> 
>>>> This leads me to believe that I should upgrade the backends to 2.4
>>>> first.
>>>> Is that true? Has anyone done a Murder upgrade from 2.3 to 2.4 and can
>>>> tell me what order they upgraded the hosts?
>>>> 
>>> 
>>> Yes, you'll want to upgrade the frontends first and suppress the new
>>> capabilities on the frontends that the old backends aren't yet aware of.
>
> I should have mentioned the reason why we did the frontends first for the 
> benefit of anyone else who is searching for this information.  You need to do 
> the frontends first because as of 2.4, the backends will (correctly) return 
> the NoSelect flag for any remote folders that you're subscribed to in an LSUB 
> response.  This is most common with shared folders, where the shared folder 
> may not be on the same backend as the user's Inbox.  The 2.4 frontends will 
> know to scrub the NoSelect flag in this case.
>
>> Hmmm, how do I know which capabilities to suppress? Should I just
>> compare the CAPABILITY response from a 2.3 and a 2.4 server?
>
> We used:
>
> suppress_capabilities: ESEARCH QRESYNC WITHIN
>
> but your idea is perfectly cromulent, also.

I compared the CAPABILITY response between 2.3 and 2.4 frontends after TLS 
was negotiated and found the following differences:

> ENABLE
> ESEARCH
< IMAP4
> LIST-EXTENDED
> QRESYNC
> SORT=DISPLAY
> URLAUTH=BINARY
> WITHIN
> XLIST

So, I tried adding all the new 2.4 capabilities to the 
suppress_capabilities setting.  I found that if I added URLAUTH=BINARY to 
suppress_capabilities, I was unable to establish an IMAP connection to the 
frontend.  imtest didn't print any output, and proxyd on the frontend was 
spinning at 100% cpu.  If I remove URLAUTH=BINARY from 
suppress_capabilities, leaving all the other new capabilities suppressed, 
it works fine.  I'm not sure if this is a bug...  Let me know if I should 
file it as a bug.

So that leaves the following capabilities suppressed:

suppress_capabilities: ESEARCH LIST-EXTENDED QRESYNC WITHIN XLIST ENABLE SORT=DISPLAY

The imapd.conf manpage says I only need:

suppress_capabilities: ESEARCH QRESYNC WITHIN XLIST LIST-EXTENDED

if I have 2.3 murder backends.  Is that correct, or should I suppress the 
new ENABLE and SORT=DISPLAY too?

Thanks,
 	Andy
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Permalink | Reply | 4 comments |
headers
Bron Gondwana | 8 Dec 2011 20:26
Gravatar

Re: 2.3 to 2.4 Murder upgrade

On Thu, Dec 08, 2011 at 10:00:26AM -0800, Andrew Morgan wrote:
> So, I tried adding all the new 2.4 capabilities to the 
> suppress_capabilities setting.  I found that if I added URLAUTH=BINARY to 
> suppress_capabilities, I was unable to establish an IMAP connection to the 
> frontend.  imtest didn't print any output, and proxyd on the frontend was 
> spinning at 100% cpu.  If I remove URLAUTH=BINARY from 
> suppress_capabilities, leaving all the other new capabilities suppressed, 
> it works fine.  I'm not sure if this is a bug...  Let me know if I should 
> file it as a bug.

Meep - sorry, it's a bug.  Fixed on master.  I really REALLY
need to take some time fixing stable.

> suppress_capabilities: ESEARCH LIST-EXTENDED QRESYNC WITHIN XLIST ENABLE SORT=DISPLAY
> 
> The imapd.conf manpage says I only need:
> 
> suppress_capabilities: ESEARCH QRESYNC WITHIN XLIST LIST-EXTENDED
> 
> if I have 2.3 murder backends.  Is that correct, or should I suppress the 
> new ENABLE and SORT=DISPLAY too?

Probably should suppress SORT=DISPLAY.  That's even newer than the
imapd.conf docs!  I think ENABLE is OK, because clients are expected
to handle NO responses.

Bron.
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Permalink | Reply | 3 comments |
headers
Andrew Morgan | 8 Dec 2011 21:20

Re: 2.3 to 2.4 Murder upgrade

On Thu, 8 Dec 2011, Bron Gondwana wrote:

> On Thu, Dec 08, 2011 at 10:00:26AM -0800, Andrew Morgan wrote:
>> So, I tried adding all the new 2.4 capabilities to the
>> suppress_capabilities setting.  I found that if I added URLAUTH=BINARY to
>> suppress_capabilities, I was unable to establish an IMAP connection to the
>> frontend.  imtest didn't print any output, and proxyd on the frontend was
>> spinning at 100% cpu.  If I remove URLAUTH=BINARY from
>> suppress_capabilities, leaving all the other new capabilities suppressed,
>> it works fine.  I'm not sure if this is a bug...  Let me know if I should
>> file it as a bug.
>
> Meep - sorry, it's a bug.  Fixed on master.  I really REALLY
> need to take some time fixing stable.
>
>> suppress_capabilities: ESEARCH LIST-EXTENDED QRESYNC WITHIN XLIST ENABLE SORT=DISPLAY
>>
>> The imapd.conf manpage says I only need:
>>
>> suppress_capabilities: ESEARCH QRESYNC WITHIN XLIST LIST-EXTENDED
>>
>> if I have 2.3 murder backends.  Is that correct, or should I suppress the
>> new ENABLE and SORT=DISPLAY too?
>
> Probably should suppress SORT=DISPLAY.  That's even newer than the
> imapd.conf docs!  I think ENABLE is OK, because clients are expected
> to handle NO responses.

Okay.  Is there any harm not suppressing URLAUTH=BINARY?  :)

 	Andy
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Permalink | Reply | 2 comments |
headers
Dave McMurtrie | 8 Dec 2011 21:24
Picon

Re: 2.3 to 2.4 Murder upgrade

On 12/08/2011 03:20 PM, Andrew Morgan wrote:
> On Thu, 8 Dec 2011, Bron Gondwana wrote:
>
>> On Thu, Dec 08, 2011 at 10:00:26AM -0800, Andrew Morgan wrote:
>>> So, I tried adding all the new 2.4 capabilities to the
>>> suppress_capabilities setting. I found that if I added URLAUTH=BINARY to
>>> suppress_capabilities, I was unable to establish an IMAP connection
>>> to the
>>> frontend. imtest didn't print any output, and proxyd on the frontend was
>>> spinning at 100% cpu. If I remove URLAUTH=BINARY from
>>> suppress_capabilities, leaving all the other new capabilities
>>> suppressed,
>>> it works fine. I'm not sure if this is a bug... Let me know if I should
>>> file it as a bug.
>>
>> Meep - sorry, it's a bug. Fixed on master. I really REALLY
>> need to take some time fixing stable.
>>
>>> suppress_capabilities: ESEARCH LIST-EXTENDED QRESYNC WITHIN XLIST
>>> ENABLE SORT=DISPLAY
>>>
>>> The imapd.conf manpage says I only need:
>>>
>>> suppress_capabilities: ESEARCH QRESYNC WITHIN XLIST LIST-EXTENDED
>>>
>>> if I have 2.3 murder backends. Is that correct, or should I suppress the
>>> new ENABLE and SORT=DISPLAY too?
>>
>> Probably should suppress SORT=DISPLAY. That's even newer than the
>> imapd.conf docs! I think ENABLE is OK, because clients are expected
>> to handle NO responses.
>
> Okay. Is there any harm not suppressing URLAUTH=BINARY? :)

I'm not aware of any clients that use it, so it probably doesn't matter 
if it's offered as a capability.
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Permalink | Reply | 0 comments |
headers
Bernie Rossi | 10 Dec 2011 01:26
Picon
Favicon

Looking for Cyrus Contractor

Hi,

We are currently looking for a strong Linux sysadmin with deep Cyrus 
experience required.  Familiarity with Exim, MySQL and Python desired.

If you are interested, please send your resume to me.

Thanks,

Bernie Rossi
Supervisor
Collaborative Tools Help Desk
UC Berkeley

----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Permalink | Reply | 0 comments |
headers
Bron Gondwana | 8 Dec 2011 21:24
Gravatar

Re: 2.3 to 2.4 Murder upgrade

On Thu, Dec 08, 2011 at 12:20:38PM -0800, Andrew Morgan wrote:
> Okay.  Is there any harm not suppressing URLAUTH=BINARY?  :)

Maybe issues with Nokia phones...

Otherwise you should be OK.

You can apply this patch if you need:

http://git.cyrusimap.org/cyrus-imapd/commit/?id=6bebf41d13f046ba41a859ab58de45098e76099d

Bron.
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Permalink | Reply | 0 comments |

Gmane