In my own experience with hacked accounts, when a spammer breaks into a legitimate account, he usually try sending messages at once, in big volumes, which is then easily spotted. I have myself a little dirty crontab script which send me a message when the queue grows larger than what I consider normal, in my case, 300 messages.
I just have to open one of the queued messages, grab the IP and search in Plesk's maillog for a smtp_auth line containing the username exploited. Altought I'm against any method that would end up generating yet more support tickets when not necessary, if I had to choose, I would also choose to be more permissive and manually disable rare problem accounts than imposing a more restrictive rule to customers. But in Yahoo's case, I have to agree that that may be a good prevention since they are a pretty huge monster, and that will surely ease the hardwork of tracking down spammers. Arthur Girardi Citando Sam Clippinger <[EMAIL PROTECTED]>: > 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 > _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
