Re: Shared Mailboxes and Postfix
Josh Whitver wrote: Thanks for the help thus far, but now when I start the mail service, I get this in /var/log/mail.log: May 9 11:37:59 testldap postfix/master[12863]: daemon started -- version 2.1.5 May 9 11:38:40 testldap postfix/smtpd[12887]: fatal: open database shared_folders.db: No such file or directory May 9 11:38:41 testldap postfix/master[12863]: warning: process /usr/libexec/postfix/smtpd pid 12887 exit status 1 May 9 11:38:41 testldap postfix/master[12863]: warning: /usr/libexec/postfix/smtpd: bad command startup -- throttling I'm no Postfix expert, so I'll just suggest that you confirm that the file(s) have adequate permissions for the user running Postfix to be able to read them... other than that, your installation may be expecting the files in a different place. --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Shared Mailboxes and Postfix
Josh Whitver wrote: As I understand it, this should allow us to send mail to "Conference+ mailbox name>@" and have the message delivered to the shared mailbox. This isn't what's happening, however. Initially, there was no mail-capable user named "Conference", so I created one, but now all mail sent to the address above gets delivered to the "Conference" user Inbox, not the shared mailbox. I just went through this myself last week :-) The Postfix 'local' process won't accept mail for users it can't identify, so it does not think there is a valid local recipient for 'Conference' unless you add it as a user, which doesn't accomplish what you want. Instead, you need to make two changes in your Postfix main.cf: First, add "recipient_delimiter = +", so that Postfix will ignore the "suffix" after the username when looking for a match. Second, if you don't already have a 'local_recipient_maps" line, add one using the default contents (which are shown in the local(8) man page). Third, create a file in your Postfix config directory called 'shared_folders', with contents like this: Conference yes (the second token can be anything, it just has to be present). In the Postfix config directory, run "postmap hash:shared_folders" to create a hash db from this file. Finally, add 'hash:shared_folders" to the end of the local_recipient_maps line in main.cf and restart Postfix. There is one downside to this configuration: Postfix will accept mail addressed to Conference+, then Cyrus will reject it if there is no matching folder. If you wish, you can list each valid shared folder in the shared_folders file, and don't add the 'recipient_delimiter' option to main.cf, which will avoid this problem but require more maintenance as you add/remove folders. --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Invalid Header
Vernon A. Fort wrote: so I could see what part of the header was invalid. There was/is a line: Message-ID: with nothing after the line. I removed the line and re-sent the message successfully. Why would single line called Message-ID: cause lmtpd message header errors? Because it's invalid syntax according to the RFCs. A header name must be followed by a value, otherwise it cannot be present. --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: confusion about setting up certificates
Jim Miller wrote: I'm still having trouble will Outlook and connecting with IMAPS to cyrus-imap 2.2.10. when I set 'tls_reqire_cert: true'. However I don't have the problem when I set tls_imap_reqire_cert: true' That's because this second setting is ignored. For settings to apply to specific services, they are _prefixed_ with the service name, so this would be "imap_tls_require_cert". --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: [RFC] EXTERNAL auth choosing between CN and email address?
Marco Colombo wrote: So it seems its usage is deprecated. If you are to code a patch, you may look into the alternative name(s). Those are standard v3 extensions. As I understand it, comforming applications should look there in order to find email addresses (of type rfc822Name). Of course, since you're using your own CA, you could use whatever field/attribute, but keeping an eye on standards won't hurt, IMHO. And after all your own mail was an RFC. :-) Yes, thanks for that. I'll keep that in mind when I get back to working on this in a few days, and check both places for addresses. --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: [RFC] EXTERNAL auth choosing between CN and email address?
Marco Colombo wrote: What field is that, exaclty? v3 extension? I'm not sure... it's in the OpenSSL headers files as "NID_pkcs9_emailAddress". Anyway, the goal of authentication is to identify users not email addresses. The whole idea of using certs is broken, unless you use the cert itself. No CA makes any attempt to provide _unique_ information. And the uniqueness of an email address it pretty weak. The only unique info you can extract from a cert is the public key, which is what you're actually using to identify the remote party. I agree, but in this case the email address _is_ the user name. Of course, if your server trust only _one_ CA, and you have control on how that CA works, you can use certs safely. You can make sure CN data (or any data) is unique. Exactly, that's the only scenario where this is viable. When I document this for people to use, I'll make that perfectly clear: if you configure your system to accept _any_ client certificate, you are not doing yourself any good. This method _only_ works when you are administering the CA yourself and have complete control over the contents of the certs and who has access to them. Granted, I could also just make the CN in the cert be the user's email address, but I'd rather leave it as their full name (it's much nicer in Horde that way, plus we also use it for Trac). --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: --with-auth only for group memberships?
Igor Brezac wrote: --auth-auth specifies an authorization (not authentication) mechanism. The unix module is mostly useful for group. OK, yeah, authorization vs. authentication, right. Since SASL cannot provide authorization details, Cyrus IMAP has to get them from somewhere else, so that's understandable. This is not correct. unix_group_enable is used only when you compile the unix authorization mechanism, otherwise it has not effect. Understood. I'll continue using the combination of --with-auth=unix and unix_group_enable turned off, which will keep Cyrus IMAP from caring about group memberships (and looking at my passwd/group files). --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
[RFC] EXTERNAL auth choosing between CN and email address?
I'm working on a webmail system using client certificates for authentication. I have Cyrus IMAP working fine with Cyrus SASL and "AUTH=EXTERNAL" after negotiating TLS... the IMAP daemon authenticate the user properly. However, it chooses the CN from the client cert as the authentication identity. With a bit of hacking to imap/tls.c I was able to convince it to use the "email address" instead, but I'd rather not keep it this way... I'll be happy to post a patch that allows for imapd.conf selection of whether to use the CN or email address as the identity when AUTH=EXTERNAL is used, but I'd like some input on what the configuration option should be called, and whether it should be a boolean or a multiple-choice option. --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Basic FAQs and HOWTOs
Craig White wrote: My goal was to be my own CA - generate per user certificates and have revocation rights. I haven't had many issues with creating certs for various applications such as ldap/apache etc. I was looking for some granular control for individual users. I do this manually using OpenSSL commands directly; it's really not that difficult. The biggest issue is ensuring that all your SSL/TLS-enabled services are aware of your CRL (revocation list). As best I can tell, Cyrus IMAP does not currently support a CRL, so you wouldn't be able to stop users from accessing your IMAP/POP servers using a cert you supplied. --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
--with-auth only for group memberships?
I've just reworked my Cyrus IMAP installation, and I'm beginning to get the impression that --with-auth (which defaults to "unix") is only for group memberships, and really has no other effect. It certainly doesn't seem to affect SASL in any way, which is what actually handles authentication. Since I have "unix_group_enable: 0" in my imapd.conf file, does that mean that it no longer matters what I specify for --with-auth? If so, the documentation could use an update to make that abundantly clear, and ideally the option could be renamed so people don't think it has anything to do with actually authenticating users :-) --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Horde/IMP authentication to Cyrus via client certificates?
Igor Brezac wrote: Your bigger issue is to find a client that supports SASL/EXTERNAL. I do not believe c-client library (this is what drives IMP/Horde via PHP) supports SASL/EXTERNAL, so this is what you need to start hacking. OK, I've successfully connected using imtest and SASL/EXTERNAL and it works fine (other than using the CN as the authentication identity, but I'll post about that in another thread). Thanks! --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Horde/IMP authentication to Cyrus via client certificates?
[EMAIL PROTECTED] wrote: cyrus/imapd[15511]: starttls: TLSv1 with cipher AES256-SHA (256/256 bits new) no authentication cyrus/imapd[15511]: login: localhost[127.0.0.1] pascal plaintext+TLS The "no authentication" at the end of the first line is due to client certicats are not allowed with webmail (c-client library doesn't support it) But the connection has well been crypted like passwd and login. Yes, I'm aware of that; what I'm proposing is to enhance c-client to support client certificates so that after the TLS negotiation is complete, the client will already be authenticated as well. --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Horde/IMP authentication to Cyrus via client certificates?
Igor Brezac wrote: SASL/EXTERNAL is what you want although I have to not tried it. OpenLDAP works great. In theory, the CN part of the client certitificate subject needs to be a valid mailbox. You can test this with imtest -t client_cert_file -m EXTERNAL I assume that you have SSL/TLS working. Yes, I do have that working. I'll test with SASL/EXTERNAL, it sounds like exactly what I need. I don't really want the CN to be the mailbox name, though, I'd rather have SASL/EXTERNAL work off the email address embedded in the certificate. Your bigger issue is to find a client that supports SASL/EXTERNAL. I do not believe c-client library (this is what drives IMP/Horde via PHP) supports SASL/EXTERNAL, so this is what you need to start hacking. That's been my plan; c-client is very simple, and I've already hacked Horde to get the PEM-encoded client cert from Apache and store it in a session variable, so I can extract it out in IMP and pass it to c-client. If I get it working I'll post the results :-) --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Horde/IMP authentication to Cyrus via client certificates?
Edward Rudd wrote: This is really a Cyrus-SASL topic. as Cyrus IMAP doesn't really care how the user gets authenticated, only that the SASL layer authenticates the users. So client certificate authentication would have to be added as a SASL authentication module. It's never been clear to me where IMAP stops and SASL starts as it relates to this... but it's my impression that Cyrus SASL has nothing at all to do with SSL/TLS, and only handles the authentication details after Cyrus IMAP has collected them. I guess that means that what I want to do will actually require changes in both Cyrus IMAP and SASL... time for more research :-) --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Hardware RAID Level & Performance
Andrew Morgan wrote: You may want to look into Dell's AX100 SAN (a rebranded version of the EMC Clariion AX100). These use SATA drives with a FC front end. They are relatively inexpensive for the amount of storage you can get, if your I/O needs match. You can also go a little more upscale with the CX300/500/700 models which support a mix of FC and SATA hard drives and offer greater expandability. Even better, they just released the AX100i, which uses iSCSI for the host interface. The array units are about the same price, but connectivity for 6-8 hosts is far, far cheaper than FC. --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Basic FAQs and HOWTOs
Wil Cooley wrote: Lately I've been trying to migrate my self-signed certs to certs generated with TinyCA from a self-signed root cert; that way once I import my root CA I can bypass all of the prompts. Yes, that is a much better plan. I do that for my clients who have private webmail/intranet sites, just generate a cert for each client who will be connecting (from the same CA that generated the server's cert), and when they install it into their browser/mail client they automatically "trust" the private CA. No prompts when they connect to the server :-) --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Horde/IMP authentication to Cyrus via client certificates?
I'm trying to come up with a configuration of Horde/IMP and Cyrus 2.2.x that will be easy to use and easy to manage :-) (I've got a number of these systems to set up). So far, I have been successful using client certificates to identify users to Apache 2.0.x, and using a custom Horde auth module I can pass that identity information into Horde (and all its apps except IMP) without trouble. This is nice, it keeps the users from having to "log in" to Horde, as long as they are using a browser where they have installed the certificate that I supply them they are all set. However, IMP needs to be able to log in to Cyrus IMAP, and that's where things break down. Even though Cyrus IMAP supports IMAP-over-TLS, which uses a certificate to identify the server, it does not appear that it knows anything about client certificates (to say nothing of the fact that I'd have to hack c-client to allow it to send the client certificate to Cyrus, but I can do that). Ideally I'd like to be able to connect to the IMAP port, issue STARTTLS, supply a client certificate and have it validated the same way that Apache does, and once that is done I have both a TLS encrypted session _and_ I'm already logged into IMAP with the email address embedded in my certificate being my authenticated/authorized name. I will also need to support password-based authentication for cases where the user is not using a browser with their custom certificate installed, but since they will be doing so 99% of the time I'd like to avoid them having to enter a username/password to get into Horde/IMP. Any thoughts on how difficult it would be to get Cyrus IMAP to accept a client certificate, validate it and automatically "log in" the user once that is done? I'll happily contribute the code back to CMU if I get it working, but I though I'd ask the gurus for their opinions before I tried to tackle it :-) --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: HowTo-ish question
Rich West wrote: We did manage to get the cyrus-imap server up and running in a Fedora Core 2 environment authenticating against PAM (which in turn talks to our LDAP servers), but we could not get users in to the system. Essentially, with our test environment, the mail client (in this case, Mozilla Thunderbird) kept erroring out stating that the mailbox did not exist (the inbox) when, in fact, users. did exist in the user's home directory. You are missing some very basic knowledge here: Cyrus IMAP is a closed system. It manages the message store on its own, entirely outside the user's home directories, and the message store is never touched by any non-Cyrus process. Messages come in via SMTP, LMTP or IMAP (or NNTP, in recent versions), and they go out via POP3, IMAP (or NNTP). The remainder of the workings are a "black box". So, any solution that we would come up with would have to satisfy the same requirements: sendmail MTA, global mail tagging, server side local user delivery filtering, and finally POP/IMAP access with user authentication passed off through PAM to our LDAP servers. Of course, we would need a way to convert from UW's mbox style to maildir format. All of this is possible; many people use sendmail to feed mail to Cyrus IMAP (and default configs for doing so are included with Cyrus IMAP), "mail tagging" can continue to be done by your MTA or some other process that sits in between the MTA and Cyrus IMAP, server side filtering is done via Sieve filters (which do not have all the flexibility of procmail, but are pretty useful nonetheless). I don't know why you think "maildir format" is relevant (see above); there is no direct filesystem conversion into Cyrus IMAP message store, it is always done via IMAP. Most people use a tool that's distributed with uw-imap to do this; you basically log in to your existing IMAP system and extract the messages, feeding them into Cyrus IMAP via IMAP as well. Can Cyrus work with procmail? It would be a lot more pain on our part to re-invent that portion of the entire process (the scripts, the customized web interface, etc). Not in the way you have been using it, no. You can certainly have global procmail filters that happen before sendmail sends the mail to Cyrus IMAP, but not per-user procmail filtering. Most people that implement Cyrus IMAP use some other form of web-based Sieve filter management (there are a few out there: websieve, Horde Ingo, avelsieve add-on for Squirrelmail, etc). --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: High availability ... again
Norman Zhang wrote: I think you can get it here, http://sources.redhat.com/cluster/gfs/ Yes, thanks. When I looked at the "sources" page I was looking for GFS directly, not a "cluster" subproject. This page appears to have everything needed to use GFS. --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: High availability ... again
Etienne Goyer wrote: On a similar note, RedHat have apparently bought Sistina, and GPLed GFS. This is great news for HA under Linux, IMHO. I will be testing it soon. Well, on their site is it listed as "open source", but it is not on sources.redhat.com (where LVM2 and device-mapper landed when they bought Sistina). In addition, it appears to only be available as part of RHEL, which is quite expensive. --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: mail server replication
Colin Bruce wrote: I haven't tried it yet but it may be that DRBD (http://www.drbd.org) might be able to do what you want. We used it with a UW Imap server and I don't see why it shouldn't work with Cyrus. It is probably possible to split the users between two cyrus servers and have each group replicated to the other server so that each server could become a server with all users reasonably quickly. I suspect it would take a few minutes to fail over. As I say I haven't tried this so perhaps it won't work. drbd in combination with "heartbeat" and a journalling filesystem can do exactly this. You can have Cyrus IMAP running on both servers (different users), with the Cyrus storage areas mirrored to the other server via drbd. When heartbeat notices that one of the servers has died, it can mount the other server's storage area (since it has a copy) and start up Cyrus (and take over the other server's IP address as well, of course). Users would notice a service disruption, but it's not likely any mail would be lost and they would only have to reconnect. If their mail client is set to only connect/check their mailboxes every few minutes, they may not notice the switchover at all :-) --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Authenticate to IMAP server via Active Directory
[EMAIL PROTECTED] wrote: Are you sure Outlook can use GSSAPI?? I tried the following : Windows 2000 Prof., Member of W2K-ADS, logged in with @ Mailclient OE 6 (latest security packs), Secure Password Authentication enabled Outlook and Outlook Express are not the same thing, in fact they are not even related except in name. --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: newspostuser --> To, but what about Reply-To?
Ken Murchison wrote: I finally got around to dealing with this. I just committed a patch which does the following: - use Followup-To (if exists) instead Newsgroups when constructing Reply-To - strip any post addresses from Reply-To when feeding the article upstream (via NNTP or SMTP) These sound like good changes Ken, I look forward to testing them. Note that there will always be problems with doing this sort of thing, you can't cover all the possibilities :-) I just had a thought (no I'm not asking you do to more work, just wondering): if a newsgroup message comes in (via fetchnews) that was crossposted to two groups, one of which is _not_ mirrored into a local IMAP folder, and then a user replies to the IMAP folder copy of that message, will the additional newsgroup followup be "lost"? No big deal if it is, just might be worth documenting. --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: exim and user+mailbox format
Erik Myllymaki wrote: Can any Exim-Cyrus users help me out here? There's a few posts around that detail this using cyrus_deliver, but my cyrus_transport in exim.conf is LMTP... Direct subfolder delivery with LMTP is a little tricky, you basically have two choices: - Set up cyrus.conf to start lmptd in pre-authenticated mode (add the -a parameter), and add an "anyone p" (post) ACL to all subfolders that you want to be able to deliver directly to. or - Set up Exim to authenticate itself to lmtpd (using PLAIN auth is fine for this, as long as you ensure that lmtpd is only listening on the loopback interface), and then add an "authenticated_sender" setting to your Cyrus delivery transport that forces Exim to supply the appropriate sender name to lmptd. There are other caveats to this method as well; if you search the exim-users archive you should find where I posted a recipe for this last year. --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: newspostuser --> To, but what about Reply-To?
Ken Murchison wrote: It shouldn't be. I never change the Newsgroups header, so once the article hits NNTP, it will propagate as usual. Well that's just dandy! --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: newspostuser --> To, but what about Reply-To?
Ken Murchison wrote: [EMAIL PROTECTED] wrote: On Tue, 17 Feb 2004, Ken Murchison wrote: I've actually been looking for more info on this type of thing, and here is what I found: http://www.unicom.com/pw/reply-to-harmful.html http://cr.yp.to/proto/replyto.html I can strip the address before transferring the article via NNTP, but this doesn't help if the article is posted/replied via SMTP. I can see what you're dealing with here, and it's significant. You've got a message in a folder with its Reply-To: set to post+folder.subfolder, and the original To:/CC: headers still in place. If the user does a straight reply, the reply goes via SMTP to the post+folder.subfolder address, which is now in the To: header. When it arrives at the lmtp2nntp gateway, this must be stripped from the To: header, and the Reply-To: header inserted again. If the user does a "reply all", then the above scenario occurs, but also other copies of the message are delivered to the original recipients of the source message. This could include a variety of problematic things including other newsgroup names (the original message was crossposted), some or all of which are not present on this Cyrus installation or even SMTP recipients (normal mail addresses). The reply may very well be sent to these other SMTP recipients as well, without any Cyrus software being involved at all, in which case the post+folder.subfolder address would be exposed to them. This will have to be handled by the outbound MTA, there is no way around that, and it's a complicated documentation issue to boot. How ever the user does a reply, the reply will end up back in the folder via lmtp2nntp, and is available to be sent upstream to an NNTP server. When this happens, I think all the headers in the message need to be searched for _any_ post+XXX addresses and those should be stripped; the message may have been sent to more than one local newsgroup folder. It would be ideal if the NNTP upload could see that and send only one copy to the relevant NNTP server (so the message would preserve its crossposting), but that's not easy to do I'm sure. --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: newspostuser --> To, but what about Reply-To?
Ken Murchison wrote: Thanks for looking this up. I'll change it locally and test it with Mozilla and Outlook (and possibly Pine). This would be a welcome change in my opinion because it means the user won't see a "bogus" To: field entry for imported newsgroups. Granted, they'll see that address if they hit Reply, but still... --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: [OT] MUA's with "direct post" support?
Ken Murchison wrote: If you're talking about posting via NNTP, the article will still end up having the To: header added by nntpd (if configured to do so). Unfortunately no, I'm considering an environment where the users don't have NNTP clients at all. Their only access to the shared folders will be via IMAP and whatever method is used for posting. In this case, it appears that the user would have to manually send a message to "post+news.group" to start a new thread, so that the message will flow through lmtp2nntp and get the right headers and such added. I can live with that, but it means adding a button or two to the SquirrelMail interface :-). --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: [OT] MUA's with "direct post" support?
Ken Murchison wrote: Are you worrying about how user's reading newsgroups via IMAP shared folders will post to these groups? If so, you can allow this fairly easily by using the newspostuser option and the lmtp2nntp software. Take a look at doc/install-netnews.html for details on how to set this up. OK, now that I've read the docs again I see how this is supposed to work. The MUA can just "reply" to the created To: address, and the SMTP server that the MUA sends the message to for delivery diverts it to lmtp2nntp. That makes sense, and is pretty straightforward to implement. In my case, the MUA is going to be SquirrelMail, so this will be _really_ easy to do, no configuration required on the user's part at all. Just had another thought: this works fine for replies, but not for users who want to start new threads in the folder. For that they'd need to use the post+news.group.subgroup syntax, right? If they used an MUA with direct posting support, the posted message wouldn't have the right To: header and noone would be able to reply to it. --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: [OT] MUA's with "direct post" support?
Wil Cooley wrote: Not that everyone in your organization will have a Linux desktop, but Evolution 1.4 has this capability. I had heard that Evolution supported this type of posting, so I'll take a look. See my other reply to Ken though about how this might now work out, as the posted message needs to have the proper headers to allow replies to work. --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
[OT] MUA's with "direct post" support?
I'm looking to set up shared folders to use as discussion boards, as well as possibly to use the new NNTP functionality to mirror some newsgroups into shared folders. However, that pretty much dictates using an MUA that supports "direct posting" of messages into those folders, rather than requiring them to be sent into the folders via SMTP (at least that's the way it seems to me). Anyone have any suggestions? I'd like it very much if I could get SquirrelMail to do this, but I'd like to try out any other alternatives to see if this technique is going to work. --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: nntp fiddling
Nils Vogels wrote:
Kevin, may I ask how you managed to get multiple groups using one
fetchnews command ?
I've been trying comma delimited group names (fetchnews -n -w
"nl.test,nl.someother" news.myisp.nl) but for some reason no articles
are fetched then. If I use space delimitations, only the first group works.
fetchnews(8) isn't too clear about this, I'm afraid and when I look at
example wildmats in imapd.conf(5) I see comma seperated grouplists
("peer.example.com:*,!control.*,@local.*")
Else I will be fetchnews-ing a complete feed (including binaries) while
I really only need a few groups, right ?
I haven't actually had a chance to set it up yet, it's on my list for
this coming week.
Re: nntp fiddling
Ken Murchison wrote: There is no overlap between the groups from the different servers, and grouping them is easy with wildcard matching: cups.* microsoft.* infragistics.* everything else OK, so you need the newspeer option to be a *list* of peers? But you *don't* need fetchnews to track the newsgroups by host? Forgive my inability to answer that at this point, I haven't studied the Cyrus NNTP support documentation yet. Here is what I like to do: (A) mirror about a dozen newsgroups from news.west.cox.net (my ISP, Usenet groups) (B) mirror about a dozen newsgroups from news.microsoft.com (public NNTP server) (C) mirror six newsgroups from news.easysw.com (public NNTP server) (D) mirror about ten newsgroups from news.infragistics.com (public NNTP server) I read _and_ post to most of these groups. No single group comes from more than one place, though, each group has only a single server that I will use to get and post messages for that group. I don't know that if that answers your questions or not... but I suspect this sort of arrangement will be a common usage of Cyrus' NNTP support (for those places that don't arrange for feeds). In fact, if you want to use any of these non-Usenet groups that corporations/etc. provide, you'll never get a feed and have to use reader mode.
Re: nntp fiddling
Ken Murchison wrote: Would you want to feed to all of the servers, or just one? Currently, fetchnews and nntpd are only setup to have one upstream peer. Yes, I would want to feed messages back to all the servers. Actually fetchnews can work with any server you want, but it doesn't keep track of the groups by server. So, as long as there isn't any intersection of the groups your are fetching from the servers, your won't have a problem. If anybody thinks that fetching the same groups from different servers is necessary, I can tweak the fetchnews.db format to handle this (I think). There is no overlap between the groups from the different servers, and grouping them is easy with wildcard matching: cups.* microsoft.* infragistics.* everything else Until I add POST support, you could set a news2mail annotation on the groups that you want to feed upstream and then use lmtp2nntp OK, I will look at that as well. My outbound message volume is very light, so I don't need anything very complicated to handle it. The "news" folders are no different from "email" folders. You can feed them via NNTP and serve them via IMAP or feed them via LMTP and serve them via NNTP (or any other combo). SquirrelMail shouldn't have any problem serving up your newsgroups. Very nice! That means that once I have this done I'll be able access all four of my mailboxes and all the newsgroups I participate in from anywhere on the Internet... life will be sweet :-)
Re: nntp fiddling
Ken Murchison wrote: Yes, it uses IHAVE. I can take a look at adding support for POST (the commands are almost identical). Does your provider also require you to authenticate? Ken, I'd like to try out this support too, I've been hanging around waiting for it to more stable (and get features like these added). In my case, I'd be mirroring newsgroups from 4-5 different servers, none of which I can get a feed from. That means using reader mode only, for both retrieval and posting; in my case, none of them require authentication (they are either public servers or use IP authentication (my ISP)). I don't have 2.2.x installed yet, but my server will be undergoing a major rebuild in the next week or two and I'm looking forward to trying this out. It will be used in combination with SquirrelMail, so I'm hoping the news folders will be easily usable from there.
Re: Authenticate Cyrus off active directory
Rob Siemborski wrote: Our webmail (squirrelmail) is doing kerberos authentication. We gutted the authentication part of squirrelmail and instead launch a persistant imtest process, which squirrelmail connects to instead (this was relatively easy to do, actually -- most of the changes that were required were in imtest). This also has the benefit of caching authentications (like a proxy), since successive page hits just re-use the same imtest process. I'd like to be able to do the same sort of thing; any chance these changes are distributable (no support, i'm sure they're ugly, etc. etc.)? The trick is that you need to get the user's kerberos ticket to the web server, which we accomplish via a system known as pubcookie, which has been developed by a few universities. Its sort of like kerberos-via-cookies, though the kerberos ticket passing bit is somewhat disconnected from the main system. This was the stumbling block in my mental exercises to get this working. I'd never heard of pubcookie before :-)
[Slightly OT]: NTLM auth via SquirrelMail?
I just recently set up SquirrelMail connected to an existing Cyrus 2.1.15 installation. So far so good, things are working well. However, I'd like to move towards a single sign-on model, and this should be possible given that the clients are running Windows/IE and authentication against a Samba domain controller. I believe I can set up mod_ntlm in Apache to learn the remote user's name and pass that to SquirrelMail, but then I need to get SquirrelMail successfully logged in to the Cyrus mailbox for that user _without knowing the user's password_... I can think of some possibilities: - make SquirrelMail always log in as some type of "super user" in Cyrus land, with authorization to access the user mailboxes - somehow use NTLM authentication in Cyrus as well (although I don't know if that could be made to work, seeing as Cyrus is not actually talking to the real client) - make Cyrus believe the IMAP connection is "preauthed" as user "x" and not require any type of IMAP LOGIN Anyone have any suggestions?
Re: Whose fault? vacation messages bounce to postmaster.
mark london wrote: I am running cyrus/squirrelmail/sendmail. I have a vacation plugin for squirrelmail and set up vacation autoresponding. However, if vacation responds to a spam message that has a bogus email address, the bounced message that says that the vacation message can't be delivered to that bogus email address, goes to postmaster at our site, rather than the person who has vacation enabled. I don't know if this is a feature or a bug, and how to change it's behavior. I notice that thevacation autoresponse messages have a line at the top of message say that cyrus set sender to <>. Is this possible the reason for this behavior? Or is it a sendmail feature? Here's the header of a vacation response message. Thanks! - Mark You've indirectly answered your own question. Automated responses, like vacation responses, are always sent using a null sender, to avoid message loops. If the response was sent using the original recipient's address as the sender, where would the bounce be sent? If it was sent to the original recipient, that would trigger the vacation response again.
Re: Determining deliverability
Pat Lashley wrote: I've been thinking about finding the cycles to whip out a utility that would take a local_part on the command line; and return success or failure to indicate whether it is deliverable. It would work by starting an LMTP session and issuing a RCPT; then RSET and QUIT after getting the response to the RCPT. Having to spawn a task to do that is a bit ugly; but I don't think Exim has a way to do it internally. (Or at least not directly. I might be able to do something with the built-in perl lib...) Exim 4.20 has (almost) what is needed to do this now. It can already do SMTP callouts to verify recipients. It can also LMTP callouts, as long you aren't using LMTP AUTH for delivery to Cyrus. I am using LMTP AUTH so I don't have to add special permissions to folders for direct subfolder delivery, but if you aren't, and are using LMTP over TCP/IP for delivery to Cyrus, then all you need is a "verify = recipient" clause in one of your ACLs, and Exim will make the callout for you. Exim also caches callout results, so it won't make repeated callouts for the same addresses more often than you specify.
Re: Determining deliverability
Pat Lashley wrote: I've been thinking about finding the cycles to whip out a utility that would take a local_part on the command line; and return success or failure to indicate whether it is deliverable. It would work by starting an LMTP session and issuing a RCPT; then RSET and QUIT after getting the response to the RCPT. Having to spawn a task to do that is a bit ugly; but I don't think Exim has a way to do it internally. (Or at least not directly. I might be able to do something with the built-in perl lib...) Follup: I mistyped, that should have been "verify = recipient/callout" in your ACL, otherwise Exim will only verify that you have a router that will accept the address, not that that it's actually deliverable.
Re: MTAs that pass SMTP AUTH?
Scott Balmos wrote: My question is, where is Sendmail getting, or even sending to the deliver program, the information that says to match against username msmith, johndoe, or whatnot? I know of the -a switch for deliver, but pretty much all the other MTAs (including Postfix) say that there can only exist a "blanket" Cyrus user, designated to the MTA, for posting to shared folders. This is intended to be used in a secure localized installation, with the users using SMTP AUTH to authenticate themselves to the MTA. The MTA then records this information and passes it along via LMTP AUTH to the Cyrus lmtpd. Where's everything come from, authentication-wise? The only thing I can think of is the user creates a message, saves to their local drafts folder, then manually "moves" the message into the proper folder on IMAP. But that seems really icky, and essentially like "IMAP Send". Well, in my case, we're not actually using SMTP AUTH to deliver the messages to the MTA. Rather, I have set up mail delivery such that a message that arrives at my MTA address to "[EMAIL PROTECTED]" is delivered as if it had been AUTH'd as "user". This means that messages can be delivered directly to any user's folders, without having to give anonymous "p" rights on those folders. Yes, this does mean that someone out there could abuse it, but all they could do is put random stuff directly into a folder, instead of into the user's INBOX. If we had shared folders set up, then I would have to implement SMTP AUTH so that the the folders could have reasonable (i.e. non-anonymous) rights.
Re: MTAs that pass SMTP AUTH?
Scott Balmos wrote: Does anyone know of any other MTAs that can pass SMTP AUTH info along to Cyrus, other than Sendmail? I'm thinking in the base case here, of a single server, for an intranet. We've already, unfortunately, ruled out Postfix earlier last week, I think I remember reading. Exim, as of version 4.14 for sure, can do this. I am using it this way, with Exim speaking LMTP over a TCP/IP port to Cyrus lmtpd. Any ideas, pointers to docs for things like this, anyone else done this somewhere, sometime? :( I do not have shared folders set up here, but I don't see any reason why that would matter. If you decide to seriously consider Exim, email me off-list and I'll forward you the relevant parts of my configuration file.
Re: Perl 5.8 and Cyrus Imap
Ken Murchison wrote: Does cyradm display the password prompt? I did a fresh RedHat 8.0 + updates (Perl 5.8.0) install on a laptop so I could do some development while on the road, and the prompt for the password doesn't display. It took me a while before I realized that cyradm wasn't hung, its just silently waiting for input. I get the same behavior with both Cyrus 2.1.12 and 2.2.0, so I know its not related to a change in Cyrus. What I don't know is if this is a problem with Perl 5.8.0, Redhat's packaging of it, or a problem in some library that Perl uses. My system is a home-built (LFS based) kit, not RedHat. There is no pam, for example. Anyway, if use cyradm --auth PLAIN localhost imap I do get a Password: prompt. I can type anything I want there, it doesn't matter. Then I get an IMAP Password: prompt. At that point I must type the actual user's password. Then I'm in and it works fine.
Re: Perl 5.8 and Cyrus Imap
Eli Ben-Shoshan wrote: Has anyone gotten the perl stuff that comes with Cyrus Imap to compile using Perl 5.8? I get the following error: I have Cyrus 2.1.12 running with Perl 5.8.0 without a problem; I did nothing special during the installation, it all just worked.
Re: Case sensitve user/mailbox names
Patrick Welche wrote: % exim -bV Exim version 4.12 #4 built 30-Jan-2003 16:41:01 Copyright (c) University of Cambridge 2002 So I think Kerstin is right... Cheers, Patrick Hmmm. I think this may have something to do with the method being used to get the messages from Exim to Cyrus. There are (at least) four ways to do that: 1) Exim can pipe the messages to the Cyrus "deliver" command. 2) The Exim LMTP transport can deliver to Cyrus' lmtpd over a Unix socket. 3) The Exim LMTP transport can deliver to Cyrus' "deliver" command via a pipe. 4) The Exim SMTP transport (in LMTP protocol mode) can deliver to Cyrus' lmtpd over a TCP/IP socket, with or without SMTP authentication. I am currently using method 4. I don't have time to test the different methods to see how they handle caseful local parts, and there could certainly be a bug in Exim in the LMTP transport. When I first set up Exim 4.x, I was using method 3 and most definitely had to lowercase local parts before sending them to Cyrus.
Re: Case sensitve user/mailbox names
Kerstin Espey wrote: As long as you don't use the option "caseful_local_part" in the exim router, exim will send all mails to the lowercase mailbox. Regards, Kerstin Exim 4.x does not act this way, but Exim 3.x did. If you don't make specific provisions to supply Cyrus a lowercase local part using Exim 4.x, the messages won't get delivered.
Re: Case sensitve user/mailbox names
Pål Olsen wrote:
Hi,
I've just implemented a new mail platform using Cyrus IMAPd 2.1.11 and Exim
4.12, and I wonder... how to deal with the fact that systems don't allways
do want you expect..?
It seem to me that exim/cyrus has problem with delivery of mail if the
mail-address are written in another case than the mailbox-name... E.g. user
fridao@mydomain can't receive mail if the sender uses mail-address
Fridao@mydomain. How should I deal with that?
I have a router like this in my Exim 4.1x setup talking to Cyrus (at the
appropriate place in the sequence, i.e. just before your Cyrus deliver
router):
lowercase_local:
driver = redirect
domains = +local_domains
redirect_router = local
data = ${lc:${local_part}}
with the Cyrus delivery router being named "local".
Re: Cyrus IMAPd 2.1.12 Released
Rob Siemborski wrote: The distribution is available at: ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.1.11.tar.gz or http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.1.11.tar.gz And those links should, of course, be: ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.1.12.tar.gz or http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.1.12.tar.gz
Re: cyradm
Piet Ruyssinck wrote: On Mon, 3 Feb 2003, Daryl wrote: It seems my problem is that I only want to offer imaps as a service, but when I comment imap out of cyrus.conf, the cyradm tool won't connect. Is there another way around this ?. enable imap in cyrus.conf, but limit it to your administration host via tcp wrappers. Or even better, just limit it to listening on 127.0.0.1 in cyrus.conf directly, and avoid tcp_wrappers completely.
Re: unix:lmtp vs /usr/cyrus/bin/deliver ?
Henrique de Moraes Holschuh wrote: On Tue, 21 Jan 2003, Thomas Hannan wrote: Anyways, with the AMaViS virus filtering, could you clarify a bit? Does your Get amavisd-new, tell your MTA to deliver to amavisd-new through SMTP, then deliver it back to the MTA through SMTP, and let it deliver to Cyrus through LMTP. Trivial to do with postfix, if you read the docs... and *very* fast. You don't interface amavisd-new directly to cyrus (although you COULD do so) so that it can generate bounces, and do some intelligent per-user processing. Besides, it is safer to have it send the messages back to a MTA. Actually, the very latest release of amavisd-new fully supports using LMTP to send the messages on after scanning, so it can be used to send them to Cyrus in LMTP mode. It can then generate DSNs if necessary and send them out via whatever SMTP MTA you are using.
Re: Why are only admins allowed to AUTH to lmtpd?
Rob Siemborski wrote: On Fri, 3 Jan 2003, Kevin P. Fleming wrote: >This is all working fine, except that I had to add my dummy authentication user >(which I create solely for Exim to authenticate itself to lmtpd with) to the >"admins" entry in /etc/imapd.conf. I had to do this because lmptd specifically >allows only admins to authenticate. use lmtp_admins if you don't want to give that user full admin rights. OK, I hadn't found that option yet. It's perfect for what I need. >Is there any particular reason why? It's not a big deal for me, but when >I document this configuration for other people I'm sure this will raise >some eyebrows. There's no reason regular users should be submitting to the LMTP server, they should be submitting using SMTP to an SMTP server, and then the LMTP server trusts the SMTP server. This (admitedly marginaly) simplifies the authorization code in lmtpd. True enough. In my case, the LMTP server listens only on a TCP socket on the loopback interface, and there are no shell accounts on this system, so it's fairly secure already.
Re: Why are only admins allowed to AUTH to lmtpd?
Lawrence Greenfield wrote: --On Friday, January 03, 2003 12:48 PM -0700 "Kevin P. Fleming" wrote: > This is all working fine, except that I had to add my dummy > authentication user (which I create solely for Exim to authenticate > itself to lmtpd with) to the "admins" entry in /etc/imapd.conf. I had to > do this because lmptd specifically allows only admins to authenticate. > > Is there any particular reason why? It's not a big deal for me, but when > I document this configuration for other people I'm sure this will raise > some eyebrows. Allowing anonymous users to directly submit via LMTP would defeat any accounting done in the MTA and allow for perfectly forged Received headers. Allowing arbitrary users to authenticate could be just as bad with the current code, though it could be modified---but it's not clear it's worth it. Since there are some LMTP extensions like IGNOREQUOTA that require administrative rights, it doesn't seem worthwhile to try to get finer grained authorization than "lmtp_admins". I responded to most of that in my reply to Rob, but thanks for the additional information. lmtp_admins will do exactly what I need.
Why are only admins allowed to AUTH to lmtpd?
I have modified my configuration here so that now my MTA (Exim 4.12) uses RFC2554 authentication to identify itself to lmtpd. This was done so that Exim could supply AUTH= on the MAIL FROM: line, thus eliminating the need to add "anyone p" ACLs to subfolders in order to allow direct subfolder delivery. This is all working fine, except that I had to add my dummy authentication user (which I create solely for Exim to authenticate itself to lmtpd with) to the "admins" entry in /etc/imapd.conf. I had to do this because lmptd specifically allows only admins to authenticate. Is there any particular reason why? It's not a big deal for me, but when I document this configuration for other people I'm sure this will raise some eyebrows.
Re: Not seeing Inbox
Gregory Chagnon wrote: Thanks...so how would I go about setting up an IMAP account for user "testuser" that would have the same folders as a Microsoft Exchange server? I'm trying to get this thing looking as similar to the Exchange server as possible so I'd like to have a visible Inbox, Sent Items, Deleted Items, Outbox, and Drafts...Thanks again. -Greg Look in the documentation regarding "altnamespace". Turning this on will make INBOX appear as a regular folder (even though it's a level above all the others). The user won't be able to create any folders underneath INBOX, if they try they will end up at the same level as INBOX. You can then create the other folders as needed. As far as Sent Items, Deleted Items, Outbox, etc. those are under control of your MUA, you can create them but it will need to actually be told how to use them.
Re: What format can Cyrus store mail in?
Erik Enge wrote: > Hi. > > I have been trying to figure out what formats Cyrus can store mail in, > but even though I have gotten hints here and there I have found no hard > information. > > Does it use Berkley DB to store the mail? How about maildir/mailbox? > > Thanks, > > Erik Enge. Cyrus stores the messages themselves in individual text files, unchanged from the way they are passed in via LMTP. It also creates various indexes, seen databases, etc., in the mail folders, and the formats of some of these can be chosen at compile time (flat textfile, skiplist, BDB).
Re: More on RedHat 8.0, Cyrus compile problems
Ken Murchison wrote: > > "Kevin P. Fleming" wrote: > >>Ken Murchison wrote: >> >>>No released version of Cyrus and SASL will work with gcc3. You'll have >>>to grab both from CVS. >>> >>> >> >>Really? My system here is running both (SASL 2.1.7 and IMAPD 2.1.9), >>compiled with GCC 3.2 and not experiencing any difficulties at all. Is >>there something I should be aware of? > > > It was my understanding that you'd get a bunch of warnings/errors using > gcc3 with the released versions. Carlos Velasco submitted configure > patches for both which have been applied to CVS. > Ahhh, ok, well yes there were extraneous warnings, but they didn't cause any compile or configure failures and everything worked for me, so I didn't worry about them. :-)
Re: More on RedHat 8.0, Cyrus compile problems
Ken Murchison wrote: > No released version of Cyrus and SASL will work with gcc3. You'll have > to grab both from CVS. > > Really? My system here is running both (SASL 2.1.7 and IMAPD 2.1.9), compiled with GCC 3.2 and not experiencing any difficulties at all. Is there something I should be aware of?
