Recommendations For Webmail Client On EL8

Home » CentOS » Recommendations For Webmail Client On EL8
CentOS 31 Comments

Hi all,

I’m still trying to find solutions to replace some aging EL6 and EL7 systems.

This time I’m looking at email. Postfix and Cyrus-IMAPd are not a problem and also additional things like DKIM are fine. However, I’m wondering what to use to replace good old squirrelmail with.

We had a heavily patched squirrelmail with lots of nice things like avelsieve plugin. Since squirrelmail is dead and unable to run on newer PHP, I’d like to use some other tool instead.

I was looking at Roundcube but it seems difficult on EL8 because a lot of PHP stuff is missing and not available as RPMs. I guess the same is true for the python things needed for Mailpile. In the end my list only contains Cypht, Rainloop and Afterlogic Webmail lite.

Is there anybody running webmail on EL8? Can you make a recommendation on a certain tool?

Thanks, Simon

31 thoughts on - Recommendations For Webmail Client On EL8

  • Hi Simon,

    I’m sure you must have noticed, but just to be clear: your aging C7
    system has more life in it than a C8 system. C8 dies this December, C7
    is projected to 30/6/24. Martin

  • Hi Martin, thanks for the hint. Yes, I’m aware of it. With EL6 and EL7 I
    mean CentOS6/7 but with EL8 I mean RHEL, CentOS (Stream) or any other RHEL
    clone.

    Simon

  • Hi Simon, we used to use Squirrelmail also, but have since migrated to RoundCube. It’s easy enough to install on a CentOS 7 server (we don’t use EL8) by downloading directly from the Roundcube website and following the installation instructions. The interface is clean, modern, and the project gets frequent updates. Updates have been mostly painless, but they can overwrite some of the customizations one might have made so that is a pain (mostly any CSS customizations or changes to the default .htaccess file which relates to PHP upload size).

    I don’t recall needing any hard to find RPMs – we generally don’t stray further than what is available via the CentOS repositories or EPEL.

    –Blake

  • Hi Thomas,

    Thanks for your suggestion. No, I’m not really thinking about docker/podman. I prefer having clean system installs, even if I have to create RPMs myself. This has worked fine for the last two decades but yes, I’m afraid, this is considered old school these days :-)

    Simon

  • Hi Chris, I have bit tried it but I’m wondering if the mail app can we used standalone without the nextcloud backend? And since it’s based on Horde, I’m wondering if it’s so easy to run on EL8.

    What IS interesting is that nextcloud itself is in EPEL8!

    Simon

  • Am 01.03.21 um 15:56 schrieb Simon Matter:

    Hey Simon, take a look at Remi’s repository …

  • Simon,

    I’m in same boat as you. I have a C6 machine running squirrelmail that I’ve been trying to get upgraded. I bought a new machine and have C8 installed, postfix, dovecot, SA, the works, running. But, I couldn’t get squirrelmail running.

    I’m also very interested in the answer to this question, “what webmail to run on C8” (or stream in the future). I’ve looked at the same SW apps you have and have not really gotten a warm fuzzy over anything.

    I wonder if another tact to take would be to try to get squirrelmail more “modern”. I know Les is still doing a bit of dev, but it does seem like squirrelmail is lagging behind.

    MTC,

    Jay

  • Jay,

    I agree, the last post on https://squirrelmail.org/ was an announcement for PHP 5.4 and 5.5 Compatibility  from 5/30/2013.

    The last plugin update was 3/28/2014.  I consider squirrelmail pretty much dead at this point.

    —
    Christopher Wensink IS Administrator Five Star Plastics, Inc
    1339 Continental Drive Eau Claire, WI 54701
    Office: 715-831-1682
    Mobile: 715-563-3112
    Fax: 715-831-6075
    cwensink@five-star-plastics.com http://www.five-star-plastics.com

  • I know this is irrelevant to CentOS and RedHat Enterprise, as I run these on FreeBSD (in separate dedicated jail). I do have both of them:
    roundcube and squirrelmail. When I tell my users about the options, I
    tell them roundcube is modern and fancy. Squirrelmail, though same good, is more older style. So, they have choices to match their taste.

    And again, this is irrelevant to Linux. But both roundcube and squirrelmail will not be phased out in close future (my own estimate), though squirrelmail has reached the stage when new features will not be added (nothing bad about that in my book).

    Valeri

  • No. it is not. It is not actively developed, no new featured are added for quite some time. Squirrelmail can be downloded here:

    https://squirrelmail.org/download.php

    Where you can see year 2021 stable version snapshots. Latest you can download works with PHP 7. As I said in another comment: they do not do new development. But they actively support what it is now, and in my estimate it will not be phased out in any observable future.

    Yes I had to do this kind of homework when I was rebuilding [freebsd jail with] webmail services.

    Valeri

    PS Not everything that paces fast with new “releases” and which releases security patches even more often (yes, I look at you, Mozilla firefox and thunderbird) is “pretty much dead”. There are great examples, like:
    netscape navigator (in its time), cvs (in its time and still here), subversion, squirrelmail, mailman 2 to name few.

    —
    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Hi Valeri, I’ve just checked FreeBSD ports:

    – squirrelmail latest with php 8
    – roundcube 1.4.11 (latest) with php 7.4
    – rainloop 1.15.0 (latest) with php 8
    – horde-webmail 5.2.22 (latest) with php 8

    Once again a slap in my face as an EL user :-)

    But I have an idea, I’ll look at the squirrelmail port closely and see how I can include the updated code in my RPMs. Sounds like a solution – or move everything to FreeBSD. I’m running a FreeBSD test VM for years and I
    really like the upgrades the FreeBSD way!

    Simon

  • Just for record: list of available packages (note PHP version):

    squirrelmail-php73-20200422
    squirrelmail-php74-20200422
    squirrelmail-php80-20200422

    Running things in FreeBSD jails (only inseparable things in the same jail) makes things extremely easy: such as upgrades to higher version, updates, migration of servers, or when what you need depends on different things which are incompatible. Several servers I run do not exist as a machines, or individual systems: a host may be a bunch of
    (2-5) different jails.

    And I for one consider FreeBSD jails much more secure and significantly slimmer an any virtualization solutions on Linux. But don’t ask me to prove the point ;-)

    Valeri

  • I found this link last Saturday but didn’t want to give up too quickly.

    I wasn’t aware that the situation with EPEL8 is so bad because a) we just started migrating systems to CentOS 8 when the bad news came some weeks ago about CentOS, and b) because we mostly built our own RPMs and didn’t depend on EPEL in the past.

    Now that building became more difficult with the new modularity, it seemed a good thing to rely more on EPEL – just to discover that EPEL is also lacking so much in 8.

    Simon

  • EPEL has always been in the need of more people who can volunteer time to help maintain and package things. However for the last 5 years (so even before EL8) the need has gotten worse:
    1) The core maintainers who pushed EL6 and EL7 have been increasingly
    ‘retired to management’ at their respective jobs.
    2) Usage has grown greatly with the expectation that what is in EL6 will be in EL7 will be in EL8.
    3) Package complexity has grown exponentially. You need more and more packages in the repo as ‘buildrequires’ or ‘install’ but are not ‘leaf nodes’ like say squirrelmail.
    4) Most people who ‘maintain’ the package in Fedora see that as a full time job already and dealing with EPEL issues/complaints is added unpaid work they don’t care less for. [For some reason a good many people who open bugs for EPEL packages expect the same level of support as they would for a paid for enterprise product.. and feel like being jerks is the way to get that from EPEL.]
    5) Many upstreams have gone whole-hog into containers and will only work with/deal with the set of tools in their container versus in RPMs or debs. They are especially that way for laggard operating systems like Enterprise Linux or LTS versions.
    6) Building *good rpms is hard. Building *good modules is harder. However building *good containers makes modularity look easy. So it is easier to just grab someone elses and YOLO.

    *good = a package which is reproducible, upgradable, secure, debugable, maintainable and probably 10 other features everyone silently expects from EPEL packages versus some one who did a tar2rpm

  • Are they Red Hat paid people? If so it confirms my impression that EPEL is not seen very important by Red Hat.

    As I did and still do a lot of packages which should build on multiple EL
    versions, I now that it’s also a result of the big changes between EL6 and EL7 with the move to systemd. It has resulted in a LOT of additional work for packagers and maybe some got tired a bit. I did at least.

    Some of it is also selfmade. New init system, changing packaging rules, new required build tools, tricky new modularity to just name a few. Other systems like the different BSD ports show that it could be made easier.

    Here is probably the biggest problem: a lot of packages are made for Fedora. Then, when EL is forked from Fedora, all additional packages seem to get stripped off. Later, when EL becomes available, some kind soul has to reimplement what has been stripped off before. Doesn’t reality come close here?

    To me this seems like a security nightmare – like closed sorce.

    I know what you mean but IMHO the real problem is that bulding good packages became too complicated. In your list above you forgot that you also have to care about SELinux and other nice things.

    My biggest concern is how this is going to be fixed? Are there any plans from anyone?

    Simon

  • Or you could try https://packages.inverse.ca/SOGo/nightly/5/rhel/8/x86_64/
    That is a link to their yum repo.

    I have not used SOGo on C-8 but I find them to be quite stable on C-7 and there is nothing that says you have to update every day.

    In addition, SOGo provides active sync which works really well on smart phones. It makes the phone think it is connected to an exchange server which makes for simple configuration and it “just works”.

    Regards,

  • I am pretty sure that whatever I will say would confirm your impression :).

    In this case, most of the people I am talking about have been outside of Red Hat volunteers versus Red Hat employees. Many of the original people involved have become VP’s, CIO’s and other places in upper management in their companies. Others have not but found that real life in other ways got in the way. It happens with any volunteer activity.

    Does that mean Red Hat never took EPEL seriously? Maybe. But the same can be said of the EPEL users. Most of the rules for package inclusion and the retirement problem I have said are public knowledge brought up over and over through the years and yet most people only ‘see’ them when EPEL is
    ‘broken’ to them. There is a continual forgetting that for the first 2
    years of EPEL-7 we didn’t have as many packages as we did in EPEL-6.. and that ‘EPEL is so broke’. There is an expectation that someone is paid to work on this when no one is.

    Anyway this rant has had to be revised multiple times so I am ending it here.

  • Am 01.03.21 um 20:21 schrieb Simon Matter:

    RH could help here by providing all missing sub packages (devel etc.).

    Not sure about the reasons in not shipping it but for a different support life cycles or in this case for the absent of support, it can be communicated, like for Streams, SCL, etc. They have already different life cycles (compared to BaseOS). If its for delaying OS
    rebuilders – well, its wasting just time.

    I would build some EPEL packages if I am not forced to rebuild distro packages just to get the Buildrequires fulfilled. Damm, this was the main workload in 2019 with RHEL8 GA …

  • free release as rpm packages:

    Do those scripts also handle the building of Objective-C, which is needed to build SOGo? I have been toying with this off and on, there’s an independent repo somewhere that has the EL8 builds of Obj-C
    and SOGo, but I haven’t had time to get everything set up.

  • I’m still running on 7, where gnustep is available from EPEL.  I think you’d need to manually rebuild gnustep for CentOS 8.

  • You may need to rebuild gcc from different source rpms to get Objective-C
    in EL-8. The RHEL gcc source rpms did not produce Objective-C rpms or binaries when I looked at it in 2019.