I hadn't considered malicious authenticated users. In that case, a filter like this would prevent them from forging addresses of other users on your server. I don't believe that it would stop spam from remote attackers who guess/steal legitimate passwords however, because they would still know at least one address that will work (the account they hacked into).
I wonder which would be easier: to implement this feature and deal with the (ongoing) technical support of authorizing different addresses for specific users OR writing a script to generate a report showing all the sender addresses that were different from the authenticated usernames and manually disabling problem accounts (also ongoing). My own server is small enough that I can trust my users and the latter option is definitely the better option for me. But I'd like to know what would work better for administrators of larger sites. -- Sam Clippinger Felix Buenemann wrote: > 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 > _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
