that is a very interesting idea.

Our problem is that our mail front ends and our mail backends 
are distributed across many machines. And that we have
sendmail at the core.

So we have some fundamental design questions to look at.



Cooper Stevenson <[EMAIL PROTECTED]> writes:

 % On Fri, 2003-07-18 at 10:50, John Sechrest wrote:
 % > We are running Cyrus at PEAK. 
 % > 
 % > It does some things nicely.
 % > 
 % > However, it has broken all of the procmail and .forward 
 % > based mail filtering. And so has broken many people.
 % 
 % John, I ran into the same thing during my test with Cyrus. The problem
 % was how to call Procmail from Postfix for destination to Cyrus IMAP. I'm
 % not certain that this is what you ran into but if so here's the way to
 % make Postfix call your procmail recepies and then deliver to the Cyrus
 % IMAP store:
 % 
 % In /etc/postfix/main.cf modify your mailbox_transport parameter to this:
 % 
 %   mailbox_transport = cyrus_procmail
 % 
 % The cyrus_procmail definition is one you will create in
 % /etc/postfix/main.cf.
 % 
 % Back up your modification in main.cf with this added line in 
 % /etc/postfix/master.cf:
 % 
 %   cyrus_procmail  unix  -       n       n       -       -       pipe
 %   flags=R user=cyrus argv=/usr/bin/procmail -m /etc/procmailrc ${user}
 % 
 % This calls procmail in "general purpose" mode and will pass the 'user'
 % argument to /etc/procmailrc... a parameter that as I understand it is
 % usually lost.
 % 
 % Finally, simply add the following to your /etc/procmailrc file as best
 % suits your needs:
 % 
 % ###########################################################
 % ### Deliver it to the user inbox
 % ###########################################################
 %                                                                                 
 %  :0
 %  | /usr/cyrus/bin/deliver -a $1 -m user.$1
 % 
 % 
 % That's it, happy people!
 % 
 % 
 % -Cooper
 % 
 % 
 % 
 % 
 % > 
 % > 
 % > I have chosen to take spam instead of moving to cyrus personally
 % > because I process on the order of 4000 messages a day. And
 % > with Cyrus breaking all the tools that I currently use, I would
 % > not be able to function.
 % > 
 % > Cyrus uses a specific structure for message storage. And
 % > as such, samba would not work underneath it.
 % > 
 % > 
 % > I would leave an escape for the onid users who try to filter
 % > mail. Loosing procmail is a big loss. The cyrus filter tools
 % > are not nearly as flexible nor as powerful.
 % > 
 % > 
 % > 
 % > 
 % > Cooper Stevenson <[EMAIL PROTECTED]> writes:
 % > 
 % >  % Scott,
 % >  % > 
 % >  % > We're accomplishing the same with a slightly different setup:
 % >  % > 
 % >  % > postfix + amavisd + spamassasin + clamav + cyrus imapd
 % >  % 
 % >  % Right, but Cyrus's IMAP server, while very fast and scalable, does not
 % >  % (to the best of my knowledge) allow an administrator to mount Samba
 % >  % shares under it's IMAP namespace. Don't get me wrong, I love Cyrus but
 % >  % it employs it's own indexing, making it a "black box" for server shares.
 % >  % If you know a way to do this, I am all ears as I found Cyrus's IMAP
 % >  % server very reliable and fast. 
 % >  % 
 % >  % > 
 % >  % > Right now we have 2 forward facing mail relays that handle email for
 % >  % > most all of campus.  These relays run amavisd which is sort of a
 % >  % > container for all of these tools like spamassasin and clamav.  It allows
 % >  % > you to quickly and easily modify your filtering tools without having to
 % >  % > muck with Postfix.
 % >  % 
 % >  % Love Amavisd for virus scanning to protect Windows clients. Does Amavisd
 % >  % let you call SpamAssassin during the MTA phase?
 % >  % 
 % >  % > 
 % >  % > This summer we're switching to using lmtp to deliver to a Cyrus IMAP
 % >  % > store for all 35,000 ONID accounts.  I'm just as curious as all of you
 % >  % > are on how that is going to work ... :-)
 % >  % 
 % >  % :-) !!
 % >  % 
 % > 
 % > -----
 % > John Sechrest          .         Helping people use
 % > CTO PEAK -              .           computers and the Internet
 % > Public Electronic         .            more effectively
 % > Access to Knowledge,Inc       .                      
 % > 1600 SW Western, Suite 180       .            Internet: [EMAIL PROTECTED]
 % > Corvallis Oregon 97333               .                  (541) 754-7325
 % >                                             . http://www.peak.org/~sechrest
 % -- 
 % --------------------------------------------------------------
 % | Cooper Stevenson        | Em: [EMAIL PROTECTED] |
 % | Open Source Consultant  | Ph: 541.924.9434                 |
 % --------------------------------------------------------------
 % 

-----
John Sechrest          .         Helping people use
CTO PEAK -              .           computers and the Internet
Public Electronic         .            more effectively
Access to Knowledge,Inc       .                      
1600 SW Western, Suite 180       .            Internet: [EMAIL PROTECTED]
Corvallis Oregon 97333               .                  (541) 754-7325
                                            . http://www.peak.org/~sechrest
_______________________________________________
EuG-LUG mailing list
[EMAIL PROTECTED]
http://mailman.efn.org/cgi-bin/listinfo/eug-lug

Reply via email to