Spam
From WhyNotWiki
Contents |
[edit] Fighting spam
Fighting spam edit (Category edit) Category:Fighting spam
[edit] My situation/to-do
- See if I can script it so that I can very easily add a new address (every time I sign up for a new site) to my users table on Dreamhost
- If not, look into scripting Thunderbird so that all e-mails that don't match my allowed catch-all patterns are deleted (no need for a comprehensive valid user list this way)
- Look into getting my own dedicated e-mail server (Tim's VPS), so that I can have a Sendmail "virtual user table" or something and reject incoming mail directly at the gateway; would still need to manage a valid user list
- Need to decide if it's worth it to even have a catch-all
- Reject DSNs that are sent to non-existent addresses on my domain (addresses from which I never send outgoing e-mail)
[edit] Sources of information
http://blogs.msdn.com/tzink/default.aspx
[edit] Techniques
- Prevent spam (easier said than done)
- Spam filter software
- Avoid using a catch-all address if you can help it (I can't help it)
[edit] Reduce collateral spam / illegitimate backsplatter
http://www.linux.com/base/ldp/howto/Spam-Filtering-for-MX/collateral.htmlt.
Collateral Spam is more difficult to block with the techniques described so far, because it normally arrives from legitimate sites using standard mail transport software (such as Sendmail, Postfix, or Exim). The challenge is to distinguish these messages from valid Delivery Status Notifications returned in response to mail sent from your own users. Here are some ways that people do this:
2.7.1. Bogus Virus Warning Filter
...
2.7.2. Publish SPF info for your domain
The purpose of the Sender Policy Framework is precisely to protect against Joe Jobs; i.e. to prevent forgeries of valid e-mail addresses.
If you publish SPF records in the DNS zone for your domain, then recipient hosts that incorporate SPF checks would not have accepted the forged message in the first place. As such, they would not be sending a Delivery Status Notification to your site.
2.7.3. Enveloper Sender Signature
A different approach that I am currently experimenting with myself is to add a signature in the local part of the Envelope Sender address in outgoing mail, then check for this signature in the Envelope Recipient address before accepting incoming Delivery Status Notifications.
...
2.7.4. Accept Bounces Only for Real Users
Even if you check for envelope sender signatures, there may be a loophole that allows bogus bounces to be accepted. Specifically, if your users have to opt in to the scheme, you are probably not checking for this signature [described above] in mails sent to system aliases, such as postmaster or mailer-daemon. Moreover, since these users do not generate outgoing mail, they should not receive any bounces.
You can reject mail if it is sent to such system aliases, or alternatively, if there is no mailbox for the provided recipient address [how?].
http://www.postfix.org/BACKSCATTER_README.html.
When a spammer or worm sends mail with forged sender addresses, innocent sites are flooded with undeliverable mail notifications. This is called backscatter mail.
...
If your machine receives backscatter mail to random addresses, configure Postfix to reject all mail for non-existent recipients as described in the LOCAL_RECIPIENT_README and STANDARD_CONFIGURATION_README documentation.
...
A plea to virus or spam scanner operators: please do not make the problem worse by sending return mail to forged sender addresses. You're only harassing innocent people. If you must return mail to the purported sender, please return the full message headers, so that the sender can filter out the obvious forgeries.
[edit] Sender Policy Framework (SPF)
http://www.openspf.org/Introduction
http://www.openspf.org/SPF_Record_Syntax
http://www.openspf.org/Introduction.
[edit] The Problem: Sender Address Forgery
Today, nearly all abusive e-mail messages carry fake sender addresses. The victims whose addresses are being abused often suffer from the consequences, because their reputation gets diminished and they have to disclaim liability for the abuse, or waste their time sorting out misdirected bounce messages.
You probably have experienced one kind of abuse or another of your e-mail address yourself in the past, e.g. when you received an error message saying that a message allegedly sent by you could not be delivered to the recipient, although you never sent a message to that address.
Sender address forgery is a threat to users and companies alike, and it even undermines the e-mail medium as a whole because it erodes people's confidence in its reliability. That is why your bank never sends you information about your account by e-mail and keeps making a point of that fact.
But it does not have to be this way!
[edit] Sender Addresses in E-Mails
The Sender Policy Framework (SPF) is an open standard specifying a technical method to prevent sender address forgery. More precisely, the current version of SPF — called SPFv1 or SPF Classic — protects the envelope sender address, which is used for the delivery of messages.
...
Even more precisely, SPFv1 allows the owner of a domain to specify their mail sending policy, e.g. which mail servers they use to send mail from their domain. The technology requires two sides to play together: (1) the domain owner publishes this information in an SPF record in the domain's DNS zone, and when someone else's mail server receives a message claiming to come from that domain, then (2) the receiving server can check whether the message complies with the domain's stated policy. If, e.g., the message comes from an unknown server, it can be considered a fake.
Once you are confident about the authenticity of the sender address, you can finally "take it for real" and attach reputation to it. While IP-address-based reputation systems like Spamhaus or SpamCop have prevailed so far, reputation will increasingly be based on domains and even individual e-mail addresses in the future, too. Furthermore, additional kinds of policies are planned for a future version of SPF, such as asserting that all of a domain's outgoing mail is S/MIME or PGP signed.
[edit] Hard fail or soft fail?
http://forums.msrportal.com/showthread.php?t=27859.
2007-09-30
I have noticed a few phishing attempts trapped in the IMF on my SBS 2003 SP1 server with Exchange SP2, and some that got through, that claim to be from some rather major domain names (banks, auction sites). When I look up to see if they have an SPF record, they all have the softfail "~all" at the end of their SPF records instead of the "-all" hardfail tag.
It seems a waste of time to have an SPF record if one is not going to set it to hardfail on a spoof attempt. Why not just use the "-all" at the end?
What am I missing?
I understand your points, but my question was more towards the point that if one is going to set up an SPF record for one's domain, why not have the "-all" had fail instead of the "~all" soft fail. I mean, if one goes to the trouble of setting up an SPF record in order to prevent spoofing of one's domain (provided the receiving system checks SPF records), why bother with SPF at all if one is not going to hard fail it when spoofed?
It does not make sense to me why such major domains would put in a soft fail rather than a hard fail when their domains get spoofed.
If they had a hard fail "-all" in their records, then my server could block all spoofed mail purporting to be from their domains.
That these organisations don't necessarily actually know that they've identified all their outbound mail servers.
If they have missed any while setting up the SPF record, and they set it for -all ("this list is definitive"), they'll get a ton of undeliverable mail. If instead they opt for ~all, their outbound mail will continue to flow.
A really good anti-garbage filtering system will use SPF results to influence further testing. The IMF does not fall into that category, as it's only a basic filtering tool.
Not everyone implements SPF checking in their anti-spam systems as a binary (pass/fail) filter. [...]
...
As a publisher of SPF records, I may not want to prevent my end users from sending their mail via necessarily unknown third parties, as I may not be able to guarantee my end users' access to my mail relays at all times, but I would want potential recipients to be able to distinguish email originating from authorized systems.
[edit] The problem of catch-all addresses
Sometime around ~2007-12, spammers started using my tylerrick.com catch-all as a [reply-to] address and I started receiving enormous amounts of back-splatter.
It wasn't until 2008-02-25 that I discovered posts describing other people having the same problem. It's good to know I'm not the only one! (Though I truly wish none of us had this problem!)
http://forum.dreamhosters.com/troubleshooting/42303-Configuring-Gmail-for-Own-Domain.htm.
I don't like catch-all accounts anyway. If you have something common like webmaster, etc, you get bombarded by spam a lot of the time.
I had to kill my catch-all due to spammers trying to use my domain name for their email. Removing the catch-call will stop [the] "user is valid" validation checks some SMTP servers use [from succeeding/passing [I assume he meant --Tyler]].
http://ask.slashdot.org/article.pl?sid=07/01/10/2349241.
My domain name is being stolen by spammers; they forge outgoing mail using my poor innocent domain name. First, I'd like to plead with mail server administrators out there: please REJECT spam and undeliverable mail. If you reject instead of bouncing then legitimate mail senders will still know there is a problem. Second, do you have any tips for dealing with a flood of spam bounces? [...]
That was the same in my case. I still get about the same number of bounces from spammers after adding SPF.
The only thing that did solve it was killing all addresses I don't use and adding filters for the most common bounces.
Welcome to my hell. I've had this happen to 8 of my domains over the last couple of years, typical spam runs of 30k at a time, based on all of the 'bounce back' messages that tell me 'my' mail is spam, or worse "go F** yourself, spammer" crud.
I believe the main reason why spammers are forging in the first place is to taint relay blacklists. RBLs hurt spammers more than anything else. When they forge from addresses they cause legitimate relays to be spammed by other legitimate relays and this in turn may prompt some relays to blacklist legitimate smtp servers and tarnish the effectiveness of RBLs. However, most admins are now wise to this and differentiate between the different types of traffic.
If you run any mail server for a reasonable amount of time, until the feds decide to get off their lazy asses and prosecute these criminals, you're going to run into this problem. It usually passes after a few days. If I run into it, I will sometimes change the MX record of the offending domain to 127.0.0.1 temporarily. And rule number one is avoid *@domain.com mail mappings...
You start by rejecting outright email for non-existant email addresses. That gets rid of all bounces that come from addresses the spammers have made up. Then you look at the Received headers of the email that you supposedly sent and validate that it did indeed come from your IP and the header is of the form that your MTA generates. If not, somebody was impersonating you and you reject the bounce [how do you do that?]. See Stopping Backscatter Email.
The problem of invalid bounces drops dramatically if you set up your incoming server so that invalid addressees are rejected with a "User unknown" note at SMTP time. If you're using Sendmail with a virtual user table [how?], this is as easy as adding the following at the end of the file
@example.com error:nouser 550 5.1.1 User unknown
It's important to do this on the server that accepts mail from the outside. If you have a setup with an antispam/virus gateway that then relays to an internal server, you need to make the gateway aware of the valid/invalid addresses.
By rejecting invalid senders in the SMTP transaction, you only get bounces from the few messages that forged an actual sender. In my experience, the addresses tend to look like ashawuiefgfyig@example.com, so most of the bounces will just disappear into the ether(net).
...
[edit] Spam filter software
[edit] Gmail
If your e-mail ends up in a Gmail inbox (whether you use their web client or download it with POP/IMAP), you will benefit from their excellent anti-spam.
I'm not sure if the same is true if you have Gmail set up to forward to a different address. Do they apply the spam filter only to messages that are "staying" in your inbox and not simply being forwarded? Probably.
[edit] SpamAssassin
SpamAssassin for Dreamhost (http://www.unsaturated.com/projects/spamassassin-for-dreamhost/) (August 19th, 2007 at 8:22 AM).
This SpamAssassin guide is for Dreamhost clients who want to run a personal copy of SpamAssassin separate from the one already provided. This will take you step-by-step through the process of downloading, installing, and configuring SpamAssassin (SA) version 3.1.0.
...
[edit] DSPAM
http://danathan.jloreview.com/2005/11/19/installing-dspam-on-dreamhost-nasty-kludge/
[edit] Spam prevention
Spam prevention edit (Category edit)
Spam can't be prevented. But it's worth a try.
[edit] [Question (category)]: Will my e-mail address be harvested if I post to a public mailing list?
Question: If you use an important (non-throwaway) address on a (public) mailing list, do you need to be concerned about that address being harvested?
specifically: there are archives of mailing lists, indexed by Google et al :(
I think, unfortunately, those archives are ripe for harvesting...
So should I only use a throwaway address for all mailing lists???
[edit] Techniques spammers use
To defeat your spam filters, etc.
Clay Shirky (2007-03-07). Spam that knows you: anyone else getting this? (http://many.corante.com/archives/2007/03/07/spam_that_knows_you_anyone_else_getting_this.php).
So a few weeks ago, I started getting spam referencing O’Reilly books in the subject line, and I thought that the spammers had just gotten lucky, and that the universe of possible offensive measures for spammers now included generating so many different subject lines that at least some of them got through to my inbox, but recently I’ve started to get more of this kind of spam, as with:
- Subject: definition of what “free software” means. Outgrowing its
- Subject: What makes it particularly interesting to private users is that there has been much activity to bring free UNIXoid operating systems to the PC,
- Subject: and so have been long-haul links using public telephone lines. A rapidly growing conglomerate of world-wide networks has, however, made joining the global
(All are phrases drawn from http://tldp.org/LDP/nag/node2.html.)
Can it be that spammers are starting to associate context with individual email addresses, in an effort to evade Bayesian filters? (If you wanted to make sure a message got to my inbox, references to free software, open source, and telecom networks would be a pretty good way to do it. I mean, what are the chances?) Some of this stuff is so close to my interests that I thought I’d written some of the subject lines and was receiving this as a reply. Or is this just general Bayes-busting that happens to overlap with my interests?
If it’s the former, then Teilhard de Chardin is laughing it up in some odd corner of the noosphere, as our public expressions are being reflected back to us as a come-on. History repeats itself, first as self-expression, then as ad copy…
