Received: from mail-pd0-f196.google.com (mail-pd0-f196.google.com [188.8.131.52]) by securemail.chicagonettech.com with SMTP
Wed, 1 Oct 2014 07:41:57 -0500
Received: by mail-pd0-f196.google.com with SMTP id ft15so266964pdb.3
for <REDACTED@chicagonettech.com>; Wed, 01 Oct 2014 05:41:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
X-Received: by 10.66.243.208 with SMTP id xa16mr30970682pac.41.1412167302596;
Wed, 01 Oct 2014 05:41:42 -0700 (PDT) <=== DATE, TIME and SMTP ID of messages - inserted by GOOGLE
Received: from BSTPC ([184.108.40.206]) <=== Shows DEVICE NAME and IP ADDRESS
by mx.google.com with ESMTPSA id fv6sm910849pdb.83.2014.10.01.05.41.39
(version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
Wed, 01 Oct 2014 05:41:41 -0700 (PDT)
Subject: Web Listing Proposal
Date: Wed, 1 Oct 2014 18:11:32 +0530
X-Mailer: Microsoft Office Outlook 12.0 <=== MICROSOFT OFFICE ID INSERT #2
X-Antivirus: avast! (VPS 141001-0, 10/01/2014), Outbound message
X-SmarterMail-Spam: SPF_Pass, DK_None, DKIM_Pass
- In both of the examples above, the messages were sent via clients.
- In both cases, they were properly SMTP AUTHENTICATED by the SENDING MX servers: the first from a SmarterMail MX server to GOOGLE; the second from the GOOGLE MX server(s) to SmarterMail.
As Google and YAHOO! further develop their SMTP authentication testing, validating the data in the message headers against the IP addresses, and, as in the case of Comcast tests, even against the route taken by the message during the negotiation and transport, will the fact that Derrick Kluyts method of "dropping" a message into the "drop" folder still provide that SMTP authentication data.
I'm already seeing issues with web forms and shopping carts which don't SMTP authenticate via the domain from which the messages allegedly originate and being refused by GMail, YAHOO!, Comcast, and even by my own antispam measures. In every case, we've worked with our clients to create SMTP authentication, via the customer's SmarterMail MX server so that all outbound messages, whether sent from a shopping cart, web form, or other source, are properly SMTP authenticated.
Future antispam measures, are already, and will increasingly, use both RBLs, BRBLs, reputation lists, and the checking of SMTP authentication information in the message header to validate incoming messages as the war against spam ramps up further, and we need to make certain that Derrick Kluyts
's method of dropping messages into the "drop" folder is not bypassing that SMTP authentication.