imapd 2.1.15 + sasl2: exits on signal 11 when trying to authenticate
I'm trying to get imapd 2.1.15 to work on a freebsd 5.1 machine with SASL 2.1.13 (I think) Imapd respond to connections but dies whenever an attempt is made to authenticate to it: Oct 6 22:22:14 ash kernel: pid 27479 (imapd), uid 60: exited on signal 11 Oct 6 22:22:14 ash master[27475]: process 27479 exited, signaled to death by 11 I'm using sasl_pwcheck_method: auxprop and sasldb2 seems to be in order. Any ideas? -- Chris Hastie
[±¤°í]°¡À»¿¡ ¸ÀÀÖ´Â ±èÄ¡º¸·¯ ¿À¼¼¿ä~!
Title: Untitled Document 남한강포기김치 5kg/19,500원 남한강총각김치 5kg/24,500원 남한강열무김치 5kg/20,000원 남한강백김치 5kg/19,500원 남한강깍두기 5kg/16,500원 남한강고들빼기김치 5kg/29,500원 보성녹차포기김치 1kg/4,400원 보성녹차오이소박이 1kg/8,000원 보성녹차동치미 1kg/4,400원 보성녹차돌삿갓김치 1kg/6,500원 보성녹차나박김치 1kg/4,400원 보성녹차고들빼기 1kg/10,000원 고명원포기김치 1kg/10,000원 고명원토종갓김치 1kg/15,000원 고명원총각김치 1kg/10,000원 고명원배추김치 1kg/12,000원 고명원고들빼기김치 1kg/20,000원 고명원갓파김치 1kg/10,000원 베다니고냉지배추김치 5kg/25,000원 베다니고냉지총각김치 5kg/19,000원 베다니고냉지깍두기 5kg/19,000원 본메일은 광고메일입니다.수신거부를 원하시면 여기를 클릭하셔서 글을 남겨주세요. 이메일주소는 인터넷상에서 취득하였으며,어떠한 개인정보도 가지고 있지 않습니다. 사업자등록번호 : 314-05-86483 통신판매업 제 2003-46호 회사주소 : 대전시 유성구 봉명동 동아벤처타워 1519호 대표 : 유미경 Tel : (042)828-7040, (080)-600-7040, Fax : (042)828-7041 [EMAIL PROTECTED] All rights reserved [EMAIL PROTECTED] for more infomation
Re: Getting the separator from an mupdate server
On Mon, 6 Oct 2003, Etienne Goyer wrote: > How would one get the separator from an mupdate server ? In IMAP, > NAMESPACE or LIST "" "" would do it. What is the equivalent in mupdate? There isn't an equivilent in mupdate. Since all the hosts are cooperating, they all should know what the hierarchy separator is. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: imapd 2.1.15 + sasl2: exits on signal 11 when trying to authenticate
On Tue, 7 Oct 2003, Chris Hastie wrote: > I'm trying to get imapd 2.1.15 to work on a freebsd 5.1 machine with > SASL 2.1.13 (I think) > > Imapd respond to connections but dies whenever an attempt is made to > authenticate to it: > > Oct 6 22:22:14 ash kernel: pid 27479 (imapd), uid 60: exited on signal > 11 > Oct 6 22:22:14 ash master[27475]: process 27479 exited, signaled to > death by 11 > > I'm using sasl_pwcheck_method: auxprop and sasldb2 seems to be in order. > Any ideas? The most common cause of "signaled to death by 11" is mismatched berkeley DB libraries. (SASL and IMAPd link different ones, for example). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
problem with kerberos
Hi…. I’ve a problem with kerberos… i saying in .configure what –with-auth= unix… and when do it make throw error what not found any directory. Any idea?? Thx in advance
STARTTLS Question
I'm currently operating a Cyrus server listening in the following configuration, and authenticating via PLAIN/LOGIN with a saslauthd backend (only relevant config lines listed): imapcmd="imapd -U 30" listen="localhost:imap" imaps cmd="imapd -s -U 30" listen="imaps" pop3s cmd="pop3d -s -U 30" listen="pop3s" The IMAPS and POP3S ports are for user interaction, and the IMAP port is for the local webmail client (which operates over apache and mod_ssl). I don't wish to offer any services in an unencrypted format. My question is, can I offer the IMAP port to any client but configure it such that they are required to STARTTLS to communicate? This would help with some picky email clients that don't like to deal with the alternate IMAPS port properly. Thanks! Daniel
Re: STARTTLS Question
Hi Daniel... I can't answer your question, but I am wondering what client behavior you have seen in this regard that is incorrect? Thanks very much... Jim --On Tuesday, October 07, 2003 4:13 PM -0400 Daniel Whelan <[EMAIL PROTECTED]> wrote: I'm currently operating a Cyrus server listening in the following configuration, and authenticating via PLAIN/LOGIN with a saslauthd backend (only relevant config lines listed): imapcmd="imapd -U 30" listen="localhost:imap" imaps cmd="imapd -s -U 30" listen="imaps" pop3s cmd="pop3d -s -U 30" listen="pop3s" The IMAPS and POP3S ports are for user interaction, and the IMAP port is for the local webmail client (which operates over apache and mod_ssl). I don't wish to offer any services in an unencrypted format. My question is, can I offer the IMAP port to any client but configure it such that they are required to STARTTLS to communicate? This would help with some picky email clients that don't like to deal with the alternate IMAPS port properly. Thanks! Daniel
Re: STARTTLS Question
On Tue, 7 Oct 2003, Daniel Whelan wrote: > My question is, can I offer the IMAP port to any client but configure it > such that they are required to STARTTLS to communicate? This would help > with some picky email clients that don't like to deal with the alternate > IMAPS port properly. Thanks! I'm not sure what you mean here? Do you mean you want your webmail client to NOT use STARTTLS and your other clients to be forced to use it? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: STARTTLS Question
Daniel Whelan wrote: I'm currently operating a Cyrus server listening in the following configuration, and authenticating via PLAIN/LOGIN with a saslauthd backend (only relevant config lines listed): imapcmd="imapd -U 30" listen="localhost:imap" imaps cmd="imapd -s -U 30" listen="imaps" pop3s cmd="pop3d -s -U 30" listen="pop3s" The IMAPS and POP3S ports are for user interaction, and the IMAP port is for the local webmail client (which operates over apache and mod_ssl). I don't wish to offer any services in an unencrypted format. My question is, can I offer the IMAP port to any client but configure it such that they are required to STARTTLS to communicate? Assuming that you want to prevent plaintext passwords from being transmitted in the clear, set the following in imapd.conf: allowplaintext: no -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Highly available and scalable Cyrus configurations
We currently have a single IMAP server and we are considering two Solaris 8/9 HA Cyrus configurations: #1. IMAP Aggregator (murder) #2. Cyrus on a Veritas cluster (common file system with parallel service groups) After looking at the murder design, it seems to me that it's a lot more complicated than having a Veritas cluster and simply running imapd and an MTA on each cluster member, because with the murder configuration, you probably have to end up with a load-balancing switch in front of murder front-end machines which in turn are in front of the backend mailstore machines. mupdate has to be run and mail delivery has to be directed to the correct machine, etc. Moreover, with the murder design, backend machines would have to be clustered anyway (2-node clusters probably) to eliminate the back-end machines as SPOFs. With a cluster configuration, all machines would run sendmail and master/imapd and offer exactly the same service. A load-balancing switch is in front of the cluster and any cluster machine can go down without losing any service. I can't see any functionality that would be lost but I'm pretty sure that the cluster solution will be more expensive even though the expense of buying murder front-end machines would be eliminated. So, my first question is: has anyone implemented a Veritas-based Cyrus service? And my second question is: is there something I'm missing with regard to the Veritas cluster being a much simpler configuration to troubleshoot and operate and a much stronger configuration in terms of availability? TIA for all input. Ben Carter University of Pittsburgh/CSSD [EMAIL PROTECTED] 412-624-6470
Re: STARTTLS Question
--Ken Murchison <[EMAIL PROTECTED]> wrote: Assuming that you want to prevent plaintext passwords from being transmitted in the clear, set the following in imapd.conf: allowplaintext: no Whoops, totally missed that. For some reason I believed that this would kill the PLAIN and LOGIN authentication methods totally. I stand corrected. This appears to do exactly what I want. --Rob Siemborski <[EMAIL PROTECTED]> wrote: I'm not sure what you mean here? Do you mean you want your webmail client to NOT use STARTTLS and your other clients to be forced to use it? This wasn't actually my original question, but if I set allowplaintext to no, my webmail no longer is able to connect (as it wants an unencrypted connection). So, I'll ask a more complicated question: Can I selectively allow 127.0.0.1 to connect plaintext? Alternately, can I allow port X to be plaintext (and limited via tcpwrappers) and have port Y be no plaintext? Hopefully I'm not being too confusing. Daniel
Re: STARTTLS Question
I'll go ahead and answer my own question, as I evidently haven't been paying as much attention to the mailing list as I should have lately and found my solution buried back a couple months. On 30 July 2003 Matt Bernstein started a thread entitled "requiring encryption but not from localhost?", where Scott Adkins proposed a solution. I implemented something more or less like he proposed, and it worked. Specifically, I created a second imapd.conf (imapd-local.conf) and configured it with allowplaintext: yes. Then, I edited my cyrus.conf to look like the following: imaplocal cmd="imapd -U 30 -C /etc/imapd-local.conf" listen="localhost:ima plocal" prefork=0 maxchild=100 imapcmd="imapd -U 30" listen="imap" prefork=0 maxchild=100 imaps cmd="imapd -s -U 30" listen="imaps" prefork=0 maxchild=100 I couldn't get imaplocal to listen localhost on the imap port, so I defined an "imaplocal" port in /etc/services as port 144, and pointed webmail at that. All is well now...webmail from localhost gets plaintext, and everyone else gets IMAPS or IMAP/STARTTLS. Now I just need to finish documenting every mail client known to man... (Mozilla, Outlook, Eudora, Mac Mail, Mulberry, mutt, pine, etc). Daniel This wasn't actually my original question, but if I set allowplaintext to no, my webmail no longer is able to connect (as it wants an unencrypted connection). So, I'll ask a more complicated question: Can I selectively allow 127.0.0.1 to connect plaintext? Alternately, can I allow port X to be plaintext (and limited via tcpwrappers) and have port Y be no plaintext? Hopefully I'm not being too confusing.
Re: Highly available and scalable Cyrus configurations
On Tue, 7 Oct 2003, Ben Carter wrote: > and an MTA on each cluster member, because with the murder > configuration, you probably have to end up with a load-balancing switch > in front of murder front-end machines which in turn are in front of the This is not the case. Simple DNS round-robining is sufficient. > design, backend machines would have to be clustered anyway (2-node > clusters probably) to eliminate the back-end machines as SPOFs. Well, the aggregator isn't solving the HA problem. It is doing its best to mitigate it however (via partial failure modes). > And my second question is: is there something I'm missing with regard to > the Veritas cluster being a much simpler configuration to troubleshoot > and operate and a much stronger configuration in terms of availability? Well its simpler unless it breaks or has poor performance. I'm not familiar with the Veritas cluster (we have had good experience with vxfs on our backends however). You also probably want to be sure you're not replaceing one single point of failure (a backend) with another (the cluster). The key about the usability of the filesystem is that file locks need to be obeyed throughout the entire cluster, and mmap() needs to be efficient (and able to deal with read() and write() being called on that file at the same time). Also, the murder does get you one performance advantage that the veritas cluster (even correctly implemented) does not: it provides a large number of read-only copies of the mailbox list that clients can use for LIST operations, and not interfere with updates of the master copy. With the size of mailbox lists on systems that are considering HA options, or moving to an aggregator configuration, this is, in fact, a serious concern to think about. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Highly available and scalable Cyrus configurations
--On Tuesday, October 07, 2003 6:43 PM -0400 Rob Siemborski <[EMAIL PROTECTED]> wrote:r On Tue, 7 Oct 2003, Ben Carter wrote: and an MTA on each cluster member, because with the murder configuration, you probably have to end up with a load-balancing switch in front of murder front-end machines which in turn are in front of the This is not the case. Simple DNS round-robining is sufficient. How is simple DNS round-robin sufficient? More than one MUA caches the DNS lookups for its mail servers. I know that at least one version of Netscape Communicator used to. It probably still does. Also, some webmail clients do. So if a front-end is down or has not network connectivity, one gets hung MUAs. design, backend machines would have to be clustered anyway (2-node clusters probably) to eliminate the back-end machines as SPOFs. Well, the aggregator isn't solving the HA problem. It is doing its best to mitigate it however (via partial failure modes). I know. The aggregator is better for us for at least one other reason: we can use our existing SCSI storage arrays. Veritas does not support clustering with SCSI (changing the host SCSI initiator IDs to be different). And my second question is: is there something I'm missing with regard to the Veritas cluster being a much simpler configuration to troubleshoot and operate and a much stronger configuration in terms of availability? Well its simpler unless it breaks or has poor performance. OK. I thought so. I'm not familiar with the Veritas cluster (we have had good experience with vxfs on our backends however). You also probably want to be sure you're not replaceing one single point of failure (a backend) with another (the cluster). The key about the usability of the filesystem is that file locks need to be obeyed throughout the entire cluster, and mmap() needs to be efficient (and able to deal with read() and write() being called on that file at the same time). That the locking needs to work is clear. I did not think of the mmap() vs read/write issues. Thanks. Also, the murder does get you one performance advantage that the veritas cluster (even correctly implemented) does not: it provides a large number of read-only copies of the mailbox list that clients can use for LIST operations, and not interfere with updates of the master copy. With the size of mailbox lists on systems that are considering HA options, or moving to an aggregator configuration, this is, in fact, a serious concern to think about. That's another good point. However, is this still an issue if one does not select the flat file format for the mailboxes file? Has anyone implemented Cyrus IMAP with any type of clustering softwarethat you know of? Thanks, Ben -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper Ben Carter Computing Services & System Development University of Pittsburgh [EMAIL PROTECTED] 412-624-6470
Re: Highly available and scalable Cyrus configurations
On Tue, 7 Oct 2003, Ben Carter wrote: > > This is not the case. Simple DNS round-robining is sufficient. > > How is simple DNS round-robin sufficient? More than one MUA caches the DNS > lookups for its mail servers. I know that at least one version of > Netscape Communicator used to. It probably still does. Also, some webmail > clients do. So if a front-end is down or has not network connectivity, one > gets hung MUAs. Er, I should have said dynamic dns style systems. Round robin, is, as you say, not sufficient. > That's another good point. However, is this still an issue if one does not > select the flat file format for the mailboxes file? Yes. Concurrent access to the mailbox list is an issue with every database format. > Has anyone implemented Cyrus IMAP with any type of clustering softwarethat > you know of? I've heard success stories in warm-spare situations where the filesystem is shared, but only one server is active at a time. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
lmtp and uppercase email addresses
Hi. I've searched this mailing list and come across some posts which indicate that cyrus 2.2 (I'm running Cyrus-IMAP 2.2.1 with Postfix 2.0.9 on FreeBSD 4.8) is not case sensitive when dealing with user accounts/email addresses. That doesn't appear to be the case with my installation. Whenever the server receives an email where the address is all in uppercase letters I get the following error in my mail log.. host /var/imap/socket/lmtp[/var/imap/socket/lmtp] said: 550-Mailbox unknown. Either there is no mailbox associated with this 550-name or you do not have authorization to see it. 550 5.1.1 User unknown (in reply to RCPT TO command) Mail delivered to the same account gets accepted by cyrus if the address is in lowercase. I'm not sure what I'm doing wrong here so I would appreciate it if someone could point out what I've overlooked. Thanks! Here are the relevant parts of my imapd.conf file, I can provide the entire file if necessary.. sasl_pwcheck_method: auxprop sasl_auxprop_plugin: sasldb sasldb_path: /usr/local/etc/sasldb2 username_tolower: yes # /usr/local/cyrus/bin/deliver -l 220 mail.tdneti.com LMTP Cyrus v2.2.1-BETA ready mail from:<[EMAIL PROTECTED]> 250 2.1.0 ok rcpt to:<[EMAIL PROTECTED]> 550-Mailbox unknown. Either there is no mailbox associated with this 550-name or you do not have authorization to see it. 550 5.1.1 User unknown # /usr/local/cyrus/bin/deliver -l 220 mail.tdneti.com LMTP Cyrus v2.2.1-BETA ready mail from:<[EMAIL PROTECTED]> 250 2.1.0 ok rcpt to:<[EMAIL PROTECTED]> 250 2.1.5 ok
Re: lmtp and uppercase email addresses
On Tue, 7 Oct 2003, Avtar Gill wrote: > Hi. I've searched this mailing list and come across some posts which > indicate that cyrus 2.2 (I'm running Cyrus-IMAP 2.2.1 with Postfix 2.0.9 > on FreeBSD 4.8) is not case sensitive when dealing with user > accounts/email addresses. That doesn't appear to be the case with my > installation. Whenever the server receives an email where the address is > all in uppercase letters I get the following error in my mail log.. > > host /var/imap/socket/lmtp[/var/imap/socket/lmtp] said: 550-Mailbox > unknown. Either there is no mailbox associated with this 550-name or > you do not have authorization to see it. 550 5.1.1 User unknown (in > reply to RCPT TO command) > > Mail delivered to the same account gets accepted by cyrus if the address > is in lowercase. I'm not sure what I'm doing wrong here so I would > appreciate it if someone could point out what I've overlooked. Thanks! > > Here are the relevant parts of my imapd.conf file, I can provide the > entire file if necessary.. > > sasl_pwcheck_method: auxprop > sasl_auxprop_plugin: sasldb > sasldb_path: /usr/local/etc/sasldb2 > username_tolower: yes > You want lmtp_downcase_rcpt: yes > # /usr/local/cyrus/bin/deliver -l > 220 mail.tdneti.com LMTP Cyrus v2.2.1-BETA ready > mail from:<[EMAIL PROTECTED]> > 250 2.1.0 ok > rcpt to:<[EMAIL PROTECTED]> > 550-Mailbox unknown. Either there is no mailbox associated with this > 550-name or you do not have authorization to see it. > 550 5.1.1 User unknown > > # /usr/local/cyrus/bin/deliver -l > 220 mail.tdneti.com LMTP Cyrus v2.2.1-BETA ready > mail from:<[EMAIL PROTECTED]> > 250 2.1.0 ok > rcpt to:<[EMAIL PROTECTED]> > 250 2.1.5 ok > > > -- Igor
[SYS/PERM] Unable to open maildrop
Hello! I'm having a strange problem on which I cannot find any answers anywhere :) I'm using Cyrus 2.1.15 with imapd and pop3 servers and I'm getting weird error MSGes. When I try this: +OK moron Cyrus POP3 v2.1.15-IPv6-Debian-2.1.15-0woody.1.0 server ready <[EMAIL PROTECTED]> user nporenta +OK Name is a valid mailbox pass * -ERR [SYS/PERM] Unable to open maildrop What does that mean? I'm using saslauthd with pam and saslauthd verbose says that authentication is just fine. Mailboxes are created and ACL should be setup right... I tried using "alwaystrue" option in imapd.conf but the same result. When I tried using cyradm i received "Segmentation fault" so something really weird is happening? Does anyone knows the solution or somehow can point me there :) Thanks... Greetz, Jernej
Re: STARTTLS Question
> This wasn't actually my original question, but if I set allowplaintext to > no, my webmail no longer is able to connect (as it wants an unencrypted > connection). So, I'll ask a more complicated question: > > Can I selectively allow 127.0.0.1 to connect plaintext? Alternately, can I > allow port X to be plaintext (and limited via tcpwrappers) and have port Y > be no plaintext? Hopefully I'm not being too confusing. What's wrong with your current setup? Use IMAP port for your localhost (and make it official in TCPwrappers nad/or kernel IPtables) and IMAPS for all others. Nix.
too many pop3d processes
cyrus30751 1 0 Sep26 ?00:00:12 /usr/cyrus/bin/master -d cyrus26549 30751 0 Oct07 ?00:00:00 pop3d cyrus29490 30751 0 Oct07 ?00:00:00 pop3d cyrus30492 30751 0 Oct07 ?00:00:00 pop3d cyrus 1131 30751 0 Oct07 ?00:00:00 pop3d cyrus 4014 30751 0 Oct07 ?00:00:00 pop3d cyrus 4088 30751 0 Oct07 ?00:00:00 pop3d cyrus 7076 30751 0 Oct07 ?00:00:00 pop3d cyrus 9484 30751 0 Oct07 ?00:00:00 pop3d cyrus 9513 30751 0 Oct07 ?00:00:00 pop3d cyrus24155 30751 0 Oct07 ?00:00:00 pop3d cyrus13883 30751 0 Oct07 ?00:00:00 pop3d cyrus 2991 30751 0 Oct07 ?00:00:00 pop3d cyrus25738 30751 0 Oct07 ?00:00:00 pop3d cyrus14734 30751 0 Oct07 ?00:00:00 pop3d cyrus 5746 30751 0 Oct07 ?00:00:00 pop3d cyrus 1109 30751 0 Oct07 ?00:00:00 pop3d cyrus21688 30751 0 Oct07 ?00:00:00 pop3d cyrus 8306 30751 0 Oct07 ?00:00:00 pop3d cyrus 1630 30751 0 Oct07 ?00:00:00 pop3d cyrus27825 30751 0 Oct07 ?00:00:00 pop3d cyrus16468 30751 0 Oct07 ?00:00:00 pop3d cyrus15544 30751 0 Oct07 ?00:00:00 pop3d What's happaning? Agri
Re: lmtp and uppercase email addresses
Igor Brezac wrote: On Tue, 7 Oct 2003, Avtar Gill wrote: Here are the relevant parts of my imapd.conf file, I can provide the entire file if necessary.. sasl_pwcheck_method: auxprop sasl_auxprop_plugin: sasldb sasldb_path: /usr/local/etc/sasldb2 username_tolower: yes You want lmtp_downcase_rcpt: yes Thanks. For anyone's future reference, the solution provided above worked.
