Proposal: Early Adopter Mode

[Snawoot]

Background

Current policy spec provides two modes for included domain:

• testing - currently useless mode for records, from senders' perspective, which doesn't yields any conclusion whether domain should present proper TLS certificate or not. This point will be expanded below.
• enforce - only mode which is interest for user. Unfortunately, it is improper to jump to it's activation without proper testing in "real field".

Actually those modes may resemble modes of MTA-STS policy with one exception: we don't need none policy here for explicit verified denial because entire list is signed and record absence in list is authoritative too.

Also there is another practical difference between MTA-STS testing and STARTTLS-E testing modes. Testing mode in MTA-STS announced to sending parties allowing them to perform some practical activities to test support of complete communication system and report failures. STARTTLS-E testing mode, AFAIK, is used by a party who doesn't participate in real regular email communication (S-E backend) to perform some sort of synthetical tests. In fact, S-E backend may conduct such tests even without real inclusion of domain into policy list.

From users perspective, if one submits his valid domain to STARTTLS-E policy list, nothing happens for a while during testing period, but after upgrading to enforce things may start to break due to incapable senders, incorporating S-E policy list.

Also current situation with testing policy looks to me like chicken and egg problem. People see no sense in policy list at current state: #94. And lack of list usage prevents from real testing trials.

Proposal

There is an easy way to break such vicious circle and satisfy needs of people who demand their correspondence privacy right now. My proposal is: add something like "early adopter" mode to config generator which threats testing policy records as enforce. This option will allow people to take responsibility for things that may break and start using policy list today. At worst, user always may override TLS policy for specific domain if some problems observed. Similar approach already proved itself somewhat useful with my implementation of MTA-STA for Postfix: people willing to enable full security at cost of small chance for service deliverability degradation.

There is potential benefits of such solution:

• Users get motivation to start using policy list.
• It strengthens role of testing mode due to real testing on systems operated by technical enthusiasts avant-garde.
• Some senders may detect problems with some (or all) destinations before security policy of their recipients takes full effect. For example, some hosters are still redirecting outgoing emails to their SMTP server in order to filter outgoing spam.
• After all these years of STARTTLS-Everywhere development, first human will be able to send first email with guaranteed transport security. That'll be one small feature for starttls-policy-cli, one big leap for internet community =)

[sydneyli]

This looks and sounds find to me. Would you like to start on it for starttls-policy-cli, and open a corresponding issue there?

[Snawoot]

Yes, I'll open issue there and even try to implement new feature.

[sydneyli]

Great! I'll close this here then.