Spam Mail

While there may be local differences throughout the world of nations concerning the legal aspect of SpamMail, to most of us it is the annoyance of receiving advertising mails that pile up and jam our mailboxes daily.

What about SpamSolutions? There are some programs, like SpamProof, SpamCop and SpiderTrap. SpamCop is an issue among organizations who do not consider themselves as spammers, though. And also not a quick solution, but rather a long-term one.

Spam filters exist and they are better than none.

Fourth, WhiteIce?, http://www.whiteice.com/.
Spam Assassin http://SpamAssassin.org/tag/. There's a wiki dedicated to SpamAssassin at http://www.exit0.us/ and another at http://wiki.spamassassin.org/w/.
SpamBayes? has a wiki http://entrian.com/sbwiki

RFC1912

Is anybody checking for sender compliance with this (Reverse DNS entries for MX records) or ensuring mailservers have their host name in the greeting? While this wouldn't get rid of spam that complies, much of it doesn't.

The problem is, not all legitimate senders (e.g. some major companies in North America) seem to have their servers configured according to the requirement.

We tried rejecting non-compliant mail but had to stop doing that after a couple of days because there was so much legitimate mail that got rejected.

Anybody else try this?

That does sound like a good idea. Were you so kind as to mention to those postmasters that their servers do not follow the standard protocol? Or are you blissfully ignorant of the RemoteStrangulationProtocol?

I sent messages to the eight offenders (after setting up filter exceptions, of course). Three postmasters rejected the delivery. No responses from the other three of the very large organizations (one of which was a large financier - CIT.com - try them out in the dnsreport.com tool). Two were smaller organizations (both were suppliers - they thanked me for the info and fixed it). I was warned by our VAR (we have no IT dept) that implementing the above solution would probably turn us into an RFC1912 cop, and he was right. I turned it off again because I didn't have the time to be monitoring the logs for mail from legitimate senders in order to set up filter exceptions. It also made me wonder if there were so many major companies (presumably with their own professional IT staff) that didn't comply, maybe there was some other reason, hence the question here.

(After some elapsed time:) I also tried asking the vendor of our email appliance for input on the problem. I never received a callback from the manager I spoke to about it. However, we recently upgraded the version, and the option for "Reject on missing reverse DNS:" is now on an "advanced options" screen with a warning Do not enable this option unless you are quite sure this is what you require. Many mail serving hosts on the Internet do not have valid Reverse DNS records associated with their IP addresses and therefore you may reject mail from as many as 40% of connecting clients.

Of course, that's a flawed phrasing. You might reject mail from 100% of "connecting clients" (or as little as 0%), depending on happenstance. They mean "as many as 40% of all clients on the Internet" or some such.

Wah. The unique e-mail address that I put on my SeanOleary HomePage just got its first piece of spam today. SpamBots must be on the WikiWikiWeb. The offending e-mailer is <freesources1@yahoo.com>. It's a typical Multi Level Marketing scheme, but one of the addresses on the list is within 25 miles of me, so I may just go up and personally visit my spammer...

Other ways to track down sources of SpamMail

(FIXME: move "the plus sign technique" to ThrowawayEmailAndRidYourselfOfSpam, since these plussed addresses are one specific kind of "throw-away address".)

Consider the plus sign technique

Or you can trace spam by putting one or more plus signs ("+") in your address after your real e-mail ID. For instance, timc+wiki+spamproof@divide.net will get to me, but I know you got it from this page :-). It doesn't work with all ISPs, though. (They have to be running a sendmail-compatible package.)

There is another weakness to this technique, although it's probably slight. You still reveal your real e-mail address to anyone who knows how to strip off the plus-sign part of the address (yes, mine's timc at divide dot net).

Incorporating a comment left here in an earlier version of this page, I'll add that all mail sent to timc@divide.net goes straight to the bit bucket. That prevents spammers from cutting at the + sign.

I talk about this in my diary, too:

http://www.kuro5hin.org/story/2003/3/24/22222/2368

<>< TimChambers

Also, use of characters people think aren't valid in email can be amusing. $ is my favourite, I need to check the RFC before spouting others.

All characters in a valid RFC 2822 address are listed at http://en.wikipedia.org/wiki/E-mail_address .

Does this "hairy address" technique still work?

Hairy, but valid RFC 2822 Email Address http://bagley.org/~doug/elisp/hairy.shtml

Email addresses with a "+" are VALID http://www.jacobsen.no/anders/blog/archives/2002/08/24/email_addresses_with_a_are_valid.html has one comment that mentions "RFC-1642 uses the + symbol as a shift character to help encode the Unicode characters. So maybe sites and/or programs that have issues with + signs in email addresses are following RFC-1642 rules ... ?" http://www.ietf.org/rfc/rfc1642.txt

By "the RFC" I presume you mean RFC 822. Be aware that RFC2822 ( http://www.ietf.org/rfc/rfc2822.txt ) obsoletes RFC 822. It also explicitly allows "+" signs in email addresses. It takes priority over RFC 1642, right ?

SpamProof mail everyone@everywhere.every.domain n!+1 is congruent to 1 modulo every prime <=n, and therefore it must have a prime factor > n. Hence, as claimed, there are infinitely many primes. QED. .

CategorySpam