I'd love to be able to do spam and virus scanning within spamdyke, before the connection is complete. That would require spamdyke to start SpamAssassin and/or ClamAV (or another AV) and capture their output. It shouldn't be too hard, since both of those programs are designed to be run this way.
The biggest change required in spamdyke would be buffering the incoming message. Currently spamdyke doesn't do this, it only passes the traffic between the network and qmail. In order to scan the message, it would have to save it (probably to a file) so it could first pass it to the scanners, then pass it to qmail afterwards. Thanks for the suggestion! I'll add it to my TODO list for a future version. Olivier Mueller wrote: > Hello, > > I'm not (yet) spamdyke user, but this may change soon: the project looks > very promising, congratulations :) Finally something not 100% based on > qmail-patches... > > At the moment (as you maybe noticed on the qmail ML), I'm thinking about > redesigning my mail systems, and this is what I'd like to do. Maybe this > will give you some ideas or suggest some feedback: > > > > ... SMTP Session Starting ... > > 1) Check IP address against 2-3 RBL (blacklists) and 1-2 > whitelists (of swiss/german/french/etc. ISP mail > server ip's) > -> transmit the result to a script which will decide > (based on logs created in 2), 4) and 5)) > if it wants to reject the connexion or not: > my goal would be to be able to tune this based > on recipient domain/mail address for legal reasons... > -> return a 5xx error or continue > > > 2) VRFY check (in my case: with cvm-vmailmgr, via > http://untroubled.org/cvm/ because most my users are > vmailmgrd-based) > -> 5xx error if not valid, and log ip (to add to a local > blacklist) or continue > > > 3) Greylist if requested/allowed by the domain owner, > and if not in the IP whitelist > > > ... Receive Mailheader/Body ... > > > 4) Virus scan (clamdscan/fsav/etc.) > -> exit with Virus Name in the 5xx error message > if a virus is found (+ log ip), else continue > > > 5) Spam scan (with parameters like "required hits" > taken from the database, to let the user decide > what to accept/reject, and for example store the > spam to a temporary quarantine for further analysis) > -> error 5xx if flagged as spam (+ log ip) > > > ... Deliver mail ... > > > > At the moment, I only have rblcheck (but server-wide, not based on > domain), recipient check and virus check (via qmail-qfilter) on SMTP > level. Antispam scan occurs after via .qmail-* files. But it seems it > is not appropriate anymore, now I think everything must be scanned (and > rejected) at directly at SMTP level. > > Feedback welcome :-) In the mean time, I'll activate some features of > spamdyke on a test system to see if it is going to be able to help. > > Regards, > Olivier > > _______________________________________________ > 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
