1
Blacklist checking of all mail servers in mail header
Question asked by Dale Harris - February 4, 2015 at 6:27 PM
Unanswered
Hi,

I currently don't run SmarterMail, but I have short listed it as our future mail server. I have a question regarding its ability to block incoming SPAM.

Can SmarterMail check all mail servers involved with the delivery of an email against an RBL, or not. I have included a header below which we received into our Inbox. When checking the one of the originating mail servers (bolded), I found that it was blacklisted, and would have been blocked by our existing RBL settings if it was actually checked. Could SmarterMail detect this as spam?
 
From researching, I think SmartMail needs to be able to do deep header parsing which I haven't been able to determine yet.

Regards,

Dale.
 
X-DN-ReceivedFileId: 14b34a75d09_YL4H_13e9-1.eml
X-DN-Spam-Bayesan-Probability: 0
Delivered-To: mark@mjm.com.au
X-DN-AuthorizedIP: RKUCAUJ4FHCHNRKARF3X4UCJNPJEXNYH-mms0XLvvWdAIS8nXc
b5vmZ2eDv8lGLsEF/lObjbTb+g=---
Return-Path: <jonathan2014m@mail.com>
Received: from vmcp15.digitalpacific.com.au ([101.0.112.4])
by mx.martinjonkersmotors.com.au (DeskNow) with SMTP ID 852
for <mark@mjm.com.au>;
Wed, 4 Feb 2015 09:31:54 +1000 (EST)
Received: from hosting.sewiwi.com ([103.11.134.181]:42585)
by vmcp15.digitalpacific.com.au with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256)
(Exim 4.84)
(envelope-from <jonathan2014m@mail.com>)
id 1YImwj-000KUN-NV
for mark@mjm.com.au; Wed, 04 Feb 2015 10:31:53 +1100
Received: from static-mum-120.63.251.105.mtnl.net.in ([120.63.251.105]:16428 helo=User)
by hosting.sewiwi.com with esmtpa (Exim 4.84)
(envelope-from <jonathan2014m@mail.com>)
id 1YImuc-0001Dz-GZ; Wed, 04 Feb 2015 06:29:42 +0700
Reply-To: <barrokekembah1@mail15.com>
From: "Barrister Mbah Okeke"<jonathan2014m@mail.com>
Subject: Congratulation, At last your Payment is made.
Date: Wed, 4 Feb 2015 04:59:03 +0530
MIME-Version: 1.0
Content-Type: text/plain;
charset="Windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - hosting.sewiwi.com
X-AntiAbuse: Original Domain - mjm.com.au
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - mail.com
X-Get-Message-Sender-Via: hosting.sewiwi.com: authenticated_id: sales@nestadvance.com
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - vmcp15.digitalpacific.com.au
X-AntiAbuse: Original Domain - mjm.com.au
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - mail.com
X-Get-Message-Sender-Via: vmcp15.digitalpacific.com.au: mailgid no entry from get_relayhosts_entry

2 Replies

Reply to Thread
1
Steve Reid Replied
February 5, 2015 at 6:21 AM
Yes this is a basic feature of the many spam tools available within Smartermail.
 
You may want to give Bruce's AntiSpam Document a read to better understand the complexity of what's offered and how it should be configured:
 
0
Dale Harris Replied
February 8, 2015 at 6:55 PM
That article is awesome, but it still doesn't tell me if SmarterMail checks all the mail servers listed in the email header against the configured RBL's.
In the example I gave, the email passed through 3 email servers before our email server saw it.  I am noticing spammers are relaying their emails through legitimate email servers more frequently these days.  My problem is that the RBL is only good for the current connection, not all the previous hops along the way.
If an email servers could check all the email servers in the email header against RBLs, then this would make maintaining the RBLs a lot easier, as they would only really need to target the sources, rather than the last email server who sent the message.  It's still no excuse for good security, but if security fails, then we need preventative tools.  Checking the email header wouldn't require a new standard to be introduced, just using the existing information more wisely.

Reply to Thread