Breaking e-mail with libunaccept
I am experimenting with e-mail delivery and spam protection on Klaki this
weekend. For that reason, I have temporarily disabled the F-Prot AVES
spam filter I wrote for FRISK Software on the
klaki.net domain and am
testing other means to keep our inboxes from filling up with garbage.
The tool I am testing, is one I actually wrote many years ago, but never
did much with:
libunaccept. (Update: more here)
Worse is better?
Anti-spam technology tends to rapidly become extremely complicated. Some examples of the techniques used by the AVES solution include:
- Heuristic evaluation of message contents
- Virus scanning
- Checking DNS-based black-lists
- Real-time tracking of outbreaks
Layers upon layers of protection. Belts and suspenders! It gets so complicated that it becomes hard to understand and evaluate what works and what doesn't.
What I am trying now, is way more stupid. It goes like this...
- Between 12:00 and 18:00, Klaki will accept e-mail from any computer on the Internet.
- Between midnight and 7:00, Klaki will only accept e-mail from mail servers that are either in Iceland or have DNS names which indicate that they are "friendly" - things like Google and Yahoo mail.
- The rest of the time, an intermediate policy is used which is less strict than the night-time policy, but more cautious than the afternoon free-for-all. Basically, if a computer looks like a dial-up machine, it gets rejected but all other machines with correctly configured DNS can still send mail.
Note that no e-mail is ever rejected by this policy. It just isn't accepted.
Any legitimate mail server will retry every few hours (for up to 7 days) until it reaches a time of day when the policy allows delivery. The reason this still cuts down on spam, is because most spammers do not use legitimate e-mail servers. It is cheaper for them to just move on to the next victim as quickly as possible when delivery fails.
The reasons I like this method are:
- It is super simple. Even simpler than greylisting.
- It should have zero false positives.
- It minimizes delays when Klaki's users are awake to read (or write) mail.
Over time, I can lengthen the list of "friendly servers" from which we always accept mail. Doing so should eventually eliminate anti-spam related delays almost completely, which (aside from incomprehensible complexity) are probably the biggest drawback of the AVES system.
Hopefully, combining this with client-side techniques like bayes filters or simple black/white-lists can eliminate whatever spam is left.
We'll see how it works anyway. If it is terrible, I'll just turn AVES back on and go back to the drawing board. :-)
I'll let you know.