Re: Slow response -logs
Troy, On 15 Jan 2004, Troy McKinnon writes: I also notice that telneting to port 25 is VERY SLOW. Does this mean it is more likely a postfix issue vs cyrus etc? Anything else I can do to help narrow down and locate the bottleneck? Delays of about a minute traditionally mean you have a DNS resolution problem, possibly for localhost or for the server's 'real' hostname. Can you do ping localhost and ping `hostname` at a shell prompt on your server and get rapid results? If DNS is the problem, you would see a big delay whle the system tries and fails to do the DNS lookups of localhost and the host name. As further confirmation, check that telnet 127.0.0.1 1 is quickly rejected, but telnet localhost 1 or telnet `hostname` 1 get delayed, and then rejected. That would pretty much confirm it is a DNS-related issue. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: multiple services doesn´t start
On 3 Dec 2003, Joachim Hummel writes: I would like defined some of this ip-addresses to listen the imap and = pop3 daemon. For example: imap cmd=imapd listen=XXX.XXX.148.1:imap prefork=0 imap cmd=imapd listen=XXX.XXX.148.2:imap prefork=0 Dec 2 23:19:45 server master[16150]: multiple entries for service 'imap' I believe you must give each service a unique name (the first entry on each line). For example, call them imap01, imap02, imap03 and so on, not all just imap. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: stuck lmtpd processes
On 24 Sep 2003, Andrew Morgan writes: I've just ran into this problem again. This time I have the gdb backtrace of both the lmtpd process trying to get the lock and the imap process holding the lock. There is nothing new in the lmtpd backtrace. Here is the imapd backtrace: 0x402ae3c4 in read () from /lib/libc.so.6 (gdb) bt #0 0x402ae3c4 in read () from /lib/libc.so.6 #1 0x40111fc4 in TXT_DB_version () from /usr/lib/libcrypto.so.0.9.6 #2 0x41754277 in ?? () Cannot access memory at address 0x62416b47 So I'm a little stuck here. I don't know enough about gdb to find out what it is actually trying to read from, although the network seems like a reasonable guess. I'm guessing here, but is this at all related to the insufficient randomness thing where reading from /dev/random hangs until more entropy gens generated? A read from code in libcrypto that hangs things ... it all sounds strangely familiar! If my guess is somewhat close to correct, then a temporary workaround (which worked on Red Hat 7.3 for me) may be to do cd /dev mv random random.orig ln -s urandom random A longer term fix may be to recompile the affected code to use /dev/urandom for its entropy source, rather than /dev/random? Hope this helps, Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
root mailboxes and aliasing (was: Re: cvt_cyrusdb_all)
On 6 Aug 2003, Simon Matter writes: root should not have a mailbox. I agree for normal systems. However, in certain situations it may be useful to have a 'root' mailbox. If you have local_transport = lmtp:unix:/var/lib/imap/socket/lmtp in /etc/postfix/main.cf to make single instance store work as expected, the aliases file has no effect and postfix will deliver syslog messages to root. One can then grant access to this box for other users via Cyrus. If you use mailbox_transport = lmtp:unix:/var/lib/imap/socket/lmtp instead, aliases seem to work fine (so root can be aliased as usual). Does this approach disable single instance store?? We use Postfix 2.0.11-2 RPMs on Red Hat 8.0 here this way. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: cyradm and spaces
On 22 Jul 2003, joe ritter writes: localhost.localdomain cm user.chef2b.Dollar Bill createmailbox: Unexpected extra arguments to Create (1) Make sure the user.chef2b mailbox already exists. (2) Try escaping all spaces in the mailbox name with a backslash, rather than quoting the whole string. localhost.localdomain cm user/chef2b localhost.localdomain cm user/chef2b/Dollar\ Bill localhost.localdomain works fine here, against 2.1.11. I'm using unixhierarchysep: yes, hence the use of / where you had . in the example. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
RE: Is it possible to store user contact/ address book in imap server?
On 15 Jul 2003, David H. Lynch, Jr. writes: There is nothing special about contact/address book information. There is no reason you can not store contacts, tasks, calendar items, ... In any IMAP server you choose. All they are is specially formatted messages. The Problem is that there are no IMAP clients that can properly understand and treat those messages as contacts, tasks, ... No IMAP clients? Ximian Evolution might qualify as one? :-) For most enterprises, MS Outlook is the de facto expected and desired client, like it or loathe it, for this sort of email plus calendaring plus contacts setup. The (commercial) Bynari Insight Connector addin for Outlook handles this. It is IMO far from perfect as an overall email/ calendaring/ contacts solution, and has had some significant stability issues on the client in the past. But if you really need this functionality, it does get the job done. While officially Bynari will only support it when used with their Insight Server, Insight Server is really a package of Postfix + Cyrus + Apache + ProFTPd and a pretty web-based management interface, so it can be used against Cyrus if you are willing to experiment a little. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
SqurrelMail and TLS support (was: Re: Webmail -- What's recommended?)
On 15 Jul 2003, [EMAIL PROTECTED] writes: Is it possible to use SSL/TLS connections to IMAP server from squirellmail? Yes, you can do that. Set the parameter: $use_imap_tls = true; in the /etc/squirrelmail/config.php file, and as long as you are running PHP 4.3 or later and have the openssl extension loaded in /etc/php.ini it will do STARTTLS when communicating with the IMAP server. This is in SquirrelMail 1.4.1, I think this capability was added in 1.4.0. You can also set $use_smtp_tls = true; for its connections to the SMTP server. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: [PROPOSAL] Sieve for shared mailboxes
On 8 Jul 2003, Ken Murchison writes: Just out of curiousity, are there any non-eLISP IMAP clients? Sure, all the ones written in other languages... oh, that's not what you meant? grin Parsing that as (non-e)LISP IMAP clients: One called PostOffice is at http://opensource.franz.com/postoffice/ and various IMAP history files say there was one for the old Xerox LISP machines, called MM-D. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: saslpasswd for batch adds
Joe, On 1 Jul 2003, joe ritter writes: However I am noticing that there is no documentation on adding all these Cyrus users to the sasldb2. What is the best way to handle this with more than a few thousand users. I looked at the man page for saslpasswd2 and it wasn't clear if it was capable of taking input from a tab delimited user/password file. We are using auxprop by the way. If anyone can share their experience or suggestions with this I would greatly appreciate it. AFAIK, saslpasswd2 can't use a tab-delimited username/pw file directly. However, it is designed for non-interactive use where the password is piped in on STDIN and the username is passed as a command line parameter. Something like: echo PASSWORD |saslpasswd2 -p -c username So, given a tab delimited username/password file, a quick line of Perl something like (perl -p -e s/^([^\t]+)\t(.*)$/echo '\2' |saslpasswd2 -p -c \1/ passwordlist) |sh would let you exec saslpasswd2 once per user (note, the above one liner probably breaks for passwords containing the single quote character). How long this would take for many thousands of users is not something I have any experience with, and the above is not exactly an optimized approach. It works for me for a few hundred users. If your auxprop does something interesting, it may be faster to bypass saslpasswd2 and create the database entries more directly? Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: Restricting IMAP (143) port just for Squirrelmail?
On 11 Jun 2003, Mark London writes: I would like to restrict Cyrus to only allow users to use IMAPS, not plain IMAP. However, I was told that would break Squirrelmail, unless I opened access to IMAP (port 143) for the node that Squirrelmail was running on. Iptables would probably be the most common way to achieve this sort of restriction. But I'm running XINETD on Redhat, and I've read Cyrus doesn't use that. I would need another TCP wrapper program ... Not really, as others have said already. Either configure cyrus to use tcp-wrappers, or use iptables to restrict the data flow instead of a wrapper. ..., or is there an easier way to do it? You could set up Cyrus to only allow IMAPS access, and then use stunnel on the squirrelmail machine to do the SSL/TLS tunneling for it. That way, no 'special' permissions would be needed on the cyrus server at all, from the cyrus perspective squirrelmail would use IMAPS just like other IMAPS clients. How this would impact performance (many SSL tunnels being created, when squirrelmail gets busy) is something you'd need to think about. Overall, which way (iptables, compiling cyrus to use a wrapper, or stunnel) is 'easier' depends on what software you are comfortable with... Which way is more secure against whatever threats you believe exist is probably a useful question to ask yourself, too (or else why bother with IMAPS at all!). If the Squirrelmail to Cyrus traffic can be sniffed by 'the bad guys', then IMO you need something to protect the accountname/password information and the email itself from such snooping, so stunnel on the Squirrelmail box (and 100% IMAPS only on the Cyrus server) might be appropriate. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
On Red Hat Linux use cyrus-imapd RPMs (was: Perl 5.8 and Cyrus Imap)
On 14 Mar 2003, [EMAIL PROTECTED] writes: I run cyradm in RedHat 7.2, perl-5.6 and just get these: Can't locate Cyrus/IMAP/Shell.pm in @INC (@INC contains: /usr/lib/perl5/5.6.1/i386-linux /usr/lib/perl5/5.6.1 /usr/lib/perl5/site_perl/5.6.1/i386-linux /usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl/5.6.0/i386-linux /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl .). BEGIN failed--compilation aborted. I suggest that you completely remove your attempted hand-compiled cyrus installation, and use the Red Hat RPMs from http://home.teleport.ch/simix/ instead. Simon Matter already did the work of configuring cyrus to work well with Red Hat if you use these RPMs instead of trying to configure cyrus by hand yourself. If for some special reason you really *need* to hand compile cyrus, then at least grab his cyrus-imapd SRPM, unpack it, and look carefully through the patches and .spec file to see how it was done. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: On Red Hat Linux use cyrus-imapd RPMs (was: Perl 5.8 and Cyrus Imap)
On 14 Mar 2003, [EMAIL PROTECTED] writes: I suggest that you completely remove your attempted hand-compiled cyrus installation, and use the Red Hat RPMs from http://home.teleport.ch/simix/ not exactly right, I just install tarball cyrus-sasl 1.5 before, then I install cyrus-imap-2.1 more than twice. OK, so uninstall all traces of *all* those hand installs! and I think every time the newer shall replace the older files, will it ?? That depends a lot on how you configure things each time. I never use rpm or srpm package of cyrus-imap and cyrus-sasl. Why ever not? They work fine, and save you a lot of trouble. I really suggest that you try them. But delete all the old hand-installed stuff first. You have chosen to use an RPM-based OS distribution. So, when RPMs exist for your OS and architecture, using them saves you a lot of work, and avoids re-inventing the software configuration for your setup by hand the hard way, and getting confused. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
RE: Questions about LDAP schema and Multi-Domain IMAP
On 5 Mar 2003, Howard Chu writes: Note that OpenLDAP 2.0.X does not work with Cyrus SASL 2.1.x anyway, so you need OpenLDAP 2.1 if you're already using SASL 2.1. I believe this general statement to be incorrect. That combination certainly seems to work fine here, in a multi-server multi-domain international directory and email deployment. OpenLDAP 2.0.27 and cyrus-sasl-2.1.7 or -2.1.10 or -2.1.12 have all worked (currently on Red Hat 7.3, on x86 SMP hardware). Please could you provide specific details on how and why this does not work? Thanks. Recommending that sysadmins 'throw away' the mainstream and well understood way of doing something, in favour of the 'latest and greatest', is not always appropriate. Working with bleeding edge software, perhaps not available in the packaging format your chosen OS distribution uses, is likely to be inconvenient at best, and lead to increased maintenance costs over time. Red Hat 8.0 ships with OpenLDAP 2.0.27 too, so using that distribution it may still be appropriate to stay with that version of OpenLDAP. Even the current Red Hat 8.1 beta release, Phoebe, sticks with OpenLDAP 2.0.27. It might also have been helpful to state that you are an OpenLDAP developer, and so are naturally interested in getting people to migrate to the current release of your software :-) Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: LMTPD problems
On 21 Feb 2003, James Miller writes: Would the LOGFILE statement go into the .procmailrc recipe? Yes. Running the command man procmailrc will provide more details, if you need them. It seems to me LMTPD is rejecting the messages because of header problems. Only because what you are sending to lmtpd is not a valid message. lmtpd won't care about the *content* of headers (other than if they contain illegal 8bit chars), only the syntax of the message. Are there any know issues between cyrus and mimedefang? That combination works fine here. But I'm not adding procmail to the mix. I really don't want Cyrus doing any validation for me. Then you'd end up with a mailstore containing invalid messages, and later on clients would choke on them... better by far to reject invalid mail before it gets into the mailstore, surely! There are good reasons why RFCs for mail exist. I simply want it to deliver the [EMAIL PROTECTED]@#$_ messages into the mailstores.. is there a way to turn off all of the message/header validation checks? AFAIK, there aren't any checks per se other than for 8 bit chars. It's just that you need to give lmtpd a valid mail message to work with. IMO it is 100% reasonable for an LMTP daemon to insist that you feed it only correctly formatted messages, and to reject those which are bad. I suggest doing this one step at a time. 1) Can you deliver hand-created correctly formatted messages to cyrus via lmtpd (via deliver -l)? For example: 11:29:14 [EMAIL PROTECTED]:/home/jonathan# /usr/libexec/cyrus/deliver -l 220 testing.net LMTP Cyrus v2.2.prealpha-GRC-RPM-2.2-cvs.20030115 ready lhlo junk 250-testing.net 250-8BITMIME 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-SIZE 250-AUTH EXTERNAL 250 IGNOREQUOTA MAIL FROM: [EMAIL PROTECTED] 501 5.5.4 Syntax error in parameters mail from:[EMAIL PROTECTED] 250 2.1.0 ok rcpt to:[EMAIL PROTECTED] 250 2.1.5 ok data 354 go ahead Subject: test a test . 250 2.1.5 Ok quit 221 2.0.0 bye 11:34:46 [EMAIL PROTECTED]:/home/jonathan# If that works, then lmtpd is doing its job. If not, then forget procmail and MIMEdefang and all that other stuff, and get lmtpd working first. If you wish, at this stage you can try providing more and more complex messages with various headers (after the data command) and see which ones are valid and which ones are not. 2) Configure your MTA to just deliver mail to cyrus via LMTP. No procmail, no antivirus stuff, just deliver the [EMAIL PROTECTED]@#$_ messages as you put it! Does *that* work? 3) Add MIMEdefang as a sendmail milter or whatever other way you call it at your site. Does *that* work? 4) Add procmail. Does *that* work? If you proceed stepwise like this, it will be a lot easier to determine where the problem lies. The chances are high that some of your mail processing is resulting in invalid messages, which lmtpd then (correctly) rejects. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: compiling error - cannot find -lssl
On 18 Feb 2003, Mike O'Rourke writes: Did you compile SASL2 on your machine? If not, did you install it from the RPM's? RedHat (even as late as 8.0) only installs SASLv1 by default. The supplied cyrus-sasl RPMs for Red Hat 8.0 appear to me to include both SASLv1 and SASLv2 libraries. They work well enough for me. You are trying to use SASLv1 to compile Cyrus-IMAPd 2.1.11! Try installing SASLv2 from the RPM's, if you do not care to download and compile it as well. In general on Red Hat x86 machines it makes no sense to compile Cyrus from tarballs anyway. Just use the SRPMs for cyrus-imapd from Simon Matter at http://home.teleport.ch/simix/ instead, and you will get a usable Cyrus setup a lot sooner. If you need cyrus-imapd 2.2 from CVS (until 2.2 gets released), I find that it makes good sense to grab the CVS tree, turn it into a tarball, and edit the .spec file from Simon's SRPM to create a cyrus-imapd 2.2 SRPM and RPM set. As to your original problem, again you need to tip your hat to the kind folks at RedHat. The default install does not install the static libraries for OpenSSL. So, unless you have explicitely installed the static libraries (I am not even sure they are available on the disks), ... Try the openssl-devel RPM package, if you need the static libssl libraries. They are most certainly available and present on Red Hat CDs and FTP sites. Only those developing (compiling from source) for OpenSSL will ever need the static libraries, so placing them in a -devel package, and not installing the, by default, is entirely natural in the RPM world. What the default install does is not intended to be appropriate for developers or for production servers anyway, but for new users. Developers (and knowledgeable sysadmins building mailservers) are expected to be able to use the package management system that their chosen distribution uses. Fortunately for Red Hat admins who want to use Cyrus, Simon Matter has done most of the hard work for us, and create suitable RPMs already. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: Problem with cyrus and deleting a message with a virus.
On 21 Jan 2003, Mark London writes: Hi - We are running uvscan, and it will delete a cyrus message file that contains a virus. ... If you're messing around with the internal data stores of a program, and then you get upset when the program doesn't work, I'd say that you've created your own problem. I'm not messing with it, uvscan is doing it. Is there a better software alternative that will delete viruses on the server? Are we the only people using cyrus that are running virus scanning software on the server? How about checking for viruses before mail reaches Cyrus? Such as with a virus scanner that runs as a milter which sendmail talks to when it receives mail? Or a similar approach for whatever your chosen MTA is? We use RAV http://www.ravantivirus.com in its Sendmail-milter version with good results here. There is no really need to treat the cyrus mailstore as a pile of files, or to run software that naively does that (thereby causing your own problem, as has been pointed out) in order to scan email for viruses. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: Problem with cyrus and deleting a message with a virus.
On 21 Jan 2003, [EMAIL PROTECTED] writes: At 14:16 -0800 Jonathan Marsden wrote: How about checking for viruses before mail reaches Cyrus? Such as with a virus scanner that runs as a milter which sendmail talks to when it receives mail? Or a similar approach for whatever your chosen MTA is? Because (as mentioned elsewhere in this thread) lmtpd is not the only way messages can be stored on an IMAP server: eg think of sending a poisoned attachment, which magically ends up in your sent folder. I don't see the 'elsewhere in this thread' mail yet, but anyway: This is technically correct. (a) That 'poisoned attachment' came from somewhere -- where? If from a workstation within your organization, why didn't the virus scanning software on that workstation detect it? Shouldn't this be the first priority? For the attachment to be sent to the Sent folder, the primary layer of workstation virus protection must already have failed. If that happens at all frequently, there is an underlying issue which needs to be addressed on the workstations. (b) That attachment in the IMAP Sent folder can't exactly do much damage from there... it can't be sent to anyone, since the outgoing MTA will trap it. Sure, it can be read/downloaded/run by the sending user... but they already have a copy on their workstation anyway, else how did they get it into the IMAP server in the first place? (c) I suspect that 99.9% of viral email does in fact arrive over the SMTP/MTA channel, so if you configured the server file system scanner to *report* stuff it found under the Cyrus mail partitions(s) but not remove it, and also use an MTA-hosted scanner for the other 99.9%, you'd have a manual user support task for one virus in 1000. That task would be something like: go to or otherwise gain control over the user's workstation concerned, fix that workstation's virus issues if any, then use their mail client to delete that attachment from their Sent folder. This last part is probably not a huge additional workload, since you'd be dealing with the infected workstation anyway. If you absolutely have to have a way to delete rare viral messages from the Cyrus mailstore 100% automatically, I'd suggest writing a small Perl script making use of Cyrus::IMAP::Admin that looks at the output of your filesystem scanner (set to report only, not delete), looks at the content of the file(s) in question (to find a Message ID or other unique identifier) and logs into Cyrus as the admin user and deletes the message(s) concerned. As a general principle, external tools *must* *not* add/edit/delete files or directories within the Cyrus mailstore. Just as they must not add/edit/delete stuff within your Oracle, Postgres or MySQL databases. Cyrus gives you a well defined API (well, two: LMTP and IMAP!). Use them, and only them, to make changes to the Cyrus mailstore, and Cyrus will stay healthier than if you bypass them. Just because your chosen scanner apparently does not respect this principle in its current (default?) configuration, does not mean the problem lies with Cyrus :-) Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: Problem with invalid headers
On 17 Jan 2003, John Straiton writes: This one has been driving me crazy. I have a Cyrus/Postfix system in place that is working quite well. However, I have one customer who tries to deliver a particular message to an individual and I get a kick back that looks like this: Jan 13 11:22:33 courier postfix/pipe[7]: 2DBF85058B: to=[EMAIL PROTECTED], relay=cyrus, delay=0, status=bounced (data format error. Command output: asncin: Message contains invalid header ) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Mon, 13 Jan 2003 16:19:55 GMT I think that is a pretty unusual Date: header. I've never seen one with actual quote marks around the zone. I just ran through some mail archives with a few thousand messages, grepping out the Date: headers... none did that. And from my reading of RFC 822 and RFC2822 I don't think they are permitted. I'd guess that whoever implemented the client or MTA that added that Date: header did not know how to read the BNF in RFCs correctly. There are quote marks around the three letter zone specifiers (defined as obs-zone in Section 3.3 of RFC 2822) in the BNF. But that means to treat the stuff within them literally, not to include the actual quota marks in the resulting string :-) Disclaimer: I don't know if that *is* what Cyrus is complaining about, but it stands out to my eye as the 'odd' header in your message. Someone who knows the Cyrus codebase can probably quickly confirm or deny whether the quotes there would be a problem for the Cyrus Date: header parser or not. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: disable logging
On 17 Jan 2003, Woerns Urstmann writes: So you will want local6.info or somesuch.. thanks. but now i got it logging to /var/log/auth.log AND /var/log/messages - there is an entry in syslog.conf: # save the rest in one file *.*;mail.none;news.none -/var/log/messages the *.* is doing it, right? but if i remove it, am i loosing some important logging entries? (1) If you want auth.info in a separate file, add ;auth.none to the entry for /var/log/messages. So it would become more like: *.*;mail.none;news.none;auth.none -/var/log/messages (2) If you want the auth messages only in /var/log/messages, just delete your syslog.conf entry for /var/log/auth.log. Which way you do it just a matter of personal preference. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: How to get a cyrus-imapd-2.2 from CVS
On 28 Feb 2003, [EMAIL PROTECTED] writes: I want to download a Cyrus-imapd-2.2 from CVS and I tried the command cvs -d :pserver:[EMAIL PROTECTED]:/cvs login But I can't login. Would someone help me ? Maybe you forgot the password of anonymous? cvs -d :pserver:anoncvs:[EMAIL PROTECTED]:/cvs login export CVSROOT=:pserver:[EMAIL PROTECTED]:/cvs cvs -z3 co -d cyrus-imapd-2.2 -r cyrus-imapd-2_2 cyrus works for me. Then cd cyrus-imapd-2.2 sh SMakefile ./configure # Add any options you need to pass to configure make and you should be all set. To generate all the documentation in HTML and as text you also need to do (cd doc ; make -f Makefile.dist) Or, if you are working in a Red Hat Linux universe and would like SRPM and binary RPMs from the 2.2 CVS, I can make mine (based very heavily on Simon Matter's RPMs for 2.1.11) available. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: [SOLVED] Re: STARTTLS negotiation failed
On 13 Jan 2003, Steve Huston writes: Finally got it! I followed the exact instructions in the manual for creating a key, and for some reason that worked. Then I realized one other thing I changed in the /etc/imapd.conf file when I used that other key, that being tls_ca_file: It seems that the program doesn't like the CA file that comes with RedHat 8.0, and if I specify that file it chokes and dies *only* on TLS connections, SSL works fine. This makes perfect sense. Red Hat creates an initial host cert (not CA, I think) that uses localhost.localdomain as the host name (CN attribute). That 'works' for HTTPS web browsing, but generally fails for IMAPS and POP3S use. You just need the correct real hostname in your certificate. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
2.2cvs, imapd OK, pop3d hangs before sending banner to clients
On one of our (Red Hat 7.3, dual PIII CPU) servers running cyrus-imapd (2.2 CVS as of late September 2002), last night POP3 and POP3S access mysteriously stopped working. IMAP and IMAPS access are still fine. Looking at the logs shows things like: Jan 10 02:11:16 aerogram pop3s[17907]: DBERROR db4: 459 lockers Which is, shall we say, unusual. Since October we have seen only very small numbers of lockers in these messages. This server has only some tens of email users at present. Only the duplicate and tls db's use berkeley. Attempting to access the server via POP3 gets a connect and then nothing. Access via pop3s gets a connect, the full SSL handshake sequence, then nothing. Restarting cyrus-imapd did not help. cyradm version output is: name : Cyrus IMAPD version: v2.2.prealpha-GRC-RPM-2.2-cvs.20020926 2002/09/26 19:19:16 vendor : Project Cyrus support-url: http://asg.web.cmu.edu/cyrus os : Linux os-version : 2.4.18-17.7.xsmp environment: Built w/Cyrus SASL 2.1.7 Running w/Cyrus SASL 2.1.10 Sleepycat Software: Berkeley DB 4.0.14: (November 18, 2001) OpenSSL 0.9.6b [engine] 9 Jul 2001 CMU Sieve 2.2 TCP Wrappers mmap = shared lock = fcntl nonblock = fcntl auth = unix idle = poll mboxlist.db = skiplist subs.db = flat seen.db = skiplist duplicate.db = berkeley-nosync tls.db = berkeley-nosync We had upgraded cyrus-sasl to 2.1.10, but downgrading back to 2.1.7 did not change this issue. Attaching to one 'connected to but hung' pop3d with gdb shows a backtrace of: (gdb) bt #0 0x420dadf4 in read () from /lib/i686/libc.so.6 #1 0x4002a480 in __DTOR_END__ () from /usr/lib/libsasl2.so.2 #2 0x40024186 in randinit () from /usr/lib/libsasl2.so.2 #3 0x400241cd in sasl_rand () from /usr/lib/libsasl2.so.2 #4 0x40023e3f in sasl_mkchal () from /usr/lib/libsasl2.so.2 #5 0x0804cccb in service_main () #6 0x0805149b in main () #7 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) How can I best troubleshoot this further -- or is a quick fix already known? Thanks, Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: STARTTLS negotiation failed
On 10 Jan 2003, Steve Huston writes: Now, our current Cyrus server has a self-signed cert which Pine doesn't like unless you add /novalidate-cert to the hostname of the server. But this time, that doesn't even help as it just says There was an SSL/TLS failure for the server The reason for the failure was: SSL Negotiation failed Cyrus also reports the same thing in the logs. I understand the point of '/novalidate-cert', meaning don't try to check the signing authority on the cert, and I could overlook things if that was the only error. Use openssl s_client -connect server.your.domain:993 to see openssl negotiate with your server. The info you see (any warnings, etc.) may give you clues about what specifically Pine is complaining about. Alternatively, use openssl x509 -text path/to/my/sslcert.pem for both the server that Pine is happy with, and the one it is unhappy with, and compare the output by hand... what attributes are different or missing in your new self-signed cert? Longer term, you might want to create your own CA and sign the server hot cert with that CA. Then provide your public CA cert to Pine and, theoretically, you won't need /novalidate-cert If you have it around, connecting with mutt rather than Pine might also be a useful test? Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
CVS 2.2 no longer compilable under Red Hat 7.3?
Something in CVS 2.2 changed since 26 Sept 2002 that apparently makes for trouble compiling it under Red Hat 7.3. (1) The first issue is probably just the a lack of a #include mkgmtime.h before using a struct tm in lib/mkgmtime.c (make output at end of message). There is a similar omission (of #include gmtoff.h) in lib/gmtoff_tm.c as well. Why wouldn't a .c file include its own .h file? Must be an 'in progress' minor buglet. (2) Hacking those in gets me slightly further, but then I get gcc -c -I.. -I/usr/include/et -I/usr/local/include -I/usr/include -DHAVE_CONFIG_H -I. -I. -Wall -O2 -march=i386 -mcpu=i686 -fPIC \ cyrusdb.c cyrusdb.c: In function `cyrusdb_init': cyrusdb.c:77: `FNAME_DBDIR' undeclared (first use in this function) cyrusdb.c:77: (Each undeclared identifier is reported only once cyrusdb.c:77: for each function it appears in.) make: *** [cyrusdb.o] Error 1 which I have not (yet?) figured out. FNAME_DBDIR is defined in acconfig.h but nowhere else. Hacking its value (of /db) into the end of lib/cyrusdb.h gets me further... but I know that's a bad approach! Do I have an underlying autoconf or configure problem? (3) Even then, I soon get something about MASTER_PIDFILE in master.c ... Is CVS for 2.2 currently intentionally unusable? If so, when is it likely to become reasonably safe to grab and use once more? Or, am I just being (even) more dense than usual? If so, help getting the current CVS tree to compile would be welcomed :-) Thanks, Jonathan PS. There is also an issue with the search for libdes failing if I try to compile with Kerberos support, which I think is an older issue that has returned to haunt me? RH 7.3 lacks a libdes.a library, the needed functions are in libdes425.a instead. Looks like the configure checks got stricter, and now break on RH 7.3, though in September they worked OK? make[1]: Entering directory `/home/jonathan/cyrus-imapd-2.2/lib' gcc -c -I.. -I/usr/local/include -DHAVE_CONFIG_H -I. -I. -Wall -g -O2 \ acl.c gcc -c -I.. -I/usr/local/include -DHAVE_CONFIG_H -I. -I. -Wall -g -O2 \ assert.c gcc -c -I.. -I/usr/local/include -DHAVE_CONFIG_H -I. -I. -Wall -g -O2 \ bsearch.c gcc -c -I.. -I/usr/local/include -DHAVE_CONFIG_H -I. -I. -Wall -g -O2 \ charset.c gcc -c -I.. -I/usr/local/include -DHAVE_CONFIG_H -I. -I. -Wall -g -O2 \ glob.c gcc -c -I.. -I/usr/local/include -DHAVE_CONFIG_H -I. -I. -Wall -g -O2 \ retry.c gcc -c -I.. -I/usr/local/include -DHAVE_CONFIG_H -I. -I. -Wall -g -O2 \ util.c gcc -c -I.. -I/usr/local/include -DHAVE_CONFIG_H -I. -I. -Wall -g -O2 \ libcyr_cfg.c gcc -c -I.. -I/usr/local/include -DHAVE_CONFIG_H -I. -I. -Wall -g -O2 \ mkgmtime.c mkgmtime.c: In function `tmcomp': mkgmtime.c:102: dereferencing pointer to incomplete type mkgmtime.c:102: dereferencing pointer to incomplete type mkgmtime.c:103: dereferencing pointer to incomplete type mkgmtime.c:103: dereferencing pointer to incomplete type mkgmtime.c:104: dereferencing pointer to incomplete type mkgmtime.c:104: dereferencing pointer to incomplete type mkgmtime.c:105: dereferencing pointer to incomplete type mkgmtime.c:105: dereferencing pointer to incomplete type mkgmtime.c:106: dereferencing pointer to incomplete type mkgmtime.c:106: dereferencing pointer to incomplete type mkgmtime.c:107: dereferencing pointer to incomplete type mkgmtime.c:107: dereferencing pointer to incomplete type mkgmtime.c:100: warning: `result' might be used uninitialized in this function mkgmtime.c: In function `mkgmtime': mkgmtime.c:119: storage size of `yourtm' isn't known mkgmtime.c:121: dereferencing pointer to incomplete type mkgmtime.c:137: warning: implicit declaration of function `gmtime' mkgmtime.c:137: warning: assignment makes pointer from integer without a cast mkgmtime.c:119: warning: unused variable `yourtm' mkgmtime.c:117: warning: `saved_seconds' might be used uninitialized in this function make[1]: *** [mkgmtime.o] Error 1 make[1]: Leaving directory `/home/jonathan/cyrus-imapd-2.2/lib' make: *** [all] Error 1
Re: Return-path header control
On 17 Dec 2002, Henrique de Moraes Holschuh writes: I could write code to add a configuration option to Cyrus so that it has two methods to deal with return-path: 1. Override (should be the default one): trash any return-path headers in the message, and add ours (from -r or MAIL FROM:) 2. Add: Add our return-path header _if_ there ins't already one in there. Messages with more than one return-path header are in error. It might be good to add a couple of other options while you are about it: 3. Remove: removes any existing Return-Path and does not add a new one. 4. Ignore: does nothing, leaves any existing Return-Path header(s) in place. That way all reasonable possibilities (at least, that I can think up!) for handling Return-Path are available and documented. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: cyrus 2.2 status
On 13 Dec 2002, Jure Pecar writes: On Thu, 12 Dec 2002 20:31:41 -0500 Ken Murchison [EMAIL PROTECTED] wrote: I addition to what Rob already mentioned, there needs to be more work done on documenting the virtdomain support and tying some loose ends. Yes, virtdomains are actually the #1 thing i'm interested in cyrus 2.2 ... I'm sure there are more people interested, so i think it would be nice to provide either a stable, known working cvs branch of 2.2 or a patch with a backport of virtdomains stuff to 2.1. I'm willing to help here, just give me some directions. I would also very much like to see this happen. To get Red Hat 7.x RPMs of cyrus-imapd with virtdomain support, I grabbed the CVS for 2.2 as of late September and turned it ito RPMs and since then I have stuck with that. I'm about to resync with CVS again to pick up the recent security fixes. But I'd be more comfortable with using a somewhat supported (or at least officially labelled!) version of the codebase. The issue on when releases happen seems to me to be that CMU has its own priorities, and tends to stick to them. Which is absolutely fine, and probably the right thing for them to do. The result is that, even if a backport patch of the virtdomain code to 2.1.x happens, I'm not sure it would really help in the supportedness/officialness stakes, since CMU would not be using it :-) So it may be that until CMU finds an internal need for something that is in 2.2 but not in 2.1, there's little anyone else can do to get virtdomain support more official than it just being there in CVS. So the question becomes: what, if anything can non-CMU people do that would help cause a release of 2.2 (or 2.1 with virtdomains in it??) to happen sooner rather than later? Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: cyrus-2.2-cvs: virtualdomains and sendmail virtusertable (cyrusv2 as local mailer)
On 16 Dec 2002, Christian Schulte writes: +`R$=L @ $=w . $#_LOCAL_ $: @ $1`@'$2 special local names +R$+ @ $=w . $#_LOCAL_ $: $1`@'$2regular local name') I think the two lines you added should look like `R$=L @ $=w .$#_LOCAL_ $: @ $1 @ $2 special local names R$+ @ $=w . $#_LOCAL_ $: $1 @ $2 regular local name') don't they ? For me thinks work after chaning them this way ! I'm glad you've found something that works for you. I'd have to run more tests to know if that same change to proto.m4 would work for me. It could be that you have found a more generic approach than mine. What I sent is in active use on multiple smallish servers under Sendmail 8.12.5, and seems to be working fine so far. Suggestions from others about using mailertable and avoiding the need to hack proto.m4 also sound like they could be worth trying; it would make upgrading sendmail versions easier, for example, to use only the standard provided m4 files. I hope that documenting how best to configure sendmail for use with Cyrus 2.2 in virtdomain mode will be part of the documentation cleanup that preceeds the 2.2 release. If I were sure what the best approach was, I'd happily submit patches to the Cyrus documentation files describing it. But I keep thinking that someone somewhere surely knows of a better way than making changes to proto.m4 :-) Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: cyrus-2.2-cvs: virtualdomains and sendmail virtusertable (cyrusv2 as local mailer)
On 16 Dec 2002, Christian Schulte writes: By the way: +`R$=L @ $=w . $#_LOCAL_ $: @ $1`@'$2 special local names What defines class L ? It seems like I do not have a so called class L! In my proto.m4 and sendmail.cf it says: # class L: names that should be delivered locally, even if we have a relay But the definition of that class is commented out: #CL root So most likely that line is not really used in either of our configurations. We don't use relay hosts; if we did, this would probably matter. And what does the first @ character in $#_LOCAL_ $: @ $1`@'$2 stand for ? I don't know for sure! I think that is a 'marker' that later sendmail.cf rules later notice and remove. It was there in the original rules I modified, so I left it there :-) Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: cyrus-2.2-cvs: virtualdomains and sendmail virtusertable (cyrusv2as local mailer)
On 16 Dec 2002, Christian Schulte writes: If I specify a final recipient (cyrus-account) in virtusertable as: @virtualdomain.it [EMAIL PROTECTED] where an account like [EMAIL PROTECTED] exists, sendmail recognizes virtualdomain.it in /etc/mail/local-host-names as a local domain and will strip the original virtualdomain.it from the recipient replacing it with the localhost hostname. All domains defined in /etc/mail/local-host-names will be recognized in virtusertable but the local delivery will only go to the user@localhostname! Where can I change sendmail to not do that ? How do I tell sendmail to never change the local-domain to the local hostname on succesfully recognized /etc/mail/local-host-names domains ? There are almost certainly neater ways, but I just patched sendmail.cf/m4/proto.m4 to do that. --- proto.m4.20020613 Thu Jun 13 11:53:24 2002 +++ proto.m4Thu Dec 12 01:54:08 2002 @@ -1092,8 +1092,8 @@ dnl $H empty (but @$=w.) R $+ + $* $+ $#_LOCAL_ $: $1 + $2plussed name? R $+ $+ $#_LOCAL_ $: @ $1 nope, local address', -`R$=L @ $=w . $#_LOCAL_ $: @ $1 special local names -R$+ @ $=w . $#_LOCAL_ $: $1 regular local name') +`R$=L @ $=w . $#_LOCAL_ $: @ $1`@'$2 special local names +R$+ @ $=w . $#_LOCAL_ $: $1`@'$2regular local +name') ifdef(`_MAILER_TABLE_', `dnl # not local -- try mailer table lookup Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: Install (use RPMs on Red Hat 7.3 from http://home.teleport.ch/simix/ )
On 16 Dec 2002, Nuno Miguel Pais Fernandes writes: I'm having problems installing Cyrus imap. I have a Redhat 7.3 and i'm trying to install it from source. You will save yourself a *lot* ot time and trouble by using Simon Matter's RPMs (compile from his SRPMs if you do not trust his binaries for some reason). If you absolutely *must* install from the source manually, then read the .spec file from his RPMs and use its approach as a basis for your own. http://home.teleport.ch/simix/ Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: Shared folders and virtual domains ?
On 3 Dec 2002, Christian Schulte writes: 20776 MAIL From:[EMAIL PROTECTED] SIZE=1076 BODY=8BITMIME 20776 250 2.1.0 ok 20776 RCPT To:+sharedfolder@domain 20776 DATA 20776 250 2.1.5 ok 20776 451 4.3.2 cannot create temporary file: No such file or directory And the logfile states the same errors ! What makes me a bit confused is the error message itself. lmtpd is trying to create a temporary file but the error is No such file or directory. Is it a missing directory or wrong permissions on a directory ? No such file or directory is a standard Unix error text for a single error code, ENOENT, defined in /usr/include/asm/errno.h on my Linux boxes. Don't read too much into the or directory part if the code concerned is not trying to work with a directory :-) I think this issue may be a version of something I tried to report some weeks back, which someone (Ken? I forget) thought might be hardware related, and then found a workaround for that was 'good enough' for me for the moment. The issue for me was that (based on my experiments) the default domain should not be passed to LMTP, only the other non-default ones. Any other approach generated the error message you are reporting. I suspect that had your RCPT TO: line read 20776 RCPT To:+sharedfolder it would have been accepted just fine! I do not know why that is -- I suspect some form of attempted backward compatibility? What I did to fix this here was a small, quick and slightly ugly patch to the sendmail sendmail-cf/m4/proto.m4 file, causing it to send the @domain part of the recipient address on to LMTP for all domains *except* the default one. I had every intention of going back and really figuring out what is going on well enough to report it in a clear way that makes more sense to the developers at some stage... but so far I have not found (or made?) time to do so. In case it helps, here is my patch. It helped for my situation. Jonathan --- /usr/share/sendmail-cf/m4.orig/proto.m4 Thu Jun 13 11:53:24 2002 +++ /usr/share/sendmail-cf/m4/proto.m4 Thu Oct 3 15:11:10 2002 @@ -1092,8 +1092,10 @@ dnl $H empty (but @$=w.) R $+ + $* $+ $#_LOCAL_ $: $1 + $2plussed name? R $+ $+ $#_LOCAL_ $: @ $1 nope, local address', -`R$=L @ $=w . $#_LOCAL_ $: @ $1 special local names -R$+ @ $=w . $#_LOCAL_ $: $1 regular local name') +`R$+ @ $m . $#_LOCAL_ $: $1 regular local +name default domain') +R$+ @ $j . $#_LOCAL_ $: $1 regular local name +default host') +R$=L @ $=w .$#_LOCAL_ $: @ $1`@'$2 special local names +R$+ @ $=w . $#_LOCAL_ $: $1`@'$2regular local +name') ifdef(`_MAILER_TABLE_', `dnl # not local -- try mailer table lookup -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: Cyradm -- Administration Port
On 29 Nov 2002, Su Li writes:
Does any one knows, what port does Cyradm telnet to Cyrus IMAP? Like
Sieve, the port is 2000.
So I can telnet to the administration port and issue a command:
setacl username1 user.username1
There is no separate administration port for Cyrus.
Instead, cyradm issues IMAP commands using the IMAP protocol, to the
IMAP port. All the administration done by cyradm is performed using
the IMAP protocol. So that would be using port 143 (unless you choose
to set Cyrus up to use some other non-standard port for IMAP). But
you can't just send setacl username1 user.username1 to an IMAP
server, because it only understands valid IMAP commands, and you must
authenticate first. There is a SETACL command in IMAP, so maybe:
a1 login cyrus mycyruspassword
a2 setacl user.username1 username1 lrswipcda
a3 logout
is closer to what you would have to send to TCP port 143.
In practice, is often easier to use the Perl modules that cyradm
itself uses, and do something like this:
#!/usr/bin/perl
use strict;
use Cyrus::IMAP::Admin;
my $server='localhost';
my $admin='cyrus';
my $cyradm = Cyrus::IMAP::Admin-new($server) or
die $0: Unable to connect to IMAP server '$server': $! ;
$cyradm-authenticate(-user = $admin, -mechanism = 'login') or
die $0: Failed to authenticate to IMAP server as '$server': $!;
foreach my $user (@ARGV) {
$cyradm-setacl(user.$user, $user = 'lrswipcda') or
warn $0: Unable to setacl for $user on mailbox user.$user : $!;
}
Save that script as setacl.pl and then you can do
perl setacl.pl username1 username2 username3 username4
and have it set all of those users to have full control over their own
INBOXes.
Jonathan
--
Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic
1252 Judson Street | Phone: +1 (909) 795-3877 | communications work
Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian
USA | http://www.xc.org/jonathan| missions worldwide
Re: Mailbox directory structure
On 26 Nov 2002, John Lederer writes: When I looked at the mailbox structure of our test group I found some disconcerting variance. Some users had a directory named INBOX, some did not. ... In any event we want a consistent mailbox structure that supports Moxilla's special Sent, Drafts, and Templates diretcories. We want to standardize, but we are not sure what to standardize on. Can someone tell me what the preferred structure is, particularly for Mozilla? A mailbox called INBOX visible as a file in your filesystem on your Cyrus IMAP server is probably a mistake of some sort, often (based on experience here at least) relating to either the choice of hierarchy separator or default folder prefix. We use the following cyradm commands (for a user named fred and with unixhiersep set to yes): cm user/fred cm user/fred/Drafts cm user/fred/Sent cm user/fred/Templates or their equivalent IMAP commands. The INBOX is created by the first of these commands. If you have altnamespace turned on, Outlook users will be happier, because they will see a folder structure that is closer to the Outlook norms when used with Exchange Server. Jonathan
Re: Problem rebuilding Simons new source RPM
On 25 Nov 2002, Simon Matter writes:
Harris Landgarten schrieb:
For some reason perl man pages are being installed to /usr/man
instead of /usr/shared/man
In older (5.x and 6.x) Red Hat distributions, /usr/man was the default
man page location. I strongly suspect that the %{_mandir} RPM macro
is being set to /usr/man on those machines, and to /usr/share/man
(note: not /usr/shared/man, presumably the extra 'd' was a typo?) on
newer distributions.
On my RH 7.3 machines %_mandir is set in /usr/lib/rpm/macros to
/usr/man (somewhat surprisingly), but this is overridden by setting it
to /usr/share/man in the architecture-specific files:
/usr/lib/rpm/athlon-linux/macros
/usr/lib/rpm/athlon-redhat-linux/macros
/usr/lib/rpm/i386-linux/macros
/usr/lib/rpm/i386-redhat-linux/macros
/usr/lib/rpm/i486-linux/macros
/usr/lib/rpm/i486-redhat-linux/macros
/usr/lib/rpm/i586-linux/macros
/usr/lib/rpm/i586-redhat-linux/macros
/usr/lib/rpm/i686-linux/macros
/usr/lib/rpm/i686-redhat-linux/macros
/usr/lib/rpm/noarch-linux/macros
/usr/lib/rpm/noarch-redhat-linux/macros
This causes the find /var/tmp/cyrus-imapd-2.1.10-root/usr/share/man
-type f -name Cyrus* to find nothing and the following string of
commands to fail with an error.
If I am correct, then it might be wise to use the %{_mandir} macro
within that find command, and anywhere else in the .spec file that the
man directory is referenced. Then man pages should be searched for in
the correct place on all distributions, based on that configurable
setting.
Do you have any idea what could be causing this?
I don't know what would change it in Red Hat 8.0 -- unless a user
copied some .rpmmacros files or /usr/lib/rpm/* or /etc/rpm/* from an
older machine, maybe?? Either that, or the machine in use does not
think of itself as being an x86 machine at all, so none of the
architecture-specific macro files are being used??
As a quick check, for Harris it could be worth trying
echo %_mandir /usr/share/man ~/.rpmmacros
and then rebuilding Simon's SRPM. If that fixes the problem, then
the issue is indeed the %mandir setting, and the cause of the /usr/man
value should be tracked back through the various places in RPM config
files where it might be being set.
Jonathan
--
Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic
1252 Judson Street | Phone: +1 (909) 795-3877 | communications work
Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian
USA | http://www.xc.org/jonathan| missions worldwide
Changing databases at runtime
On 25 Nov 2002, Rob Siemborski writes: On 25 Nov 2002, Erik Enge wrote: I wouldn't rate it as easy unless it was a config option at run-time, not an option to configure at compile-time. This wouldn't be tremendously hard to do (probably just a matter of replacing some macros with some code that is a bit more clever), but there'd be a (small) performance penalty and there isn't really any intrest in doing it, since converting databases shouldn't be a common operation anyway. This is in part a packaging and upgrading issue, though. Especially when the recomended default choices for what databases within Cyrus are in what form seem to change over time, and that this may get 'worse' as new backends are implemented, the ability to build a compiled version of Cyrus that could find and use whatever database format it can see (or failing that, whatever database some separate utility can see and then edit into the config files), would probably help reduce the I upgraded Cyrus to the latest package, and everything broke type of posts -- which in some cases have reportedly led to users giving up on Cyrus altogether. I don't know for sure whether a simple and reliable package upgrade is worth a (small) performance penalty for the average user of a pre-packaged (RPM or .deb) Cyrus, but I suspect it might well be. And over time, such sites may become the majority of Cyrus installations. This probably isn't something of great utility to CMU, but for the average Linux sysadmin who just wants to grab an RPM or a .deb and install it and have Cyrus just work, upgrading as new RPMs/.debs are released, it could be a big deal in the long run. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: How to make cyrus not change non US-ASCII characters to X
On 21 Nov 2002, Peter Runestig writes:
I'm using this little sendmail milter to fix the subject line (could of
course be extended to fix other headers as well):
ftp://ftp.runestig.com/pub/misc/subject2rfc2047.c
http://ftp.runestig.com/pub/misc/subject2rfc2047.c
This is a nice idea. Your program does not seem to encode the equals
sign = or underscore _ in 'Q' encoded headers. I suspect that in
your function mlfi_eom:
if (subj[n] 0x80 || subj[n] == ' ' || subj[n] == '\t' || subj[n] == '?') {
should be:
if (subj[n] 0x80 || subj[n] == ' ' || subj[n] == '\t' || subj[n] == '?' || subj[n]
== '=' || subj[n] == '_') {
Otherwise (I think) Section 4.2(3) of RFC2047 is not quite being followed.
Also, extending this milter to handle From: and To: and Cc: and so
forth would require an RFC822 header parsing capability, so it could
distinguish ctext, text, and word tokens within them. I suspect that
would significantly increase the complexity of the code.
Jonathan
--
Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic
1252 Judson Street | Phone: +1 (909) 795-3877 | communications work
Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian
USA | http://www.xc.org/jonathan| missions worldwide
Re: Skiplist / best practice for 2.1 branch
On 18 Nov 2002, Henrique de Moraes Holschuh writes: For Linux: 1. Heavily tested and debugged AND patched BerkeleyDB 3.2, stay away from 4.x for now. (i.e. use the ones from RedHat or Debian, not upstream). Red Hat now supplies 4.0.14, for example the db4-4.0.14-14.i386.rpm in Red Hat 8.0. It appears to work OK for me, but we have small setups only here... maybe we have just not met the bug(s) yet?? In general, though the statement Use 3.2... ie. use the ones from RedHat or Debian ... is confusing, because for Red Hat 8.x users, the current RH-supplied production release of these libraries is now 4.0.14. Are you recommending that RH 8.0 users running Cyrus should downgrade their BDB libraries to a 3.x RPM set for db3 (perhaps as supplied for RH 7.3)? Wouldn't that tend to have adverse consequences for other software (Sendmail comes to mind) which expects them and which might well be on a Red Hat 8.0 mail server along with Cyrus? 2. Linux stability patches for Cyrus (see the Debian Cyrus package :-) Cyrus upstream source works wonderfuly on Solaris, but not in Linux. I think some of the RPMs distributed by people in this list have many, if not all the patches recommended by me and the fastmail.fm crew. What will it take to get some/all of these patches into 2.1.11 or 2.2 or both? Is that a worthwhile objective? Or are these changes so Linux-specific that they have would negative consequences if applied to a source tree used for a Solaris or *BSD build?? With Linux being a more and more commonly chosen platform for smaller Cyrus installations, to me it seems worthwhile getting these patches incorporated into the upstream codebase -- if that can be done without adversely affecting Cyrus on other platforms. 3. Use the db3_nosync, skiplist, skiplist, flat, db3_nosync like Rob recommended. Unlike the other things you mention, this is something that *does* seem to be constant across OS platforms. If that is the case, then putting this info into a FAQ (as well as making it the default in 2.2) seems approriate. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: Skiplist / best practice for 2.1 branch
On 18 Nov 2002, Jules Agee writes: Jonathan Marsden wrote: Are you recommending that RH 8.0 users running Cyrus should downgrade their BDB libraries to a 3.x RPM set ... I think a lot of people would recommend you stay away from RH 8.0 for production servers. Not that I know of any particular problems... it's just that there's a lot of bleeding-edge stuff that hasn't proved itself as far as I'm concerned. Fair enough as a personal choice. However, do bear in mind that Red Hat 8.0 will not go away -- and in a few months there will be 8.1. Red Hat 8.x is here and is a reality that must be faced. If application software doesn't work well with a popular Linux distribution, IMO the appropriate response is Let's find out why, and work to get the problems fixed, either in that distribution or in our software. A response of Let's just not use or recommend that distribution is not likely to be a useful long-term approach if you want the application to be widely used :-) FYI, I don't actually have Red Hat 8.0 on any production servers here yet. I do have Cyrus 2.2 from CVS running against db-4.0.14 though... on Red Hat 7.3. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: autocreatequota - does it really work?
On 14 Nov 2002, Rob Siemborski writes:
On 14 Nov 2002, Scott Douglass wrote:
I've been wondering for a while if the /etc/imapd.conf option:
autocreatequota is actually implemented (I'm running 2.1.9 right
now). It isn't working on any of my servers. No quota is set for
new user.names.
Anyone have any experience with this? It would be handy if it did
work.
autocreatequota only affects users who log in and create their own
INBOX. Is this how your mailboxes are being created?
I started using autocreatequota recently. The 'automatic' mailbox
creation *does* work, just not the way I initially and perhaps naively
expected it to work. I'm less sure about the automatic setting of a
quota, which I agree would be handy.
The name of the option is potentially confusing, in that the desired
mailbox is not 100% *automatically* created. Rather, it is only
created when the new user logs in and issues a CREATE INBOX command.
I initially thought the INBOX would be created at login.
I think the man page for imapd.conf changed fairly recently to make
this clearer (thankyou!). Since some IMAP clients do not seem to
issue that CREATE INBOX command upon disovering the lack of an INBOX,
mailbox creation is not quite as 'automatic' as it sounds for most
users.
What we did here was to make a very small edit to our webmail client
of choice (Squirrelmail) to check for the existence of the INBOX and
issue a CREATE INBOX command at login time if the INBOX does not
already exist. So the first time a new user uses webmail, their INBOX
is now automatically created for them.
This approach will not directly help users who use a commercial IMAP
client which doesn't send the CREATE INBOX, unless by policy helpdesk
staff use webmail to verify the new account (this check will now have
the side-effect of creating the INBOX).
Below is the diff against Squirrelmail 1.2.8 sources, in case it would
be useful to anyone else.
Like Scott, I do not see a quota being set on the newly (auto-)created
INBOX here, either in 2.1.9 or in 2.2 from CVS a month or so back, but
we have not tracked that down yet -- it might just be some
configuration mistake we have made? At least we can add a new user to
the LDAP directory, and have them be able to use webmail, with no use
of cyradm required.
Jonathan
--- squirrelmail.orig/functions/imap_general.php Tue Sep 17 08:10:03 2002
+++ squirrelmail/functions/imap_general.php Tue Oct 22 17:13:05 2002
@@ -231,6 +231,10 @@
exit;
}
}
+/* Create INBOX if it doesn't exist -- autocreates a new user.
[EMAIL PROTECTED] */
+if (!sqimap_mailbox_exists($imap_stream, 'INBOX')) {
+ sqimap_mailbox_create($imap_stream, 'INBOX', '');
+}
return $imap_stream;
}
--
Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic
1252 Judson Street | Phone: +1 (909) 795-3877 | communications work
Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian
USA | http://www.xc.org/jonathan| missions worldwide
Re: Unable to auth (saslauthd on Red Hat 7.3)
Hi Gerke, On 12 Nov 2002, Gerke Kok writes: I have a problem to get Cyrus running on RedHat 7.3. I used the rpm's provided by Simon Matter. They install nicely. But I keep getting errors on the authentication ( via saslauthd) Could anyone give any pointers to a solution, please? This is what syslog sais: imapd[28564]: cannot connect to saslauthd server: No such file or directory imapd[28564]: badlogin: localhost.localdomain[127.0.0.1] plaintext gerkek SASL(-1): generic failure: checkpass failed Is saslauthd actually running? If it is, what socket is it listening on (should be /var/run/saslauthd/mux)? Is /etc/sysconfig/saslauthd set the way you want it (ie. for whatever actual authentication method you want to use on this server)? These RPMs work fine for us on Red Hat 7.2 and 7.3 here (modified to use the CVS code for virtual domain support in some cases). You might want to include the contents of /etc/imapd.conf, /etc/sysconfig/saslauthd, and /usr/lib/sasl*/*.conf as well as the exact versions of the cyrus-imapd and cyrus-sasl-* RPMs you are using. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: Unable to auth (saslauthd on Red Hat 7.3)
On 12 Nov 2002, Gerke Kok writes: This was what I feared all along: the cyrus-imap server looked at: /var/state/saslauthd/mux iso /var/run/saslauthd/mux. Don't realy know why. It might be because I had tried to install the two (cyrus-sasl and cyrus-imapd) from source first. This must have messed it up. It's a pity I could not find the setting/option that I would need to give to cyrus-imapd where to find the mux-socket. I was looking for it, see. It sounds as though you have solved your problem (by using RPMs for both cyrus-sasl and cyrus-imapd), but just for completeness: The socket location is a runtime option for saslauthd, you can set it (using the Red Hat RPM version) in /etc/init.d/saslauthd or (better) by adding a line to /etc/sysconfig/saslauthd that says something like: SOCKET=/whatever/path/you/want/mux Or, for debugging purposes, you can set it by hand using the -m option to saslauthd directly. The socket location used by cyrus-imapd is the one compiled into the libsasl2.so shared library, as far as I can tell it is not directly set or used within the imapd code at all. So there is no option to imapd to change it, either at run-time or at compile-time -- you'd need to recompile the sasl libraries. I suspect that your imapd was loading a copy of the sasl libraries from /usr/local/lib (where you compiled things by hand earlier) instead of the sasl libs from /usr/lib, and that was how the two pieces got out of sync with each other? Did you put /usr/local/lib into the /etc/ld.so.conf file, perhaps? Thanks again: it works nicely! Good :-) Take care, Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: passing envelope recipient with sendmail (for virtual domains)
On 17 Oct 2002, Kervin L. Pierre wrote, quoting Christian Schulte: You have to change your cyrusv2.mc file: S=EnvFromSMTP/HdrFromL, R=EnvToSMTP/HdrToSMTP, E=\r\n, Christian, thanks for the tip. I tried it, but it did not work by itself. I had to edit the generated cf file and under the 'Parse1' part of 'Rule 0', change... R$+ @ $=w . $#cyrusv2 $: $1 regular local name To... R$+ @ $=w . $#cyrusv2 $: $1 @ $2 . regular local name I have no idea what this change breaks :) but it seems to be the only way I can get sendmail to pass the full address to cyrus. I did this too, on Red Hat 7.3, but by editing the proto.m4 file which generates that line in sendmail.cf. I did not change cyrusv2.mc at all. This way, I can run m4 sendmail.mc sendmail.cf without worrying. Since Red Hat does that for you in the backgroupd (!) with the (RawHide, Sendmail 8.12.5-5 SRPM tweaked by me to use SASLv2) Sendmail version I use, it was very important to me to avoid any manual fixup of sendmail.cf itself. Actually, I *then* discovered that what I really needed was apparently more like: R$+ @ $m . $#cyrusv2 $: $1 regular local name default domain R$+ @ $j . $#cyrusv2 $: $1 regular local name default host R$=L @ $=w . $#cyrusv2 $: @ $1@$2special local names R$+ @ $=w . $#cyrusv2 $: $1@$2 regular local name This way the @domain part is left *off* for the default domain but *added* for the other (virtual) domains. This seems to get rid of some strange errors I was seeing for mail to users in the default domain. I didn't get back to Ken to try and figure this out further because the workaround of not passing the domain part for the users in the default domain just works. But I don't think I should really have had to do that, so there is possibly a buglet lurking in the imapd virtual domain stuff somewhere in this area?? Jonathan -- Jonathan Marsden [EMAIL PROTECTED]
Try RPMs/SRPMs under Red Hat 7.x (was: Re: cyrus-imap make errors)
On 8 Apr 2002, David Goodrich writes: i am attempting to install cyrus-imapd-2.0.16 from source. i am using make-3.79.1-8, gcc-2.96-98, and glibc-2.2.4-19.3. this is being done on a redhat 7.2 system with the 2.4.7-10 kernel. Is it OK to ask why you feel a desire or need to do this? It seems to me that you could use existing SRPMs of Cyrus 2.0.16 from at least two different sources, and achieve the apparent goal more easily and more quickly. They seem to compile/build/install just fine on Red Hat 7.x. There are even 2.1.3 SRPMs available now. Other than as a learning experience, what is the benefit of struggling through a manual tarball-based installation? Others have gone before you, and done the necessary work to make the exact same piece of software compile and install on your chosen Linux distribution. It's probably worth considering using their work as a basis for your own. For Cyrus-IMAPd 2.0.x and SASL 1.5.x see: http://rmorales.modwest.com/rpms/cyrus-imapd/ http://www.caliban.org/files/redhat/SRPMS/cyrus-imapd-2.0.16-6.src.rpm http://www.caliban.org/files/redhat/SRPMS/cyrus-sasl-1.5.27-1.src.rpm For Cyrus-IMAPd 2.1.x and SASL 2.1.x, see: http://www.caliban.org/files/redhat/SRPMS/cyrus-imapd-2.1.3-1.src.rpm http://www.caliban.org/files/redhat/SRPMS/cyrus-sasl-2.1.1-1.src.rpm http://home.teleport.ch/simix/ As a more general question to the list: Is there any way we can get this sort of info about locations of Cyrus RPMs, and other packages such as .deb's for Debian etc etc, onto the primary Cyrus-related web site? Jonathan -- Jonathan Marsden [EMAIL PROTECTED]
Re: Automated RPM config of imaps/pop3s during RPM install
On 28 Mar 2002, Clifford Thurber writes: At 01:40 PM 3/27/2002 -0800, you wrote: will allow connections to the imaps and pop3s ports, and for STARTTLS to work on the standard IMAP port, with no manual post-install configuration by the user at all related to SSL/TLS. This is very cool. Is adding TLS support to IMAP documented anywhere? What is the basic procedure? Thanks As I eventually discovered the hard way (!), the information is in the install-configure.html file that comes with cyrus-imapd 2.0.16 (and 2.1.3, though I have not yet tried it with that version). In essence for cyrus-imapd 2.0.16 you just: (1) Create a key file: openssl req -new -x509 -nodes -out /var/imap/server.pem -keyout /var/imap/server.pem -days 365 (2) Set its permissions appropriately: chown cyrus:mail /var/imap/server.pem (3) Add two lines to your imapd.conf: echo tls_cert_file: /var/imap/server.pem /etc/imapd.conf echo tls_key_file: /var/imap/server.pem /etc/imapd.conf (4) If necessary, add lines for imaps (TCP port 993) and pop3s (TCP port 995) to /etc/services. (5) Restart cyrus. If you do not see imaps and pop3s listeners on ports 993 and 995, check cyrus.conf for lines such as imaps cmd=/usr/cyrus/bin/imapd -s listen=imaps prefork=0 pop3s cmd=/usr/cyrus/bin/pop3d -s listen=pop3s prefork=0 in the SERVICES section. (6) Test the result: imtest -t localhost:993 Of course, once you have done this, getting sendmail to do STARTTLS and AUTH so that users protect mail they *send* in a similar way, is a whole different problem... :-) See Claus Assmann's info at http://www.sendmail.org/~ca/email/starttls.html for more on that. Jonathan
Cyrus 2.x HOWTO for Linux?
On 28 Mar 2002, Clifford Thurber writes: Wow great thanks. I did this last summer but I lost my notes on getting this working so this helps. Are you using cyrus with sendmail? Yes. Did you manage to get the TLS working as mentioned in that article? Curious? Not quite yet, but I'm very close... I seem to have some permissions issues with the certificate files right now. I'll document the process, once it actually works for me. This is sendmail-8.12.2-11 (built from the SRPM from Red Hat 'rawhide') on Red Hat 7.2 on x86 hardware. Again thanks. I am thinking of writing up a how to on installing cyrus since it seems like many people are having problems with the BerkeleyDB on linux and cyrus finding the distro shipped verion of the db. Not a bad plan! Though some of the solutions I have seen for that issue on this list look a little manual and unpolished. I think this is more an issue with Cyrus IMAPd 2.1.x -- can you confirm this? With 2.0.16, rebuilding the SRPM by Ramiro Morales seems to work fine. At least until I have SSL/STARTTLS working well for me with 2.0.16 (for IMAP and SMTP), I have no real drive/need to get involved with 2.1.x -- though the altnamespace stuff would definitely be nice to have. As you probably know, there is an existing Cyrus IMAP HOWTO at http://www.linuxdoc.org/HOWTO/Cyrus-IMAP.html but it was written in 2000 and so is for 1.6.24, which is now pretty obsolete. I suggest you contact its author and perhaps work with him if you want to update it for 2.0.16. I'd suggest doing that, and then updating again for 2.1.x, that way there will be a version for each major version of cyrus-imapd (1.6.x, 2.0.x, 2.1.x). My own inclination would be to work instead on packaging the new 2.1.x version as an RPM for Red Hat 7.2, fixing or working around any configure.in buglets discovered along the way, and so making the installation a lot easier for many Linux users. But I don't know if I will need/want this badly enough to make the time to do it -- maybe one of the folks who created cyrus-imapd 2.0.x RPMs will work on this before I get there. Jonathan
Cyrus 2.1.x and DB3 vs DB4
On 28 Mar 2002, Simon Matter writes: Ramiro Morales schrieb: FYI, Simon Matter announced his WIP RPM packages of Cyrus 2.1.x in thsi last back in February. http://home.teleport.ch/simix/ I have updated to cyrus imapd 2.1.3. The database backends are now configurable at compile. I'm still using db3 as default because db4 has generated error messages and I build on RedHat 7.2 at the moment. db3 is standard on 7.2, I guess db4 will be in for 7.3/8.0. I'll test it on skipjack-beta1 when I find some time. FYI, the cyrus-imapd-2.1.3 SRPM rebuilt problem-free on my Red Hat 7.2 machine here. Looks good so far! I am intrigued by the DB4/DB3 change. Why is use of DB4 important for Cyrus 2.1.x, compared to DB3? Performance? Scalability? Reliability? Does it only matter for the folks with tens of thousands of IMAP users? I realize it is generally good to use the latest and greatest libraries, but when (as with Red Hat 7.2) the db3 (3.2.9) stuff is there by default, and replacing it with db4 for Cyrus seems to have tripped up at least a couple of people on the list, I'm wondering whether there is a significant real world benefit to using db4 that I have missed? The only reference to db4 I can find in the cyrus-imapd-2.1.3/doc directory is in changes.html, which says only: * now compatible with Berkeley DB4 (Larry M. Rosenbaum, [EMAIL PROTECTED]) Can someone who has used (or is now using) db4 as a Cyrus backend db either explain, or provide a pointer to an explanation of, the benefits of using db4 over db3 for cyrus-imapd? Thanks, Jonathan
Re: Cyrus 2.1.x and DB3 vs DB4
On 29 Mar 2002, Simon Matter writes: Mee too I don't know what is much better with DB4. I just tried it and wanted the SRPM to be ready when DB4 comes in. I have expected to see cyrus-sasl 2.x and DB4 in the upcoming RedHat release. Both packages were on rawhide but now it seems they are gone. They are not in skipjack-beta1. Maybe this meens that DB4 is not important for RedHat but what about sasl? Maybe it was too much trouble with sasl2 and that's why they stay with 1.5.24. I hope not because it will make usage of cyrus-imapd 2.x more difficult in future. Until sendmail supports SASL v2, I think SASLv2 will be a hard sell, at least for smaller installations. Users who use Cyrus for IMAP often also need to use sendmail (or Exim or Postfix, but sendmail is what comes installed out of the box) for outbound mail, and that means SMTP AUTH to avoid 'relaying denied', and that means a password database... as far as I can see, right now that means either (i) have two databases, such as /etc/sasldb and /etc/sasldb2, and somehow keep them synced, or (ii) use LDAP or some other external database and point both SASL versions at it. This seems pretty cumbersome to me, unless you already need or want LDAP for other reasons. Or is there a simple way to have Cyrus IMAPd 2.1.3 and sendmail 8.12.2 use the same SASL db that I didn't spot? Jonathan
Automated RPM config of imaps/pop3s during RPM install
Here is a patch against the cyrus-imapd.spec file for the Red Hat
Linux RPMs cyrus-imapd-2.0.16-5rm. This patch adds the creation and
use of a test SSL certificate automatically if openssl is also
installed. Because under Red Hat 6.2 the imaps and pop3s service
names are not defined in /etc/services by default, these will also be
added if necessary.
With this patch, at least in my very limited testing (!), installing
cyrus-imapd frpm the RPM will allow connections to the imaps and pop3s
ports, and for STARTTLS to work on the standard IMAP port, with no
manual post-install configuration by the user at all related to
SSL/TLS.
Jonathan
--- SPECS.orig/cyrus-imapd.spec Sun Jan 27 15:03:56 2002
+++ SPECS/cyrus-imapd.spec Wed Mar 27 21:15:48 2002
@@ -1,6 +1,6 @@
Name: cyrus-imapd
Version: 2.0.16
-Release: 5rm
+Release: 5rm+ssl
# In the following defines 1 means true or yes and 0 means false or no
@@ -603,6 +603,36 @@
END {if(f){exit 0} exit 1}' %{_sysconfdir}/imapd.conf || \
echo -e 'sievedir: /var/imap/sieve' %{_sysconfdir}/imapd.conf
+%triggerin -- openssl
+# Generate server key and certificate, and append lines to imapd.conf to use them
+umask 077
+CERT=/var/imap/server.pem
+CONF=/etc/imapd.conf
+
+if [ ! -f $CERT ] ; then
+ cat EOF |openssl req -new -x509 -nodes -out $CERT -keyout $CERT -days 365
+--
+SomeState
+SomeCity
+SomeOrganization
+SomeOrganizationalUnit
+localhost.localdomain
[EMAIL PROTECTED]
+EOF
+chown root.mail $CERT
+chmod 0640 $CERT
+fi
+
+# Add entries to imapd.conf file to point to the new cert
+grep -sq ^tls_cert_file: $CONF || echo tls_cert_file: $CERT $CONF
+grep -sq ^tls_key_file: $CONF || echo tls_key_file: $CERT $CONF
+
+# Add imaps and pop3s services to /etc/services if necessary
+grep -sq ^pop3s[[:space:]] /etc/services ||
+echo -e pop3s\t\t995/tcp\t\tpop-3s\tspop3\t# POP3 over SSL /etc/services
+grep -sq ^imaps[[:space:]] /etc/services ||
+echo -e imaps\t\t993/tcp\t\tsimap\t\t# IMAP over SSL /etc/services
+
%files
%defattr(-,root,root)
%config %{_sysconfdir}/cyrus.conf
@@ -698,6 +728,9 @@
%attr(750,cyrus,mail) %{_localstatedir}/imap/sieve
%changelog
+* Wed Mar 27 2002 Jonathan marsden [EMAIL PROTECTED]
+- Automatically generate and use a test SSL cert, if openssl is installed.
+
* Sun Jan 27 2002 Ramiro Morales [EMAIL PROTECTED]
- release 5rm
README.RPM corrections
Re: IMAPS/POP3S not configured/working in cyrus-imapd 2.0.16/RH 7.2
On 26 Mar 2002, Ramiro Morales writes (as part of a series of ideas): tls_cert_file: /usr/local/lib/ssl/newcert.cer tls_key_file: /usr/local/lib/ssl/key.pem with these SSL cert and key files created as described in the install-configure.html file? This one was the solution. Many thanks! I feel somewhat silly... I should have RTFMed... and yet... in a way, I *did*! I read the imapd.conf man page, which supposedly lists all possible options which can be placed within that file. I did so more than once. It does not include these two, nor anything relating to TLS or SSL. I did not go through the HTML install docs step by step, because the install was already done by the RPM. Red Hat's apache RPMs go so far as to set it up to create use self-signed SSL certificates automatically, when the mod_ssl RPM is installed. This might be a nice enhancement for future cyrus-imapd RPMs. I'll happily script just such an automated setup (now that it works for me manually!) and send you a patch against your cyrus-imapd.spec file, if that would be useful. One other way to 'alert' people (like me!) to these options could be to include them, commented out, in the RPM-supplied default imapd.conf file. This problem (lack of info on tls_* options in the imapd.conf man page) seems to have been fixed in the 2.1.3 man page, so only people like me who are still a little wary of the newness of 2.1.x and SASLv2, and who prefer RPMs when they can get them, will run into this... Thanks again for pointing me in the right direction, Jonathan
IMAPS/POP3S not configured/working in cyrus-imapd 2.0.16/RH 7.2
I'm attempting to deploy cyrus-imapd on a Red Hat 7.2 machine (single
Athlon XP, 512MB RAM, RAID-1 IDE disks). I have use cyrus-imapd
before, but not the SSL (pop3s/imaps) implementation.
I'm finding that if I install from the RPMs by Ramiro Morales
(cyrus-imapd-2.0.16-5rm from
http://rmorales.modwest.com/rpms/cyrus-imapd/ ) and recompile them
from the SRPM, things work fine, EXCEPT that connections to the pop3s
and imaps ports connect and then do nothing. Connecting to these
ports using the command
openssl s_client -connect localhost:995 -status -debug
generates:
CONNECTED(0003)
SSL_connect:before/connect initialization
write to 0814D810 [0814D858] (124 bytes = 124 (0x7C))
- 80 7a 01 03 01 00 51 00-00 00 20 00 00 16 00 00 .zQ... .
0010 - 13 00 00 0a 07 00 c0 00-00 66 00 00 05 00 00 04 .f..
0020 - 03 00 80 01 00 80 08 00-80 00 00 65 00 00 64 00 ...e..d.
0030 - 00 63 00 00 62 00 00 61-00 00 60 00 00 15 00 00 .c..b..a..`.
0040 - 12 00 00 09 06 00 40 00-00 14 00 00 11 00 00 08 ..@.
0050 - 00 00 06 00 00 03 04 00-80 02 00 80 2d 6d 29 83 -m).
0060 - 21 b1 e7 f5 19 ee fa 6c-cb 93 d8 e5 23 95 0f 10 !..l#...
0070 - 5a 67 a5 e5 b0 a7 3e d3-25 0b 5b eb Zg.%.[.
SSL_connect:SSLv2/v3 write client hello A
and then sits there. The TCP connection stays open, but no data is
received across it from the server. The SSL tunnel is never
initialized.
Connections to the non-SSL pop3 and imap ports work fine. Using the
cyrus-imapd-2.0.16-4 RPMs from
I note that the difference in the way the servers are called
(specified in /etc/cyrus.conf) is the -s option. Running them by hand
generates the probably highly relevant error message:
06:59:47 jonathan@test:~$ /usr/cyrus/bin/imapd -s
/usr/cyrus/bin/imapd: invalid option -- s
Playing a little with gdb suggests that getopt is being called with an
options string of C:, though in imap/imapd.c the code seems to read:
while ((opt = getopt(argc, argv, C:sp:)) != EOF) {
What further tests or changes to my configuration should I make I make
in order to get pop3 and imap over SSL working for this platform? I'd
prefer not to update to Cyrus 2.1.x just yet, because of the SASLv2
requirement.
I suspect I may have just missed something obvious...?
Thanks in advance!
Jonathan
--
Jonathan Marsden [EMAIL PROTECTED]
