When Sending mail via the drop folder the mail should automatically appear in the sent folder of the sender
Idea shared by Derrick Kluyts - September 27, 2014 at 7:24 AM
When Sending mail via the drop folder the mail should  automatically appear in the sent folder of the sender (from address) this would allow tacking of sent mails and the ability to resend.

1 Reply

Reply to Thread
Bruce Barnes Replied
October 1, 2014 at 6:48 AM
I have a question about using the "drop method" to send:
When you drop into the folder, does the message still show that it was SMTP AUTHENTICATED by SmarterMail?
I ask because there are a number of large providers, YAHOO! and COMCAST among them, who are experimenting with validating the SMTP VALIDATION information show in the header against other antispam tools to further eliminate the latest deluge of snowshoe spam.
Here's the header of a TEST message which originated from a test account, on a client's SmarterMail server, sent to a GMAIL account:
Delivered-To: REDACTED@gmail.com 
Received: by with SMTP id b8csp568708lfe;
        Wed, 1 Oct 2014 06:05:20 -0700 (PDT)
X-Received: by with SMTP id h6mr56321175oew.14.1412168720012;
        Wed, 01 Oct 2014 06:05:20 -0700 (PDT)

Return-Path: test@REDACTED_DOMAIN_NAME.com <=== SENDING E-MAIL ADDRESS inserted in header by SmarterMail.
Received: from mail.REDACTED.net (mail.REDACTED_MX_SERVER_DOMAIN_NAME.net. [])
        by mx.google.com with ESMTPS id f9si1726551oel.66.2014.
        for <REDACTED@gmail.com>
        (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
        Wed, 01 Oct 2014 06:05:19 -0700 (PDT)

Received-SPF: none (google.com: test@rREDACTED_DOMAIN.com does not designate permitted sender hosts) client-ip=; <=== GOOGLE's SPF TEST = must be sent from domain, nothing else authorized.  IP PARTIALLY REDACTED
Authentication-Results: mx.google.com; <=== AUTHENTICATON RESULTS
       spf=neutral (google.com: test@SENDING_DOMAIN_REDACTED.com does not designate permitted sender hosts) smtp.mail=test@REDACTED.com
X-SmarterMail-Authenticated-As: test@REDACTED.com
Received: from RedactedSendingDeviceName (REDACTED-999-000-000-149-Illinois.hfc.comcastbusiness.net [REDACTED-999.000.000.149]) by mail.REDACTED.net with SMTP
cipher=Aes128 bits=128);
   Wed, 1 Oct 2014 06:05:10 -0700
Reply-To: <test@REDACTED.com>
From: <test@REDACTEDr.com>
To: <REDACTED@gmail.com>
Subject: test for SMTP authentication
Date: Wed, 1 Oct 2014 08:05:13 -0500
Organization: test@rivieralaser.com
Message-ID: <008f01cfdd78$5758b8c0$060a2a40$@REDACTED.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: Ac/deEQG88tVBO/5RrCgZNqE81fPBw==

This is a multipart message in MIME format.
Here's the header of a spam message, received from GOOGLE, which was been properly SMTP validated.  This makes both spam decision making and spam reporting extremely easy:
Return-Path: REDACTED@gmail.com <===  Shows REPLY TO and GOOGLE ROUTING information
Received: from mail-pd0-f196.google.com (mail-pd0-f196.google.com []) by securemail.chicagonettech.com with SMTP
                cipher=Aes128 bits=128);
   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;
        d=gmail.com; s=20120113;
X-Received: by 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
Return-Path: REDACTED@gmail.com <==== RETURN PATH
Received: from BSTPC ([]) <===  Shows DEVICE NAME and IP ADDRESS
        by mx.google.com with ESMTPSA id fv6sm910849pdb.83.2014.
        for <REDACTED@chicagonettech.com>
        (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
        Wed, 01 Oct 2014 05:41:41 -0700 (PDT)
From: REDACTED@gmail.com <=== SENT FROM
To: <REDACTED@Chicagonettech.com>
Subject: Web Listing Proposal
Date: Wed, 1 Oct 2014 18:11:32 +0530
Message-ID: 094801cfdd75$100c7e00$30257a00$@com <=== MICROSOFT OFFICE ID INSERT #1
MIME-Version: 1.0
Content-Type: multipart/alternative;
X-Mailer: Microsoft Office Outlook 12.0 <=== MICROSOFT OFFICE ID INSERT #2
Thread-Index: Ac/ddQd3yLZ11XPAR7WQE3+S+AKpyQ==
Content-Language: en-us
X-Antivirus: avast! (VPS 141001-0, 10/01/2014), Outbound message
X-Antivirus-Status: Clean
X-SmarterMail-Spam: SPF_Pass, DK_None, DKIM_Pass
X-SmarterMail-TotalSpamWeight: 10
  • 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. 
Bruce Barnes
ChicagoNetTech Inc

Phone: (224) 444-0169

E-Mail and DNS Security Specialist
Network Security Specialist

Customer Service Portal: https://portal.chicagonettech.com
Website: https://www.ChicagoNetTech.com
Security Blog: http://networkbastion.blogspot.com/

Web and E-Mail Hosting, E-Mail Security and Consulting

Reply to Thread