MTA-STS when?

classic Classic list List threaded Threaded
14 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
Reply | Threaded
Open this post in threaded view
|

Re: MTA-STS when?

yarmak
In reply to this post by Jonathan Sélea
I have implemented such policy server: it lookups MTA-STS policy, caches and
updates it as RFC 8461 defines.

Github: https://github.com/Snawoot/postfix-mta-sts-resolver
PyPI: https://pypi.org/project/postfix-mta-sts-resolver/

Daemon lacks some features required by standard like proactive policy fetch,
reporting and ratelimit, but it serves its main purpose - TLS policy
discovery. I use it for my personal mailserver. Hope it'll be useful for
someone.




--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Reply | Threaded
Open this post in threaded view
|

Getting quotes for MTA-STS implementation (was: MTA-STS when?)

Paul Menzel
In reply to this post by Wietse Venema
Dear Postfix folks,


On 02/19/18 20:11, Wietse Venema wrote:

> 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.
$10.000 doesn’t seem a lot judging from all the companies and
organizations using Postfix in their critical infrastructure.

Are Postfix developers and companies listed somewhere, which could
give a quote for the implementation?

If not, could interested people please reply with their contact
detail?


Kind regards,

Paul


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MTA-STS when?

Wietse Venema
In reply to this post by yarmak
yarmak:

> I have implemented such policy server: it lookups MTA-STS policy, caches and
> updates it as RFC 8461 defines.
>
> Github: https://github.com/Snawoot/postfix-mta-sts-resolver
> PyPI: https://pypi.org/project/postfix-mta-sts-resolver/
>
> Daemon lacks some features required by standard like proactive policy fetch,
> reporting and ratelimit, but it serves its main purpose - TLS policy
> discovery. I use it for my personal mailserver. Hope it'll be useful for
> someone.

This may be a good start. Thanks.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Getting quotes for MTA-STS implementation (was: MTA-STS when?)

Wietse Venema
In reply to this post by Paul Menzel
Paul Menzel:

> Dear Postfix folks,
>
>
> On 02/19/18 20:11, Wietse Venema wrote:
> > 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.
>
> $10.000 doesn?t seem a lot judging from all the companies and
> organizations using Postfix in their critical infrastructure.
>
> Are Postfix developers and companies listed somewhere, which could
> give a quote for the implementation?

The two developers are fully employed and can't take money; if
someone can provide a viable design, then I think that we would
consider it. This could be hashed out on the postfix-devel list.

> If not, could interested people please reply with their contact
> detail?

        Wietse