Restrictive access to some users
Hi, On our cyrus server some users need access from office as well as from outside our LAN. So we nat the imap port on our firewall and people are able to access But Contract employees need not access mails from outside the office. How can I allow access for such users only from the office Thanks Ram Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: mail coming without MX; how ?
>if you check the domain "infoservices.in" with dnsstuff.com you can >see no MX for that domain. >But still mail is coming at [EMAIL PROTECTED]we are using it for >our official purposes and infoservices.in is our official site too. > >I wounder how mail is still coming with out MX ? could any one kindly >explain ? Most Mail Transport Agents will fall back to the A record if no MX records are found. This precident was set by sendmail, and woe betide any implementation that ignores precident, but it would be foolish to count on all MTAs behaving this way. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: mail coming without MX; how ?
Antoine Jacoutot wrote: > On Thu, 26 Apr 2007, JOYDEEP wrote: >> if you check the domain "infoservices.in" with dnsstuff.com you can >> see no MX for that domain. >> But still mail is coming at [EMAIL PROTECTED]we are using it for >> our official purposes and infoservices.in is our official site too. >> >> I wounder how mail is still coming with out MX ? could any one kindly >> explain ? > > This is to summarize... > If no MX is found for your domain, the MTA will sent the mail to the > resolving host. > > $ host -t MX infoservices.in > infoservices.in has no MX record > $ host infoservices.in > infoservices.in has address 85.199.129.73 > > So, your mail to [EMAIL PROTECTED] will be delivered to "user" at > 85.199.129.73. Thanks Antoine for the clarification , have a nice day > > Cheers. > Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: mail coming without MX; how ?
On Thu, 26 Apr 2007, JOYDEEP wrote: if you check the domain "infoservices.in" with dnsstuff.com you can see no MX for that domain. But still mail is coming at [EMAIL PROTECTED]we are using it for our official purposes and infoservices.in is our official site too. I wounder how mail is still coming with out MX ? could any one kindly explain ? This is to summarize... If no MX is found for your domain, the MTA will sent the mail to the resolving host. $ host -t MX infoservices.in infoservices.in has no MX record $ host infoservices.in infoservices.in has address 85.199.129.73 So, your mail to [EMAIL PROTECTED] will be delivered to "user" at 85.199.129.73. Cheers. -- Antoine Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
mail coming without MX; how ?
Dear list, if you check the domain "infoservices.in" with dnsstuff.com you can see no MX for that domain. But still mail is coming at [EMAIL PROTECTED]we are using it for our official purposes and infoservices.in is our official site too. I wounder how mail is still coming with out MX ? could any one kindly explain ? thanks Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: syncserver[4715]: Fatal error: Virtual memory exhausted
Yeah, that's a good point. I use sync_batch_size of 100,000. Regarding the original question, there are other operations that will exhaust memory as well. We've had two recent reports of Thunderbird users who unexpectedly developed extremely large cyrus.* files in their trash. Since cyrus.* files get mmap'd, a very large one may exhaust the address space of sync_server (or imapd for that matter). :wes On 18 Apr 2007, at 07:16, Bron Gondwana wrote: If you're using 2.3.8 just add: sync_batch_size: 1000 to your imapd.conf (or any other value - this works fine for me) The above patch is probably fine too, but I still prefer to stop the unbounded edge case regardless. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: syncserver[4715]: Fatal error: Virtual memory exhausted
On 18 Apr 2007, at 01:27, Simon Matter wrote: I'm still wondering why the code is there, can anybody comment on this? The buffer in question is dynamically sized. I gather that an earlier version of the code pre-allocated 5 paths. A later version allowed an arbitrary number, adjusting the buffer size appropriately. :wes Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: lmtpd -a and unified murder
On Wed, 25 Apr 2007, Janne Peltonen wrote: On Tue, Apr 24, 2007 at 02:01:08PM -0700, Andrew Morgan wrote: valid authentication mechanisms available and gives up. So. Is there a way to configure lmtpd so that it won't expect being able to authenticate to the remote backend (sic) and just proxies through everything it gets? Nope. I beat my head against this for a while myself and finally configured my MTA (postfix) to use authentication when talking to lmtp. Previously, I was using pre-authentication and tcp-wrappers. OK, thanks, that's what I thought. *sigh* Now, the Murder here will receive mail from two different systems: mail that's addressed directly to users' personal mailboxes comes from our spam-scanner machines, and list-mail comes from the list server (which receives the mail through the spam-scanners, so that we don't have to scan mail for spam for every member of every list separately). The spam-scanners are modern Linux machines, and we have no trouble configuring the Sendmails there to use authentication, but the list server is a Tru64 system - and whatever we do, we don't seem to get the Sendmail there to authenticate succesfully; as far as we understand, the Sendmail config there is identical to the Sendmail config on the Linux machines that work. Our best guess is that the SASL library is just too old (and newer versions don't seem to be available for Tru64). So, dear all: might it be possible that Cyrus SASL 1.5.28 is 'just too old'? Or are there some Catch-22's in its configuration with a Sendmail that wants to use authentication (the version we've here is 8.14.1)? Or are there some people who've succesfully compiled a newer SASL on a Tru64? I can't answer the SASL question. How about relaying the mail from the list server to your spam-scanner machines? Andy Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ZFS compression?
We're using ZFS on a V440 for our Cyrus spools that are on a 6920 and all I have to say is KICK A$$!!! ;-) ZFS will use as much memory as you can spare for caching, but it hasn't really caused us any problems. At first it made us nervous because it seemed like all our free memory disappeared (of course a leak in PAM/saslauthd didn't help.) However, it has turned out to be fine. And yes, compression is on. At first I was anxious about that, but it has turned out to be a total non-issue. So far we've been extremely happy with ZFS. In fact a short while ago we had a cooling problem with the particular server room this equipment is in, and to make matters worse the temperature warning sensor failed us. So the heat got high enough that things started shutting down on their own, including our Cyrus server. CRAP! I know for a fact that VxFS would have had to fsck the entire spools before they would come back. That probably would have taken a day. If we had to do a restore from tape, oh my that would have been nasty! However, ZFS came back instantly without the slightest hint of problems. Things have been running swimmingly (knock on wood) since then. On 4/24/07, Vincent Fox <[EMAIL PROTECTED]> wrote: Has anyone attempted using ZFS compression on mail spools? This is a new Cyrus 2.3.8 mail-store, and we are using dual fiber HBA to SAN switches and Sun 3510FC units on the backend, multipath and active-active on the dual-controllers. RAID-5 LUNs on each array are ZFS mirrored between arrays. Yes, multiple levels of paranoia. We have Sun T2000 which are quad-CPU. So it seems like there is plenty of CPU there for the extra overhead that inline compression is likely to add. Anyhow, I still envision the I/O being the bottleneck though so I am wondering if turning this on will buy me any performance and at what price? This system is not in production yet so I am still throwing things at it to see at what point it breaks. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: how to enable digestmd5 and crammd5 ? [ auf Viren überprüft]
Hi! JOYDEEP schrieb: I am using cyrus with ldap basded authentication. I am usin PLAIN and LOGIN mechanism in /etc/imapd.conf. How can I enable digestmd5 and crammd5 now ? Shared secret mechs in SASL2 are only available with sasldb or ldapdb (do I forget any?) not with saslauthd. So if you want ldap (with is possible with saslauthd, probably you do that) _and_ shared secret mechs, you should go with ldapdb. It is available from SASL 2.1.21 and above. I think, I posted an example conf here a while ago. Shared secret mechs need an unencrypted password to build and check the challenge. So you need unencrypted passwords in ldap, which is not a problem at all with proper acls. Hans Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: How to move mailbox across domains?
On Mon, Apr 23, 2007 at 05:09:17PM +0400, Igor Zhbanov wrote: > Hello! > > How to correctly move all user mailboxes (preserving hierarchy and > letters) from one domain to another? I mean rename user > [EMAIL PROTECTED] to [EMAIL PROTECTED] afaik cyrus imapd doesn't have standard feature for this, but you can use mailutil with proxyservers option in imapd.conf. WBR. Dmitriy Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: lmtpd -a and unified murder
On Tue, Apr 24, 2007 at 02:01:08PM -0700, Andrew Morgan wrote: > >valid authentication mechanisms available and gives up. So. Is there a > >way to configure lmtpd so that it won't expect being able to > >authenticate to the remote backend (sic) and just proxies through > >everything it gets? > Nope. I beat my head against this for a while myself and finally > configured my MTA (postfix) to use authentication when talking to lmtp. > Previously, I was using pre-authentication and tcp-wrappers. OK, thanks, that's what I thought. *sigh* Now, the Murder here will receive mail from two different systems: mail that's addressed directly to users' personal mailboxes comes from our spam-scanner machines, and list-mail comes from the list server (which receives the mail through the spam-scanners, so that we don't have to scan mail for spam for every member of every list separately). The spam-scanners are modern Linux machines, and we have no trouble configuring the Sendmails there to use authentication, but the list server is a Tru64 system - and whatever we do, we don't seem to get the Sendmail there to authenticate succesfully; as far as we understand, the Sendmail config there is identical to the Sendmail config on the Linux machines that work. Our best guess is that the SASL library is just too old (and newer versions don't seem to be available for Tru64). So, dear all: might it be possible that Cyrus SASL 1.5.28 is 'just too old'? Or are there some Catch-22's in its configuration with a Sendmail that wants to use authentication (the version we've here is 8.14.1)? Or are there some people who've succesfully compiled a newer SASL on a Tru64? Thank you. --Janne -- Janne Peltonen <[EMAIL PROTECTED]> Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
