Re: Announcing cyrus-user-map, a local recipient map generator for Postfix

[Stefan Schmidt]

Hi Farzad,

On Tuesday 10 March 2009 00:25:42 Farzad FARID wrote:
> Having just deployed a Cyrus Imap server with Postfix, with only
> virtual users and no Unix or LDAP based imap accounts, I needed a way
> to generate a local recipient map for Postfix. This map is used by
> Postfix to identify existing email accounts and correctly reject
> incoming mail received for unknown recipients (as in
> http://www.postfix.org/LOCAL_RECIPIENT_README.html).
>
> So I wrote a little tool that generates and update this map
> automatically, with the help of cron. You can download the script and
> documentation from my website
> http://www.pragmatic-source.com/en/opensource/source-code/cyrus-user-
>map-generate-cyrus-user-map-postfix or from GitHub:
> http://github.com/Farzy/cyrus-user-map

Nice thing, but just out of curiosity, why don't you use postfix' 
recipient verification mechanism?
In smtp_recipient_restrictions add reject_unverified_recipient at a 
reasonable position in these restrictions. Everything else 
automagically happens.

Greetings,

Stefan
-- 
Stefan Schmidt  listrea...@jsj.dyndns.org

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Calling all regressions

[Bron Gondwana]

I was looking through the bug tracker, and one of the items was "skiplist 
issues in 2.2" - well, the ticket has morphed into that anyway.

The question is - do we backport the skiplist bugfixes to Cyrus 2.2?  For that 
matter, do we try to isolate just the actual bug fixes and backport them, or do 
we copy the whole cyrusdb_skiplist.c file (pretty self-contained, and the API 
is unchaged) back?

What about other bugfixes in the 2.3 branch?  There have been plenty, and not 
all related to new 2.3 branch features.


So - I ask now.  Does anybody know of any regressions in 2.3 that aren't 
present in the earlier branches?  Even performance regressions are interesting 
to some sites.

Is there any good reason for a site to continue running 2.2 or even 2.1?

If there is - I want to know it, and I want to fix it, so we don't have to 
think about maintaining the old Cyrus.  There aren't enough of us working on 
Cyrus to split the effort!


Now - also of interest is the cost of having to change configurations when 
upgrading.  2.3.x is NOT a direct dropin for 2.[12].x because some defaults 
have changed.  That's annoying.  I don't know any good solution other than 
refusing to start or complaining very loudly if those keys are NOT present in 
the config file.  I would make the error spit out:

a) the backwards compatible value
b) the new default value
c) a BRIEF description of the benefits of using the new value.

Along with a line to copy and paste into the config file for each of the above. 
 Distro maintainers can of course avoid most of this by having clever upgrade 
scripts, but we need to make sure each site can find and fix the issues caused 
by an upgrade quickly.

Ok, enough manifesto for me for one evening!  Let me know about those 
regressions, or forever hold your peace as I push for deprecation of the old 
branches...
-- 
  Bron Gondwana
  br...@fastmail.fm


Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Announcing cyrus-user-map, a local recipient map generator for Postfix

[Farzad FARID]

Le 10.03.2009 09:59, Stefan Schmidt a écrit :

Nice thing, but just out of curiosity, why don't you use postfix'
recipient verification mechanism?
In smtp_recipient_restrictions add reject_unverified_recipient at a
reasonable position in these restrictions. Everything else
automagically happens.
   
Thanks for asking. In the "Postfix Address Verification Howto" 
(http://www.postfix.org/ADDRESS_VERIFICATION_README.html) it says that:


 "/A Postfix MTA verifies a sender or recipient address by probing the 
nearest MTA for that address, without actually delivering mail. The 
nearest MTA could be the Postfix MTA itself, or it could be a remote MTA 
(SMTP interruptus). Probe messages are like normal mail, except that 
they are never delivered, deferred or bounced; probe messages are always 
discarded./"


This is a very heavyweight process, especially if we have the Cyrus 
database at hand :) So I think that looking up an entry in a hash map is 
much faster and doesn't involve any SMTP/LMTP connection.


And if the Postfix relay and the Cyrus database are not on the same 
physical computer, and someone's interested, I can extend my little tool 
to use a network connection to fetch the user database.


Best regards

--
Farzad FARID / Architecte Open Source - Associé
Pragmatic Source / http://www.pragmatic-source.com
Tel : +33 9 53 19 21 90 / Mob : +33 6 03 70 65 46


Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Announcing cyrus-user-map, a local recipient map generator for Postfix

[Farzad FARID]

Hi,

Le 10.03.2009 02:56, Reinaldo de Carvalho a écrit :

So I wrote a little tool that generates and update this map
automatically, with the help of cron. You can download the script and
documentation from my website
http://www.pragmatic-source.com/en/opensource/source-code/cyrus-user-map-generate-cyrus-user-map-postfix
or from GitHub: http://github.com/Farzy/cyrus-user-map
 

Its not necessary use ruby (or another language) merely to call shell
commands, do it on pure (ba|c|k)sh.
   
You're right! But I chose a somewhat cleaner and higher level language 
to have a more readable script. You may rewrite it in *sh if you're 
interested and I'll include it in my package or add a link to it.


It's also a proactive choice for the reason that Ruby is gaining in 
popularity, is available on many server platforms (even Sun promotes 
Ruby) and I'm pushing the use of Ruby for agile sysadmin tasks :) This 
is off-topic but interested *french speaking* people can view my 
lightning talk in this subjet: http://tinyurl.com/avuebz


 Best regards,

--
Farzad FARID / Architecte Open Source - Associé
Pragmatic Source / http://www.pragmatic-source.com
Tel : +33 9 53 19 21 90 / Mob : +33 6 03 70 65 46


Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Announcing cyrus-user-map, a local recipient map generator for Postfix

[Vladimir Klejch]

On Tue, 10 Mar 2009, Farzad FARID wrote:


Le 10.03.2009 09:59, Stefan Schmidt a écrit :

 Nice thing, but just out of curiosity, why don't you use postfix'
 recipient verification mechanism?
 In smtp_recipient_restrictions add reject_unverified_recipient at a
 reasonable position in these restrictions. Everything else
 automagically happens.

Thanks for asking. In the "Postfix Address Verification Howto" 
(http://www.postfix.org/ADDRESS_VERIFICATION_README.html) it says that:


"/A Postfix MTA verifies a sender or recipient address by probing the 
nearest MTA for that address, without actually delivering mail. The nearest 
MTA could be the Postfix MTA itself, or it could be a remote MTA (SMTP 
interruptus). Probe messages are like normal mail, except that they are never 
delivered, deferred or bounced; probe messages are always discarded./"


This is a very heavyweight process, especially if we have the Cyrus database 
at hand :) So I think that looking up an entry in a hash map is much faster 
and doesn't involve any SMTP/LMTP connection.


And if the Postfix relay and the Cyrus database are not on the same physical 
computer, and someone's interested, I can extend my little tool to use a 
network connection to fetch the user database.


Best regards




what about something like "Postfix version of smmapd" : 
http://www.mail-archive.com/info-cyrus@lists.andrew.cmu.edu/msg31479.html 
...


it is good solution, it has test for existention of mailbox and overquota 
..


i have fidled with it, but have not working solution, because there is 
some problem with unixhierarchysep and altnamespace , i think ... :-((


its about 1.5 years ago as tryed it ...



--
_
|  You have moved the mouse.  #
| Windows must be restarted for the changes to take effect.   #
| #
##/

~~  ~~  ~~  ~~  ~~  ~~  ~~
Vladimir `KLEO' Klejch  Kleo'at'netbox.cz
... ... ... ...


Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Announcing cyrus-user-map, a local recipient map generator for Postfix

[Eric Luyten]

On Tue, March 10, 2009 10:58 am, Farzad FARID wrote:
> Le 10.03.2009 09:59, Stefan Schmidt a écrit :
>
>> Nice thing, but just out of curiosity, why don't you use postfix'
>> recipient verification mechanism? In smtp_recipient_restrictions add
>> reject_unverified_recipient at a reasonable position in these
>> restrictions. Everything else automagically happens.
>>
> Thanks for asking. In the "Postfix Address Verification Howto"
> (http://www.postfix.org/ADDRESS_VERIFICATION_README.html) it says that:
>
>
> "/A Postfix MTA verifies a sender or recipient address by probing the
> nearest MTA for that address, without actually delivering mail. The nearest
> MTA could be the Postfix MTA itself, or it could be a remote MTA
> (SMTP interruptus). Probe messages are like normal mail, except that
> they are never delivered, deferred or bounced; probe messages are always
> discarded./"
>
> This is a very heavyweight process, especially if we have the Cyrus
> database at hand :) So I think that looking up an entry in a hash map is
> much faster and doesn't involve any SMTP/LMTP connection.


Correct, but those probes are pretty lightweight and the results can be
cached by Postfix.
We service dozens of our internal (!) mail domains using those Postfix
probes and performance has never been an issue, even with small mail
backends or small relays.
Recipient address validation is a very useful Postfix feature.

When we started operating IronPort appliances for the main mail domains
we were forced to feed to complete local recipient address list to an
LDAP server, so, yes, your method certainly has its uses and merits.


Regards,
Eric Luyten, Computing Centre VUB/ULB.



Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Announcing cyrus-user-map, a local recipient map generator for Postfix

[Stefan Schmidt]

On Tuesday 10 March 2009 10:58:36 Farzad FARID wrote:
> Thanks for asking. In the "Postfix Address Verification Howto"
> (http://www.postfix.org/ADDRESS_VERIFICATION_README.html) it says
> that:
> 
: verification process
>
> This is a very heavyweight process, especially if we have the Cyrus
> database at hand :) So I think that looking up an entry in a hash map
> is much faster and doesn't involve any SMTP/LMTP connection.

Postfix cashes to test result for a configurable time spam, with 
separately definable ranges for positive and negative test results.
It is - after an initial learning period - basically a hash table lookup 
without the hazzles of manually generating the lookup table.

> And if the Postfix relay and the Cyrus database are not on the same
> physical computer, and someone's interested, I can extend my little
> tool to use a network connection to fetch the user database.

Still no problem, as postfix has to deliver the mail sto cyrus somehow, 
either smtp or lmtp. The verification simply works here.

Greetings,

Stefan
-- 
Stefan Schmidt  listrea...@jsj.dyndns.org

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Calling all regressions

[Michael Menge]

Quoting Bron Gondwana :


Is there any good reason for a site to continue running 2.2 or even 2.1?



Some Enterprise Distibutions still use 2.2.x as they maintain the
same version for a very long time. E.g. Suse (SLES 10) uses Cyrus 2.2.12.
These Distrutions patch the software with own patches and backports,
but I don't know if SuSE backported changes from 2.3.x

If there is - I want to know it, and I want to fix it, so we don't  
have to think about maintaining the old Cyrus.  There aren't enough  
of us working on Cyrus to split the effort!



Now - also of interest is the cost of having to change  
configurations when upgrading.  2.3.x is NOT a direct dropin for  
2.[12].x because some defaults have changed.  That's annoying.  I  
don't know any good solution other than refusing to start or  
complaining very loudly if those keys are NOT present in the config  
file.  I would make the error spit out:




Is there a way to know if cyrus was updated?

Regards

 Michael Menge


M.MengeTel.: (49) 7071/29-70316
Universität Tübingen   Fax.: (49) 7071/29-5912
Zentrum für Datenverarbeitung  mail:  
michael.me...@zdv.uni-tuebingen.de

Wächterstraße 76
72074 Tübingen

smime.p7s
Description: S/MIME krytographische Unterschrift

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Announcing cyrus-user-map, a local recipient map generator for Postfix

[Farzad FARID]

Thanks to you and Eric Luyten for the information on the small overhead. 
So until someone ports smmapd to Postfix I agree that the recipient 
address validation setting is sufficient.

Regards,

Le 10.03.2009 11:50, Stefan Schmidt a écrit :
>
> Postfix cashes to test result for a configurable time spam, with
> separately definable ranges for positive and negative test results.
> It is - after an initial learning period - basically a hash table lookup
> without the hazzles of manually generating the lookup table.
>
-- 
Farzad FARID / Architecte Open Source - Associé
Pragmatic Source / http://www.pragmatic-source.com
Tel : +33 9 53 19 21 90 / Mob : +33 6 03 70 65 46


Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Calling all regressions

[Adam Tauno Williams]

On Tue, 2009-03-10 at 12:07 +0100, Michael Menge wrote:
> Quoting Bron Gondwana :
> > Is there any good reason for a site to continue running 2.2 or even 2.1?
> Some Enterprise Distibutions still use 2.2.x as they maintain the
> same version for a very long time. E.g. Suse (SLES 10) uses Cyrus 2.2.12.
> These Distrutions patch the software with own patches and backports,
> but I don't know if SuSE backported changes from 2.3.x
> > If there is - I want to know it, and I want to fix it, so we don't  
> > have to think about maintaining the old Cyrus.  There aren't enough  
> > of us working on Cyrus to split the effort!
> > Now - also of interest is the cost of having to change  
> > configurations when upgrading.  2.3.x is NOT a direct dropin for  
> > 2.[12].x because some defaults have changed.  That's annoying.  I  
> > don't know any good solution other than refusing to start or  
> > complaining very loudly if those keys are NOT present in the config  
> > file.  I would make the error spit out:
> Is there a way to know if cyrus was updated?

Documentation is pretty miserable;  best source for changes is either
 or to read the CVS
commit maillist  [or
subscribe to it cyrus-cvs-subscr...@lists.andrew.cmu.edu ]
-- 
OpenGroupware developer: awill...@whitemice.org

OpenGroupware & Cyrus IMAPd documentation:



Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Calling all regressions

[Michael Menge]

Quoting Adam Tauno Williams :


On Tue, 2009-03-10 at 12:07 +0100, Michael Menge wrote:

Quoting Bron Gondwana :
> Is there any good reason for a site to continue running 2.2 or even 2.1?
Some Enterprise Distibutions still use 2.2.x as they maintain the
same version for a very long time. E.g. Suse (SLES 10) uses Cyrus 2.2.12.
These Distrutions patch the software with own patches and backports,
but I don't know if SuSE backported changes from 2.3.x
> If there is - I want to know it, and I want to fix it, so we don't
> have to think about maintaining the old Cyrus.  There aren't enough
> of us working on Cyrus to split the effort!
> Now - also of interest is the cost of having to change
> configurations when upgrading.  2.3.x is NOT a direct dropin for
> 2.[12].x because some defaults have changed.  That's annoying.  I
> don't know any good solution other than refusing to start or
> complaining very loudly if those keys are NOT present in the config
> file.  I would make the error spit out:
Is there a way to know if cyrus was updated?


Documentation is pretty miserable;  best source for changes is either
 or to read the CVS
commit maillist  [or
subscribe to it cyrus-cvs-subscr...@lists.andrew.cmu.edu ]


I think i should rephrase my question.

Is there a way for cyrus to know that it was updated
since the last time it did run, so it can do the things
suggested by Bron.


M.MengeTel.: (49) 7071/29-70316
Universität Tübingen   Fax.: (49) 7071/29-5912
Zentrum für Datenverarbeitung  mail:  
michael.me...@zdv.uni-tuebingen.de

Wächterstraße 76
72074 Tübingen

smime.p7s
Description: S/MIME krytographische Unterschrift

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Calling all regressions

[Wesley Craig]

On 10 Mar 2009, at 08:51, Michael Menge wrote:
> Quoting Adam Tauno Williams :
>> Documentation is pretty miserable;  best source for changes is either
>>  or to read the CVS
>> commit maillist   
>> [or
>> subscribe to it cyrus-cvs-subscr...@lists.andrew.cmu.edu ]

I'd probably say the "documentation" was miserable if all I could  
find was a web page that hadn't been updated since 2.3.1, too.  A  
more nuanced bash might be that the web site is miserably out of  
date.  In fact, changes.html from the distribution is current for  
each release.  Of course, contributions to improve the miserable  
documentation are always welcome.

> I think i should rephrase my question.
>
> Is there a way for cyrus to know that it was updated
> since the last time it did run, so it can do the things
> suggested by Bron.

Perhaps we should add a config option with no default whose value  
must be the version of the software you're running.

:wes

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Vacation Application

[Gottschalk, David]

Hi All,
  I have a question regarding a vacation application for Cyrus servers. I want 
to know what others are using to meet this need. Currently, we have a home 
grown application that allows users to enable/disable vacation messages for 
their Cyrus accounts. This application is old and outdated, and needs to be 
replaced. I found the Horde vacation application which looks like it will meet 
my needs, but I have one issue. We currently have three Cyrus servers with all 
the accounts spread out across those three servers. The problem I am running 
into with any vacation application, is how to identify to the vacation 
application which server a user is on without the user needing to know this 
information. Is anyone else in a similar situation?

Thanks for any help.

David Gottschalk
UTS Email team
david.gottsch...@emory.edu



This e-mail message (including any attachments) is for the sole use of
the intended recipient(s) and may contain confidential and privileged
information.  If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution
or copying of this message (including any attachments) is strictly
prohibited.

If you have received this message in error, please contact
the sender by reply e-mail message and destroy all copies of the
original message (including attachments).

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Vacation Application

[Nic Bernstein]

On 03/10/2009 12:42 PM, Gottschalk, David wrote:
> Hi All,
>   I have a question regarding a vacation application for Cyrus servers. I 
> want to know what others are using to meet this need. Currently, we have a 
> home grown application that allows users to enable/disable vacation messages 
> for their Cyrus accounts. This application is old and outdated, and needs to 
> be replaced. I found the Horde vacation application which looks like it will 
> meet my needs, but I have one issue. We currently have three Cyrus servers 
> with all the accounts spread out across those three servers. The problem I am 
> running into with any vacation application, is how to identify to the 
> vacation application which server a user is on without the user needing to 
> know this information. Is anyone else in a similar situation?
>   
Um, use a murder?  Otherwise you may want to adapt something like the 
cyrus user validation script which was recently posted here.  Your 
application could then perform lookups in the output of that script.  
Lastly, you could just let you application attempt authenticating 
against each server, in turn, stopping once it succeeds.

Cheers,
-nic

-- 
Nic Bernstein n...@onlight.com
Onlight llc.  www.onlight.com
2266 North Prospect Avenue #610   v. 414.272.4477
Milwaukee, Wisconsin  53202-6306  f. 414.290.0335


Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Vacation Application

[Adam Tauno Williams]

On Tue, 2009-03-10 at 13:42 -0400, Gottschalk, David wrote:
> Hi All,
>   I have a question regarding a vacation application for Cyrus servers. I want
>  to know what others are using to meet this need. Currently, we have a home 
> grown application that allows users to enable/disable vacation messages for 
> their Cyrus accounts. This application is old and outdated, and needs to be 
> replaced. I found the Horde vacation application which looks like it will 
> meet my needs, but I have one issue. We currently have three Cyrus servers 

We use Horde's Ingo application which I assume is what your referring
to.  It works very well and is relatively "pretty".

> with all the accounts spread out across those three servers. The problem I
>  am running into with any vacation application, is how to identify to the 
> vacation application which server a user is on without the user needing to
>  know this information. Is anyone else in a similar situation?

Could you use Horde hooks to this?  Horde hooks are pretty easy and they
can set values you then refer to in your sources configuration.

-- 
OpenGroupware developer: awill...@whitemice.org

OpenGroupare & Cyrus IMAPd documenation @



Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Vacation Application

[Michael Menge]

Hi,

Quoting "Gottschalk, David" :


Hi All,
  I have a question regarding a vacation application for Cyrus  
servers. I want to know what others are using to meet this need.  
Currently, we have a home grown application that allows users to  
enable/disable vacation messages for their Cyrus accounts. This  
application is old and outdated, and needs to be replaced. I found  
the Horde vacation application which looks like it will meet my  
needs, but I have one issue. We currently have three Cyrus servers  
with all the accounts spread out across those three servers. The  
problem I am running into with any vacation application, is how to  
identify to the vacation application which server a user is on  
without the user needing to know this information. Is anyone else in  
a similar situation?




We are in the same situation. We have our accounts spread across six servers.
For each account there is a DNS-alias pointing to the mailserver the account
is on. We use the Horde Framework as webmailer and pim server, and  
allow our users to change their sieve scripts.


You can use the hooks in Horde to change the server, or you can run  
functions in your horde configuration file, to set the correct value  
for the servername.


Editing the filter rules and Vacations is easy and sufficent for most  
users. But the webinterface does not allow all what would be possible  
with sieve.

You should restrict the access to timsieved to horde, so that the
sievescripts are consitent with the horde database.

Regards

Michael Menge



M.MengeTel.: (49) 7071/29-70316
Universität Tübingen   Fax.: (49) 7071/29-5912
Zentrum für Datenverarbeitung  mail:  
michael.me...@zdv.uni-tuebingen.de

Wächterstraße 76
72074 Tübingen

smime.p7s
Description: S/MIME krytographische Unterschrift

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

RE: Vacation Application

[Gottschalk, David]

No murder here.

Oldschool Cyrus setup. I want to upgrade it actually, but there are 30K + 
accounts on these 3 servers.

The only problem I see with having it try each server, but failing how do you 
know if it really isn't that server, or there is just a network issue.

David Gottschalk
UTS Email team
david.gottsch...@emory.edu


-Original Message-
From: Nic Bernstein [mailto:n...@onlight.com]
Sent: Tuesday, March 10, 2009 2:00 PM
To: Gottschalk, David
Cc: info-cyrus@lists.andrew.cmu.edu
Subject: Re: Vacation Application

On 03/10/2009 12:42 PM, Gottschalk, David wrote:
> Hi All,
>   I have a question regarding a vacation application for Cyrus servers. I 
> want to know what others are using to meet this need. Currently, we have a 
> home grown application that allows users to enable/disable vacation messages 
> for their Cyrus accounts. This application is old and outdated, and needs to 
> be replaced. I found the Horde vacation application which looks like it will 
> meet my needs, but I have one issue. We currently have three Cyrus servers 
> with all the accounts spread out across those three servers. The problem I am 
> running into with any vacation application, is how to identify to the 
> vacation application which server a user is on without the user needing to 
> know this information. Is anyone else in a similar situation?
>
Um, use a murder?  Otherwise you may want to adapt something like the
cyrus user validation script which was recently posted here.  Your
application could then perform lookups in the output of that script.
Lastly, you could just let you application attempt authenticating
against each server, in turn, stopping once it succeeds.

Cheers,
-nic

--
Nic Bernstein n...@onlight.com
Onlight llc.  www.onlight.com
2266 North Prospect Avenue #610   v. 414.272.4477
Milwaukee, Wisconsin  53202-6306  f. 414.290.0335


This e-mail message (including any attachments) is for the sole use of
the intended recipient(s) and may contain confidential and privileged
information.  If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution
or copying of this message (including any attachments) is strictly
prohibited.

If you have received this message in error, please contact
the sender by reply e-mail message and destroy all copies of the
original message (including attachments).

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

RE: Vacation Application

[Gottschalk, David]

I'm actually using the Horde vacation app that is part of Sork utilities.

David Gottschalk
UTS Email team
david.gottsch...@emory.edu
404.727.9744


-Original Message-
From: info-cyrus-bounces+dgottsc=emory@lists.andrew.cmu.edu 
[mailto:info-cyrus-bounces+dgottsc=emory@lists.andrew.cmu.edu] On Behalf Of 
Adam Tauno Williams
Sent: Tuesday, March 10, 2009 1:58 PM
To: info-cyrus@lists.andrew.cmu.edu
Subject: Re: Vacation Application

On Tue, 2009-03-10 at 13:42 -0400, Gottschalk, David wrote:
> Hi All,
>   I have a question regarding a vacation application for Cyrus servers. I want
>  to know what others are using to meet this need. Currently, we have a home
> grown application that allows users to enable/disable vacation messages for
> their Cyrus accounts. This application is old and outdated, and needs to be
> replaced. I found the Horde vacation application which looks like it will
> meet my needs, but I have one issue. We currently have three Cyrus servers

We use Horde's Ingo application which I assume is what your referring
to.  It works very well and is relatively "pretty".

> with all the accounts spread out across those three servers. The problem I
>  am running into with any vacation application, is how to identify to the
> vacation application which server a user is on without the user needing to
>  know this information. Is anyone else in a similar situation?

Could you use Horde hooks to this?  Horde hooks are pretty easy and they
can set values you then refer to in your sources configuration.

--
OpenGroupware developer: awill...@whitemice.org

OpenGroupare & Cyrus IMAPd documenation @



Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

This e-mail message (including any attachments) is for the sole use of
the intended recipient(s) and may contain confidential and privileged
information.  If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution
or copying of this message (including any attachments) is strictly
prohibited.

If you have received this message in error, please contact
the sender by reply e-mail message and destroy all copies of the
original message (including attachments).

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Vacation Application

[Kenneth Marshall]

We use SmartSieve (http://smartsieve.sourceforge.net/) to
manage vacation/sieve scripts. We look up the appropriate backend
in our LDAP directory, but a DNS lookup could be done just as
easily. It is simple to setup an configure, 1.0RC2.

Cheers,
Ken

On Tue, Mar 10, 2009 at 03:00:39PM -0400, Gottschalk, David wrote:
> No murder here.
> 
> Oldschool Cyrus setup. I want to upgrade it actually, but there are 30K + 
> accounts on these 3 servers.
> 
> The only problem I see with having it try each server, but failing how do you 
> know if it really isn't that server, or there is just a network issue.
> 
> David Gottschalk
> UTS Email team
> david.gottsch...@emory.edu
> 
> 
> -Original Message-
> From: Nic Bernstein [mailto:n...@onlight.com]
> Sent: Tuesday, March 10, 2009 2:00 PM
> To: Gottschalk, David
> Cc: info-cyrus@lists.andrew.cmu.edu
> Subject: Re: Vacation Application
> 
> On 03/10/2009 12:42 PM, Gottschalk, David wrote:
> > Hi All,
> >   I have a question regarding a vacation application for Cyrus servers. I 
> > want to know what others are using to meet this need. Currently, we have a 
> > home grown application that allows users to enable/disable vacation 
> > messages for their Cyrus accounts. This application is old and outdated, 
> > and needs to be replaced. I found the Horde vacation application which 
> > looks like it will meet my needs, but I have one issue. We currently have 
> > three Cyrus servers with all the accounts spread out across those three 
> > servers. The problem I am running into with any vacation application, is 
> > how to identify to the vacation application which server a user is on 
> > without the user needing to know this information. Is anyone else in a 
> > similar situation?
> >
> Um, use a murder?  Otherwise you may want to adapt something like the
> cyrus user validation script which was recently posted here.  Your
> application could then perform lookups in the output of that script.
> Lastly, you could just let you application attempt authenticating
> against each server, in turn, stopping once it succeeds.
> 
> Cheers,
> -nic
> 
> --
> Nic Bernstein n...@onlight.com
> Onlight llc.  www.onlight.com
> 2266 North Prospect Avenue #610   v. 414.272.4477
> Milwaukee, Wisconsin  53202-6306  f. 414.290.0335
> 
> 
> This e-mail message (including any attachments) is for the sole use of
> the intended recipient(s) and may contain confidential and privileged
> information.  If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution
> or copying of this message (including any attachments) is strictly
> prohibited.
> 
> If you have received this message in error, please contact
> the sender by reply e-mail message and destroy all copies of the
> original message (including attachments).
> 
> Cyrus Home Page: http://cyrusimap.web.cmu.edu/
> Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
> List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
> 

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

RE: Vacation Application

[Gottschalk, David]

That looks great! I will check it out.

Thanks for the link.

David Gottschalk 
UTS Email team
david.gottsch...@emory.edu


-Original Message-
From: Kenneth Marshall [mailto:k...@rice.edu] 
Sent: Tuesday, March 10, 2009 3:06 PM
To: Gottschalk, David
Cc: Nic Bernstein; info-cyrus@lists.andrew.cmu.edu
Subject: Re: Vacation Application

We use SmartSieve (http://smartsieve.sourceforge.net/) to
manage vacation/sieve scripts. We look up the appropriate backend
in our LDAP directory, but a DNS lookup could be done just as
easily. It is simple to setup an configure, 1.0RC2.

Cheers,
Ken

On Tue, Mar 10, 2009 at 03:00:39PM -0400, Gottschalk, David wrote:
> No murder here.
> 
> Oldschool Cyrus setup. I want to upgrade it actually, but there are 30K + 
> accounts on these 3 servers.
> 
> The only problem I see with having it try each server, but failing how do you 
> know if it really isn't that server, or there is just a network issue.
> 
> David Gottschalk
> UTS Email team
> david.gottsch...@emory.edu
> 
> 
> -Original Message-
> From: Nic Bernstein [mailto:n...@onlight.com]
> Sent: Tuesday, March 10, 2009 2:00 PM
> To: Gottschalk, David
> Cc: info-cyrus@lists.andrew.cmu.edu
> Subject: Re: Vacation Application
> 
> On 03/10/2009 12:42 PM, Gottschalk, David wrote:
> > Hi All,
> >   I have a question regarding a vacation application for Cyrus servers. I 
> > want to know what others are using to meet this need. Currently, we have a 
> > home grown application that allows users to enable/disable vacation 
> > messages for their Cyrus accounts. This application is old and outdated, 
> > and needs to be replaced. I found the Horde vacation application which 
> > looks like it will meet my needs, but I have one issue. We currently have 
> > three Cyrus servers with all the accounts spread out across those three 
> > servers. The problem I am running into with any vacation application, is 
> > how to identify to the vacation application which server a user is on 
> > without the user needing to know this information. Is anyone else in a 
> > similar situation?
> >
> Um, use a murder?  Otherwise you may want to adapt something like the
> cyrus user validation script which was recently posted here.  Your
> application could then perform lookups in the output of that script.
> Lastly, you could just let you application attempt authenticating
> against each server, in turn, stopping once it succeeds.
> 
> Cheers,
> -nic
> 
> --
> Nic Bernstein n...@onlight.com
> Onlight llc.  www.onlight.com
> 2266 North Prospect Avenue #610   v. 414.272.4477
> Milwaukee, Wisconsin  53202-6306  f. 414.290.0335
> 
> 
> This e-mail message (including any attachments) is for the sole use of
> the intended recipient(s) and may contain confidential and privileged
> information.  If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution
> or copying of this message (including any attachments) is strictly
> prohibited.
> 
> If you have received this message in error, please contact
> the sender by reply e-mail message and destroy all copies of the
> original message (including attachments).
> 
> Cyrus Home Page: http://cyrusimap.web.cmu.edu/
> Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
> List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
> 

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Announcing cyrus-user-map, a local recipient map generator for Postfix

[Omni Flux]

I have a policy daemon which verifies quotas via smmapd. I have not
looked at it in a long time, but maybe it can be easily extended to
verify mailbox existence as well?

It is available at http://www.omniflux.com/devel/

It does have some shortcomings such as not supporting virtual domains,
but this is because I haven't needed that, not because it cannot be done.

-- 
Omni Flux

Farzad FARID wrote:
> Thanks to you and Eric Luyten for the information on the small overhead. 
> So until someone ports smmapd to Postfix I agree that the recipient 
> address validation setting is sufficient.



Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Replication question

[Gary W. Smith]

A couple weeks back I asked about combining multiple stores into a
single one and someone recommended replication.  So I started playing
around with it to populate a new store from an existing.  This seems to
be working fine.  I still have a little more testing to do though.

My question is about the multiple mail stores.  Each mail store has
unique names.  I assume the only thing I need to do is configure all of
the masters to replicate to the backend and then run sync_client (with a
list of all of the unique mailbox names for that server) on each of the
mail stores. 

Is this correct?

Also, if they have sieve rules in place, do these copy over as well or
is it just the mailbox?

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Calling all regressions

[Bron Gondwana]

On Tue, Mar 10, 2009 at 01:33:00PM -0400, Wesley Craig wrote:
> On 10 Mar 2009, at 08:51, Michael Menge wrote:
> > I think i should rephrase my question.
> >
> > Is there a way for cyrus to know that it was updated
> > since the last time it did run, so it can do the things
> > suggested by Bron.
> 
> Perhaps we should add a config option with no default whose value  
> must be the version of the software you're running.

Hmmm v2.3.13-fmsvn18309-5c1c69c4 ;)  It makes inplace updates
a cow, since cyrus detects the new file and automatically closes
old processes and starts new ones.  Pretty tricky.

Though a configuration with no default that said "running Cyrus 2.3
series" would be reasonable.

Actually, I think at this point I would recommend releasing
Cyrus 2.4 based on our current stable plus this change, and
require a config variable that said "I'm running Cyrus 2.4".

At this point I would also recommend revisiting EVERY config
option and making the default be the best value (in our humble
opinions) rather than the backwards compatible one.  I have
written about this before - and I think it's a jump we should
take pretty soon, to get all new users using the best possible
options without having to maintain a giant config file.

Bron.

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Calling all regressions

[Simon Matter]

> On Tue, Mar 10, 2009 at 01:33:00PM -0400, Wesley Craig wrote:
>> On 10 Mar 2009, at 08:51, Michael Menge wrote:
>> > I think i should rephrase my question.
>> >
>> > Is there a way for cyrus to know that it was updated
>> > since the last time it did run, so it can do the things
>> > suggested by Bron.
>>
>> Perhaps we should add a config option with no default whose value
>> must be the version of the software you're running.
>
> Hmmm v2.3.13-fmsvn18309-5c1c69c4 ;)  It makes inplace updates
> a cow, since cyrus detects the new file and automatically closes
> old processes and starts new ones.  Pretty tricky.
>
> Though a configuration with no default that said "running Cyrus 2.3
> series" would be reasonable.
>
> Actually, I think at this point I would recommend releasing
> Cyrus 2.4 based on our current stable plus this change, and
> require a config variable that said "I'm running Cyrus 2.4".
>
> At this point I would also recommend revisiting EVERY config
> option and making the default be the best value (in our humble
> opinions) rather than the backwards compatible one.  I have
> written about this before - and I think it's a jump we should
> take pretty soon, to get all new users using the best possible
> options without having to maintain a giant config file.

As a package maintainer I would be happy to see some more advanced options
being the default. My rpms have different defaults but that requires
patching not only the options file but also the docs to reflect the
changes. Unfortunately it can still lead to confusion if people "forget"
to read the manpage and other docs.

About the config variable discussed above:
Since my rpms do quite some magick to make upgrades work without any user
intervention, I had this problem for a long time. One should keep in mind
that having old config files is one thing, the other thing are old
configdir/spooldirs. My solution for the latter was to maintain a db
config file in the rpm package, and maintain another db config file in the
configdir. That way the init script evaulates the two db configs and the
imapd config, it they don't match it takes any action it needs and then
writes the new config to the configdir. That way you can also transfer a
configdir/spooldir from another server with different cyrus-imapd version
to the current server and things will still work correctly. Or you can
change imapd.conf and the changes will take effect on the configdir on
startup.

At the moment the db config includes the db version and the sieve version
like this:
annotation_db=skiplist
duplicate_db=skiplist
mboxkey_db=skiplist
mboxlist_db=skiplist
ptscache_db=skiplist
quota_db=quotalegacy
seenstate_db=skiplist
sieve_version=2.2.3
statuscache_db=skiplist
subscription_db=flat
tlscache_db=skiplist

My question is how can all this be implemented in cyrus-imapd without too
many changes. What about having a function to read all current setting
(something like postconf does in postfix) and have cyrus-imapd maintain a
copy of this in the configdir? That way cyrus-imapd or the init script
could check whether both configs match enough and they action or refuse to
start if they don't match. The config file should not only include
configurable options but also internal options like what I did with the
sieve_version to reflect internal changes. Cyrus-imapd does handles a lot
of those changes on the fly but not all, live upgrading sieve scripts, and
those should be found in the configs.

Regards,
Simon


Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html