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> 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
> http://www.spamdyke.org/mailman/listinfo/spamdyke-users
_______________________________________________
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
