How much spam is meta-spam?

[Dan in Saint Louis]

Lately I have noticed that a large fraction of the spam I get each day is generated by "Mailer-Daemons" that cannot properly parse email headers. My (spoofed) address appears in the "From:" field but the headers are showing origins in all the usual places: Russia, China, etc.

Are the email admins around the world really so ill-informed that they cannot tell where the offending messages actually originate? Help me out here, did the message below not originate at [alshamil.net.ae] in Abu Dhabi?

Return-Path: <dan@landiss.com> (dan@landiss.com)
Received: (qmail 24764 invoked by uid 110); 11 Apr 2010 07:04:53 +0200
Delivered-To: 1-dom@alovelyworld.com
Received: (qmail 24757 invoked from network); 11 Apr 2010 07:04:51 +0200
Received: from auh-b126026.alshamil.net.ae (86.98.151.118)
by wpc4201.amenworld.com with SMTP; 11 Apr 2010 07:04:50 +0200
Received: from [39.139.128.27] (account dan@landiss.com HELO wuwpctwkvm.hoaoqkurqrdk.{LET:ru,org,com,va,net,biz ,info,tv,ua,su})
by auh-b126026.alshamil.net.ae (CommuniGate Pro SMTP 5.2.3)
with ESMTPA id 706984916 for dom@alovelyworld.com; Sat, 10 Apr 2010 21:04:47 -0800
From: "Wilburn Mahoney" <dan@landiss.com> (dan@landiss.com)
To: <dom@alovelyworld.com> (dom@alovelyworld.com)

[Judy G. Russell]

Are the email admins around the world really so ill-informed that they cannot tell where the offending messages actually originate?I suspect they don't care exactly where it originated; they just care that it ain't "right."

[sidney]

Are the email admins around the world really so ill-informed that they cannot tell where the offending messages actually originate?

What they are ill-informed about is how to set up a mail server.

Back in the good old days before there were spam problems the Return-Path header at the beginning of the email was placed there to make sure that the receiving mail server could know where to bounce undeliverable mail to no matter what might be in the (optional) From header or what complicated paths and relays the mail might have gone through to get there.

Now, of course, spammers forge a Return-Path header along with the From header, so even if the mail can't be delivered to its To address they get a second shot at spamming you via the bounce message.

Because of that, current best practice in setting up a mail server is to never bounce mail once it has been accepted by a receiving mail server. If at the time the mail arrives the server can determine that the To address doesn't exist, it can simply reject the message, which puts the responsibility for any bounce message on the actual sending server. Some ISPs will not reject (or bounce) an email to a non-existent email address, just dropping it so that spammers can't figure out which addresses are good and which aren't.

Once mail is received by the receiving server there is no way to know for sure where it really came from, given all the ways there are to spoof the identifying information in the headers, and so no mail server should be configured to attempt to bounce back such mail.

[Dan in Saint Louis]

Once mail is received by the receiving server there is no way to know for sure where it really came from, given all the ways there are to spoof the identifying information in the headers
Does that mean that we can no longer trust the oldest (farthest down the list) "Received:" header? I was always told that one could not be forged.

[sidney]

Does that mean that we can no longer trust the oldest (farthest down the list) "Received:" header? I was always told that one could not be forged.

It's a little more complicated than that. Starting at the top Received header and going down you are working backwards through the chain of mail servers at your ISP or whoever handles your email. When you get to the Received header that was added by the server where the mail the mail entered the ISP's system, that identifies the server that supplied the mail to the ISP. If, for example, the mail was sent to your GMail addess which is set up to forward to your domain name address at your ISP, then the next few Received headers you see going down will be from Google mail servers. So far all of the Received headers were placed there by servers that are known to be trustworthy. Someone might send spam through them, but you know that the servers are not operated by spammers.

Finally you get to the bottom-most Received header that is from a server that you can trust. That header tells you the ip address of the server that sent the mail to it, which supposedly generated the next lowest Received header. But every Received header below that one could contain anything at all that a mail server decided to add, and you have no way of knowing if those headers are accurate or are forgeries.

So it is not the bottom-most Received header that cannot be forged. It is that there is a bottom-most one that can't be forged, possibly followed by a bunch of forged ones. However it is usually possible to determine which of the Received headers is the bottom-most unforgeable one.

[Dan in Saint Louis]

It's a little more complicated than that.
Ah! I was informed that all new headers are added to the top of the stack and therefore the bottom one was "real." If a junk mailer can decide WHERE in the stack to add headers, it's a whole different ball game. Thanks for the explanation. What scares me is that I think I understand it.

[ndebord]

What they are ill-informed about is how to set up a mail server.

Back in the good old days before there were spam problems the Return-Path header at the beginning of the email was placed there to make sure that the receiving mail server could know where to bounce undeliverable mail to no matter what might be in the (optional) From header or what complicated paths and relays the mail might have gone through to get there.

Now, of course, spammers forge a Return-Path header along with the From header, so even if the mail can't be delivered to its To address they get a second shot at spamming you via the bounce message.

Because of that, current best practice in setting up a mail server is to never bounce mail once it has been accepted by a receiving mail server. If at the time the mail arrives the server can determine that the To address doesn't exist, it can simply reject the message, which puts the responsibility for any bounce message on the actual sending server. Some ISPs will not reject (or bounce) an email to a non-existent email address, just dropping it so that spammers can't figure out which addresses are good and which aren't.

Once mail is received by the receiving server there is no way to know for sure where it really came from, given all the ways there are to spoof the identifying information in the headers, and so no mail server should be configured to attempt to bounce back such mail.

Sydney,

Can you set up something like babywebserver on your desktop that can filter out this stuff? (Way beyond my pay scale).

[sidney]

Can you set up something like babywebserver on your desktop that can filter out this stuff? (Way beyond my pay scale).

Theoretically, but there is no substitute for your ISP doing as good a job as possible on their mail server. Their server has the most complete information to work with. For example, my ISP, Sonic.net is able to simply refuse to accept something like 50% of all incoming mail because they meet some criteria that they can be absolutely sure makes it spam. Those criteria include mail with a virus attachment, mail from certain ip addresses that are on a list that they maintain of addresses that send them nothing but spam, mail messages that are copies of the same spam message being sent in a flood to many people at that ISP, mail from ip addresses in countries that the Sonic.net user that is addressed to has configured to be blocked, or similarly are in ip address block lists that the user has said that they want to use, and mail from a mail server that has not been seen before that does not respond to a protocol request to try again in a few minutes. (By the way, all of those filter are optional for the user, so people who do business with one of those countries or who are on an email list that posts virus signatures could opt out of parts or all of the filtering.)

Without access to the information that they glean from the millions of emails they handle every day I could not do that front end filtering as effectively as they do.

The 50% or so of the email messages that make it through that are fed through SpamAssassin. There is little more that I could do on my own server. Sonic.net allows me to tweak almost all the SpamAssassin settings that I could running my own copy. The biggest difference is that I could enable the Bayesian learning plugin, which takes too much processing and I/O to be practical for an ISP to run for every customer. That doesn't improve the results enough to make it worthwhile for me.

My situation may not be the same as everyone's. Almost all of my email comes from known sources which I can whitelist. If I were getting a wide range of email from people I don't know I would probably have to set up something to make it easier to check my spam folder more regularly.

[ndebord]

sidney,

Yes, a good point, I don't have the resources of Gmail. Never tried SpamAssassin, but my anti-virus program (AVAST Home) uses a variety of shields to protect against incoming malware. I used to use AVIRA, but it had a different philosophy and only checked stuff that had landed on your computer and tried to execute.

I can use my email program (Foxmail 5) to do black lists but it is more work than I care to put in to it. By default, no HTML in the email. IF I want to see HTML, I have to click on that little HTML icon in Foxmail to read the stuff in IE or right click to open it up with K-Meleon.

So I guess, the short answer is, YUP, after reading your post, I think I'll skip setting up my own web server.