Re: Folders must be in Inbox
On Tue, 14 Jan 2003, David Borgesen wrote: Hello, Our company recently installed Cyrus and we can not add folders at the same level as the Inbox. He says we must place all folers within the Inbox. Is this accurate, if so can we change it so I can have all my core folders at the root level and not within the in box? Also my folders and mailboxes both look like folders in Eudora, any idea why? Read the imapd.conf manual page and look for altnamespace -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Piet RUYSSINCKe-mail: [EMAIL PROTECTED] Unix Systeem Administratie tel: +32 9 264 4733 Directie Informatie- en Communicatietechnologie (ICT) fax: +32 9 264 4994 Universiteit Gent (RUG) Krijgslaan 281, gebouw S9 - 9000 Gent, Belgie -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Please avoid sending me Word or PowerPoint attachments See http://www.fsf.org/philosophy/no-word-attachments.html
Re: Cyrus-2.1.11 error: message is no longer available
Dmitry Novosjolov wrote: Hello All, I've upgraded cyrus-2.1.4 to cyrus-2.1.11 and sometimes message could not be retrieved from the server, it is shown as deleted but not read in my outlook express. Outlook express shows message is no longer available on server. The problem can be fixed manually by deleting message file from the imap spool and recunstructing the mailbox. I wonder how to avoid it at all ? there is nothing interesting in cyrus's log files. I'm using suse 8.0, sasl-2.1.10. here are my configure options of cyrus: ./configure --with-cyrus-prefix=/usr/local/cyrus-2.1.11 --with-auth=unix -- with-sasldir=/usr/local/lib/ --with-openssl=../openssl-0.9.6g --enable-serve r --with-duplicate-db=skiplist --with-mboxlist-db=flat --with-subs-db=flat - -with-tls-db=skiplist --with-lock=fcntl here is my imapd.conf file (I'm using sieve): configdirectory: /var/imap partition-default: /cyrus/mail admins: cyrus allowanonymouslogin: no allowplaintext: yes sasl_pwcheck_method: auxprop sasl_auto_transition: yes hashimapspool:true reject8bit: no sieveusehomedir: false sievedir: /var/lib/sieve sendmail: /usr/sbin/sendmail When I asked that question here, I was told it was a known bug in OE. I only saw it a few times in a 2300 user base, and I have not seen it since I applied my patch for flushing seen state to disk after any change (search the archives for it - if you have a lot of OE users you will definitely want it since it uses multiple connections to manipulate the seen state, but if your machine is already having a lot of disk IO you may not be able to handle the additional traffic). I don't know if that is coincidence or related. You don't have to reconstruct the mailbox to fix it -- you can delete the account in OE and recreate it (doesn't lose anything), or I have also been told that you can drag the offending message to another folder and back expunging in both places. You can tell it is a client problem rather than a server problem because using another client (even a different instance of OE configured fresh for the account) while that OE is having a problem will see the message just fine. -- John A. Tamplin Unix Systems Administrator
Cyrus IMAPd auth problem
Hi all, I am having some troubles with my cyrus setup. I am using saslauthd with method pam. This is working now for over a year. Now I tried to add a user and if I want to login with this user, for example, with pine, I get this: Jan 15 11:23:26 intern master[8733]: about to exec /opt/cyrus/bin/imapd Jan 15 11:23:26 intern imap[8733]: executed Jan 15 11:23:26 intern imapd[8733]: accepted connection Jan 15 11:23:29 intern imapd[8733]: no secret in database Jan 15 11:23:29 intern imapd[8733]: badlogin: localhost[127.0.0.1] CRAM-MD5 [SASL(-13): user not found: no secret in database] well, that user isn't in the sasl2db file, but I think I am using saslauthd with auth method pam? Any hints? I am clueless atm. ciao, Marc
[no subject]
Hello All, I want to write a CGI script and use it I can create or delete mailbox,etc.(just like cyradm,but I found if I invoke cyradm I must use expect to send password,It's too inconvenient :-( ) I am going to use Cyrus::IMAP,but I don't know how can I send username and password to the server,I tried method authenticate and login,but I fault. Would someone give me some advice ? --- Kai __ Do You Yahoo!? Yahoo! BB is Broadband by Yahoo! http://bb.yahoo.co.jp/
Re: Cyrus IMAPd auth problem
On Wednesday 15 January 2003 11:39, David Brandt wrote: Hi David, CRAM-MD5 doenst work with saslauthd. this cannot be the reason. I have other users as well using the same MUA with the same setup. The only difference here is that sasl2db contains all working users. The non-working user isn't listed in sasl2db. ciao, Marc
SOLVED Re: debugging deliver
Francesc Guasch Ortiz wrote: Hi. A disk drive crashed this morning, so I copied all the data to a new disk using tar. It looks /tmp mode was wrong and the virus mail scanner failed. cat 14384. | /usr/cyrus/bin/deliver jordi I thought this was supposed to deliver the message. Maybe it failed because it found it was duplicated. -- frankie
Re: Too many open file in 2.2 (Re: Exploding number of cyrus processes)
This is a situtation when I get the problem: . . . . [6247] (SECURE) d48093.upc-d.chello.nl[213.46.48.93] [5762] (SECURE) node-c-b7b7.a2000.nl[62.194.183.183] [717] (SECURE) c5246.upc-c.chello.nl[212.187.5.246] rc2249-b13-10.bouhof.nhl.nl[141.252.84.102]peppelenuser.peppelen rc3130-b22-10.bouhof.nhl.nl[141.252.84.21] riemersfuser.riemersf [4378] (SECURE) d48093.upc-d.chello.nl[213.46.48.93] rc2811-b02-08.bouhof.nhl.nl[141.252.83.211]wit user.wit [31747] (SECURE) a143016.upc-a.chello.nl[62.163.143.16] rc2781-b02-19.bouhof.nhl.nl[141.252.83.181]huizingguser.huizingg [29693] (SECURE) node-c-af29.a2000.nl[62.194.175.41] [31061] (SECURE) e34-200-252-141.laptop.nhl.nl[141.252.200.34] [32499] (SECURE) c3234.upc-c.chello.nl[212.187.3.234] [31850] (SECURE) a36056.upc-a.chello.nl[62.163.36.56] [3826] (SECURE) e88177.upc-e.chello.nl[213.93.88.177] [6971] (SECURE) a50072.upc-a.chello.nl[62.163.50.72] [7546] (SECURE) colijn-it.nl[213.84.97.99] [31837] (SECURE) c58118.upc-c.chello.nl[212.187.58.118] [958] (SECURE) colijn-it.nl[213.84.97.99] [3859] (SECURE) e89149.upc-e.chello.nl[213.93.89.149] [3864] (SECURE) e104049.upc-e.chello.nl[213.93.104.49] [3854] (SECURE) d48093.upc-d.chello.nl[213.46.48.93] [824] (SECURE) colijn-it.nl[213.84.97.99] rc3450-b08-20.bouhof.nhl.nl[141.252.83.127]buisuser.buis rc4144-f218.tem.nhl.nl[141.252.160.205]bokkes user.bokkes [31247] (SECURE) dhcp23.engineering.tech.nhl.nl[141.252.172.23] [1607] (SECURE) a50072.upc-a.chello.nl[62.163.50.72] rc4409-b02-12.bouhof.nhl.nl[141.252.83.12] woudas user.woudas.Verzonden items [5842] (SECURE) cc21402-a.groni1.gr.home.nl[217.120.144.148] rc4081-f02-02.tem.nhl.nl[141.252.175.47] wayop user.wayop [32445] (SECURE) e34-200-252-141.laptop.nhl.nl[141.252.200.34] [32624] (SECURE) rc3377-f304.tem.nhl.nl[141.252.160.156] [6416] (SECURE) e107004.upc-e.chello.nl[213.93.107.4] [961] (SECURE) a143016.upc-a.chello.nl[62.163.143.16] [32700] (SECURE) a36056.upc-a.chello.nl[62.163.36.56] [32674] (SECURE) d48093.upc-d.chello.nl[213.46.48.93] rc3432-b08-10.bouhof.nhl.nl[141.252.84.53] dijkemamuser.dijkemam [2944] (SECURE) c59235.upc-c.chello.nl[212.187.59.235] [4560] (SECURE) a36078.upc-a.chello.nl[62.163.36.78] [3821] (SECURE) rc4858-v402.tem.nhl.nl[141.252.181.203] [2946] (SECURE) c2072.upc-c.chello.nl[212.187.2.72] [5880] (SECURE) d48093.upc-d.chello.nl[213.46.48.93] [31803] (SECURE) a50072.upc-a.chello.nl[62.163.50.72] [898] (SECURE) colijn-it.nl[213.84.97.99] [31796] (SECURE) cc133908-a.sneek1.fr.home.nl[212.120.122.114] rc4437-f124.tem.nhl.nl[141.252.160.63] pooluser.pool [31089] (SECURE) rc3377-f304.tem.nhl.nl[141.252.160.156] [1504] (SECURE) 1Cust14.tnt30.rtm1.nld.da.uu.net[213.116.154.14] rc4337-f138.tem.nhl.nl[141.252.160.91] hettingauser.hettinga [1530] (SECURE) colijn-it.nl[213.84.97.99] [1659] (SECURE) a143016.upc-a.chello.nl[62.163.143.16] [1750] (SECURE) a50072.upc-a.chello.nl[62.163.50.72] [2055] (SECURE) dhcp23.engineering.tech.nhl.nl[141.252.172.23] [31911] (SECURE) a36056.upc-a.chello.nl[62.163.36.56] rc2459-f227.tem.nhl.nl[141.252.160.18] blomuser.blom [5968] (SECURE) colijn-it.nl[213.84.97.99] [31759] (SECURE) a50072.upc-a.chello.nl[62.163.50.72] [4352] (SECURE) dhcp23.engineering.tech.nhl.nl[141.252.172.23] [31753] (SECURE) e126017.upc-e.chello.nl[213.93.126.17] [31912] (SECURE) [62.21.140.36] rc3630-f305.tem.nhl.nl[141.252.160.183]kuikuser.kuik [3148] (SECURE) colijn-it.nl[213.84.97.99] [5823] (SECURE) a143016.upc-a.chello.nl[62.163.143.16] [6986] (SECURE) ip91357ae9.adsl-surfen.hetnet.nl[145.53.122.233] [6987] (SECURE) colijn-it.nl[213.84.97.99] [2991] (SECURE) c32177.upc-c.chello.nl[212.187.32.177] [956] (SECURE) e16-201-252-141.laptop.nhl.nl[141.252.201.16] [4964] (SECURE) d48195.upc-d.chello.nl[213.46.48.195] [4369] (SECURE) e16-201-252-141.laptop.nhl.nl[141.252.201.16] [32460] (SECURE) ip91357ae9.adsl-surfen.hetnet.nl[145.53.122.233] [32669] (SECURE) e126017.upc-e.chello.nl[213.93.126.17] rc3534-f245.tem.nhl.nl[141.252.160.171]verhees user.verhees [5179] (SECURE) ppp32-4-59-62.dialup.zonnet.nl[62.59.4.32] rc2514-t206.tem.nhl.nl[141.252.161.103]stout user.stout [2373] (SECURE) c5246.upc-c.chello.nl[212.187.5.246] [2057] (SECURE) e75166.upc-e.chello.nl[213.93.75.166] [1541] (SECURE) [62.21.140.36] [31913] (SECURE) c58118.upc-c.chello.nl[212.187.58.118] [6989] (SECURE) e88177.upc-e.chello.nl[213.93.88.177] [5848] (SECURE) node-c-b7b7.a2000.nl[62.194.183.183] rc2616-b02-06.bouhof.nhl.nl[141.252.83.44] hoelen user.hoelen [7542] (SECURE) 1Cust241.tnt15.rtm1.nld.da.uu.net[213.116.124.241] [32618] (SECURE) eng5103.engineering.tech.nhl.nl[141.252.170.81] [32532] (SECURE) cc75841-a.frane1.fr.home.nl[213.51.86.145] [701] (SECURE) dhcp23.engineering.tech.nhl.nl[141.252.172.23] [3028] (SECURE) d48093.upc-d.chello.nl[213.46.48.93] rc1013.tem.nhl.nl[141.252.163.16] vdulken user.vdulken [2259] (SECURE)
Re: Cyrus IMAPd auth problem
Marc-Christian Petersen wrote: On Wednesday 15 January 2003 11:39, David Brandt wrote: CRAM-MD5 doenst work with saslauthd. this cannot be the reason. I have other users as well using the same MUA with the same setup. The only difference here is that sasl2db contains all working users. The non-working user isn't listed in sasl2db. saslauthd is only used for login, not CRAM-MD5 or DIGEST-MD5. Those methods require the cleartext password to be stored in sasl2db (etc). If you have no users in sasl2db, you should disable CRAM-MD5 and DIGEST-MD5 as authentication methods. There is an option to migrate users from LOGIN to CRAM-MD5/etc by storing them in sasl2db after they login once -- take a look at the documentation if that is what you are trying to do. -- John A. Tamplin Unix Systems Administrator
Re: Cyrus IMAPd auth problem
On Wed, 15 Jan 2003, Marc-Christian Petersen wrote: On Wednesday 15 January 2003 11:39, David Brandt wrote: Hi David, CRAM-MD5 doenst work with saslauthd. this cannot be the reason. I have other users as well using the same MUA with the same setup. The only difference here is that sasl2db contains all working users. The non-working user isn't listed in sasl2db. If the non-working user isn't in sasldb2, then how is the CRAM plugin getting the secret to check against? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
IMSP and RH 8.0
Has anyone been able to get IMSP 1.6a3 (or a2) running on a RH 8.0 box? I get stopped in configure with the sasl.h test. cyrus-sasl (v2) is installed via an RPM. I also tried to drop back to cyrus-sasl (v1.5) but get fatal errors about checkpw.c. Thanks Dave 6781 Morehouse Flats Road Jamesville, NY 13078 [EMAIL PROTECTED]
Re: Sendmail: deliver to local and cyrus users
On Tue, 14 Jan 2003, John Colton wrote: I'm using cyrus-imapd-2.1.11 and sendmail-8.11.6 on RedHat 6.2. I have some users who are local and some who are cyrus. What's the best way to set this up? My experience so far is that when cyrus is defined as the local mailer using define(`confLOCAL_MAILER',`cyrus'), mail to non-cyrus users is bounced. If cyrus is not defined as the local mailer, mail to the cyrus users is bounced. I know this is a sendmail question but I thought I'd try here first. A bit of a hack, but: Deliver all mail to Procmail, and have a default rule to deliver to Cyrus at the end of /etc/procmailrc. Then create a .procmailrc for each local user, which ends with delivering to their $MAIL location. You might also be able to define $MAIL per-user, and just deliver to $MAIL for everyone; have the default set to cyrus, and each local user has it set to their mailbox. Though I admit, I like the idea of virtusertable better : -- Steve Huston - Unix Systems Administrator, Dept. of Astrophysical Sciences Princeton University | ICBM Address: 40.346525 -74.651285 126 Peyton Hall |On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (609) 258-7375 | headlong into mystery. -Rush, 'Cygnus X-1'
Antivirus
Hi, What is the best antivirus solution for my mail serverCyrus/Postfix ? Thanks a lot, Sebastien.
Re: [PATCH][saslauthd] cyrus-sasl-2.1.10/saslauthd credential caching
On Tuesday 14 January 2003 23:36 pm, Igor Brezac wrote: Jeremy, This stuff looks great and with a limited user sample (10) the performance improvement was almost 100 fold. Keep in mind, this is my first crack at it. I am using Solaris 9. I am getting the following error # ./saslcache -s could not attach shared memory segment: 1200 shmat: Invalid argument It is likely I need to adjust shared memory params. I'll let you know what I find. One more note, can you make the changes against the cvs version? -Igor Ok, I've set things up on a Solaris 8 machine for testing. After a few tweaks, things appear to be working ok. One thing though, it seems that the maximum shared memory segment size on Solaris is 1M by default. Solaris users will have to tweak their system settings if a larger cache is desired. Due to this, I've set the default cache size to under 1M (down from ~4M). This way saslauthd will always start with the cache enabled under default circumstances. Changes at: ftp://ftp.net.ohio-state.edu/pub/users/jrumpf/cyrus-sasl/cyrus-sasl-2.1.10-cache-2.patch Or fully patched source at: ftp://ftp.net.ohio-state.edu/pub/users/jrumpf/cyrus-sasl/cyrus-sasl-2.1.10-cache-2.tar.gz I'll work on getting a diff against current cvs as well Thanks, Jeremy
Re: [PATCH][saslauthd] cyrus-sasl-2.1.10/saslauthd credential caching
Hi Jeremy, Just wanted to let you know that the default shared memory segment size on Solaris 9 has been changed to 8 MB. If you want more on any versions of Solaris you simply need to edit /etc/system. Regards Marc Jeremy Rumpf To: Igor Brezac [EMAIL PROTECTED] [EMAIL PROTECTED]cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Sent by: Subject: Re: [PATCH][saslauthd] cyrus-sasl-2.1.10/saslauthd credential caching [EMAIL PROTECTED] ew.cmu.edu 01/15/03 04:33 PM On Tuesday 14 January 2003 23:36 pm, Igor Brezac wrote: Jeremy, This stuff looks great and with a limited user sample (10) the performance improvement was almost 100 fold. Keep in mind, this is my first crack at it. I am using Solaris 9. I am getting the following error # ./saslcache -s could not attach shared memory segment: 1200 shmat: Invalid argument It is likely I need to adjust shared memory params. I'll let you know what I find. One more note, can you make the changes against the cvs version? -Igor Ok, I've set things up on a Solaris 8 machine for testing. After a few tweaks, things appear to be working ok. One thing though, it seems that the maximum shared memory segment size on Solaris is 1M by default. Solaris users will have to tweak their system settings if a larger cache is desired. Due to this, I've set the default cache size to under 1M (down from ~4M). This way saslauthd will always start with the cache enabled under default circumstances. Changes at: ftp://ftp.net.ohio-state.edu/pub/users/jrumpf/cyrus-sasl/cyrus-sasl-2.1.10-cache-2.patch Or fully patched source at: ftp://ftp.net.ohio-state.edu/pub/users/jrumpf/cyrus-sasl/cyrus-sasl-2.1.10-cache-2.tar.gz I'll work on getting a diff against current cvs as well Thanks, Jeremy
Re: Antivirus
Sophos has worked great for me and my company. Damon On Wed, 2003-01-15 at 10:38, Sebastien Marmorat wrote: Hi, What is the best antivirus solution for my mail server Cyrus/Postfix ? Thanks a lot, Sebastien.
Re: Antivirus
On Wed, 15 Jan 2003, Sebastien Marmorat wrote: What is the best antivirus solution for my mail server Cyrus/Postfix ? I use AMaViS acting as a SMTP filter for postfix. AMaViS is configured to use F-Prot and Clam AntiVirus for it's virus engines, though it can support many others. Specifically, I am using amavis-ng. The following page has it (and other versions of amavis): http://sourceforge.net/projects/amavis If you go with amavis-ng, make sure to look at and download the various user patches. Clam AntiVirus: http://clamav.elektrapro.com/ F-Prot (free for non-commercial use): http://www.f-prot.com/products/index.html Good luck. -peace -- Let he who is without clue kiss my ass
Re: Antivirus
We use Trend Micro's Interscan Viruswall, and it seems to work really well...the install was trivial actuallyl. _ David ChaitSys Admin - Facilities Operations333 Bonair Siding Road #107Stanford CA, 94305[EMAIL PROTECTED] - Original Message - From: Sebastien Marmorat To: [EMAIL PROTECTED] Sent: Wednesday, January 15, 2003 7:38 AM Subject: Antivirus Hi, What is the best antivirus solution for my mail serverCyrus/Postfix ? Thanks a lot, Sebastien.
Re: [PATCH][saslauthd] cyrus-sasl-2.1.10/saslauthd credential caching
I have a comment. From the readme: 1) The entry was not found, but was created for future lookups. 2) The entry was found, but the password in the cache didn't match the supplied password. In this case, the password in the cache is updated with the supplied password for future lookups. Being paranoid, another call after a successful login is a safer way of implementing this. As it sits, it is possible to hammer saslauthd w/ requests and I could get successfully authenticated w/ a bogus password if I can get a request in between the time the cache entry is added and the actual authentication occurs and the cached entry is purged. This is VERY easy to do with auth backends w/ long time outs or worse yet a denial of service against the auth backend could give me windows of access.. check cache (don't add) if cache_ok return sucess else check auth backend if backend successs add to cache return success Just my two cents.. Nice work Jeremy.. you saved me a few days worth ;-) Jeremy Rumpf wrote: All, I've been working on combining some of the ideas for a credential caching layer into saslauthd. This is the first release for review/comments/testing. Changes: Three files have been added to the saslauthd package: cache.c cache.h README.cache saslcache.c Four files have been modified Makefile.am Makefile.in saslauthd-doors.c saslauthd-unix.c The saslauthd executable now accepts three new command line switches. -c Enables the credential cache -s Sets the size of the credential cache in kilobytes -t Sets the timeout of items in the credential cache in seconds A show_usage() function has been added that dumps all possible options out when an invalid command line switch is found: ./saslauthd: invalid option -- - usage: saslauthd [options] option information: -a authmech Selects the authentication mechanism to use. -c Enable credential caching. -d Enables debugging, run in the foreground. -O optionOptional argument to pass to the authentication mechanism. -m path Alternate path for the mux socket, must be absolute. -n threads Number of worker threads to create -s kilobytes Size of the credential cache (in kilobytes) -t seconds Timeout for items in the credential cache (in seconds) -T Honor time-of-day login restrictions. -v Display version information and available authentication mechanisms and exit. The caching layer caches the username, realm, service, and an md5 hash of the passwords for all authentication mechanisms (LDAP, rimap, PAM, etc). It's been tested it on RedHat 7.2 Alpha and RedHat 7.3 Intel. I've also only been able to compile the modifications using the unix IPC option (saslauthd-unix.c). The same modifications have been made to the doors IPC option (saslauthd-doors.c), but have not been compiled or tested. More detailed information about the cache is in the README.cache file. In addition to testsaslauthd, a second utility is included, saslcache. The saslcache utility can be used to attach to the shared memory segment and perform various tasks. The saslcache utility can be built by: cd saslauthd make saslcache Usage examples: ./saslcache -s dumps out some information about the cache Saslauthd Cache Detail: timeout (seconds) : 28800 total slots allocated : 3643 slots in use: 3 total buckets : 21858 buckets per slot: 6 buckets in use : 3 hash table size (bytes) : 2098536 bucket size (bytes) : 96 minimum slot allocation : 0 maximum slot allocation : 1 slots at maximum allocation : 3 slots at minimum allocation : 3640 overall hash table load : 0.00 hits* : 19 misses* : 3 total lookup attempts* : 22 hit ratio* : 86.36 * May not be completely accurate ./saslcache -d dumps the contents of the cache in a csv format user,realm,service,created,created_localtime m3,,imap,1042513583,Mon Jan 13 22:06:23 2003 m2,,imap,1042513256,Mon Jan 13 22:00:56 2003 m1,,imap,1042513355,Mon Jan 13 22:02:35 2003 ./saslcache -f purges/deletes all entries in the cache 21858 entries purged Todo: Test the doors IPC stuff. Test on alternate OSs (only linux so far) Have someone help with the autoconf stuff. I'm not very familiar with autoconf and modeled the modifications after those for testsaslauthd. I'm not sure if they're entirely correct. For testing one should probably run saslauthd with the -d switch. The cache will log
Re: Antivirus
On Wed, 15 Jan 2003, Sebastien Marmorat wrote: What is the best antivirus solution for my mail server Cyrus/Postfix ? We use amavisd-new at work, which works very very well with Postfix. Use whatever virus scanner you want (such as clamav), and you can also have side-wide SPAM filtering through spamassassin, if you've got the CPU to spare. This question is best send to the MTA (postfix, in your case) mailinglist, since Cyrus doesn't even enter the picture. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: [PATCH][saslauthd] cyrus-sasl-2.1.10/saslauthd credential caching
On Wed, 15 Jan 2003, Jeremy Rumpf wrote: Ok, I've set things up on a Solaris 8 machine for testing. After a few tweaks, things appear to be working ok. One thing though, it seems that the maximum shared memory segment size on Solaris is 1M by default. Solaris users will have to tweak their system settings if a larger cache is desired. Due to this, I've set the default cache size to under 1M (down from ~4M). This way saslauthd will always start with the cache enabled under default circumstances. I've taken a look at this new code, and I have a number concerns right off the bat. (The idea is sound, I think, but it looks like the current implementation is a security nightmare). The biggie: cache_lookup() writes the user-provided password hash into the hash table BEFORE it is verfied. There's now a race where an attacker can submit an arbitrary string as a password, (if there's currently an entry in the cache, it will be evicted), then while the real lookup is happening he'll try a second authentication, which will succeed if cache_purge has not yet been called. I think I have a general problem with cache_lookup writing to the hash table, I'd expect lookup to be a read-only operation. If it fails, we do a lookup to the backend anyway, and then only if we SUCCEED in that lookup do we write the good password to the table. Another important one: No locking of any kind is used on the shared memory segment. I'm not sure this is directly exploitable, but it could give odd behavior. Let's assume that we've fixed the above problem. Now we have a cache_write() (that looks similar to the writing portion of the current cache_lookup()) instead of a cache_purge(). If two processes are in cache_write at the same time, there's a race where they could both pick the same block to evict, and the result could be some mangled combination of both (or one or the other, but not both). Take this for instance (we assume that we had two cache misses, and that we only have one processor): processes time(a) (b) 1 find old bucket 2 find old bucket -they now have the same bucket- 3 compute pw hash 4 write pw hash 5 compute pw hash 6 write pw hash 7 write offsets 8 write offsets 9 write creds 10 write creds -uh-oh, now we have a bucket with offesets for one entry but -credentials and password for another 11 update timestamp 12 update timestamp There clearly needs to be some sort of semaphore on the table (or on entries, or something). Wasn't this originally going to use libmm? Finally: I think shared memory is way overkill for the doors version, since it all takes place within one process. Though, we'd still need to use some sort of councurrancy control. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
RE: Sendmail: deliver to local and cyrus users
Thanks to all for your ideas. In the end, I added the following line to my sendmail mc file: define(`LUSER_RELAY', `cyrusv2:localhost') Now all apparently local names that aren't accounts or aliases are sent to cyrusv2 which is the name of my cyrus mailer. This works great for me. Thanks Deke Clinger for pointing me at http://www.arrayservices.com/projects/Exchange-HOWTO/html/x354.html where I got this idea. -john -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Colton Sent: Tuesday, January 14, 2003 2:50 PM To: [EMAIL PROTECTED] Subject: Sendmail: deliver to local and cyrus users I'm using cyrus-imapd-2.1.11 and sendmail-8.11.6 on RedHat 6.2. I have some users who are local and some who are cyrus. What's the best way to set this up? My experience so far is that when cyrus is defined as the local mailer using define(`confLOCAL_MAILER',`cyrus'), mail to non-cyrus users is bounced. If cyrus is not defined as the local mailer, mail to the cyrus users is bounced. I know this is a sendmail question but I thought I'd try here first. Thanks, John
Re: Antivirus
At 15:00 -0200 Henrique de Moraes Holschuh wrote: since Cyrus doesn't even enter the picture. Hey, why not? Now that you've switched from UW-IMAP to Cyrus, you need something to do with your spare CPU cycles.. Maybe a hook could be bolted in whenever an IMAP fetch or store command is requested. There is a possible protocol for this called ICAP, for which patches to squid exist. At least Symantec offer a commercial ICAP server; there's a GPLish one written in Python IIRC. Alternatively a small, clean API could be introduced at build time (a bit like local_scan() in Exim 4) or via DSOs (a la Apache), and if someone wanted to write an ICAP client as such a function or modules it would be their concern. Matt :-)
Re: [PATCH][saslauthd] cyrus-sasl-2.1.10/saslauthd credential caching
_My_ original plan was to use libmm.. Jeremy already had a similiar solution that he modified. libmm does have the advantage that it is platform neutral -- no need for fancy autoconf tricks to figure out what kinda of shm we have. not to mention it can do the locking in a platform neutral format. If I have time I might try to mangle Jeremy's code to use libmm.. We must be on the right track -- Rob and I both voiced the same concern ;-) Rob Siemborski wrote: On Wed, 15 Jan 2003, Jeremy Rumpf wrote: Ok, I've set things up on a Solaris 8 machine for testing. After a few tweaks, things appear to be working ok. One thing though, it seems that the maximum shared memory segment size on Solaris is 1M by default. Solaris users will have to tweak their system settings if a larger cache is desired. Due to this, I've set the default cache size to under 1M (down from ~4M). This way saslauthd will always start with the cache enabled under default circumstances. I've taken a look at this new code, and I have a number concerns right off the bat. (The idea is sound, I think, but it looks like the current implementation is a security nightmare). The biggie: cache_lookup() writes the user-provided password hash into the hash table BEFORE it is verfied. There's now a race where an attacker can submit an arbitrary string as a password, (if there's currently an entry in the cache, it will be evicted), then while the real lookup is happening he'll try a second authentication, which will succeed if cache_purge has not yet been called. I think I have a general problem with cache_lookup writing to the hash table, I'd expect lookup to be a read-only operation. If it fails, we do a lookup to the backend anyway, and then only if we SUCCEED in that lookup do we write the good password to the table. Another important one: No locking of any kind is used on the shared memory segment. I'm not sure this is directly exploitable, but it could give odd behavior. Let's assume that we've fixed the above problem. Now we have a cache_write() (that looks similar to the writing portion of the current cache_lookup()) instead of a cache_purge(). If two processes are in cache_write at the same time, there's a race where they could both pick the same block to evict, and the result could be some mangled combination of both (or one or the other, but not both). Take this for instance (we assume that we had two cache misses, and that we only have one processor): processes time(a) (b) 1 find old bucket 2 find old bucket -they now have the same bucket- 3 compute pw hash 4 write pw hash 5 compute pw hash 6 write pw hash 7 write offsets 8 write offsets 9 write creds 10 write creds -uh-oh, now we have a bucket with offesets for one entry but -credentials and password for another 11 update timestamp 12 update timestamp There clearly needs to be some sort of semaphore on the table (or on entries, or something). Wasn't this originally going to use libmm? Finally: I think shared memory is way overkill for the doors version, since it all takes place within one process. Though, we'd still need to use some sort of councurrancy control. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
7PNTTmaqgML4vI7ZqEvd 1GMsGVm9SOf5UituhpldaEzdAxy
Title: ¤â¾÷¥X¯²¤¤¤ß
¤½¥q²¤¶ ¤â¾÷¥X¯²
Ápµ¸§ÚÌ
¦X§@¤è®×
Åwªï¥úÁ{ Û¯Sº¸¤â¾÷¥X¯²¤¤¤ßWELCOME Rentele Mobilephone
Rental Center
¨C¤Ñ¥un¥x¹ô18¤¸¡þOnly US 0.5Dollar
a day¥»¤¤¤ß´£¨Ñ¦U´Ú¤â¾÷µ¹Á{®É»Ýnªº¤H¨Ï¥Î¡CIf
you need mobile phone for the occasionÅwªï»P¦U®È¦æªÀ©Î¶º©±¬¢½Í¦X§@
We
have cooperation project to a tourist agency and Hotel
Do you need mobilephone for anytime you
need.
Maybe your mobilphone get in to maintain.
Are you come from foregin to Taiwan ? maybe
you need a telephone to communicate.
If you want go to north america where is
1900 system , maybe you need a 1900 telphone.
§A¦³Á{®É»Ýn¤â¾÷«oWµL¤â¾÷¶Ü¡H
§Aªº¤â¾÷¥¿¦bºûסA¥Ø«e¤S¤£¯à¨S¦³¤â¾÷¡A«ç»ò¿ì©O¡H
§An¨ì¥_¬ü¡A¤â¤W¨S¦³1900¨t²Îªº¤â¾÷¡A§A·Qn¼È¥Î¤@¤U¡A«ç»ò¿ì¡H
§A¬O±q°ê¥~¨Ó¥xÆW¡AÁ{®Én¥Î¤@°¦¤â¾÷¤Îªù¸¹®É¡A«ç»ò¿ì¡H
[Introduce][Price][Order][Cooperation]
Copyright (c) 1996-2004 Rentele Interactive Inc. All rights reserved.[EMAIL PROTECTED]
how to make sendmail authenticate to lmtpd
We are trying to get a murder configuration going. Thus far we have the backend, frontend, and mupdate (running on a frontend) servers mostly working. Here are the outstanding issues to resolve - and all have to do with authentication. 1. Mailbox move from one backend to another using cyradm on a frontend fails with following errors: - couldn't authenticate to backend server: no mechanism available - Could not move mailbox: user.test100, Initial backend connect failed Note: we were having authenticaion problems with imap proxy till I hacked imapd.c as below: /* secprops = mysasl_secprops(SASL_SEC_NOPLAINTEXT); */ secprops = mysasl_secprops(0); There was a discussion thread with the above tip from Rob (Thanks Rob). However it made imap proxy work but not mailbox move from one backend to another. 2. sendmail fails to deliver messages via lmtpproxyd due to authentication problems.This is a typical mail deliver test that fails on the frontend server running lmtpproxyd. root@spnode21$ mail -v test100 Subject: test test . Cc: test100... Connecting to [127.0.0.1] port 2003 via cyrusv2... 220 spnode21 LMTP Cyrus v2.1.11 ready LHLO ufl.edu 250-spnode21 250-8BITMIME 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-SIZE 250-STARTTLS 250-AUTH PLAIN 250 IGNOREQUOTA MAIL From:[EMAIL PROTECTED] SIZE=32 [EMAIL PROTECTED] 430 Authentication required test100... Deferred: 430 Authentication required Closing connection to [127.0.0.1] QUIT 221 2.0.0 bye The cyrusv2 mailer is defined in sendmail.cf as Mcyrusv2, P=[IPC], F=lsDFMnqXzA@/:|m, S=EnvFromSMTP/HdrFromL, R=EnvToL/HdrToL, E=\r\n, T=DNS/RFC822/SMTP, A=TCP [127.0.0.1] lmtp The above mailer (lmtp via a tcp socket) works fine on backend machines, which is using preauthenticated lmtpd i.e. lmtpd -a in cyrus.conf. Any help will be appreciated. Thanks. -- Gautam Das [EMAIL PROTECTED] Senior Systems Programmer Northeast Regional Data Center University of Florida
Re: how to make sendmail authenticate to lmtpd
On Wed, 15 Jan 2003, Gautam Das wrote: /* secprops = mysasl_secprops(SASL_SEC_NOPLAINTEXT); */ secprops = mysasl_secprops(0); There was a discussion thread with the above tip from Rob (Thanks Rob). However it made imap proxy work but not mailbox move from one backend to another. I'm not going to make any guarantees about trying to use the murder in a plaintext environment. It hasn't been tested in any way and there might be some surprises that I haven't thought of. That said, it's entirely possible that the backend imapd that is working as a client is refusing to use plaintext in *its* authentication, so I'd troll around in backend.c some. 2. sendmail fails to deliver messages via lmtpproxyd due to authentication problems.This is a typical mail deliver test that fails on the frontend server running lmtpproxyd. root@spnode21$ mail -v test100 Subject: test test . Cc: test100... Connecting to [127.0.0.1] port 2003 via cyrusv2... 220 spnode21 LMTP Cyrus v2.1.11 ready LHLO ufl.edu 250-spnode21 250-8BITMIME 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-SIZE 250-STARTTLS 250-AUTH PLAIN 250 IGNOREQUOTA MAIL From:[EMAIL PROTECTED] SIZE=32 [EMAIL PROTECTED] 430 Authentication required test100... Deferred: 430 Authentication required Closing connection to [127.0.0.1] QUIT 221 2.0.0 bye [snip] The above mailer (lmtp via a tcp socket) works fine on backend machines, which is using preauthenticated lmtpd i.e. lmtpd -a in cyrus.conf. Any help will be appreciated. You shouldn't run lmtpd on a TCP socket with -a. That basically bypasses any sense of delivery security LMTP is offering you. In reality, sendmail should be configured to do SMTP AUTH. At the very least, lmtpproxyd has to be able to do authenticated delivery from your smtp servers to the lmtpds on the backends. (and you can run lmtpproxyd -a on a unix socket on the local machine). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: [PATCH][saslauthd] cyrus-sasl-2.1.10/saslauthd credential caching
On Wed, 15 Jan 2003, Jeremy Rumpf wrote: On Tuesday 14 January 2003 23:36 pm, Igor Brezac wrote: Jeremy, This stuff looks great and with a limited user sample (10) the performance improvement was almost 100 fold. Keep in mind, this is my first crack at it. I am using Solaris 9. I am getting the following error # ./saslcache -s could not attach shared memory segment: 1200 shmat: Invalid argument It is likely I need to adjust shared memory params. I'll let you know what I find. One more note, can you make the changes against the cvs version? -Igor Ok, I've set things up on a Solaris 8 machine for testing. After a few tweaks, things appear to be working ok. One thing though, it seems that the maximum shared memory segment size on Solaris is 1M by default. Solaris users will have to tweak their system settings if a larger cache is desired. Due to this, I've set the default cache size to under 1M (down from ~4M). This way saslauthd will always start with the cache enabled under default circumstances. Solaris 9 defaults to 8M: http://docs.sun.com/db/doc/806-7009/6jftnqsj7?a=view I would think that 1M is a fairly generous cache size unless you have millions of users. This is a 'short lived' cache mechanism where a username is most likely to be reused shortly there after. Changes at: ftp://ftp.net.ohio-state.edu/pub/users/jrumpf/cyrus-sasl/cyrus-sasl-2.1.10-cache-2.patch Or fully patched source at: ftp://ftp.net.ohio-state.edu/pub/users/jrumpf/cyrus-sasl/cyrus-sasl-2.1.10-cache-2.tar.gz I'll work on getting a diff against current cvs as well Cool. I'll wait for your cvs diff. Do you use any kind of locking mechanism such as semaphores or messages? -- Igor
Re: Antivirus
On Wed, 15 Jan 2003, Matt Bernstein wrote: Maybe a hook could be bolted in whenever an IMAP fetch or store command is requested. There is a possible protocol for this called ICAP, for which patches to squid exist. At least Symantec offer a commercial ICAP server; there's a GPLish one written in Python IIRC. I know nothing about ICAP, but it might be an interesting idea... go ahead ;-) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Delivering to NonExistant Subfolder...
If a subfolder doesn't exists, it seems to put it in INBOX. Is there anyway to make the email go to the parent folder? IE: INBOX INBOX.Test1 INBOX.Test1.Personal INBOX.Public So if mail was to be delivered to Personal, but for some reason it didn't exist, could deliver try and deliver it to INBOX.Test1, and then INBOX, etc? Is there any way to make that happen in v2.1.5 ? Thanks, -Allan - Allan Rafuse, CCNA - Systems Administrator Equat.com Technologies email: [EMAIL PROTECTED] web: http://www.equat.com
Re: [PATCH][saslauthd] cyrus-sasl-2.1.10/saslauthd credential caching
Thanks, excellent feedback. I've been busy coding away all day. I'm not quite ready for another realease, but I thought I'd drop a line with some of the mods I'm making (they're pretty major). The biggie: cache_lookup() writes the user-provided password hash into the hash table BEFORE it is verfied. There's now a race where an attacker can submit an arbitrary string as a password, (if there's currently an entry in the cache, it will be evicted), then while the real lookup is happening he'll try a second authentication, which will succeed if cache_purge has not yet been called. I think I have a general problem with cache_lookup writing to the hash table, I'd expect lookup to be a read-only operation. If it fails, we do a lookup to the backend anyway, and then only if we SUCCEED in that lookup do we write the good password to the table. Round 3 now has: cache_lookup() cache_commit() cache_discard() Another important one: No locking of any kind is used on the shared memory segment. I'm not sure this is directly exploitable, but it could give odd behavior. Let's assume that we've fixed the above problem. Now we have a cache_write() (that looks similar to the writing portion of the current cache_lookup()) instead of a cache_purge(). If two processes are in cache_write at the same time, there's a race where they could both pick the same block to evict, and the result could be some mangled combination of both (or one or the other, but not both). Take this for instance (we assume that we had two cache misses, and that we only have one processor): . ... There clearly needs to be some sort of semaphore on the table (or on entries, or something). I've put in a first attempt at per bucket level locking via fcntl(). The only thing left to consider is if we should acquire a lock when the stats counters are updated. I'm not sure if the perf difference would be worth some inaccuracies in the hits/misses/attempts counters. Wasn't this originally going to use libmm? My knowledge on libmm is brief (quick reading today), Saslauthd already depends on fcntl() being there natively. If I understand correctly, libmm only does shm segment level locking. I'm not sure what the perf differences would be between per bucket level locking via fcntl() and table level locking via fcntl(). Since fcntl() is required by saslauthd, I went with per bucket level locking. libmm introduces another dependency (including autconf checks), unless libmm would be distributed with the saslauthd package. I originally thought it beneficial to keep any additional dependencies down if a good alternative could be presented. Plus, all in all, it sounded pretty challenging. Haven't done any hard core coding in awhile :). Finally: I think shared memory is way overkill for the doors version, since it all takes place within one process. Though, we'd still need to use some sort of councurrancy control. -Rob Yes, I've started to addresses this to. I've broken out the memory allocation so that the unix IPC method will use a shared memory segment, while the doors IPC method would stick with a malloc'd segment. The doors IPC method will retain the fcntl() based locking for the malloc'd segment. I have some reading up to do on doors IPC (is it thread based?). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper Thanks, Jeremy
Re: how to make sendmail authenticate to lmtpd
Rob, Thanks. SMTP AUTH was the answer. Now sendmail is authenticating to frontend lmtpproxyd as murder and delivering mail via the backend lmtpd with proper authentication. Next I have to figure out how to get mailbox moves between backends to work. Just wanted to clarify, I am not running lmtpd -a on the backends. I had done some testing with lmtpd -a to allow only localhost to connect to the localhost:lmtp port via TCP socket. lmtpd was not open to the world:) Gautam On Wed, 2003-01-15 at 16:45, Rob Siemborski wrote: On Wed, 15 Jan 2003, Gautam Das wrote: /* secprops = mysasl_secprops(SASL_SEC_NOPLAINTEXT); */ secprops = mysasl_secprops(0); There was a discussion thread with the above tip from Rob (Thanks Rob). However it made imap proxy work but not mailbox move from one backend to another. I'm not going to make any guarantees about trying to use the murder in a plaintext environment. It hasn't been tested in any way and there might be some surprises that I haven't thought of. That said, it's entirely possible that the backend imapd that is working as a client is refusing to use plaintext in *its* authentication, so I'd troll around in backend.c some. 2. sendmail fails to deliver messages via lmtpproxyd due to authentication problems.This is a typical mail deliver test that fails on the frontend server running lmtpproxyd. root@spnode21$ mail -v test100 Subject: test test . Cc: test100... Connecting to [127.0.0.1] port 2003 via cyrusv2... 220 spnode21 LMTP Cyrus v2.1.11 ready LHLO ufl.edu 250-spnode21 250-8BITMIME 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-SIZE 250-STARTTLS 250-AUTH PLAIN 250 IGNOREQUOTA MAIL From:[EMAIL PROTECTED] SIZE=32 [EMAIL PROTECTED] 430 Authentication required test100... Deferred: 430 Authentication required Closing connection to [127.0.0.1] QUIT 221 2.0.0 bye [snip] The above mailer (lmtp via a tcp socket) works fine on backend machines, which is using preauthenticated lmtpd i.e. lmtpd -a in cyrus.conf. Any help will be appreciated. You shouldn't run lmtpd on a TCP socket with -a. That basically bypasses any sense of delivery security LMTP is offering you. In reality, sendmail should be configured to do SMTP AUTH. At the very least, lmtpproxyd has to be able to do authenticated delivery from your smtp servers to the lmtpds on the backends. (and you can run lmtpproxyd -a on a unix socket on the local machine). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: [PATCH][saslauthd] cyrus-sasl-2.1.10/saslauthd credential caching
On Wed, 15 Jan 2003, Jeremy Rumpf wrote: Round 3 now has: cache_lookup() cache_commit() cache_discard() I'm guessing a failure to call cache_discard() just results in a memory leak and nothing worse (since you are preserving state from cache_lookup to cache_commit)? Wasn't this originally going to use libmm? My knowledge on libmm is brief (quick reading today), Saslauthd already depends on fcntl() being there natively. Sure. If I understand correctly, libmm only does shm segment level locking. I'm not sure what the perf differences would be between per bucket level locking via fcntl() and table level locking via fcntl(). Since fcntl() is required by saslauthd, I went with per bucket level locking. libmm introduces another dependency (including autconf checks), unless libmm would be distributed with the saslauthd package. I originally thought it beneficial to keep any additional dependencies down if a good alternative could be presented. Its unclear to me how standard the shared memory APIs are on more esoteric unixes anyway, so I'm pretty sure we want autoconf checking for this functionality as it is. The advantage of libmm is that we only need to check for libmm (and disable caching if its not there), instead of trying to cope with all the potential portability problems (which, presumably, libmm has solved). Plus, all in all, it sounded pretty challenging. Haven't done any hard core coding in awhile :). I can definately appreciate that. Yes, I've started to addresses this to. I've broken out the memory allocation so that the unix IPC method will use a shared memory segment, while the doors IPC method would stick with a malloc'd segment. The doors IPC method will retain the fcntl() based locking for the malloc'd segment. I have some reading up to do on doors IPC (is it thread based?). Yes. I'm not sure fcntl() locking is good enough within a single process. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
