Re: segfaults with cyrus-imapd 3.0.9 on latest arch linux
> "AP" == Andreas Piesk writes: AP> Hello list, i'm trying to get cyrus-imapd 3.0.9 (testet 3.0.8 too) AP> running on latest arch linux. Here's the configure summary: AP> External dependencies: ldap: no openssl: yes zlib: yes pcre: yes AP> #6 0x7fc4aa385050 re_acquire_state_context (libc.so.6) AP> #7 0x7fc4aa3907d4 re_compile_internal (libc.so.6) AP> #8 0x7fc4aa391511 regcomp (libc.so.6) You have pcre enabled but you are calling glibc regex functions. You may wish to double check that you are linking properly. Fedora went through a similar issue a while back when --Wl,--as-needed was added to the default set of compiler flags, which caused subtle variations in the link order. The end result was that Fedora picked up a set of pcre patches similar to what some other distros have to avoid duplicating the glibc symbol names. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Cyrus IMAP in the next Debian
> "PV" == Paul van der Vlis writes: PV> Somebody has packaged Cyrus version 3.08, but there are problems PV> with some of the Cassandane tests. It may be useful to see how Fedora handles Cassandane as part of its build process. I did a lot of work to get things functioning and get patches pushed back upstream to make it easier to run Cassandane as part of our package build process. A fair bit of work to get things working better on our less-common architectures is also in there. That said, we do still have to disable a few Cassandane tests for various reasons. The Fedora specfile (https://src.fedoraproject.org/rpms/cyrus-imapd/raw/master/f/cyrus-imapd.spec) has explanations and information about each disabled test. Search for "Run the Cassandane test suite". PV> I think it would be good if there would be more contact between the PV> Cyrus Debian developers and the Cyrus IMAP community. I have always find the Cyrus developers to be helpful. Nobody had to put me in contact with them; I just filed tickets and asked questions here and on IRC. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: System I/O error (in reply to end of DATA command) for LMTP delivery
> "SI" == Stephen Ingram writes: SI> I did turn it off just to see what happened, but it was not SI> the problem. Nice though, because I learned how to relabel a volume SI> to get back in the good graces of SELinux. Well, just using setenforce doesn't disable selinux; it just disables enforcement. You would still get denials in the audit logs and such. So it's a nice way to do a quick test that selinux isn't the problem. Just setenforce 0, test, and setenforce 1. If the behavior changed then yeah, it's probably selinux. If you actually really disabled selinux via the kernel command or by setting SELINUX=disabled in /etc/selinux/config then, indeed any files you created while it was in the disabled state would not be labeled and the easiest way out of that is probably 'touch /.autorelabel; reboot'. Which is why it's generally best to not disable it if you intend for that system to normally use selinux. Once you get used to ausearch -m AVC -ts recent (or today, or whatever) then it's a pretty small leap to using audit2why and audit2allow to make small modifications to the policy, or using semanage fcontext -a to make sure the proper labels are applied. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: System I/O error (in reply to end of DATA command) for LMTP delivery
If you suspect selinux, please do 'ausearch -m avc -ts today' and see what you get. You may also wish to do 'setenforce 0' and try again, just to make sure. I can provide some basic help with selinux if that's needed. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Backup methods
> "A" == Anatoli writes: A> What about mysqldump > dump.sql, then mysql < dump.sql? Also a wrong A> way and didn't have to be implemented? No, that's exactly my point. Thanks for making it for me! The analog to the way you indicated that you would like it to work would be having the mysql server stop IO so that you can take a filesystem snapshot while the database is in a consistent state. But instead, the database (like cyrus) implements a backup method which you can use to extract the data. And it also requires disk space to hold the backup until you can transfer it to your backup medium. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Backup methods
> "A" == Anatoli writes: A> What you mention is highly related to the replication backup A> we were talking about in the previous mails. Well, sort of. It is a method that is actually focused around doing backups. It happens to make use of the replication protocol because that is actually the smart way to do it. I did detail the differences in my message. A> In both cases, a copy of the master data is made, which requires A> twice the space of real usage (Cyrus Backups tries to apply A> compression on stored data, not sure how well it works). As I mentioned, the documentation discusses this. A> What is really needed, IMO, for SME environments is the ability for A> Cyrus to sync to disk all data, so one can take a hot copy of that A> data with standard UNIX tools and then handle it accordingly. Once a A> recovery is needed, one just copies a backup to the Cyrus dir and A> starts the service. Honestly I believe that's the wrong way to go about it, but it's certainly one way to do things if you have no backup solution integrated into the software. But hey, it's your data. I only wanted to mention that there really is an existing backup solution which wasn't being discussed. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Backup methods
Cyrus does have an integrated backup system (see https://cyrusimap.org/imap/reference/admin/backups.html) which I'm not sure has been mentioned in this thread. But you still have to have enough space to keep the compressed backups on disk in order to move them to tape or whatever archival storage you're using. There is discussion of the storage requirements in the documentation. I don't think any of it is particularly unreasonable, but I haven't actually tried it myself. Technically I don't think you need a separate machine (though that's simpler); it may just be possible to have a second cyrus server listening on different ports to act as the replication target. I probably wouldn't do it that way anyway; old hardware with some cheap disk would suffice to stage the backups until they're sent to tape or wherever. As for it all being marked "experimental", I'm sure that if bugs were found (and reported), they would be fixed. It probably just needs more testing and back and forth with the devs to flesh out the documentation and add any missing functionality. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Solaris Compiling 3.0.5 with libical3.0
> "JD" == Jean-Christophe Delaye writes: JD> Is Libical 3.0.0 supported with 3.0.5 ? Any idea ? It is not, but you can apply https://github.com/cyrusimap/cyrus-imapd/commit/1966c22fc4249a1157a4d4c1224138ce78653514 At least that's what I do in Fedora. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Failure making cyrus-imapd-3.0.5 on CentOS 7
> "DJW" == David J Weller-Fahy writes: DJW> Greetings again, I've made it a bit further in my attempt to DJW> install cyrus-imapd, but am getting failures when executing `make`. DJW> The failure is shown below. You should look at what the Fedora specfile does to build the package. Technically it's possible with some tweaking to get that package to build on EL7, but you have to disable some things because the EL7 versions of things like Xapian are too old. The specfile is at https://src.fedoraproject.org/rpms/cyrus-imapd/blob/master/f/cyrus-imapd.spec Look down at what is currently line 288 for how I specifically handle the perl/annotator directory. There are certainly other cyrus-imapd packages for EL7 that you could just make use of. I was considering trying to get a non-conflicting cyrus-imapd3 package into EPEL, but that's more difficult than just getting the thing to build. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: update to 3.0.3 even more problematic than 3.0.2
> "BG" == Bron Gondwana writes: BG> https://github.com/cyrusimap/cyrus-imapd/issues/2132 BG> We're pretty sure we've found the cause. Do you plan to cut a 3.0.4 release or should I plan on pushing this patch into my distro packages? - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Fedora26. Cyrus- 3.0.3. cyr_virusscan None Configured.
> "AS" == Anton Shilov via Info-cyrus > writes: AS> I think it is missconfig because ClamAV isn't part of cyrus-imap AS> packet. The Fedora package is not configured to use clmav. This is because clamav in Fedora still uses the old openssl libraries while cyrus uses the new libraries. Using them together results in problematic behavior, though the nature of this depends on the architecture and probably other factors, some of which might be random. In Fedora, I saw various test suite failures. You can of course rebuild the Fedora package from source if you wish. Just edit the spec to add back in BuildRequires: clamav-devel and the rest is automatic. The reasons for the removal are also documented in the spec file, as well in the cyrus documentation itself. Note that the Fedora package is also not configured to use mysql for the same reason, though I think I will be able to enable it in Fedora 27. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: any working cyrus-imapd-3.0.2?
> "SL" == Stephan Lauffer writes: SL> ...ok found working fedora 26 packages... Yes, I have updated packages in Fedora 26, but if you have any specific questions about how I've built things please let me know. The spec file is relatively well commented: https://src.fedoraproject.org/cgit/rpms/cyrus-imapd.git/tree/cyrus-imapd.spec - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Update from cyrus-imapd 2.5 to 3.0
> "JLT" == Jason L Tibbitts writes: JLT> Maybe it would be better if you could provide more explicit JLT> information in some way. Like, a directory listing or something. To update the list, the issue was that the admins: line contained a regular user ID. When that user logged in, the namespace was rather confused. The documentation is already pretty clear that you aren't supposed to do that, but the negative effects were a bit odd and it wouldn't surprise me if 3.0 reacts differently from previous versions. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Update from cyrus-imapd 2.5 to 3.0
> "DH" == David Hill writes: DH> Also, if a folder is created, it is created in DH> /var/spool/imap/[first_letter_of_folder]/Junk instead of DH> /var/spool/imap/d/user/dhill/Junk ... In your bug you indicated that things were being stored under /var/spool/[first letter]/ in the previous version. Here you say they were being stored under /var/spool/imap/first letter]/. Perhaps that's why my responses to you in the bugzilla ticket are so confused. Maybe it would be better if you could provide more explicit information in some way. Like, a directory listing or something. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Can't find icu-uc to build IMAP 3.0.0
> "RLM" == Rosenbaum, Larry M writes: RLM> I am trying to build Cyrus-IMAP 3.0.0 on RHEL6. That's pretty old these days EL6 has a version of libicu that doesn't include any of the icu-* pkgconfig files. It does contain libicuuc, though. You just need to tell the configure script to use "-licuuc -licudata" to link with the libraries. The message you receive should tell you what you need to know. I just verified that RHEL7 does have the necessary pkgconfig files, so there shouldn't be any problems there. I'll attach the pkgconfig file for icu-uc from a current version. - J< icu-uc.pc Description: Binary data Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: imap impersonate
> "PG" == Patrick Goetz via Info-cyrus > writes: PG> Why would you need to do this as opposed to, say, just setting up PG> multiple personalities on your MUA? I used impersonation to initially import mailboxes into Cyrus way back when I switched from uw-imapd. I guess it might also be useful to be able to see the same view of a user's mailbox that they have without having their password. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: "Resource temporarily unavailable", systemd and your FAQ Webpage
> "NB" == Nic Bernstein via Info-cyrus > writes: NB> I'm curious which Linux distribution NB> you're using? For the record, Fedora's systemd has task accounting enabled (and I've added some information to the unit file about it). I'm not sure about RHEL7 as its systemd/system.conf file doesn't mention Tasks at all. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: fetching spam from users junk folder
> "MS" == Marcus Schopen via Info-cyrus > writes: MS> Hi, I'm looking for an easy way to fetch spams, which were moved MS> into a special junk subfolder by users in their accounts. I'd like MS> to move those messages from there to my account, so I can analyse MS> them to adjust anti spam rules. How would you do that? I posted about my setup for this just a couple of months ago. I set up a confirmed-spam folder for each user, which has an ACL that gives the "spamkill" user access. Then I have a simple program that pulls the mail out of there and stuffs it in an mbox file, and another program to run on my mail filter hosts that passes all of that spam to sa-learn. You can find the relevant code at: https://www.math.uh.edu/~tibbs/spamsuck/ If you just wanted to be able to read the mail in those folders, though, why not just add an ACL for yourself and read the mail normally? - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Did calculating the quota change from 2.3 to 2.5?
> "BG" == Bron Gondwana via Info-cyrus > writes: BG> If you use imapsync, it doesn't know about that, and will upload the BG> same message twice. 2.5 doesn't have the smarts to recognise that BG> it's the same message. Fun random question: Does anything blow up if you run hardlink on your mail spool? (The hardlink program finds identical files and hardlinks them.) Given an index of message-id/filenames it should be possible to write a deduplicator that's orders of magnitude faster than hardlink, but I have a sneaking suspicion that someone's already done that. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Cyrus mail spool entirely on SSD
> "MU" == Michael Ulitskiy via Info-cyrus > writes: MU> My question is: assuming cost is not an issue, would it be advisable MU> to put an entire cyrus mail spool on SSD? I'm thinking about MU> combinining multiple SSDs into RAID10 to further increase MU> performance. I don't see why not. You certainly will want redundancy and will need to monitor the health of storage regardless of whether you store your bits in polysilicon or magnetized rust. Of course the failure modes and rates are completely different; disks don't really care how much you write to them while SSDs will have basically a fixed write quantity. Once you hit that, your SSD is generally out of warranty regardless of its age. And, of course, there are all sorts of complicated interactions because SSDs are still relatively new and things like TRIM and what happens to read data after it has been trimmed are still kind of up in the air. Of course, if cost really is no object, go all NVMe, use the latest Intel datacenter grade SSDs, enjoy the incredible speed and drives rated for multiple petabytes written. One thing of importance is that the Cyrus mailbox index files get rewritten a whole lot. I don't know if anyone has tried to quantify the write load of a mail spool for purposes of predicting SSD replacement intervals. MU> What do you think? I think if I had the money I'd have done it already. I have several all-SSD machines, but not yet my Cyrus server. For cost containment, I would probably go with a mixed NVMe-SATA system, putting the hottest bits on NVMe (and, of course, tmpfs for things which can disappear) and the spool on SATA, still with plenty of redundancy. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: watching and processing a Spam folder for each user
> "PB" == Patrick Boutilier via Info-cyrus > writes: PB> Only problem with that is users always seem to report some stuff as PB> spam when it clearly isn't. :-) True, but at least it's only a statistical thing. You could easily extract the From: headers and blacklist them, but that would be far more problematic, I think. What I really want to be able to do is to periodically plow through all of the unread messages in everyone's mailboxes and pass them back through spamassassin. The blacklists lag the spam runs and it would be nice to at least get rid of stuff which wasn't blocked initially but which would be blocked later. I guess I need to write some more code. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: watching and processing a Spam folder for each user
> "BJM" == Brian J Murrell via Info-cyrus
> writes:
BJM> So leaving out the latter part (the per-user database and handling,
BJM> etc.) I wonder what, if anything exists to monitor the Spam (and
BJM> NotSpam) folders for all users.
I have a system which sucks things out of everyone's "confirmed-spam"
folders and feeds it to spamassassin on each filtering host. It's in
Perl (back from when I remembered how to do perl) and is probably
unpleasant.
https://www.math.uh.edu/~tibbs/spamsuck/
Run spamsuck to pull down all of the spam folders into mbox files and
empty them. Note that the "spamkill" user (or whatever you choose to
call it) needs ACLs ("lrte", I think) on the confirmed-spam folder, so
your user creation process or sommething run as your admin user needs to
set that up. There's no reason you couldn't pull out ham folders as
well.
Run spamlearn on each filtering host to feed the sucked spam to
sa_learn. This updates the global bayes databases, not anything
personal to each user.
I don't bother to do this all automatically, but you could.
- J<
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: how to deal with mail retention/archival.
> "GR(" == Giuseppe Ravasio (LU) via Info-cyrus
> writes:
GR(> I saw that someone proposed to make a sort of abuse of delayed
GR(> expunge, but I think that in order to comply with regulatory
GR(> retention should be better considering some specific software.
True, but it seems odd (to me, in a situation where I don't have
infinite money) to have basically two mail servers: one which actually
removes things when the user deletes stuff and one which doesn't.
I guess they can be optimized for different things, but it still seems
odd when we already have a server that can store as much mail as you
want, provides a means to access and search it with ACLs for auditors
and such, and of course is already installed and running.
If it were possible to hook the message deletion functions in cyrus to
move things to a different place in the hierarchy and then control
expiry on those differently than the regular folders, it would probably
be sufficient. But that requires code and I don't have the skills to
write it.
Alternately, it _could_, instead of removing the message files at
deletion time, just move them somewhere. Then you could script what you
want to do with them. Certainly not super featureful but frankly when
the lawyers want something, I just dump mail files on them and let them
sort it out.
- J<
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: [cyrus 3.0] 20 delayed mailbox deleted limit?
> "BG" == Bron Gondwana writes: BG> Just to be really clear what this is. It's per mailbox name - if BG> you create and delete the SAME mailbox more 20 times, it only keeps BG> the most recent 20 of that mailbox. Hmm. That's much less problematic, but it still allows someone to force something to be deleted if they really want it to be deleted. That's not really an issue for me because my users wouldn't figure it out, but I can imagine that someone using delayed expiry to easily implement some sort of legal requirement might be unhappy. But that's somewhat of a stretch. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: [cyrus 3.0] 20 delayed mailbox deleted limit?
> "BG" == Bron Gondwana via Info-cyrus > writes: BG> How would you suggest we protect against exploiting delayed delete BG> to fill the server without going over quota? Well, I don't even run quotas. But I do keep deleted messages around for 12 weeks, and even if I didn't, I do delete accounts occasionally. Deleting one account would go over the limit, and though I suck the messages out to mbox format for the final archiving, an instant nuke of older mailboxes would prevent an "easy" restore. BG> Maybe a new quota BG> field for "total mailbox usage including deleted stuff" that can be BG> set to a high enough value that no reasonable user will ever hit it? As long as I can just set it to 'unlimited', I don't care. Disk is cheap and I don't have enough users to worry about it. But I've had people delete all 100+ of their mailboxes before, and come screaming. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: LDAP backed aliases
> "TG" == Tony Galecki via Info-cyrus > writes: TG> I’ve done a quick search and haven’t come across anything yet. Is TG> there a way to manage or pull alias information via LDAP? It could TG> be that my google fu is weaker than yours. Well, I have my aliases in LDAP and have for years, but that doesn't involve cyrus at all. It's done at the MTA level on our inbound mail servers, though you could do it at the MTA level on your cyrus machine as well. My mail servers run Exim, but I doubt yours do so I don't think an example from my configuration would be very useful to you. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: berkdb in configure.ac
> "EA" == Eray Aslan writes: EA> The berkdb macros in cmulocal/berkdb.m4 tries to find the installed EA> berkeley include files and libraries but they are just too painful EA> and error prone. I had reports of imapd crashes because of EA> include/lib mismatches. Fedora has carried a (much smaller) patch forever which reorders the bdb detection in cmulocal/berkdb.m4. http://pkgs.fedoraproject.org/cgit/cyrus-imapd.git/tree/cyrus-imapd-2.3.12p2-current-db.patch It is annoying to have to do this, but then 3.0 won't use bdb at all so it shouldn't be an issue much longer. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Cyrus IMAP 3.0.0-beta1 released
> "SM" == Simon Matter writes: SM> As I'm currently working on a 2.5.x release of our Invoca RPMs I'm SM> wondering if it would make sense to just go with 3.0 beta? The work SM> on 2.5.x will still take some more time because it's a big change SM> with the new build system, new functionality and support for new SM> systems with systemd. I'm actually going to be putting some work into the Fedora packages soon. Of course, they already support systemd so that may be useful to you, even though they're only at 2.4.something. Although there are going to be some differences (Fedora has some new tools for self-signed certificate generation, for example) it would be nice if the RPMs didn't diverge too much, especially in terms of file location (which I understanding is changing a bit in 3.0 anyway). For now I'm just doing this work because I need 2.5.x packages locally and I'm not entirely sure they'll make it into Fedora, but they might. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Communicating kerberos password expiration
> "DW" == Dan White writes: DW> There is an annotation (/comment) which you can set per mailbox, DW> which should result in an alert being displayed: Checking that again, I'm not sure that's the case. There's a misformatting in the FAQ entry which squishes the text for /motd into the description of /comment. I don't think /motd can be set per-mailbox, and I don't think /comment does anything other than set a comment. Drat. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Communicating kerberos password expiration
Thanks for your response! > "DW" == Dan White writes: DW> I haven't found it common for IMAP clients to display Quota alerts, DW> but I haven't extensively tested. Squirrel mail, and perhaps Horde, DW> will display Quota Alerts, so it's possible that it would display DW> any alert provided by the imap server. Interesting. I figure the most common clients would be thunderbird, outlook express, whatever mail client Apple is shipping by default, the default iOS and Android clients, and maybe K9 mail and its derivatives (because it's what I recommend to users). Looks like I'll need to do some testing. DW> There is an annotation (/comment) which you can set per mailbox, DW> which should result in an alert being displayed: DW> https://cyrusimap.org/mediawiki/index.php/FAQ Oh, neat. This is great. DW> I'm unfamiliar with the EXPIRED response code or what Cyrus' plans DW> are for supporting it. I only found it by searching; it's documented in RFC5530: EXPIRED Either authentication succeeded or the server no longer had the necessary data; either way, access is no longer permitted using that passphrase. The client or user should get a new passphrase. C: d login "fred" "foo" S: d NO [EXPIRED] That password isn't valid any more - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Communicating kerberos password expiration
I know this isn't entirely a Cyrus question, but I figure some folks
here would have some idea of my issue.
Basically, we use Kerberos authentication with Cyrus. The passwords in
Kerberos expire. With shell and (Linux) desktop logins and such, the
system alerts users and if necessary forces them to change their
password. And obviously these days it's not terribly useful to actually
mail someone with information about their password expiring.
My understanding is that IMAP has a limited way to communicate password
expiration (through the EXPIRED response code). Does Cyrus support
communicating that to the client when appropriate? Anyone know if any
clients actually do something useful with it? Does anyone know if the
protocol (or Cyrus) has any way to communicate password expiration in
advance of the password actually expiring? ("You have 5 days to change
your password" or something like that.)
Really I'd like to integrate something with the Horde webmail system to
at least cover webmail-only users. I can actually hack on that a bit,
but I'll obviously ask the Horde people about that. Though I wouldn't
turn down any advice there either if someone here happened to have any.
- J<
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Ban some users from accessing IMAP
> "DM" == Dave McMurtrie writes: DM> The good news is that user_deny.db does exactly what you want. It DM> allows you to deny any specific service to a valid user, even if DM> they can successfully authenticate to your Cyrus server. Oh, that's what that does. I see one mention of something in the imapd.conf manpage but it's just about the format of the database involved. (Says it defaults to "flat"; is that a good idea? I don't anticipate having more than a handful of users banned in this way.) I will see if I can whip something up that pulls a group out of ldap and calls cyr_dbtool appropriately. Run it from cron and I'll be done. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Ban some users from accessing IMAP
I have a pretty simple cyrus setup; I have a long-running 2.3.16 install on RHEL5 (one day I'll update), with authentication handled by cyrus-sasl 2.1.22 and everything authenticating to a kerberos server. What I would like to do is ban some valid users from accessing IMAP. We've had a rash of users falling victim to phishing attacks and would like to simply prevent those users from any remote access. So they need a valid kerberos principal in order to access desktops here, but would lose IMAP access. (Need to ban remote SSH access as well, but that's trivial with DenyGroups). I know this probably isn't strictly a Cyrus IMAPd thing, but I figure some folks must have run into this kind of requirement before. I realize I also need to restrict SMTP logins as well, but that goes through SASL and the Kerberos server as well so if the solution involves either of those then perhaps I get it for free. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Code for manipulating all messages matching some criteria?
Recently our campus was hit with a particularly bad targeted trojan attach and the IT overlords sent out a demand that we (a small department with several hundred mailboxes on our own server) go through all user mailboxes and actually delete the offending messages. At least using the admin account this is actually kind of reasonable to do. While I'm sure I could whip something up if I actually had enough free time, I was wondering if anyone had already been through this kind of thing and had cobbled together any code to do it. I see something called imapfilter which might do the trick, but it seems to be completely opaque. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Deleting unused or dormant mail accounts.
> "BG" == Bron Gondwana writes:
BG> yes, it should work with 2.4.
Good news.
Since folks may not know much about this, here's some detail.
I've been using this little Perl script to talk to the fud server for so
long that I've no recollection of where it came from. It's only 53
lines, so I'll just include it. And of course you have to add the
following to cyrus.conf:
fud cmd="fud" listen="fud" proto="udp" prefork=1 maxchild=10
and give the proper (weird) permission so that fud actually works:
sam user/* anonymous 0
The script follows. Output looks like this:
> fud-client tibbs
|tibbs|Inbox|0|1315866483|1315866228|
user: tibbs
mbox: Inbox
Number of Recent: 0
Last read: Mon Sep 12 17:28:03 2011
Last arrived: Mon Sep 12 17:23:48 2011
but of course you could hack it up to do whatever you wanted.
- J<
#!/usr/bin/perl -w
# perl "port" of contrib/fud-client.c that comes with the Cyrus IMAP
# distribution (http://asg.web.cmu.edu/)
# Written by Jason Englander
#
# Released under the GNU GPL. See http://www.gnu.org/copyleft/gpl.html
# for more information.
#
# 0.1 - July 3, 2002
# [jme] - Initial release
use Socket;
use strict;
my ($hisiaddr, $hispaddr, $iaddr, $paddr, $port, $proto, $resp);
my $server = 'your.imap.server.here';
my $user = $ARGV[0];
my $mailbox = $ARGV[1] || 'Inbox';
die "\nUsage: $0 user mailbox\n\n" if ! $server || ! $user || ! $mailbox;
die "\nUsage: $0 server user mailbox\n\n" if ! $server || ! $user || ! $mailbox;
$proto = getprotobyname('udp');
$port = getservbyname('fud', 'udp');
socket(SOCKET, PF_INET, SOCK_DGRAM, $proto) || die "socket: $!";
$| = 1;
$hisiaddr = inet_aton($server) || die "unknown host";
$hispaddr = sockaddr_in($port, $hisiaddr);
defined(send(SOCKET, "$user|$mailbox", 0, $hispaddr)) || die "send $server: $!";
recv(SOCKET, $resp, 512, 0) || die "recv: $!";
close(SOCKET);
my $resp_str = unpack('A*',$resp);
print "|$resp_str|\n";
if ("$resp_str" eq "UNKNOWN") {
printf "Server did not recognize mailbox %s\n", $mailbox;
}
elsif ("$resp_str" eq "PERMDENY") {
printf "Permission denied attempting get mailbox info for %s\n",
$mailbox;
}
else {
my ($uname,$mbox,$numrecent,$lread,$lappend) = split('\|',$resp_str);
printf "user: %s\nmbox: %s\nNumber of Recent: %d\n", $uname, $mbox,
$numrecent;
$lread = localtime($lread);
printf "Last read: %s\n", $lread;
$lappend = localtime($lappend);
printf "Last arrived: %s\n", $lappend;
}
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Long term offline mail retention
I manage email (and practically everything else) for a medium sized university department. Recently I've been informed that we're adopting a three-year retention policy for email. We're allowed to keep things for longer than that, so I'm not looking at forced expiration (which is all I found when I searched the mailing lists for info). Basically I'm just looking for a way to still allow me to use cyr_expire with something less nuts than -X 1100 -D 1100 that still keeps the mail somewhere. (I'm honestly quite afraid of how long an expire run will take three years hence.) I'm thinking of hacking cyr_expire to actually save the data off somewhere, then tarring that up to some less expensive storage and destroying that when its time comes. Any ideas? Has anyone done anything like this? - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Berkeley DB: private copy?
Just so you know, the policies of most Linux distributions forbid this kind of bundling, so unless it's easily disabled (and preferably defaults to using system libraries) the distributions will just have to patch it back out again. For example, here's the Fedora policy: http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
FYI: if startup is too fast, IDLE fails
Thought I'd mention an odd problem with idled which I've worked around so that it gets into the list archive. Running 2.3.16, the master starts idled without error. However, all of the services initially started by master would fail to contact idled and give the following error: imap[23494]: error sending to idled: 3 Inspection of the source indicates that 3 is the NOOP operation, sent during the initial ping over the socket to ensure that idled was available. The socket exists and permissions are OK. A search of the list archives turned up no relevant hits, except for one person seeing the same error who does not seem to have received a reply. http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2006-November/000802.html Services started by the master later would connect to idled without issue. Adding another START item after idled in cyrus.conf (in this case, syncclient) caused the problem to go away. It looks as if master starts the services before idled is ready to accept connections, and adding another service to the START section delays things just enough. This system is pretty fast (dual socket quad core Nehalem with 48GB of RAM) but I'm sure others have run on fancier hardware so I'm not sure what's up. - J< 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: Not possible to replicate from 2.3.7 to 2.3.16?
> "BG" == Bron Gondwana writes: BG> The advantage of reconstructing (if you choose that BG> path instead, heaps more IO use though) is that you'll get real SHA1 BG> GUIDs rather than padded GUIDs. Not a huge deal - though I'll BG> probably force the SHA1 calculation in the 2.4 upgrade, because I BG> want full integrity checking enabled! I ended up not doing a reconstruct run; I did a replication to a test server, update it to 2.3.16 and tested; everything was fine. Then I did the reconstruct: /usr/lib/cyrus-imapd/reconstruct -r -s -k "user/*" as suggested elsewhere in this thread and it ran without problems except for a few complaints about messages with over 1000 lines of header. Unfortunately, after running it, all messages in folders besides my INBOX had lost their seen state and were shown as "new" in two different clients (alpine and thunderbird). I can't quite determine if this is expected behavior. If it is, that's a significant downside. If it isn't, I wonder what's going wrong. I have altnamespace: 1 and unixhierarchysep: 1 in imapd.conf, if it matters. It looks like the seen.db was still intact but it's not as if I can actually read a skiplist file. - J< 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: Not possible to replicate from 2.3.7 to 2.3.16?
[Forgot to send this to the list; sorry. > "BG" == Bron Gondwana writes: BG> No, sorry. I figured as much; I backed off to 2.3.7 on the new machine so that I could get a good replica. BG> Replication across versions is trick at the best of times, and BG> you're talking about versions 3 and a half years apart! I had guessed, though perhaps I had hoped that something would simply tell me that instead of giving odd errors that made me think that I had misconfigured something. But I think I have my plan of attack readied. BG> Unfortunately, your only real option is to upgrade to 2.3.16 on both BG> at roughly the same time. Actually my plan is to simply abandon the old, failing master (leaving it with the current content in case things blow up), upgrade the replica to 2.3.16, make it the master and set up yet another machine as a replica. BG> The upgrade itself should go seamlessly. Because of the mailbox BG> format change, you will get an IO hit as each mailbox open causes a BG> full index file rewrite to upgrade it to the new format! Not a big deal, though I wonder if there's any way I can force this to happen all at once in the middle of the night instead of when some user happens to open their multi-gigabyte inbox. The new machine is seriously over-specified for the task at hand so I don't think the extra IO will be a problem, but it would still be nice to do it all at once. BG> This also means you can't downgrade again without doing a full BG> reconstruct of every mailbox. I hope to not need to do so, but in case I do, that's just reconstruct -r on everything under user, right? I guess it's a credit to the software that I've never really have to mess with the recovery tools in the years I've been using it. - J< 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
Not possible to replicate from 2.3.7 to 2.3.16?
I'm trying to move my mail services to both new hardware and a new Cyrus version. This involves a change in architecture from i386 to x86_64. I was going for what looked like the simplest method: set the new server as a replica, let everything replicate, then quickly shut things down, configure the replica as the master and switch IPs. Unfortunately I'm stymied at step one; replication seems to fail. Simply running sync_client and trying to sync one user: /usr/lib/cyrus-imapd/sync_client -S util1 -u tibbs yields (on a completely fresh installation, with no existing mailboxes): Mar 27 00:10:32 util6 sync_client[32618]: Doing a peer verify Mar 27 00:10:32 util6 sync_client[32618]: verify error:num=20:unable to get local issuer certificate Mar 27 00:10:32 util6 sync_client[32618]: received server certificate Mar 27 00:10:32 util6 sync_client[32618]: starttls: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits new) no authentication Mar 27 00:10:32 util6 sync_client[32618]: USER received NO response: IMAP_MAILBOX_NONEXISTENT Failed to access inbox for tibbs: Mailbox does not exist Mar 27 00:10:32 util6 sync_client[32618]: CREATE received BAD response: Missing required argument to Create Mar 27 00:10:32 util6 sync_client[32618]: Error in do_user(tibbs): bailing out! The replica machine says: Mar 27 00:10:32 util1 syncserver[12709]: Failed to access inbox for tibbs Mar 27 00:10:32 util1 syncserver[12709]: cannot unlink /var/lib/imap/user/t/tibbs.seen: No such file or directory Mar 27 00:10:32 util1 syncserver[12709]: cannot unlink /var/lib/imap/user/t/tibbs.mboxkey: No such file or directory I note that after this operation, the mailbox ended up being created, probably because of the autocreateinboxfolders setting. (I'm running the Fedora packages rebuilt for RHEL5; they seem to be pretty closely based on Simon's.) So, is it expected to be generally possible to replicate from 2.3.7 to 2.3.16? If so, would anyone have any idea what I might be doing wrong here? If it's not possible, would it be reasonable to migrate initially using 2.3.7 on the replica and then update to 2.3.16? (I'm trying to avoid downtime as much as is possible.) - J< 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: Meaning of "Discarding" messages from sync_client?
> "WC" == Wesley Craig writes: WC> This is the client trying to re-sync the protocol with the WC> server. There should be a line preceding the "Discarding:" messages WC> with containing the word "invalid" or "illegal", which is the actual WC> problem. Indeed: Mar 25 23:17:36 util6 sync_client[31645]: MAILBOXES: Invalid unsolicited response type 1 from server: 0 Not much idea what that means, though. WC> At a guess, I'd say that things are messed up. Joy. Also, I happened to look in /var/lib/imap/sync and found over four thousand files with names beginning with "log-" going back years. I can't imagine that's good. A spot check of a few folders shows that the replica is indeed receiving new messages, but that it's also holding on to messages which have long since been removed from the master. I'm not seeing anything that's being missed entirely, but it's not all that easy to say for sure. Is there any reasonable way to get the process back on track, or should I just sync_reset on the replica and delete the spool? I guess if I need to do that, I should just start replicating to the new server. A related question, perhaps: if I set up a fresh replica, is there anything I need to do on the master to reset the process (besides restart the service, of course)? - J< 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
Meaning of "Discarding" messages from sync_client?
Could anyone explain the meaning of lines like: Mar 26 00:49:50 util6 sync_client[31645]: Discarding: 3082 () I have literally millions of these in my maillog (occasionally with flags between the parentheses and rarely other text in place of the zeroes) and am wondering if it means that my replica is screwed somehow. A search of the list archives didn't seem to turn up anything except a thread about failing replication after an upgrade from 2.3.9 to 2.3.11 which doesn't seem related. Both the master and the replica are running an admittedly old 2.3.7 straight from Centos 4 (so the guid stuff isn't available). I'm in the process of getting another server going (because the master is beginning to have hardware issues) and will almost certainly have further questions, but at the moment I'd just like to make sure that my current replica is OK before I begin to replicate everything to the new server. Thanks in advance for any insight. - J< 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
