We have a system where SF tags spam emails and forwards all emails to an internal server for further processing. We seem to be getting a lot of spam emails which are not detected by our system because we only look at the email headers and on some emails the SF headers are after the CRLFCRFL which indicates the start of the message body, below is an example.

 

So, Why does SF place it's headers after CRLFCRLF pair??  I would have thought that the SF headers should be placed directly after the "Received" headers and in any case BEFORE the start of the message body.

 

Below is the raw text of an email and you can clearly see the SF headers are in the wrong place - according to the RFC, a CRLFCRLF indicates the end of the headers and the start of the email.

Now, I understand that the spammer might intentionally add CRLFCRLF entries to try and evade spam filters, but this does not explain why SF places it's headers after the CRLFCRLF, essentially within the message body.

 

Thanks,

 

Steve.

 

example spam email.

 

 

 

Received: from ns1.protected-mail.co.uk ([192.168.0.1]) by mail.protected-mail.co.uk (6.0.3790.3959); Thu, 18 Jun 2009 11:43:11 +0100
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325
Received: From mail.protected-mail.co.uk ([127.0.0.1]) by ns1.protected-mail.co.uk (WebShield SMTP v4.5 MR3) id 1245321790847; Thu, 18 Jun 2009 11:43:10 +0100
Received: from 64.202.189.88 by mail.protected-mail.co.uk (IMS Spam Filtering Server); Thu, 18 Jun 2009 11:43:10 +0100
Received: (qmail 6680 invoked from network); 18 Jun 2009 10:36:29 -0000
Received: from unknown (HELO ip-72-167-141-38.ip.secureserver.net) (72.167.141.38)  by k2smtpout01-01.prod.mesa1.secureserver.net (64.202.189.88) with ESMTP; 18 Jun 2009 10:36:29 -0000
Received: by ip-72-167-141-38.ip.secureserver.net (Postfix, from userid 48) id 35A5AADF7FF; Wed, 17 Jun 2009 00:05:13 -0700 (MST)
To: < mailto:lisa.nicol@envirotec-group.co.uk - lisa.nicol@envirotec-group.co.uk >
Subject:  I HAVE A VITAL INFORMATION TO DISCLOSE TO YOU
From: "sherrydavis" < mailto:sherry4davis@gmail.com - sherry4davis@gmail.com >

 

Reply-To: mailto:sherry4davis@gmail.com - sherry4davis@gmail.com

 

MIME-Version: 1.0

 

Content-Type: text/plain

 

Content-Transfer-Encoding: 8bit

 

Message-Id:
< mailto:20090617072336.35A5AADF7FF@ip-72-167-141-38.ip.secureserver.net - 20090617072336.35A5AADF7FF@ip-72-167-141-38.ip.secureserver.net >
Date: Wed, 17 Jun 2009 00:05:13 -0700 (MST)
X-Server: LogSat Software SMTP Server
X-SF-RX-Return-Path: < mailto:apache@ip-72-167-141-38.ip.secureserver.net - apache@ip-72-167-141-38.ip.secureserver.net >
X-SF-HELO-Domain: k2smtpout01-01.prod.mesa1.secureserver.net
X-SF-Originating-IP: 64.202.189.88
X-Rejection-Reason: 16 - 557 Your domain
ip-72-167-141-38.ip.secureserver.net does not have a valid MX DNS record.
Disconnecting...
X-SF-SPAM:Y
Return-Path: mailto:apache@ip-72-167-141-38.ip.secureserver.net - apache@ip-72-167-141-38.ip.secureserver.net
X-OriginalArrivalTime: 18 Jun 2009 10:43:11.0691 (UTC)
FILETIME=[937DF9B0:01C9F001]

 

I'm Sherry Davis from Quebec Canada, grew up in an

 Orphanage and ended up as a Journalist. I have a genuine

 property worth $6.7 Million with a trustworthy Security

 Company which I'm about to will to you because I'm

 very sick and I have limited time to live. If you care to

 know more do get back to me.

 Sherry Davis

 

No, the "Return-Path: apache@ip-72-167-141-38.ip.secureserver.net" headers is NOT from our server.

Email comes into SF and is passed to an internal server for further processing, however the internal server does NOT add any headers. The only reason that we run an internal server in this way is because SF cannot dump the emails into a folder for us to pick up. We have written the internal SMTP server so I know it doesn't change any headers. It's very simple, it receives the data and streams it out to a file, that's all. The file is then picked up and catagorised, but is NEVER changed.

 

This email (I think) was intentially malformed to try to evade spam filters, and it appears very likely that SF has put it's headers well after the start of the body.

 

I am seeing an increasing number of these messages.

 

Cheers

 

Steve