Hi, I think it'd be a great idea to add Mail Address Verification (MAV) into spamdyke. MAV means checking the Envelope-From address used by a relayclient against an accesslist to deny from-address forgery or misuse.
Adding MAV into spamdyke would IMHO be a smart thing to do, because it can block quite a bit of relaying abuse and doing it on the qmail side requires a lot of patching. There is a qmail MAV patch by Erwin Hoffmann of www.fehcom.de which I am currently using, but I had to merge a lot of code manually and rewrite code to apply it to my already heavily patched qmail. More info on MAV: http://www.fehcom.de/qmail/mav/PROPOSAL.mav MAV as implemented in the qmail/spamcontrol patch allows the follwoing checks: - Basic check of Envelope-From against control/rcpthosts - Adavanced check against a CDB mapping: - AUTH user to allowed envelope addresses - IP/IP-range to allowed envelope addresses - (partial) RDNS to allowed envelope addresses - combinations of the above Also usefull would be: - Checking RHS part of AUTH user against envelope address. - Allow only envelope address associated with auth user. - Partual user-part checking for mailing list daemons etc. - Deny envelope-addresses otherwise allowed by a wildcard. - Stricter network matching by allowing ip/subnet classification. - Wildcard matching of RHS part When implemented in spamdyke configuration syntax could look like: mav-level=basic|advanced|hybrid mav-entry=127.0.0.1: # unrestricted envelope-from for localhost mav-entry=10.12.23.:@clientdomain.com # allow @clientdomain.com for 10.12.23.0/24 relayclients mav-file=/var/qmail/spamdyke/mav_rules With the following meaning: - basic: only check Envelope-From RHS against control/rcpthosts - advanced: check against directives in mav-entry and mav-file. - hybrid: check against mav-entry/mav-file first, then fallback to control/rcpthosts. Sample mav-file: --snip--- # allow [EMAIL PROTECTED], [EMAIL PROTECTED], etc. and # [EMAIL PROTECTED] (eg. webform) for localhost 127.0.0.1:[EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED] # allow relaying with from [EMAIL PROTECTED] and domain2.com for 10.12.23.1 10.12.23.1:@domain1.com,@domain2.com # allow any user authenticated with a user in domain3.com (eg. # [EMAIL PROTECTED]) to relay with enevlope adress ending in @domain3.com # except the address [EMAIL PROTECTED] @domain3.com:@domain3.com,[EMAIL PROTECTED] # allow cient authenticated by username 'user' to relay with envelope # [EMAIL PROTECTED] or [EMAIL PROTECTED] if his originating IP is in # either one of the subnets 87.25.3.128/25 or 89.43.7.0/24 which # supposedly matches the dynamic ip pools of his provider [EMAIL PROTECTED]/25,[EMAIL PROTECTED]:[EMAIL PROTECTED],[EMAIL PROTECTED] # allow user authenticated with userid [EMAIL PROTECTED] to # send mail from [EMAIL PROTECTED] or [EMAIL PROTECTED] [EMAIL PROTECTED]:[EMAIL PROTECTED],[EMAIL PROTECTED] # unrestricted relaying for *.int.ourdomain.com except for # [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] .int.ourdomain.com:[EMAIL PROTECTED],!admin,!webmaster,[EMAIL PROTECTED] ---snip--- The above described feature-set is probably a bit too excessive, the purpose of this mail was to give an impression of what could be achieved with Mail Address Verification. Best Regards, Felix Buenemann _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
