Forged Headers

[jangarella]

I'm having a problem where spammers use my domain name as the sending SMTP server name. Shouldn't MailEnable check to ensure that the IP address in the "Received:" field resolves to an MX record, a PTR record, or an SPF record for incoming mail? The SPF filter marked the following message as a softfail since the "From:" field shows a hotmail account and the address was not resoved via SPF.

Here's what I mean:

Received: from mail.angarella.com ([80.171.154.244]) by XPERCOMM.NET with MailEnable ESMTP; Sun, 04 Dec 2005 10:24:39 -0700
From: "mollins" <loypscpnemq@hotmail.com>
To: joseph@angarella.com
Content-type: text/html

In the above header, the "Recieved:" field shows mail.angarella.com which is a valid domain hosted by my server. The IP address is not an IP address from the angarella.com domain. So, shouldn't the message have been rejected if "Require PTR DNS entry for unauthenticated connections" is turned on? Also, shouldn't the SPF filter have considered this a hard failure?

Am I missing something? Certainly there must be a way to prevent this kind of SPAM attack - it happens far too often to not have resulted in a solution. Any advice would be greatly appreciated.

Joe Angarella

[jangarella]

I'm touching this post in order to keep it alive. Does anyone have any information that might be helpful regarding catching forged headers? Unfortunately, if I can't get this question answered, I am going to be forced (from internal political pressure) to use SM rather than MailEnable Enterprise.

[MailEnable-Ben]

Hi sorry, I am a little perplexed of your angle here, maybe if this needs a priority result and a managed outcome you should lodge a defect or a paid support request to http://www.mailenable.com/support/step1.asp

I can tell you however that the PTR lookup is done on the IP 80.171.154.244 this IP does have a PTR record associated.

With the SPF lookup it is done against the command file or envelope senders address not the message address, but you could find further information on this in the SMTP activity logs. Also not completely sure but I think the hotmail servers will report a soft fail and do not hard fail any results.

[jangarella]

Thank you for responding...

Here's an example of an offending message header:

Received: from mail.angarella.com ([85.18.136.85]) by XPERCOMM.NET with MailEnable ESMTP; Fri, 16 Dec 2005 11:24:46 -0700
From: joseph@aol.com
To: joseph@angarella.com
Content-type: text/html
Subject: Stylish Tag Heur replica watches at Replica Classics
Received-SPF: neutral (XPERCOMM.NET: 85.18.136.85 is neither permitted nor denied by domain of aol.com) client-ip=85.18.136.85

As you can see, the envelope says that the message is from a server named mail.angarella.com. However, the IP address of 85.18.136.85 is not the IP address of any host in the angarella.com domain. Further, if the SPF check were done on this address, it would have hard-failed the test and I could then do something about the message. If you notice, the SPF check is done against the AOL.COM domain which defeats the purpose of SPF record checking in the first place.

mail.angarella.com is hosted on the same machine as the MailEnable Enterprise server. So, it seems to be that I should be able to - in advance of accepting the message - compare mail.angarella.com with the IP address of the SMTP server that is sending the message. If the host name of the sever that is sending this message does not resolve via either a PTR record or an SPF text record, shouldn't I be able to refuse the message? Even if I only had the ability to validate those domains for which I host post offices, whether by an SPF check or otherwise, that alone would prevent these kinds of messages.

I guess my point is that if the SPF check is done against the domain name that the message sender uses in the return address (From field), it's rather useless since senders can use any address they wish as the sender of the message. However, if the SPF record check is done at the SMTP service level, it's not likely that the sender can forge the IP address of one of my own servers. Or, even if the sender's host name was validated against the list of local post offices, the message could be refused simply because the local domain shouldn't be using the SMTP connector to route messages, unless there are multiple MX records for the domain.

I get over 100 messages a day like this and if I could stop them at the SMTP connector tier, it would vastly reduce the strain on the rest of the system (MTA, Post Office connector, etc.) It seems to me that there should be an easy way to prevent these kinds of messages from being accepted by the SMTP connector, whether by SPF record check, validation of a PTR record (not just seeing if one exists), by performing a DNS check on the host name, or by some other such means.

Any ideas?

Again, thank you for responding to my request. I have to make a decision soon regarding the mail server software I am offering my customers, as well as what software I recommend in my consultancy practice. Other than this single issue (and the .NET problems with Beta 2), I am very comfortable recommending MailEnable Enterprise.

Joe Angarella
Angarella Communications

[MailEnable-Ben]

Hi the header information you have supplied is not the envelope address maybe this information will help with your questions on the SPF.

Envelope Address vs. Message Header Address: An analogy between electronic mail and U.S. Mail (snail mail) is helpful in understanding the distinction between the envelope address and the message header address. With U.S. Mail, there is address information the envelope, but your address also often appears in the text of the letter or contents inside the envelope (i.e., a bill or legal letter). The address printed on the envelope is what allows the letter to be delivered to your house or office, not the address printed on letter/message inside the envelope. In theory, the letter/message address could be totally different from what appears on the envelope, but it would still get to you. This is similar for the sender's address. It can appear on both the envelope and on the letter/message inside the envelope.

Like U.S. Mail, Electronic mail has two sets of addresses. Email has an envelope address that is used to actual deliver email to the correct person. You don't see this envelope address information when you receive the message, even if you look at the full-headers. The envelope address is used by programs on the email servers (i.e., email.med.yale.edu, omega.med.yale.edu, biomed.med.yale.edu) that actually direct the mail delivery to individual email accounts (i.e., mcgrathf@biomed.med.yale.edu). Just like there is an address as part of the text of a letter inside a U.S. mail envelope, email has a second set of addresses in the header of the email message. These are the addresses you normally see in the To: and From: headers of the email message (examples: normal/brief headers and full-headers). As with the U.S. Mail, these addresses need not be correct for you to receive the message. In fact, the sender can make these be anything they wish.

The addresses used during the delivery process (envelope addresses) do NOT have to be the same as in the message header, but they can often (but not always) be seen in the full headers. This is especially important to remember when viewing SPAM where the To: and From: headers are usually meaningless having been made up by the sender.

In a Nutshell:
The ENVELOPE address can NOT be spoofed. This address is used to deliver email to the correct recipient. The address in the HEADERS of the message can be spoofed. Addresses that appear in the To: and From: message headers are NOT the addresses used in the delivery of the message.
When you are reading an email message you can view the address in the message HEADERS, but you can not view the ENVELOPE address.

You can check what was in the envelope or command file by reviewing the activity logs in MailEnable.

In regards to the PTR record check as I stated in my earlier post this lookup is done on the IP, it does not match up the IP to the domain written in the header but check the IP address does have a reverse PTR record which the one you show does.

You may have to look at removing the messages once they have entered the server if you are sure that your SPF is configured correctly and not preventing the delivery of such messages. To check what SPAM preventions there are in the ME product please search the KB for the word SPAM. I would doubt that the 100 messages per day would be putting undue stress on your server ME can process 100 of thousands of messages per day.

[jangarella]

Thank you for your response, Ben.

I get the metaphor regarding the envelope header. Interestingly, the log file shows the exact same information from the envelope, but that point is now moot. Perhaps there is another mechanism you can recommend.

Regardless of whether SPF is the correct mechanism, or the semantics of envelopes and return addresses, how can I prevent message delivery from hosts that purport to be valid (e.g., mail.anagarella.com) when the IP address is not associated with the host name, especially when my DNS server is authoritative for the host? Is there a way to prevent these kinds of messages when there is an attempt to forge a host name?

Please advise.


Thanks,

Joe Angarella
Angarella Communications
http://www.angarella.com