MTA-STS when?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

MTA-STS when?

Jonathan Sélea
Hi

Hopefully, I am not one of several who already has asked this question
before, but here it goes:

When does postfix plans to implement MTA-STS? Big providers (Google,
Yahoo, Comcast and soon Microsoft) has already implemented it and
ofcourse - it would be nice if postfix could support it too,  separate
package for postfix that do the reporting.

I can find this old thread from this list, but it is not 100% clear how
the status of MTA-STS in postfix is:
http://postfix.1071664.n5.nabble.com/SMTP-STS-and-policy-delegation-for-smtp-client-td82868.html


Some references:
https://tools.ietf.org/html/draft-margolis-smtp-sts-00
https://datatracker.ietf.org/meeting/100/materials/slides-100-uta-mtasts/

Thanks!

--
Jonathan



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MTA-STS when?

Scott Kitterman-4
On Saturday, February 17, 2018 07:04:23 PM Jonathan Sélea wrote:

> Hi
>
> Hopefully, I am not one of several who already has asked this question
> before, but here it goes:
>
> When does postfix plans to implement MTA-STS? Big providers (Google,
> Yahoo, Comcast and soon Microsoft) has already implemented it and
> ofcourse - it would be nice if postfix could support it too,  separate
> package for postfix that do the reporting.
>
> I can find this old thread from this list, but it is not 100% clear how
> the status of MTA-STS in postfix is:
> http://postfix.1071664.n5.nabble.com/SMTP-STS-and-policy-delegation-for-smtp
> -client-td82868.html
>
>
> Some references:
> https://tools.ietf.org/html/draft-margolis-smtp-sts-00
> https://datatracker.ietf.org/meeting/100/materials/slides-100-uta-mtasts/
Here's the current draft:

https://tools.ietf.org/html/draft-ietf-uta-mta-sts-14

Having given it a quick read, I don't know that postfix needs to make any
changes for this.  I believe it could be readily manged by an external policy
server, which is, AIUI, the preferred approach.  See:

http://www.postfix.org/SMTPD_POLICY_README.html

Scott K

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MTA-STS when?

Viktor Dukhovni


> On Feb 17, 2018, at 2:35 PM, Scott Kitterman <[hidden email]> wrote:
>
> Here's the current draft:
>
> https://tools.ietf.org/html/draft-ietf-uta-mta-sts-14
>
> Having given it a quick read, I don't know that postfix needs to make any
> changes for this.  I believe it could be readily manged by an external policy
> server, which is, AIUI, the preferred approach.  See:
>
> http://www.postfix.org/SMTPD_POLICY_README.html

Unfortunately that will not work.  The policy service only applies to
inbound mail.  One can of course automate periodic SMTP TLS policy
updates from the STS URIs of a handful of providers, and let the
usual outbound TLS policy take care of the rest:

   http://www.postfix.org/TLS_README.html#client_tls_policy

For example (mode: testing, means there's little security from this
at present):

  $ curl https://mta-sts.gmail.com/.well-known/mta-sts.txt
  version: STSv1
  mode: testing
  mx: gmail-smtp-in.l.google.com
  mx: .gmail-smtp-in.l.google.com
  max_age: 86400

would translate (via a suitable cron job to update the table) into:

  tls-policy:
     gmail.com secure match=gmail-smtp-in.l.google.com:.gmail-smtp-in.l.google.com

assuming one also has something along the lines of:

  main.cf:
    indexed = ${default_database_type}:${config_directory}/
    smtp_tls_policy_maps = ${indexed}tls-policy
    smtp_tls_CApath = ... c_rehash'ed directory with usual WebPKI roots ...

and provided one is bold enough to ignore "testing" and just require
working TLS authentication.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: MTA-STS when?

Wietse Venema
Viktor Dukhovni:
> [...].  One can of course automate periodic SMTP TLS policy
> updates from the STS URIs of a handful of providers, and let the
> usual outbound TLS policy take care of the rest:
>
>    http://www.postfix.org/TLS_README.html#client_tls_policy

I'm much in favor of reusing the Postfix SMTP client's TLS policy
lookup mechanism for this, for example

    smtp_policy_maps = socketmap:inet:host:port:name

and to extend the policy map feature set as needed.

If the (key, value) interface turns out to be too restrictive, this
interface could be generalized towards something like the SMTP
server access policy delegation protocol (possibly with multiple
commands, multiple request attributes, or multiple reply attributes).

Like DKIM/DMARC I do not think that complex policies like STS should
be built into core Postfix SMTP components.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: MTA-STS when?

Jonathan Sélea



>> [...].  One can of course automate periodic SMTP TLS policy
>> updates from the STS URIs of a handful of providers, and let the
>> usual outbound TLS policy take care of the rest:
>>
>>    http://www.postfix.org/TLS_README.html#client_tls_policy
> I'm much in favor of reusing the Postfix SMTP client's TLS policy
> lookup mechanism for this, for example
>
>     smtp_policy_maps = socketmap:inet:host:port:name
>
> and to extend the policy map feature set as needed.
>
> If the (key, value) interface turns out to be too restrictive, this
> interface could be generalized towards something like the SMTP
> server access policy delegation protocol (possibly with multiple
> commands, multiple request attributes, or multiple reply attributes).
>
> Like DKIM/DMARC I do not think that complex policies like STS should
> be built into core Postfix SMTP components.
>
It sounds like it is a fairly "easy" implementation? If so, when can
expect a testing version for this?
I will gladly test this!

--
Jonathan


0x94B964DD.asc (20K) Download Attachment
smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MTA-STS when?

Viktor Dukhovni


> On Feb 19, 2018, at 1:43 PM, Jonathan Sélea <[hidden email]> wrote:
>
> It sounds like it is a fairly "easy" implementation? If so, when can
> expect a testing version for this?
> I will gladly test this!

Likely some time this year, but it is not entirely trivial, because
the spec requires a first successful delivery to "activate" the policy,
and expedited policy cache refresh on delivery failure.  Therefore,
there would need to be some sort of new feedback mechanism at delivery
completion.

Also the new "tlsrpt" draft solicits aggregated delivery failure stats,
which might also require similar feedback.

Cycles to work on this are not immediately available.  With so few
early adopters, and even Gmail in "testing", you might just build
manual policy that gets you secure transport to Gmail, Yahoo and
the other "free" email providers.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: MTA-STS when?

Jonathan Sélea

> Likely some time this year, but it is not entirely trivial, because
> the spec requires a first successful delivery to "activate" the policy,
> and expedited policy cache refresh on delivery failure.  Therefore,
> there would need to be some sort of new feedback mechanism at delivery
> completion.
>
> Also the new "tlsrpt" draft solicits aggregated delivery failure stats,
> which might also require similar feedback.
>
> Cycles to work on this are not immediately available.  With so few
> early adopters, and even Gmail in "testing", you might just build
> manual policy that gets you secure transport to Gmail, Yahoo and
> the other "free" email providers.
>
As always, the answers I get in this list is always straight forward and
informative.
Thank you very much!

--
Jonathan



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MTA-STS when?

Viktor Dukhovni


> On Feb 19, 2018, at 1:58 PM, Jonathan Sélea <[hidden email]> wrote:
>
>> Cycles to work on this are not immediately available.  With so few
>> early adopters, and even Gmail in "testing", you might just build
>> manual policy that gets you secure transport to Gmail, Yahoo and
>> the other "free" email providers.
>>
>
> As always, the answers I get in this list is always straight forward and
> informative.

Thanks.  Note that "by manual" I mean not-based on the missing STS support,
but still based on their published STS policy which you can map to a Postfix
TLS policy via a cron job that updates the data once a week or so.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: MTA-STS when?

Jonathan Sélea

> Thanks.  Note that "by manual" I mean not-based on the missing STS support,
> but still based on their published STS policy which you can map to a Postfix
> TLS policy via a cron job that updates the data once a week or so.
>

Fair enough :)
Looking forward to it!

--
Jonathan



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MTA-STS when?

Wietse Venema
In reply to this post by Jonathan Sélea
Jonathan S?lea:

> >> [...].  One can of course automate periodic SMTP TLS policy
> >> updates from the STS URIs of a handful of providers, and let the
> >> usual outbound TLS policy take care of the rest:
> >>
> >>    http://www.postfix.org/TLS_README.html#client_tls_policy
> > I'm much in favor of reusing the Postfix SMTP client's TLS policy
> > lookup mechanism for this, for example
> >
> >     smtp_policy_maps = socketmap:inet:host:port:name
> >
> > and to extend the policy map feature set as needed.
> >
> > If the (key, value) interface turns out to be too restrictive, this
> > interface could be generalized towards something like the SMTP
> > server access policy delegation protocol (possibly with multiple
> > commands, multiple request attributes, or multiple reply attributes).
> >
> > Like DKIM/DMARC I do not think that complex policies like STS should
> > be built into core Postfix SMTP components.
> >
>
> It sounds like it is a fairly "easy" implementation? If so, when can
> expect a testing version for this?

By my estimate this would involve multiple weeks of sustained effort
by a highly-skilled person. The elapsed time would be considerably
longer because Postfix maintainers have real jobs, don't take time
off to do work on the side, and STS development would compete with
other Postfix development. I would not even estimate the year of
completion.

The bulk of Postfix SMTPUTF8 support was done by a developer who
acquired sponsorship from CNNIC (I spent some time to make it nice).
If you have 10 grand lying around, maybe you can find someone.

> I will gladly test this!

Sure you will.

        Wietse