> We've had IMP abuse as well, for what purports to be a British Lotto, > and we've been on the receiving end of the same kind of spam from other > IMP and Squirrelmail installations. > I'm glad to know we're not the only ones seeing this.
We've had a dramatic increase of spam coming from compromised accounts in our own Horde / IMP installation since this summer.. which has resulted in our some of our webmail servers being placed on blacklists by yahoo, excite, etc. Very annoying. Checking the IP addresses of the people sending the spam, we're actually being used by Nigerian spammers. It's so cliche. > They send a lot of mail very fast. Clearly it is not hand-typed. The > spam gang must have software that can submit the necessary form data to > popular webmail software to log in and send mail. They need an account > and password to do it. We suspect the source is keyboard loggers > installed in places like Internet cafes. > What we've noticed in our compromised accounts is that spammers generally set up alternate identities, placing the text of the spam in the signature for each identity. We've got a cron job that check the size of our mail queue on each of the webmail servers and it contacts us if we've crossed our "acceptable" threshold. That at least allows us to clean it up.. but it would be good to catch it before it gets queued. Is anyone running antispam checks on their outgoing mail? > Since IMP requires a successful login before it will send mail, IMP is > not at fault. However it is important to have IMP record what user > sent each message, in order to track down what account has been > compromised and stop further abuse. We have chosen to insert the user > into an X- header, and to write the user to syslog. This makes it > simple for our security team to cut off the account that was used. > If you don't do this, your IMP installation will be abused at some > point. By "a lot of mail" I mean more than 100,000 messages We insert the user and user agent into our headers. What I'd really like is an apache directive that's the opposite of "Require user". We could use "Deny from env=badusers" if SetEnvIf actually worked reliably with Remote_User. Short of auto_prepending a file that checked a bad user list and denied access, does anyone have any suggestions? Liam -- IMP mailing list - Join the hunt: http://horde.org/bounties/#imp Frequently Asked Questions: http://horde.org/faq/ To unsubscribe, mail: [EMAIL PROTECTED]
