Subject: [Uta] Implementing STS

From: Arvel Hathcock <[email-masked]>
Date: Thu, 14 Apr 2016 09:20:01 -0500

Hi everyone!  I just wanted to speak up and say that in the case of my 
MTA (MDaemon) the question of whether to link in a web-client lib is a 
non-issue because (for me) that had to be done years ago. Perhaps that 
lib is not called by the SMTP delivery code but its in the EXE already 
at least. I have no serious issue with this and one way to handle it (as 
I think was mentioned before) is by deferring back to queue any delivery 
attempt which finds a previously unknown STS policy record until such 
time (not long) as a separate thread safely dedicated to the task can 
validate the policy and update the cache file.  I will have to take this 
approach due to my MTA's internal design.

I also wanted to mention that I serve the world of the very small 
on-premise business community and I've received numerous emails stating 
the expectation and desire to have something like this implemented for 
them. This is a consequence of the STS articles etc recently put to 
press but also shows that its not only the big players who might push 
for it. Its true though that the vast majority are oblivious to these 
matters (which is fine) and they want us vendors to "just handle it" 
(which we should).  So I hope that this effort moves forward and above 
all does not get overly complicated.

A couple of tiny minor spec things for starters:  Section 3 says that MX 
patterns are required yet the example at the end of the doc doesn't have 
them.  Also,  "_.example.com" has the _ char as the wild-card.  Maybe 
there's a reason not to use * for this?  See, minor stuff.  It would be 
good to have some reference STS records/hosts setup somewhere that 
implementers can test against.

Arvel

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 14 Apr 2016 16:59:37 +0000

On Thu, Apr 14, 2016 at 09:20:01AM -0500, Arvel Hathcock wrote:

> ... one way to handle it (as I think was mentioned before) is by deferring
> back to queue any delivery attempt which finds a previously unknown STS
> policy record until such time (not long) as a separate thread safely
> dedicated to the task can validate the policy and update the cache file.
> I will have to take this approach due to my MTA's internal design.

Doing background policy validation makes sense, but deferring
delivery until that completes is requires some care.  A policy
might be invalid for some time, and during that time you want to
periodically retest (in the background, subject to some minimum
inter-probe delay) while continuing normal email delivery to the
domain.

This means that if background validation is your approach, you
would defer mail only until the first validation succeeds or fails.
In case of failure, keep retesting the policy periodically, but
continue delivery without delay.

> there's a reason not to use * for this?  See, minor stuff.  It would be good
> to have some reference STS records/hosts setup somewhere that implementers
> can test against.

It is still much too early for that, the draft proposal is I think
due for some major incompatible changes.

-- 
	Viktor.