On 7/24/2012 6:24 PM, mouss wrote: > anvil is not an anti-spam solution. it's measure against "clients gone > crazy".
Precisely. And that's how I advised the OP to us it: Plug the artery until surgery can be performed. Surgery in this case being disabling the account and setting a strong password. > fighting outbound spam is a serious challenge. Of course it is, harder for some org types and easier for others. ISPs have the toughest battle here, obviously. Many/most corps and SOHOs not so tough. >> [skip] >> You'd think humans beings would be smart enough to follow directions and >> use strong passwords, AV software, etc, and not fall for phishing scams. >> Your adversary in this war isn't the spammers, it's not the technology, >> but your users. > > oh come on! the "users" excuse is wa too old. if your software accepts > weak passwords, then the problem is with the software, not the user. AV? > oh no, I don't want any on my unix boxen. phising? well, it's far from > being a simple thing. It's not an excuse, but a fact. I'm surprised you'd argue this mouss. ;) Success requires a multi-pronged approach, and all of the above are required. over 99% of users have Windows not *nix desktops, so the AV requirement is a given. And even with software that enforces strong passwords, many users fall prey to phish and give up the password. Which is why the only way to win this hacked account spam is user education. Now, whether that's a pipe dream or achievable will be debated forever. > when OS, pki & browser vendors will ignore their business for the > "happiness of the universe", things might get better in an Alice > wonderfull world. do you really believe it? As long as human beings are allowed to submit mail to their provider for relay, and those humans control their machines doing the submitting, it's ultimately up to those users to secure their logon information. The ISP can't control the user PC or the user. It can only attempt to educate. As myself and others have stated many times, there is no technical solution to this side of the spam problem, as there is no technical solution to the MX recipient side of the spam problem. One can only mitigate and fix, which... Is why I recommended using anvil for the mitigation part. It's quick, it's integrated, it's low overhead vs a policy daemon. But yes, it requires some custom scripting to match up the auth user name for account disabling. > I disagree. those who put the responsibility of their failure on others > (call em users or whataver) should get another job. More accounts are compromised via phishing than brute force attacks. Are you calling this a failure on the part of the technical staff at $ISP? Are you saying technical means readily exist to stop phishing? -- Stan
