Re: qmail + procmail + cyrus
Yeah ... this is what I did (keep in mind I had to implement the procmail systemwide since the mail has to go to procmail PRIOR to deliver ... So if I makr [EMAIL PROTECTED] as pure spam then all cyrus users will never get those messages (if you cat to /dev/null) ... here is how I did it... (you could change this to make it NOT system wide btw) in your .qmail-domain-default | /usr/bin/preline /usr/bin/procmail -a $EXT2 Keep in mind that my .qmail-domain-default is OWNED by cyrus (ie. user cyrus controls .qmail-domain) - $EXT2 is a env variable set by qmail - see http://www.lifewithqmail.org for more info on qmail env vars. Then in your .procmailrc ... TRASH='Spam' DELIVER=/usr/cyrus/bin/deliver CYUSER=$1 AMAVIS=/usr/cyrus/bin/amavis-stdin :0w:$CYUSER.lock | tail +2 | $AMAVIS $CYUSER | $DELIVER -e -a $CYUSER -m user.$CYUSER Alternatively this will send spam to the spam folder ... (using razor - which kicks ass ...) :0 Wc | razor-check :0 Waf | tail +2 | $AMAVIS $CYUSER | $DELIVER -e -a $CYUSER -m user.$CYUSER.$TRASH You may notice amavis takes stdin (which is not the norm) I've hacked it extensively to work with procmail/qmail. If you are interested in this version of it (which should be a simple drop in) email me offlist - it requires you us the mcaffee virus scanner ... This is how I set up qmail+cyrus+procmail+amavis+razor :) --Joe On Thu, Jan 24, 2002 at 05:34:32PM -0800, Erik Myllymaki wrote: > You have any luck with this combo? > > I am at the stage too where I am so close but yet so far away ;-) > > TIA, > > > -- > > Erik Myllymaki > [EMAIL PROTECTED] Joe Stump <[EMAIL PROTECTED]> "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." msg05668/pgp0.pgp Description: PGP signature
dothack and cyrus 2.0.16
Hi: We are locking for "dothack" patch in order to be able to create logins with dots... i.e. enric.ramos.atlassolutions.net so in cyradm ... we should do "cm user_enric.ramos.atlassolutions.net" or something like this... I know that in cyrus-imapd-2.0.12 this patch exists... I have applied this patch into cyrus-imapd-2.0.16 but it doesn't work... Could someone provide me this patch for this exact version ? (2.0.16) It's urgent !! I will really appreciate your help. regards, Enric Ramos Atlas Internet Solutions Telf: +34 934 452 461 - Fax: +34 934 452 462 e-mail: [EMAIL PROTECTED] -http://www.atlassolutions.net * La información transmitida en este mensaje es CONFIDENCIAL y está dirigida únicamente al destinatario del mensaje arriba indicado. No puede ser transmitida ni revelada a persona distinta del destinatario sin autorización expresa del remitente. La recepción de este mensaje, por cualquier causa, por persona distinta al destinatario del mismo no le autoriza para hacer uso alguno de la información. En este caso queda prohibida, y puede ser ilícita, cualquier divulgación, copia, distribución y/o cualquier uso de la información. Le rogamos borre inmediatamente el mensaje de su sistema y, en su caso, todas las copias del mismo y lo notifique al remitente. Gracias.
Re: [Exim] Cyrus/Exim incompatibility
--On Thursday, January 24, 2002 12:04 PM -0500 Ken Murchison <[EMAIL PROTECTED]> wrote: > Yeah, I mentioned this to Larry a while back, but he didn't really like > the idea. I don't remember his exact reasoning, but I think it had > something to do with not knowing whether the reject/vacation message > ever got sent or something. Larry? > > I would be nice if there was some kind of LMTP/ESMTP backchannel for > sending out a responses to a message just delivered, via the already > open connection to the MTA. I think SMTP TURN may do this, but its use > is deprecated. Hmm. Why not just jave LMTP keep an SMTP connection (or pool of connections) permanently open, and send all messages through that using RSET after each one? Wouldn't that be more efficient than calling sendmail/exim etc once per message if the volume gets to be large? -- Cyrus Daboo
Re: [Exim] Cyrus/Exim incompatibility
John Holman wrote: > > At 15:25 24/01/02, Ken Murchison wrote: > > >Philip Hazel wrote: > > > > > > On Wed, 23 Jan 2002, John Holman wrote: > > > > > > > Messages generated by Cyrus's lmtpd (e.g. as the result of a sieve > > vacation > > > > or reject rule) are created with CRLF as line terminators and piped > > to the > > > > mail program (by default sendmail, which in our case is actually > > > > exim). Messages presented to sendmail in this way should, I think, > > > > conform to the Unix conventions for line termination rather than > > those for > > > > SMTP, and therefore not contain CR characters. > > > > > > This is also my view. > > > > > > > This suggests that exim's author, at least, would consider Cyrus to be > > > > broken in this respect! > > > > > > I am Exim's author. > > > >Is there a spec or reference which states that when sending a message to > >an MTA via stdin that only LF should be used as the line terminator? Or > >are people saying that this is best common practice? > > My guess is that there is no real standard, but I think it makes sense when > passing a message to an MTA via stdin to comply with the conventions of the > local operating system. That would mean LF under Unix, CRLF under Windows etc. > > Actually, if it's true that there are no standards to be upheld, I also > think it would be better for Exim (which claims to be a Sendmail clone > insofar as the command line interface is concerned) to accept either CRLF > or LF as a line terminator when mail is presented on standard input, if > that is what Sendmail does. Agreed. But on the flip side, if there is a best common practice (whether officially documented or not), we should probably follow it. > As Lawrence has said, Cyrus could avoid the issue entirely by connecting to > an SMTP server when it sends mail. Yeah, I mentioned this to Larry a while back, but he didn't really like the idea. I don't remember his exact reasoning, but I think it had something to do with not knowing whether the reject/vacation message ever got sent or something. Larry? I would be nice if there was some kind of LMTP/ESMTP backchannel for sending out a responses to a message just delivered, via the already open connection to the MTA. I think SMTP TURN may do this, but its use is deprecated. Hmm. Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: [Exim] Cyrus/Exim incompatibility
At 15:25 24/01/02, Ken Murchison wrote: >Philip Hazel wrote: > > > > On Wed, 23 Jan 2002, John Holman wrote: > > > > > Messages generated by Cyrus's lmtpd (e.g. as the result of a sieve > vacation > > > or reject rule) are created with CRLF as line terminators and piped > to the > > > mail program (by default sendmail, which in our case is actually > > > exim). Messages presented to sendmail in this way should, I think, > > > conform to the Unix conventions for line termination rather than > those for > > > SMTP, and therefore not contain CR characters. > > > > This is also my view. > > > > > This suggests that exim's author, at least, would consider Cyrus to be > > > broken in this respect! > > > > I am Exim's author. > >Is there a spec or reference which states that when sending a message to >an MTA via stdin that only LF should be used as the line terminator? Or >are people saying that this is best common practice? My guess is that there is no real standard, but I think it makes sense when passing a message to an MTA via stdin to comply with the conventions of the local operating system. That would mean LF under Unix, CRLF under Windows etc. Actually, if it's true that there are no standards to be upheld, I also think it would be better for Exim (which claims to be a Sendmail clone insofar as the command line interface is concerned) to accept either CRLF or LF as a line terminator when mail is presented on standard input, if that is what Sendmail does. As Lawrence has said, Cyrus could avoid the issue entirely by connecting to an SMTP server when it sends mail. John. >-- >Kenneth Murchison Oceana Matrix Ltd. >Software Engineer 21 Princeton Place >716-662-8973 x26 Orchard Park, NY 14127 >--PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: Cyrus/Exim incompatibility
At 16:05 24/01/02, Lawrence Greenfield wrote: >Date: Thu, 24 Jan 2002 09:49:59 + (GMT) >From: Philip Hazel <[EMAIL PROTECTED]> > >On Wed, 23 Jan 2002, John Holman wrote: > >> Messages generated by Cyrus's lmtpd (e.g. as the result of a sieve > vacation >> or reject rule) are created with CRLF as line terminators and piped > to the >> mail program (by default sendmail, which in our case is actually >> exim). Messages presented to sendmail in this way should, I think, >> conform to the Unix conventions for line termination rather than > those for >> SMTP, and therefore not contain CR characters. > >Sendmail has, for many many years, dynamically adjusted to CRLF >instead of LF. I suppose I could pass the "-ba" flag, which might >tell /usr/lib/sendmail to expect CRLF, but I'd worry that any sendmail >wrapper that doesn't deal with CRLF won't deal with the -ba flag. Certainly that doesn't seem to be a flag that Exim recognizes, so it wouldn't help in this particular case. >I suppose I should just make Cyrus connect to an SMTP server so I know >what sort of beast I'm dealing with. I think that would be a good thing to do. John.
Cyrus and SSL - not like you've heard that one before...
Hiya all, just a quick question: how does cyrus determine whether it will accept a connection or not. I have cyrus set up on a protected machine, all local users can sucessfully use IMAPS to talk to it. Out IP addresses are partitioned into subnetworks. Machines on other subnetoworks can use IMAPS fine. Machines _oustide_ our network are refused by our firewall if they try IMAP (as I've instructed it) but the firewall lets IMAPS through and cyrus is giving the message imapd: refused connection from xxx.xxx.xxx.xxx is it looking into hosts.allow (we're running redhat 6.2)? The client is reporting an error and saying the server dropped us. Client is Outlook Express - but again is working fine on our internal network. Absolutely _any_ thoughts welcome. Cheers, Jim Grimmett. Systems Manager, Department of Computer Science, University of Bath. Internal Tel: 3084 ; External Tel: (01225) 323084 ; Mobile: 07989 595399
Re: [Exim] Cyrus/Exim incompatibility
Date: Thu, 24 Jan 2002 09:49:59 + (GMT) From: Philip Hazel <[EMAIL PROTECTED]> On Wed, 23 Jan 2002, John Holman wrote: > Messages generated by Cyrus's lmtpd (e.g. as the result of a sieve vacation > or reject rule) are created with CRLF as line terminators and piped to the > mail program (by default sendmail, which in our case is actually > exim). Messages presented to sendmail in this way should, I think, > conform to the Unix conventions for line termination rather than those for > SMTP, and therefore not contain CR characters. Sendmail has, for many many years, dynamically adjusted to CRLF instead of LF. I suppose I could pass the "-ba" flag, which might tell /usr/lib/sendmail to expect CRLF, but I'd worry that any sendmail wrapper that doesn't deal with CRLF won't deal with the -ba flag. I suppose I should just make Cyrus connect to an SMTP server so I know what sort of beast I'm dealing with. Larry
Re: Why doesn't IMAPd 2.1.1 support libsasl?
Jeremy Howard wrote: > > Rob Siemborski wrote: > > This would be possible with an LDAP auxprop plugin that correctly served > > the userPassword property. > > > I haven't come across "auxprox" or "auxprop plugins" before. > > Can you give a quick summary of what this is or a link to a backgrounder? doc/plugprog.html#auxprop in the SASL distribution. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: [Exim] Cyrus/Exim incompatibility
Philip Hazel wrote: > > On Wed, 23 Jan 2002, John Holman wrote: > > > Messages generated by Cyrus's lmtpd (e.g. as the result of a sieve vacation > > or reject rule) are created with CRLF as line terminators and piped to the > > mail program (by default sendmail, which in our case is actually > > exim). Messages presented to sendmail in this way should, I think, > > conform to the Unix conventions for line termination rather than those for > > SMTP, and therefore not contain CR characters. > > This is also my view. > > > This suggests that exim's author, at least, would consider Cyrus to be > > broken in this respect! > > I am Exim's author. Is there a spec or reference which states that when sending a message to an MTA via stdin that only LF should be used as the line terminator? Or are people saying that this is best common practice? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: [Exim] Cyrus/Exim incompatibility
On Wed, 23 Jan 2002, John Holman wrote: > Messages generated by Cyrus's lmtpd (e.g. as the result of a sieve vacation > or reject rule) are created with CRLF as line terminators and piped to the > mail program (by default sendmail, which in our case is actually > exim). Messages presented to sendmail in this way should, I think, > conform to the Unix conventions for line termination rather than those for > SMTP, and therefore not contain CR characters. This is also my view. > This suggests that exim's author, at least, would consider Cyrus to be > broken in this respect! I am Exim's author. -- Philip HazelUniversity of Cambridge Computing Service, [EMAIL PROTECTED] Cambridge, England. Phone: +44 1223 334714.
Re: Cyrus/Exim incompatibility
At 04:57 24/01/02, Amos Gouaux wrote: >jh> Messages generated by Cyrus's lmtpd (e.g. as the result of a sieve >jh> vacation or reject rule) are created with CRLF as line terminators >jh> and piped to the mail program (by default sendmail, which in our >jh> case is actually exim). Messages presented to sendmail in this way >jh> should, I think, conform to the Unix conventions for line >jh> termination rather than those for SMTP, and therefore not contain CR >jh> characters. > >To quote RFC2033: > >Although LMTP is an alternative protocol to ESMTP, it uses (with a >few changes) the syntax and semantics of ESMTP. This design permits >LMTP to utilize the extensions defined for ESMTP. Certainly true when lmtpd is handling an incoming message over LMTP. But lmtp is not speaking LMTP when it *sends* vacation or reject messages - it calls sendmail on the command line and passes the message on the standard input. John.
