Hi Sam, sorry for my late reply, I've been away for a few days.
On 01.10.2008 0:35 Uhr, Sam Clippinger wrote: > 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. Well this all depends on wether or how much you trust your authenticated users and the security of their systems. It kind of troubles me, that all users authenticated to my mailserver can forge email from another domain on the same system but from a different customer, which would look totally legitimate to a receiver. Also weak passwords or security holes can lead to crackers gaining smtp auth priviledges and misusing them for relaying spam [1], which could be made much harder because the attacker doesn't neccesarily know the valid sender address associated with the hacked account and also logging such unauthorized use could lead to detecting account leaks and/or automatic blocking of hosts or accounts. [1] Plesk currently has a security hole allowing login with the password for user AND password on suse systems when short logins are enabled, which I've seen exploited on at least one host. I'm currently running patched binaries directly from the plesk developers to fix this. > > 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. I think such a mechanism only makes sense with SPF, although a manual definition of mx host/network to domain could be useful for sites not supporting SPF. > > -- Sam Clippinger -- Felix > 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], listx-admin-9IKiO1iGCm/[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 joe-413jTGZXy/[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 joe.niceguy-413jTGZXy/[EMAIL PROTECTED] >> [EMAIL PROTECTED]:[EMAIL PROTECTED],joe.niceguy-413jTGZXy/[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
