From ietf-dane at dukhovni.org  Sat Sep  2 20:01:06 2017
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sat, 2 Sep 2017 18:01:06 +0000
Subject: Ironic interaction of greylistiing, backup MX hosts and DANE
Message-ID: <20170902180106.GB3322@mournblade.imrryr.org>

[ Also sent to the postfix-users at postfix.org list. ]

I sent a "please fix your TLSA records" notice to "postmaster" and
"info" at a domain whose primary MX host certificate fails to match
its TLSA records:

    postfix/pickup[62805]: 7672C1DD39: ...
    postfix/cleanup[63835]: 7672C1DD39: message-id=<...>
    postfix/qmgr[844]: 7672C1DD39: from=<...>, size=8815, nrcpt=2 (queue active)
    postfix/smtp[63837]: 7672C1DD39: host mail.example.nl[192.0.2.1]
	said: 450 4.2.0 ... Greylisted, ...
    postfix/smtp[63837]: 7672C1DD39: to=<postmaster at example.nl>,
	relay=mail.example.nl[192.0.2.1]:25, delay=3.7, delays=0.03/0.01/1.5/2.2,
	dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 119F07F861)
    postfix/smtp[63837]: 7672C1DD39: to=<info at example.nl>,
	relay=vps.example.nl[192.0.2.2]:25, delay=5.7, delays=0.03/0.01/5/0.61,
	dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 2FBDC2064A)

The  "postmaster" account copy was accepted by the primary MX, but
the "info" address was greylisted: *only* by the primary MX.

However, the secondary MX accepts email *without* greylisting!
This has the effect of delivering all mail via the secondary, with
the primary never seeing any retries that cause greylisting to
pass.

What happened next was interesting and ironic.  I got a "delay"
notification from the secondary:

    Your message could not be delivered for more than 3 hour(s).
    It will be retried until it is 5 day(s) old.

    For further assistance, please send mail to postmaster.

    If you do so, please include this problem report. You can
    delete your own text from the attached returned message.

		       The mail system

    <info at example.nl>: Server certificate not trusted

The secondary is configured to verify DANE TLSA when relaying mail
to the primary, so the problem report to "info", and indeed pretty
much all mail to the system in question is queueing on the secondary
MX host, waiting for the primary MX TLSA records to be fixed!

Only "postmaster" email gets through to its destination (if the
sending system does not validate TLSA records, which is naturally
the case for my outbound "please fix your TLSA records" notices).

The main lesson here is not implement Greylisting on only a subset
of your MX hosts.  Don't do that!  

    1. When greylisting, make sure that all MX hosts with equal
       or worse (higher) MX preference also greylist.

    2. It is harmless (though less effective) to greylist only on
       (all) backup MX hosts, and skip greylisting on the primary.
       It is not a good idea to greylist on the primary, and not
       on the backups.

    3. Monitor your DANE TLSA records, in such a way that notices
       of problems get through even when the TLSA records are
       stale.

    4. Handle certificate rotation correctly.

	https://dane.sys4.de/common_mistakes#3

	http://tools.ietf.org/html/rfc7671#section-8.1
	http://tools.ietf.org/html/rfc7671#section-8.4
	https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022
	https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/

	With "3 1 1" + "2 1 1" TLSA records, the rollover process
	can be substantially simplified:

	    https://www.ietf.org/mail-archive/web/uta/current/msg01498.html

Happy greylisting and TLSA record publishing to you all...

-- 
	Viktor.

From ietf-dane at dukhovni.org  Sun Sep 17 09:15:56 2017
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sun, 17 Sep 2017 03:15:56 -0400
Subject: New DANE TLSA monitoring/diagnostic utility
Message-ID: <512E084B-6A05-4BBC-95EB-7FCC8C09E414@dukhovni.org>


I am pleased to offer to the DANE user community a new monitoring
and diagnostic utility.  This is a one-shot variant of my survey
code specialized for monitoring cron jobs and troubleshooting.

Code and instructions at https://github.com/vdukhovni/danecheck

While Haskell may be an unfamiliar programming development toolchain
for many of you, I hope that it will not be difficult to install it
for the purpose of compiling an existing project.  See the README.md
for build instructions.

Enjoy.

-- 
	Viktor.