I've seen systems like this before; Yahoo! uses something similar to restrict authenticated email. In their system, authenticated users can only send messages "from" the authenticated address. To use a Yahoo! account for sending "from" other addresses, you must first login to their control panel and add the second address to the account. This occasionally trips up my users who have their own domain names but use Yahoo!'s mail servers for outbound email.
I've considered implementing a similar feature in spamdyke before, but it quickly began to seem like "a solution looking for a problem". Maybe I'm missing something, but it seems like restricting authenticated connections would only stop viruses that hijacked a user's MUA to pump out spam. I've heard of viruses that use Windows' MAPI system to send mail (instead of running their own SMTP engine) but (AFAIK) they're pretty rare. In any case, even if a virus were that smart/capable, wouldn't it send the spam messages using the MUA's default address? That would seem to defeat this kind of filter. For restricting unauthenticated connections to certain sender addresses/domains by IP/rDNS, spamdyke would only need a filter to restrict the sender address to a specific list. The filter could be targeted using configuration directories. -- Sam Clippinger Felix Buenemann wrote: > 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 > _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
