If I come arround, I will list here all the texts from me about SPAM and Anti-SPAM.
Many texts (Links) are in German, but a lot are in English language, too. Perhaps, sometimes, I come arround to translate everything into English (often maybee only partially). But not now and today.
What is SPAM?
SPAM is everything wich electronically disturbs you and you are not able to easily get rid of for the time being. Examples of SPAM:
- Offtopic posts: This is where the term originates. These include annoying crossposts and things which are not on topic at all.
- UCE: Unsoliticed Commercial EMail. This are all those little letters you get in your inbos.
- Search Machine SPAM: All those false search results you get from search machines if you look for well known words and are tricked to look for sites which have nothing in common with what you are looking for.
- Login SPAM: That are registration eMails from services, wich do not verify eMails. Note that login verification eMails are not SPAM!
- Newsletter SPAM: Newsletters which do not verify if you want the newsletter by sending a registration eMail are SPAM, too.
- SPAM backlog: This are eMails you receive because somebody has used your eMail address in the From without your consent. These eMails are either complaints by others asking you why you sent these eMails (which you didn't, so the others are braindead, as you must not answer SPAM!) or delivery notifications which say, that the recipient is unavailable (which is done by braindead delivery systems which first accept eMail and then check if they can deliver. It might be open Releays, too, though).
Yes, this is all SPAM. So if you are a service where others can enter their eMail-Address and you don't check if this eMail-address is correct, then you are a SPAMmer. Note that there are few exceptions to this rule:
- If your service was created in the last millenium and it was never changed. Back the old days this was no problem and Anti-SPAM-features like eMail address tests might not be possible to implement in this old service without breaking it. But new services (everyhting developed or changed since 2001) must have those simple Anti-SPAM-features in place, else it is a SPAMming service.
- If your service does not verify eMail addresses but allows deactivation of the fraudulent eMail address with 2 clicks (only two clicks, better one) via an URL then it is a badly designed OPT OUT system. If it is more complex (like answering eMail, typing in something like an eMail address, etc.) then it's a SPAM system. However in this case your name must be well known from TV or similar. If you are somebody who is unknown to the major public (this is more than 50% of the people world wide don't know your domain) then you are a SPAMmer. Period.
Note that this all are the SPAM rules applied to eMails I receive to train the SPAM filters of my GoogleMail account. And hopefully others will do too.
Well, who am I?
I am nobody. But as an admin I fight against SPAM since 1994 (or even bevor) and thus have my own thoughts about SPAM and how Anti-SPAM methods must be constructed:
- They must not discriminate old behavior: People sending with an eMail client from 1984 must not have problems reaching recipients even if they do not know anything about SPAM.
- Must be easy to administer: It may have a little bit setup overhead, but it must have 0 additional TCO when processing eMail. I am too overloaded with work, so the last thing I need are instable relays due to Anti-SPAM measures or a higher administrative overhead.
- Full local control: You must not have any external system or policies deciding if something is good or evil.
Intersting ways which will get full support from me as soon as they are available for productive use (this means: They are stable and mature enough for Nerds like me):
Things which should get lost. They are defective implementations:
Things, which cannot be used at my side:
- SpamAssassin: Good way to go. But if you don't want to have the effort of the additional housekeeping SpamAssassin needs, you leave the control to others who provide the signatures. If you don't want eihter way, you cannot use SpamAssassin.
- Bayes-filter: Interesting idea, but does not come easy. And you must train the filter. So it's not static and needs a lot of effort to keep it perfect. Additionally it is not easy for me to provide the infrastructure needed, as my eMail network is thought not to have one central point where one could place such a filter.
- RBL: Is controlled by extern.
External, Heise, German Language
- MetaSPAM an area, where I noted about why I want to go offline with my eMail. With my thoughts to systems like Marid and MASS.
- spam.geht.net/ - The basic idea was, to do exactly the opposit of what ORBS wanted to do:
- Open relays to fight SPAM! This way spammers cannot detect if a relay is open or closed, and thus only find open relays. Relays, which do not forward the SPAM to the recipient, but in contrast, charge the spammer for using the service.
- So the difference to SpamAssassin is not to filter SPAM on the recipient side, but to filter it on the side of the abused relays.
- Nobody listened. ORBS even blacklisted my relays because they pretended to be open (thus failed the ORBS test) because they must pretend to be open to fight the spam.
- None of my relays ever transferred one single SPAM, but killed million of SPAM mails.
- It stopped working as newer sendmail versions started to implement Anti-SPAM-measures into the code (instead in the sendmail.cf), such that I was not able to continue to use my hacks.