Re: Backing up db directory
--On Tuesday, December 10, 2002 4:35 PM -0500 Jay Levitt [EMAIL PROTECTED] wrote: Am I correct in assuming that the db directory doesn't need to be backed up - in fact should not be backed up - and I should instead be backing up the db.backup1 and db.backup2 dirs and using reconstruct to recreate db itself? The db.backup1 and db.backup2 dirs are created by obeying Sleepycat's recommendations on backing up Berkeley db to prepare for possible catastrophic recovery. If you have to restore everything from backup, using the latest clean version of the db.backup's is safer than trying to use the db/ directory as your backup software grabbed them (since your backup software might not have done it in the correct order). Backup and disaster recovery (and really our interaction with Berkeley db as a whole) are things that need to be better documented. Larry
Re: files in stage. directory ...
--On Tuesday, December 10, 2002 4:18 PM -0400 Marc G. Fournier [EMAIL PROTECTED] wrote: What are they, and how do you clean them out? I have stuff dating back to march 19th in there: Mar 19 2002 27181-1016554210 just delete, or is there somethign I should be fixing? Most likely cause is either (a) a bug in lmtpd and it isn't cleaning up after itself or (b) lmtpd is crashing or (c) you're shutting down the server while it's in the middle of delivering a message. None of these are a particularly big deal. (b) would be the worst but you'd probably notice it if it was happening a lot. You can just remove these; these should all be very transitory, so anything older than, say, an hour can be safely nuked. Larry
Re: Automatic content-type insertion
--On Monday, December 02, 2002 10:43 AM +1100 Rob Mueller [EMAIL PROTECTED] wrote: I'm just wondering why cyrus automatically adds a content type charset to every message, even if none is specified in the message itself. For example: [...] So there's no Content-Type line in the message, but the bodystructure has given it an implicit charset of us-ascii. Now, I know that this is technically true, but unfortunately, there seem to be quite a few broken iso-2022-jp messages out there which don't actually specify the charset in the header. What we allow on our site is a 'default charset', which is used if no charset is available, which would work fine in this situation. Unfortunately in this case, there's no indication that the (CHARSET us-ascii) response was auto-generated, rather than explicitly set. It does this because that's what the IMAP spec says to do. Section 7.4.2: BODYSTRUCTURE A parenthesized list that describes the [MIME-IMB] body structure of a message. This is computed by the server by parsing the [MIME-IMB] header fields, defaulting various fields as necessary. The main solutions I see are: 1. Remove the implicit setting of the charset if none supplied It appears that this would conflict with the RFC. 2. us-ascii is a subset of most encodings anyway, so always allow overriding of a us-ascii charset anyway This is probably reasonable, especially if your allowable default encodings are all supersets of US-ASCII. 3. Do a fetch body[header.fields (Content-Type)] to see if one actually exists This seems more annoying and I suspect it's not particularly fast on Cyrus. Larry
Re: quick and dirty patch for flushing seen state
John's patch for flushing seen state looks reasonable to me. Clients should be prepared for unsolicited \Seen responses at any time, so that shouldn't be a problem. Larry
Re: Skipstamp?
--On Monday, December 23, 2002 10:37 AM -0600 Scott Smith
[EMAIL PROTECTED] wrote:
I just checked out the 2.2 branch and set it up on a machine here...It
built just fine and I got the virtdomain stuff working fine.
My only problem is that I am getting the DBERROR messages about
/var/imap/db/skipstamp. mkimap didn't create the file, and the only place
I can find it in the code is in lib/cyrusdb_skiplist.c.
So what creates the file? I saw a post from Ken Murchison saying that it
wasn't something to worry about, but if it's not, then why is my logfile
getting spammed with the errors?
ctl_cyrusdb should create this file when you run recovery, which should be
kicked off from the START {} section of your cyrus.conf.
If you get DBERROR: reading skipstamp, assuming the worst during normal
operation, something has inhibited ctl_cyrusdb from creating the file.
Larry
Re: Aborting locker errors...
--On Wednesday, December 18, 2002 4:32 PM +1100 Rob Mueller [EMAIL PROTECTED] wrote: Given that it's for the deliver.db, which is used for duplicate delivery suppression and sieve, will an aborted locker result in sieve not correctly processing an email? I don't think so. Since Sieve always uses berkeley db in a rather straightforward fashion, the transaction will just be retried and the error never gets propogated up to a higher level. Larry
Re: Fwd: pre-login buffer overflow in Cyrus IMAP server
--On Friday, December 06, 2002 1:27 AM +0100 Simon Josefsson [EMAIL PROTECTED] wrote: Any comment on why it took over a month to react to this reported vulnerability? Hi Simon, You'll note that it has taken me almost a month to respond to your message. This is mostly because I get very distracted very easily. When the initial bug report came in, it was evaluated as fairly low vulnerability (all it contained was the fact that you could overwrite a malloc'd buffer), since the only obvious overflows would cause the entire process to crash. Sadly, I didn't think of process reuse---nor did I fully understand the GNU malloc implementation that makes this an exploitable overflow on certain architectures. Timo wrote back approximately 2 weeks later that he could demonstrate an exploit on Debian linux. We had a new version about a week later after a small amount of back and forth with Timo about what a good solution might be. A comment explaining why it took so long and what happened in the meantime would be useful in extrapolating how future vulneribilities will be handled. If this has already been discussed somewhere, I am sorry for duplicating the discussion and would appreciate a pointer. I suspect that future exploits will be handled similiarly. We have to make a initial guess on how important any information sent to cyrus-bugs is, since there's no one here who is solely devoted to Cyrus maintaince. I guess our (mostly my) initial triaging was off on this. Note that the Sieve vulnerabilities were reported significantly later and were therefore fixed with, what I'd call, all due speed. I hope this helps. Larry
Re: [PATCH][CVS IMAPd 2.1] lmtp_downcase_rcpt implementation (Re:Case Sensitivity)
--On Tuesday, December 24, 2002 12:01 AM -0200 Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: Here's the cleaned up patch, against 2.1 CVS. It could be enhanced not to touch the +fooobar part of the recipient, I suppose. Yes, and I wanted to add a comment on this... Put the work in now to make it not touch the +foobar part of the recipient, before it is given to the CMU folk for integration into CVS. We have all kinds of +plussed folders here at our site, and many of them contain mixed case characters (usually, the first character gets up-cased). So, I imagine that it would be a common issue elsewhere as well. Scott -- +---+ Scott W. Adkinshttp://www.cns.ohiou.edu/~sadkins/ UNIX Systems Engineer mailto:[EMAIL PROTECTED] ICQ 7626282 Work (740)593-9478 Fax (740)593-1944 +---+ PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/ msg10058/pgp0.pgp Description: PGP signature
Re: [PATCH][CVS IMAPd 2.1] lmtp_downcase_rcpt implementation (2)
Henrique de Moraes Holschuh wrote: Here's the improved patch. It skips over the +Mailbox part of the recipient, in the most straightforward way possible ;-) Would it make sense to make the control more generic, such as downcase_account_name, and have it also apply to logins and other places besides LMTP? We have a number of users who were logging in with randomly capitalized account names in UW IMAP (and it happily accepted them). We have been contacting them to change it, but perhaps others with a similar problem might prefer to just accept it. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
9800¶àÍòÈ«¹úÓÊÖ·×Ü¿â+100¶à¿îÍøÂçÓªÏúÈí¼þ¹âÅÌ
Title: 9800¶àÍòÈ«¹úÓÊÖ·×Ü¿â 9800¶àÍòÈ«¹úÓÊÖ·×Ü¿â+100¶à¿îÓªÏúÈí¼þ¹âÅÌ Ö»ÐèÒª200Ôª¡¡ÏêÇéµã»÷ ±¾Õ¾¾¹ý½üÒ»ÄêµÄËѼ¯ÕûÀí¡¢·´¸´²âÊÔÑéÖ¤,ÏÖ¹²ÕûÀí9800¶àÍò¸ö¹úÄÚÓû§ÓʼþµØÖ·,¾×¨Òµ¹¤¾ßУÑéɸѡȥ³ýÖظ´ÎÞЧ,²¢Í¨¹ýÓʼþ¹ÜÀí¹¤¾ßÔÚÏßÑéÖ¤,²¢°´ÐÐÒµºÍµØÇø·ÖÀàºÃ.È»ºóÎÒÃÇÔÙ×Ðϸ½«ÓÊÖ·¿â×ö³É¹âÅÌ,·²¹ºÂò±¾²úÆ·Õß,¿ÉÒÔÃâ·ÑµÃµ½100¶à¿îÍøÂçÓªÏúÈí¼þ(°üÀ¨Èº·¢¡¢ËÑË÷¡¢ÑéÖ¤µÈ¹¤¾ß,¾ù¿ÉÕý³£Ê¹ÓÃ)¡£±¾Õ¾ÌṩµÄÓʼþµØÖ·¿â²úÆ·¾ßÓм«ºÃµÄÖÊÁ¿£¬¼«µÍµÄ¼Û¸ñ£¬ÍêÉƵÄÊÛºó·þÎñ£¬Êܵ½¿Í»§µÄÒ»ÖºÃÆÀ¡£°ÑÄ¿¹âͶÏòÎÒÃǵIJúÆ·£¬ÊÇÄúÃ÷ÖǵÄÑ¡Ôñ£¬ÎÒÃǽ«ÎªÄúÌṩ×îÓŵķþÎñ¡£ ¹âÅ̼۸ñ£º200Ôª Á¢¼´¶¨¹º ¸¶¿î·½Ê½ Èç¹ûÕâ·âÓʼþ´òÈÅÄúÁË£¬·³ÇëËæÊÖɾµô£¬²¢Çë¼ûÁ¡£ÈôÄú²»Ï£ÍûÔÙ´ÎÊÕµ½ÎÒÃǵÄÓʼþ£¬Çëµã»÷ÕâÀï
Sendmail/Plussed Folders --WAS-- Re: [PATCH][CVS IMAPd 2.1]lmtp_downcase_rcpt implementation (2)
--On Wednesday, December 25, 2002 10:59 AM -0200 Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: Here's the improved patch. It skips over the +Mailbox part of the recipient, in the most straightforward way possible ;-) Sorry, didn't see this message until too late... ignore my last post on the subject... you just fixed it :) On another note, it seems that sendmail has issues with talking directly to LMTP (meaning, not using the deliver program) and being able to deliver messages to plussed folders of a user account. At least as of sendmail 8.12.5, messages sent to plussed folders are simply deposited to the user's INBOX. Maybe that has been fixed by mucking around with the M4 code for the Cyrus configuration, but I doubt it. There is a PRESERVE_LOCAL_PLUS_DETAIL option in proto.m4 that can be used, but as I have seen from my testing, it only works when sendmail calls the deliver program directly (deliver -e -m $h -- $u was what we used), and the reasoning for that is that the hostname and the username were broken out into two seperate macros and passed individually on the deliver command line. Using that option with LMTP directly ends up losing the $h portion of the macro, and only $u is sent via the LMTP protocol. S I ended up patching sendmail (I can post the patch, which is current as of 8.12.5, but should work for 8.12.6) that allows plussed folder details to be passed along untouched to the LMTP server, and even implemented a flag that would allow the username to be lowercased and leave the plussed folder portion untouched before passing it to LMTP. So, my question to the list is this: Has anyone else had this problem (plussed folder emails sent to sendmail that is configured to talk to LMTP directly, either my UNIX domain socket or my TCP socket)? If so, how was it resolved? Is there a better way to do this using the M4 macros as opposed to how I solved the problem by patching the code? Thanks, Scott -- +---+ Scott W. Adkinshttp://www.cns.ohiou.edu/~sadkins/ UNIX Systems Engineer mailto:[EMAIL PROTECTED] ICQ 7626282 Work (740)593-9478 Fax (740)593-1944 +---+ PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/ msg10062/pgp0.pgp Description: PGP signature
sasldb2 set secret not seen
Hi. I've upgraded from cyrus 2.0.14 and sasl 1.5.24 (I think it was) to cyrus 2.1.11 and sasl 2.1.10 on freebsd 4.5. I used the freebsd ports for the recent reinstallation, thanks Hajimu. I had been using with the earlier cyrus version the feature auto transition, such that a plain/login success through pam would add the user/pw information into the sasldb. Future authentications could then be done with challenge response from the sasldb, since the set secret code fed the sasldb file. With the new versions, I don't get transition from pam login/plain authentication into the sasldb2 file. I'd expect perhaps success with the fragment of my imapd.conf - specifying ... sasl_pwcheck_method:auxprop saslauthd #would probably be right (or with the order reversed?) #with auxprop_plugin: sasldb # If enabled, the SASL library will automatically create authentication # secrets when given a plaintext password. See the SASL documentation. # sasl_auto_transition: yes # When set to 'yes' and when using the sasldb auxprop plugin, automatically transition # users to other mechs when they do a successful plaintext authentication # http://asg.web.cmu.edu/cyrus/download/sasl/doc/options.html -- I also wonder what I should set for sasl_mech_list: I want pam to do plain/login and saslauthd to service other requests. Anyway, I'm not getting auto transition to the sasldb file. My imapd account (cyrus) has rw access to /usr/local/etc/sasldb2 which is the file of concern. Can anyone suggest why I'm having trouble stuffing the sasldb file? I've seen others have trouble with this auto transition also. Not unrelated, I'm having trouble understanding the basis for two conflicting-to-me statements in the documentation concerning auto_transition... http://asg.web.cmu.edu/cyrus/download/sasl/doc/sysadmin.html (There's no point in enabling this option if pwcheck_method is auxprop, and the sasldb plugin is installed) yet http://asg.web.cmu.edu/cyrus/download/sasl/doc/options.html says about auto_transition When set to 'yes' and when using the sasldb auxprop plugin, automatically transition users to other mechs when they do a successful plaintext authentication What makes there be no point when it appears to be recommended for the behavior to function? Thanks John
Re: Automatic content-type insertion
I'm just wondering why cyrus automatically adds a content type charset to every message, even if none is specified in the message itself. For example: [...] So there's no Content-Type line in the message, but the bodystructure has given it an implicit charset of us-ascii. Now, I know that this is technically true, but unfortunately, there seem to be quite a few broken iso-2022-jp messages out there which don't actually specify the charset in the header. What we allow on our site is a 'default charset', which is used if no charset is available, which would work fine in this situation. Unfortunately in this case, there's no indication that the (CHARSET us-ascii) response was auto-generated, rather than explicitly set. It does this because that's what the IMAP spec says to do. Section 7.4.2: BODYSTRUCTURE A parenthesized list that describes the [MIME-IMB] body structure of a message. This is computed by the server by parsing the [MIME-IMB] header fields, defaulting various fields as necessary. The main solutions I see are: 1. Remove the implicit setting of the charset if none supplied 'defaulting various fields as necessary' seems an awfully broad statement. Where does it specify which fields should be defaulted? Rob
