1. This forum is read-only and considered to be an Archive. Please utilize the SmarterTools Community for future interaction and posts.

RESOURCES: SPF, DMARC, DOMAINKEYS, DKIM, TESTING TOOLS, and STANDARDS . . .

Discussion in 'SmarterMail' started by chicagonettech, Apr 1, 2012.

  1. chicagonettech

    chicagonettech Product Expert

    Given the myriad new reputation tools for domains which are now being included in both SmarterMail and other e-mail server software programs, I thought I would post some of the resources which I commonly use for testing, along with some of the standards resources, I commonly use in diagnosing issues which present themselves from time-to-time with my customer networks and by members of these forums who post here.
    Let's start with UNLOCK THE IN-BOX

    ============================

    UNLOCK THE IN-BOX

    UNLOCK THE IN-BOX is an excellent took available on the web which is FREE - supported by donations only, at http://www.unlocktheinbox.com/

    The service will both discuss the basis for, proper configuration of, and let you test your settings for:
    • SPF Records;
    • MX Records;
    • PTR Records;
    • DOMAINKEYS
      • - Note that in addition to the DOMAINKEYS TXT record, ADDITIONAL DOMAINKEYS TXT records, called a DOMAIN KEY POLICY RECORDS [each item must be in a SEPARATE TXT RECORD], can be added which allow you to can publish a policy statement in DNS that help email receivers understand how they should treat your email.
      • The four DOMAINKEYS statements, which can be published IN ADDITION TO the DOMAINKEY certificate, include [remember to OMIT THE QUOTES from the TXT record!]:
        • "t=y" - Which means that your email DomainKeys are in test mode
        • "o=-" - All email from your domain is digitally signed
        • "o=~" - Some email from your domain is digitally signed.
        • "n=*" - n stands for notes. Replace the * symbol, with any note you like
    NOTE: Be VERY careful about how you configure your DKIM DOMAIN POLICY RECORD!
    If you state "o=-" that is 'lowercase o equals minus" [ANOTHER REMINDER: Remember to REMOVE THE QUOTES in the actual record!] in that record, this will indicate that ALL outgoing e-mail in that domain is digitally signed. If you make such a restrictive statement, and then decide to allow any user to override the DKIM policy, their e-mail will probably get rejected as SPAM as the DOMAINKEYS and DKIM policies are implemented by more and more e-mail providers.​

    ============================

    DMARC

    DMARC, is a relatively new antispam standard and appears, from both the comments and postings in these and other forums, to confuse a number of those who either have implemented, or are thinking of implementing the protocol.

    DMARC.ORG has an excellent tool for creating the DMARC record for your domain(s) at: http://www.unlocktheinbox.com/dmarcwizard/

    DMARC can be a very confusing protocol because many of those who want to implement DMARC feel that the SENDER should be notified when a message is rejected.

    DMARC can also be very confusing because it is one of the few antispam protocols which MUST be checked BEFORE a message is actually accepted by the receiving e-mail server. That is counterintuitive to both programmers and e-mail server admins.

    More information about the DMARC protocol, the standards upon which it was developed, and the proper implementation, by both programmers and end users, can be found at http://www.dmarc.org/.

    The complete technical specifications for DMARC, which stands for "Domain-based Message Authentication, Reporting and Conformance" can be read at: http://www.dmarc.org/draft-dmarc-base-00-01.html.

    Whether you agree with how DMARC works or not, it is a standard which has been implemented and, if used, is expected to be implemented and work in the manner specified by both DMARC.ORG and the IETF, so please do not respond to this post with debate because I will not debate standards.

    ============================

    TLS

    TLS is an encryption protocol which is the replacement standard for SSL. TLS capabilities were introduced into SmarterMail 8 ENTERPRISE edition.

    TLS requires:

    Once you have setup TLS on your SmarterMail 8 Enterprise, or SmarterMail 9 Enterprise installation, you can TEST your SmarterMail TLS installation to make certain it is working properly by using the test available at: http://www.checktls.com/perl/TestReceiver.pl?ASSURETLS


    After opening http://www.checktls.com/perl/TestReceiver.pl

    You will be on the TEST RECEIVER page of the testing system. This will test the capability of your SmarterMail e-mail server to run TLS for mail delivered to other e-mail servers which also run valid TLS.
    • Enter A VALID e-mail address on the SmarterMail server you wish to test;
    • Select CERT DETAIL from the drop down menu below the e-mail window;
    • Click START TEST;
    There will be a short delay, shown by a countdown timer, and your test will begin.

    By using the CERT DETAIL test you will see all of the detail, along with any errors which might be reported, in the report window.

    NOTE: There was a problem with SmarterMail 9.2.4464, which broke TLS. The errors were showing up as a down-conversion to SSL, along with errors in the SMTP logs in SmarterMail. There were also errors with clients who were trying to use TLS to connect to SmarterMail to send and receive e-mail.T

    This was resolved with an interim release of SmarterMail 9.2.4469 which fixed the problems. Again, PLEASE NOTE that TLS ONLY WORKS IN SMARTER MAIL 8 and 9 ENTERPRISE VERSIONS and requires a very specific set of configurations on the part of the SmarterMail licensee.

    You will also see a summary at the top of the window.

    NOTE: Greylisted e-mail accounts may show RECEIVER FAIL if they are Greylisted. If that is the case, simply wait the required time stated by your greylisting settings and retry the tests. This will show up in the TLS TEST detail as: "451 Greylisted, please try again in 240 seconds".

    Here is an example of GREYLISTED TLS RESULTS:

    greylisted_cnttlstest.jpg
    If you would like to try our chicagonettech.com e-mail server, then use the e-mail address of
    TLSTEST@CHICAGONETTECH.COM to test to our SmarterMail installation so you can see the results of our chicagonettech.com e-mail server.

    Here is an example of an e-mail address which has been retried after the greylisting period requirements have been met.:

    NOTE THAT THE SECOND LINE WILL INDICATE A FAILURE because the 2nd e-mail server is NOT setup with an SSL certificate:

    cnttlstest.jpg


    You can also test e-mail sent FROM your SmarterMail server by opening the page at http://www.checktls.com/perl/TestSender.pl and following the instructions to SEND an e-mail FROM your SmarterMail e-mail account, or any other e-mail account you may have access to, via the link and key provided on that page.

    And finally, bringing this all together, with antispam settings and some resources on standards:

    http://www.chicagonettech.com/docs/pdf/smartermail_anti-spam_settings.pdf

    Attached Files:

    1 person likes this.
  2. Bruce many thanks for sharing your knowledge and years of trial, error and searching. You're an invaluable resource to this forum!

    ST Mods / Admin, please make this a sticky
  3. Matty-CT

    Matty-CT Member

    Good for a sticky, methinks.
  4. justintoxicated

    justintoxicated New Member

    agreed. how is this still not a sticky?