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 
<> 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 mailing list

Reply via email to