We recently had a rash of spam sending due to someone finding, guessing, or leaking a user's password. Sometimes, it just requires that, not some security breach. Well, we didn't catch it and stop it in time, and now we're suffering some deliverability problems ranging from slowdowns to outright blocking by some servers.
What I've learned, aside from the importance of being proactive, and maybe even running spamassassin on outgoing mail, is that a few email providers are clamping down on spam by blocking servers, or downgrading the deliverability of some servers.
Some of these companies are Gmail, Yahoo, AOL and Microsoft. These companies dominate the web-based email, and represent the majority of email on the network.
I don't know the details, but there are a number of things which help deliverability, ranging from easy to hard, cheap to expensive. This article will be revised with things I'm doing to improve deliverability. In no particular order.
This is a TXT (text) record in a domains DNS that lists what servers are allowed to send mail for the domain. The simplest is to use "a mx ~all", which means "the parent domain, and any domains in the MX record, and nobody else". The SPF syntax is simple. Here's what it looks like in BIND:
example.com. IN TXT "v=spf1 a mx ~all"
And how it looks in djbdns/tinydns:
'example.com:v=spf1 a mx ~all:::
In tinydns, you need to escape the : with \072 (octal 072), because : is a delimiter.
'example.com:v=spf1 a mx ip4\0722.214.171.124 ~all:::
This is mainly for Google and Yahoo at this time. You publish a public key and then sign all your email with the private key. (This would not have prevented our spam problem.)
Test all the mail accounts for weak passwords using John The Ripper. This was our security hole - a guessable password. This is the same problem facing the big guys.
Run all the outgoing mail through Spamassassin, and record the stats. If someone is sending too much spam, block that account. (Not implemented.)
Not yet written - issues that affect inbound email.