Our mail servers are being spammed and joe jobbed to death. Things are so bad I see at least 100 bounces caused by joe jobbing for each valid email. At the same time we are getting a huge amount of same at least 100 spams for one legit mail. That's not all there are so many emails being sent to none existent users of our domains, that the mail server has a massive queue of bouncers.
Mail server is qmail and we are using russel nelson's double bounce trim patch. Even so one mail server has a massive queue that is always in excess of 5000 message. Atrocious. When these are bounced the receiving server thinks we are sending out spam! This particular server is temporarily black listed on yahoo and comcast.
We decided to adapt several measures to counter it, if sucessfull (meaning we don't lose any legit mails). It will be carried over to the other servers as well. The most important change was to the queuelifetime. By default qmail will keep a message in it' queue for a week. That's rediculous. We changed to to less than half day on the machine that's worst effected. We don't use it for outgoing mail, so we can afford to.
We have changed two other control files timeoutremote and timeoutsmtpd they control the timeout setting for SMTP connections. They both default to an atrocious 20 minutes. Some mail servers will sleep when it encounters spam. Remember even though we are not sending out spam of our own, the messages that we are returning would be tagged as spam. This results in at least half a dozen qmail-remote processes just waiting at any time. What a waste of resources.
Then we decided to try something similar on our own. We applied the tarpitting patch so that qmail will now wait a few seconds (nothing drastic) when there are more than two rcpts in the transaction.
The last step was to and SPF. We didn't create our own SPF records but patched qmail with both the big DNS patch and the SPF patch so that we can reject mails where the sender and the outgoing mail server don't match. Currently the spfbehavior is configured to just create the SPF headers without blocking. Initial findings are dissapointing. Only a small percentage of mails have any SPF records at all.
Though SPF is not effective, the other methods certainly are effective at least in reducing the load on the server if nothing else. On the machine that was worst effected the queue has slid down to the 1000 message level where as it was at the 5000 levels earlier.