Yikes!  I don't think that's going to be possible.  spamdyke was written 
specifically for qmail and makes a lot of assumptions about how qmail works.  
For example, the way it controls relaying is by setting an environment variable 
that qmail checks, tt reads lots of files from /var/qmail that must be in 
qmail's peculiar formats, etc.  It's very unlikely any other mail software is 
going to work the same way (I would hope not!).

As for running spamdyke in a non-proxying mode that can just evaluate the input 
and return a code, it doesn't currently do that either.  I'm not sure how well 
that would work anyway -- most of spamdyke's filters rely on intercepting the 
SMTP protocol before the message actually begins, only one or two filters 
examine the message content itself.

I've long wanted to restructure spamdyke to work as a more basic SMTP proxy -- 
accept an incoming TCP connection and open an outgoing TCP connection, then 
forward everything along and cut it off if a filter is tripped.  That would let 
it work seamlessly with any email server, not just qmail.  That would also 
provide a chance to rework spamdyke's configuration and remove its dependence 
on qmail-specific files.  It might even be time to reimplement spamdyke in a 
different language (probably Go).  Unfortunately my life has changed 
dramatically over the last few years and my free time now is measured in (a 
small number of) minutes per week and spamdyke development is off the table.  
If anyone else is interested in picking up the torch, I'd be happy to help 
migrate the project to Github (or similar) and consult if desired.

-- Sam Clippinger

> On Mar 29, 2020, at 2:32 AM, Philip Rhoades via spamdyke-users 
> <spamdyke-users@spamdyke.org> wrote:
> Sam,
> I am gradually getting organised to change my netqmail installation over to 
> IndiMail:
>  http://www.indimail.org
> but have struck problems with getting SD working with it.  It looks like SD 
> is hard-coded to expect stuff to be in:
>  /var/qmail
> What files does SD need from qmail?
> Is there a non-SMTP invocation which just takes mail on stdin and outputs the 
> same on stdout and exists with a return value depending on whether the mail 
> was spam or not spam? ie exits with some return value?
> Thanks,
> Phil.
> -- 
> Philip Rhoades
> PO Box 896
> Cowra  NSW  2794
> Australia
> E-mail:  p...@pricom.com.au
> _______________________________________________
> spamdyke-users mailing list
> spamdyke-users@spamdyke.org
> https://spamdyke.org/mailman/listinfo/spamdyke-users

spamdyke-users mailing list

Reply via email to