Sam,

I don't bother with Solaris since Oracle closed the source. Instead I use the open-sourced branch for the kernel called Illumos which is being developed by the upstream commercial distros as well as other contributors.


There are three main distributions for x86 platforms.

OpenIndiana -- This is the continuation of OpenSolaris. Good for server and desktop. This was the distribution I have used for years. There is a lot of reorganization (compilers, userland, etc.) recently which tends to break things. The package repositories are also in flux as well (broken dependencies). It's a good distro but no longer stable and no reasonable release schedule.

SmartOS -- You can get support from Joyent. It's a cloud-based implementation and the OS is booted from USB drive to provide a memory resident hypervisor. It has regular releases and uses NetBSD pkgsrc as it's package system which has pretty much everything you'd want (including spamdyke). It's designed for VM farms.

OmniOS -- You can get support from OmniTi. It's a minimalistic server with regular releases (bloody, stable, LTS). It comes with IPS but you can use pkgsrc from SmartOS as well. This is the distro I'm moving to. It's very stable. IPS is nice because it allows you to freeze and rollback packages. However, it's hard to find something missing in pkgsrc so that's what I've chosen for my userland.

I've worked with several Linux distros (my company is a Linux house) and have found they need much more care than illumos-based servers.

SInce we're just using qmail backend as a delivery agent, I'm not sure what the strength of a proxy-based approach is other than to broaden it's appeal (which makes a lot of sense). However, it's spamdyke that kept me using qmail for so long.

Gary

On 8/18/15 8:05 PM, Sam Clippinger via spamdyke-users wrote:
That's good to know, thanks for posting that info. I'm always amazed to hear people still use Solaris any more... I endured it a few years ago because ZFS was worth the pain, but finally had to abandon it because it was impossible to get security updates without an enterprise contract.

spamdyke's next version is nearly ready but I'm still running tests. It fixes the recipient validation code in spamdyke-qrv when vpopmail is being used, which has increased the number of test scripts to 4-6 million (from about 200K-300K). So it's taking a lot longer to test (about 2 weeks straight on 20 EC2 instances). They say familiarity breeds contempt, and lately I've become very familiar with vpopmail's code, so it's very hard to regard it with anything but contempt. I'll write up a complete rant about it later; for now I'll just say I will never install it on a new server again and I'm giving serious thought to deleting it from my current server. If anyone out there has vpopmail running on a server where users can edit their own .qmail files inside their mail folders, be very very afraid. Crashes and fork bombs are easy to do and cooking up a denial of service attack would probably be simple. I haven't been looking for exploitable holes, but I'm positive they're in there.

Anyway, sadly spamdyke's next version doesn't include any earth-shattering features but it does add one small thing -- the ability to block authorization attempts unless SSL/TLS is active. IPv6 is certainly on my radar, but frankly I'm far more interested in adding a real "proxy mode" to spamdyke so it will work with other mail servers beyond qmail. Qmail has become an anachronism and I'm convinced it's time to let it go. If spamdyke can forward connections from port 25 to port X while doing all the filtering it does now, it should work nicely with just about any other mail server.

-- Sam Clippinger




On Aug 18, 2015, at 12:03 PM, Gary Gendel via spamdyke-users <spamdyke-users@spamdyke.org <mailto:spamdyke-users@spamdyke.org>> wrote:

I use port 22 for non-auth mail and 587 for TLS with auth mail. On 587 I ended up using postfix because I could never get spamdyke working. It always failed valid authorizations.

I was putting together a new server and I decided to take another look. The problem ended up in the checkpassword-pam module on Illumos (Solaris). Illumos (and possibly other Unix derivatives) require that pam has PAM_TTY set before starting a session. The checkpassword-pam module doesn't do this. I posted a bug report but my solution was to add the following code just before opening the pam session (in pam-support.c).

retval = pam_set_item(pamh, PAM_TTY, "/dev/null");
if (retval != PAM_SUCCESS) {
   fatal("Setting PAM_TTY failed: %s", pam_strerror(pamh, retval));
   return 1;
}

I just thought I'd send this information along in case anyone else was having issues with spamdyke authorization.

Sam,

How's the "next gen" version coming?  Will it support IPv6?

Gary


_______________________________________________
spamdyke-users mailing list
spamdyke-users@spamdyke.org <mailto:spamdyke-users@spamdyke.org>
http://www.spamdyke.org/mailman/listinfo/spamdyke-users



_______________________________________________
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

_______________________________________________
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Reply via email to