[spamdyke-users] Spamdyke auth problems resolved

2015-08-18 Thread Gary Gendel via spamdyke-users
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




smime.p7s
Description: S/MIME Cryptographic Signature
___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users


Re: [spamdyke-users] Spamdyke auth problems resolved

2015-08-18 Thread Sam Clippinger via spamdyke-users
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


Re: [spamdyke-users] Spamdyke auth problems resolved

2015-08-18 Thread Gary Gendel via spamdyke-users

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