[pfx] Re: mta-sts and smtp_tls_security_level

On Sat, Mar 09, 2024 at 07:21:53PM +0100, Joachim Lindenberg via Postfix-users wrote: > I thought almost all cloud providers use anycast these days, > elminating the need to serve different IPs per region. No. That's not the case. Anycast is a useful tool, but isn't the whole story. The

[pfx] Re: mta-sts and smtp_tls_security_level

I thought almost all cloud providers use anycast these days, elminating the need to serve different IPs per region. Joachim -Ursprüngliche Nachricht- Von: Viktor Dukhovni via Postfix-users Gesendet: Samstag, 9. März 2024 18:42 An: postfix-users@postfix.org Betreff: [pfx] Re: mta-sts

[pfx] Re: mta-sts and smtp_tls_security_level

On Sat, Mar 09, 2024 at 10:46:17AM +0100, Joachim Lindenberg via Postfix-users wrote: > > Viktor Dukhovni: > > not sufficient market pressure to make it a priority. > Unfortunately yes, not yet. > > various load balancers would need to do online DNSSEC signing > Can you please elaborate why that

[pfx] Re: mta-sts and smtp_tls_security_level

> Viktor Dukhovni: > not sufficient market pressure to make it a priority. Unfortunately yes, not yet. > various load balancers would need to do online DNSSEC signing Can you please elaborate why that should be required? Thanks, Joachim ___

[pfx] Re: mta-sts and smtp_tls_security_level

scale is non-trivial, (various load balancers would need to do online DNSSEC signing) and resources for work that is not a business priority are scarce. I can more easily see "gmail.com" being signed, but even there the incentives need to get stronger before that happens. Yes, mta-sts

[pfx] Re: mta-sts and smtp_tls_security_level

But is there any reason that prevents google to use DNSSEC other than the arrogance of power? Imho it is obvious that mta-sts is only useful for big players that prefer to ignore destinations not in their cache. For the rest of us, mta-sts is inferior to smtp-dane. Joachim -Ursprüngliche

[pfx] Re: mta-sts and smtp_tls_security_level

On Fri, Mar 08, 2024 at 10:01:29PM +0100, Joachim Lindenberg via Postfix-users wrote: > Imho you get pretty close to mta-sts if you use verify together with a > DNSSEC-validating resolver. You just validate the "authorized" MTAs by > different means. Yes, but googl

[pfx] Re: mta-sts and smtp_tls_security_level

Imho you get pretty close to mta-sts if you use verify together with a DNSSEC-validating resolver. You just validate the "authorized" MTAs by different means. I still think SMTP-DANE (RFC 7672) is preferrable. Regards, Joachim -Ursprüngliche Nachricht- Von: Michael W. Lucas v

[pfx] Re: mta-sts and smtp_tls_security_level

On Fri, Mar 08, 2024 at 03:05:43PM -0500, Viktor Dukhovni via Postfix-users wrote: > On Fri, Mar 08, 2024 at 01:28:00PM -0500, Michael W. Lucas via Postfix-users > wrote: > > > Realistically, Gmail and Yahoo do not care about my MTA-STS > > reports. All they care abo

[pfx] Re: mta-sts and smtp_tls_security_level

On Fri, Mar 08, 2024 at 01:28:00PM -0500, Michael W. Lucas via Postfix-users wrote: > Realistically, Gmail and Yahoo do not care about my MTA-STS > reports. All they care about is that I validate their X.509 certs. > > Is there any reason to use something like mta-sts-daemon in that

[pfx] mta-sts and smtp_tls_security_level

Hi, Pondering MTA-STS validation. My understanding is the recommendation is to use DANE as the default (smtp_tls_security_level=dane), but if you want MTA-STS for select domains you can point them at a transport that requires X.509 validation. Realistically, Gmail and Yahoo do not care about my

[pfx] Re: [CERT-Bund#2023092728001552] Vulnerability report regarding postfix and postfix-mta-sts-resolver

I am the main Postfix author. At this time, there is no MTA-STS support in the software that is distributed by the Postfix project. The postfix-mta-sts-resolver software is a third-party extension that is developed and maintained separately from Postfix. I suggest that you contact their authors

[pfx] Re: TLS client policy according to domain MTA-STS policy

A more quick and dirty option is to configure transport policy "verify" for any mta-sts destinations (I am doing this in a script). That doesn´t really check the mx one connects to are enumerated, but at least the certificate validation part of mta-sts will prevent connections to

[pfx] Re: TLS client policy according to domain MTA-STS policy

On Wed, May 24, 2023 at 02:25:38PM +0200, Paul Menzel via Postfix-users wrote: > Running the *Public Email & DNS Testbed* [1], I was reminded, that we > have MTA-STS set up, but do not take the MTAT-STS policy of other > domains into account. > > As a solution I found *postf

[pfx] TLS client policy according to domain MTA-STS policy

Dear Postfix folks, Running the *Public Email & DNS Testbed* [1], I was reminded, that we have MTA-STS set up, but do not take the MTAT-STS policy of other domains into account. As a solution I found *postfix-mta-sts-resolver* [2], which warns about a “RFC violation” [3]: ### War

Re: AW: MTA-STS implementation

- Message from Joachim Lindenberg - Date: Fri, 26 Aug 2022 17:00:32 +0200 From: Joachim Lindenberg Subject: AW: MTA-STS implementation To: postfix-users@postfix.org I definitely suggest to look into RFC 7672 SMTP-DANE instead of MTA-STS. SMTP-DANE is more secure than

AW: MTA-STS implementation

I definitely suggest to look into RFC 7672 SMTP-DANE instead of MTA-STS. SMTP-DANE is more secure than MTA-STS, and in my "samples" also more widely adopted than MTA-STS. In my view, MTA-STS is only interesting if you do not want to adopt DNSSEC. Postfix supports DANE out of the bo

Re: MTA-STS implementation

On 08-26-2022 10:08 am, Paul Kingsnorth wrote: MTA-STS seems to be getting more widespread. I wondered how many people are using the postfix-mta-sts-resolver from Snawoot, and whether there are any standout good/bad features of it? Or whether there are any other ways of implementing MTA-STS

MTA-STS implementation

MTA-STS seems to be getting more widespread. I wondered how many people are using the postfix-mta-sts-resolver from Snawoot, and whether there are any standout good/bad features of it? Or whether there are any other ways of implementing MTA-STS with postfix? Paul

Re: off-topic mta-sts/office.com question

.317 Message expired, cannot connect to remote > > > server(451 4.7.5 Remote certificate MUST have a subject alternative name > > > matching the hostname (MTA-STS))' > > > 4/30/2022 11:59:28 PM - Server at libslack.org (82.134.31.111) > > > returned '450 4.4.3

Re: off-topic mta-sts/office.com question

01.prod.outlook.com > > > > r...@libslack.org > > 5/1/2022 12:09:32 AM - Server at ME3PR01MB8390.ausprd01.prod.outlook.com > > returned '550 5.4.317 Message expired, cannot connect to remote > > server(451 4.7.5 Remote certificate MUST have a subject alternative name

off-topic mta-sts/office.com question

for a bunch of domains. For testing, I've made it the only MX server for one of my spare domains, and sent an email to there from an account at outlook.office.com. For this test, I remembered to add the new server to the list of mx records that MTA-STS knows about. I probably should have removed

Re: DANE, MTA-STS and TLS-RPT

On Tue, Mar 22, 2022 at 01:41:48PM +0100, Damian wrote: > I am looking for input how to implement a DANE- and MTA-STS-capable > Postfix setup which is able to produce SMTP TLS reports (RFC8460). The simplest approach is to just manually configure static TLS policies of "secure"

DANE, MTA-STS and TLS-RPT

I am looking for input how to implement a DANE- and MTA-STS-capable Postfix setup which is able to produce SMTP TLS reports (RFC8460). Right now I see several obstacles. There is postfix-mta-sts-resolver [1], and my first reflex was to use it with smtp_tls_policy_maps as documented, and fall

Re: mta-sts - main.cf - no trusted TLC Connection string appair

On Tue, Apr 20, 2021 at 09:34:05AM +0200, Maurizio Caloro wrote: > # mta-sts > smtpd_policy_maps = socketmap:inet:127.0.0.1:8461:postfix The smtpd(8) policy service filters incoming traffic, it has nothing to do with outgoing TLS policy. > /etc/ # postmap -q caloro.ch socketmap:inet:

Re: mta-sts - main.cf - no trusted TLC Connection string appair

Maurizio Caloro: > i was thinking that any of this need to appair inside mail.log > > ->Trusted TLS connection established > ->Verified TLS connection established In the client log? Server log? Why?

mta-sts - main.cf - no trusted TLC Connection string appair

Postfix 3.4.14 - Debain 10 main.cf [snip] # SMTP from other servers to yours disable_vrfy_command = yes smtpd_delay_reject = yes smtpd_helo_required = yes # mta-sts smtpd_policy_maps = socketmap:inet:127.0.0.1:8461:postfix - # netstat | grep 8461 tcp 127.0.0.1:8461

Re: AW: AW: mta-sts service, running, but how do see this?

to postfix 3.1. It looks like: Go to  https://github.com/Snawoot/postfix-mta-sts-resolver/tree/master/postfix _mta_sts_resolver and click on sni: make default and add compatibility notice on the line of  defaults.py --  Marcel de Riedmatten

Re: AW: AW: mta-sts service, running, but how do see this?

Maurizio Caloro: > Wietse Venema: > > Maurizio Caloro: > >> > Oct 2 15:54:27 nmail postfix/smtp[30568]: warning: > >> > smtp_tls_policy_maps, next-hop destination "gmail.com": invalid > attribute name: "servername" > >> > >> Attribute name 'servername' requires Postfix 3.4 or later. > >> >

AW: AW: mta-sts service, running, but how do see this?

Wietse Venema: > Maurizio Caloro: >> > Oct 2 15:54:27 nmail postfix/smtp[30568]: warning: >> > smtp_tls_policy_maps, next-hop destination "gmail.com": invalid attribute name: "servername" >> >> Attribute name 'servername' requires Postfix 3.4 or later. >> >>'servername' is used for SNI. It

AW: AW: mta-sts service, running, but how do see this?

Wietse Venema: > Maurizio Caloro: >> > Oct 2 15:54:27 nmail postfix/smtp[30568]: warning: >> > smtp_tls_policy_maps, next-hop destination "gmail.com": invalid attribute name: "servername" >> >> Attribute name 'servername' requires Postfix 3.4 or later. >> >>'servername' is used for SNI. It

Re: AW: mta-sts service, running, but how do see this?

Wietse Venema: > Maurizio Caloro: > > Oct 2 15:54:27 nmail postfix/smtp[30568]: warning: smtp_tls_policy_maps, > > next-hop destination "gmail.com": invalid attribute name: "servername" > > Attribute name 'servername' requires Postfix 3.4 or later. 'servername' is used for SNI. It ensures that

Re: AW: mta-sts service, running, but how do see this?

Maurizio Caloro: > Oct 2 15:54:27 nmail postfix/smtp[30568]: warning: smtp_tls_policy_maps, > next-hop destination "gmail.com": invalid attribute name: "servername" Attribute name 'servername' requires Postfix 3.4 or later. Wietse

AW: mta-sts service, running, but how do see this?

>systemctl restart postfix.service >If everything is done correctly, then for STS connections in the /var/log/mail.info log instead > >root@r:/var/log# cat mail.info | grep mta-sts root@r:/var/log# If i try to send any Email to gmail domain, then gmail will support and check mta-s

AW: mta-sts service, running, but how do see this?

>> Installing the postfix-mta-sts service, and on my view this will running >> now, but how i can check this, if this service are running up and correct? >Where does this postfix-mta-sts service logs its activities? > Wietse systemctl restart postfix.service If

Re: mta-sts service, running, but how do see this?

Maurizio Caloro: > Hello together > > Installing the postfix-mta-sts service, and on my view this will running > now, > > but how i can check this, if this service are running up and correct? Where does this postfix-mta-sts service logs its activities? Wietse

mta-sts service, running, but how do see this?

Hello together Installing the postfix-mta-sts service, and on my view this will running now, but how i can check this, if this service are running up and correct? after watching mail.log i dont see nothing more then else Main.cf smtp_tls_policy_maps = socketmap:inet:127.0.0.1:8461

Re: MTA-STS <-> DANE Interactions

Thanks for the thorough review (would be cool to add the stats to your stats page, presuming you have the time!). Right, my plan is just to continue enforcing TLS for google/gmail domains and not bother with MTA-STS unless more domains follow the Google anti-DNSSEC cargo cult going forward

Re: MTA-STS <-> DANE Interactions

On Sat, Jul 04, 2020 at 05:45:18PM -0400, Viktor Dukhovni wrote: > On Sat, Jul 04, 2020 at 04:35:01PM -0400, Matt Corallo wrote: > > > Right, I figured they were from your stats, but figured I'd ask since > > I never saw any MTA-STS data on your site :) > > We don't

Re: MTA-STS <-> DANE Interactions

On Sat, Jul 04, 2020 at 04:35:01PM -0400, Matt Corallo wrote: > Right, I figured they were from your stats, but figured I'd ask since > I never saw any MTA-STS data on your site :) We don't presently track MTA-STS numbers. They're easy enough to collect on an ad-hoc basis. Speaking of

Re: MTA-STS <-> DANE Interactions

Right, I figured they were from your stats, but figured I'd ask since I never saw any MTA-STS data on your site :) Anyway, I'm happy I didn't misunderstand the state of things, at least. Looking forward to getting a "secure-but-also-dane" option in smtp_tls_policy_maps eventually :)

Re: MTA-STS <-> DANE Interactions

loys DANE for inbound (at least so they claim), at which point a > substantial volume of mail will hit this. The customer domains opting-in to DANE on Microsoft's cloud platform will not quickly alter the landscape. And quite possibly not all of them will also enable MTA-STS. > Of course bu

Re: MTA-STS <-> DANE Interactions

today it’ll be 2021 at least (thanks Debian, Redhat, et al). Matt > On Jul 4, 2020, at 12:21, Viktor Dukhovni wrote: > > On Sat, Jul 04, 2020 at 02:34:15PM -0400, Matt Corallo wrote: > >> Thanks for the response, will see if it makes sense to at least disable >> MTA-STS

Re: MTA-STS <-> DANE Interactions

On Sat, Jul 04, 2020 at 02:34:15PM -0400, Matt Corallo wrote: > Thanks for the response, will see if it makes sense to at least disable > MTA-STS for DANE-enabled domains at > https://github.com/Snawoot/postfix-mta-sts-resolver/issues/67. I don't think that's presently warranted. Ther

Re: MTA-STS <-> DANE Interactions

Thanks for the response, will see if it makes sense to at least disable MTA-STS for DANE-enabled domains at https://github.com/Snawoot/postfix-mta-sts-resolver/issues/67. On 7/4/20 2:10 PM, Viktor Dukhovni wrote: > On Sat, Jul 04, 2020 at 01:54:14PM -0400, Matt Corallo wrote: > >&

Re: MTA-STS <-> DANE Interactions

On Sat, Jul 04, 2020 at 01:54:14PM -0400, Matt Corallo wrote: > The only reference google appears to find on this list to MTA-STS indicates > that folks should use an external MTA-STS > resolver as a part of smtp_tls_policy_maps (the one by Snawoot on GitHub > appears to be goo

MTA-STS <-> DANE Interactions

The only reference google appears to find on this list to MTA-STS indicates that folks should use an external MTA-STS resolver as a part of smtp_tls_policy_maps (the one by Snawoot on GitHub appears to be good). Sadly, I don't believe its possible to properly capture the DANE/MTA-STS interaction

Re: MTA-STS?

David Mehler: > Hello, > > I just heard about this and started reading on it. Is MTA-STS > something Postfix works with? https://www.google.com/search?q=postfix+mta-sts This uses the Postfix's smtp_tls_policy_maps plugin. Wietse

Re: MTA-STS?

On Tuesday, April 7, 2020 11:15:27 AM EDT David Mehler wrote: > Hello, > > I just heard about this and started reading on it. Is MTA-STS > something Postfix works with? You need https://github.com/Snawoot/postfix-mta-sts-resolver and then yes. Scott K

MTA-STS?

Hello, I just heard about this and started reading on it. Is MTA-STS something Postfix works with? Thanks. Dave.

Re: Respecting MTA-STS

On Fri, Oct 11, 2019 at 02:17:16PM -0400, Viktor Dukhovni wrote: > > that Gmail enabled SNI on their SMTP client is an indicator that using SNI > > may not cause relevant trouble. But it's also known, Gmail is able to do > > such stuff very selective to prevent damage. > > Indeed I am not

Re: Respecting MTA-STS

On Fri, Oct 11, 2019 at 08:02:32PM +0200, A. Schulze wrote: > that Gmail enabled SNI on their SMTP client is an indicator that using SNI > may not cause relevant trouble. But it's also known, Gmail is able to do > such stuff very selective to prevent damage. Indeed I am not presently able to

Re: Respecting MTA-STS

Am 11.10.19 um 18:10 schrieb Viktor Dukhovni: > So likely at this point it is safe to conclude that sending SNI is > unlikely to cause problems. Your mileage may vary. Hi, that Gmail enabled SNI on their SMTP client is an indicator that using SNI may not cause relevant trouble. But it's

Re: Respecting MTA-STS

a good 'gamification' site that people use that could be > convinced to add this check? FWIW, I just sent my system a message from a Gmail account, with a tcpdump capture running to record inbound SMTP traffic. My system does not advertise MTA-STS, and, AFAIK, Gmail does not support outbound

Re: Respecting MTA-STS

Viktor Dukhovni writes: >> On Oct 11, 2019, at 10:19 AM, micah anderson wrote: >> >> I am aware of that, but I'm not asking specifically how to implement >> this, I'm more trying to find out what really is the concern here with >> enabling this, and what we need to do to fix that. > > The

Re: Respecting MTA-STS

, we don't know what remote MTAs will do if they receive an unexpected SNI. You can try it I guess, and see what happens. One way to hedge your bets is to use the "servername" field in per-destination TLS policies, but otherwise leave SNI disabled. Since you probably need a policy service

Re: Respecting MTA-STS

"A. Schulze" writes: > micah anderson: > >> If we want to try and respect MTA-STS, when doing STARTTLS, the sender >> needs to send the right information in the TLS SNI (Server Name >> Inidication) extension. An MTA-STS-honoring SMTP client expects to

Re: Respecting MTA-STS

micah anderson: If we want to try and respect MTA-STS, when doing STARTTLS, the sender needs to send the right information in the TLS SNI (Server Name Inidication) extension. An MTA-STS-honoring SMTP client expects to validate the X.509 certificate of the receiving MTA, but that MTA might

Respecting MTA-STS

If we want to try and respect MTA-STS, when doing STARTTLS, the sender needs to send the right information in the TLS SNI (Server Name Inidication) extension. An MTA-STS-honoring SMTP client expects to validate the X.509 certificate of the receiving MTA, but that MTA might be known by a dozen

Re: postfix and MTA-STS

Viktor Dukhovni: > The socketmap service could check for DANE TLSA records first, > and return "dane", it would have to check that the domain is > DNSSEC signed, and then check whether all of (the first 10 by > preference to reduce delay) the MX hosts have TLSA records. A. Schulze: > That mean

Re: postfix and MTA-STS

> Adding the full trust store is largely harmless, unless your goal > is to "harden" MTA-STS by trusting only the subset of CAs actually > used in practice by "real" MTA-STS domains. sounds reasonable, will think about that... Andreas

Re: postfix and MTA-STS

On Sat, Apr 27, 2019 at 08:09:51PM +0200, A. Schulze wrote: > one way to implement MTA-STS in postfix is a server that generate responses > that smtp_tls_policy_maps can consume. I evaluate > https://github.com/Snawoot/postfix-mta-sts-resolver... > > smtp_tls_policy_maps = soc

Re: postfix and MTA-STS

Perhaps you could allow the Postfix SMTP client to have access to the PKI store, and let that SMTP client use DANE certificate verification for some domains, and PKI for others. Wietse

postfix and MTA-STS

Hello, one way to implement MTA-STS in postfix is a server that generate responses that smtp_tls_policy_maps can consume. I evaluate https://github.com/Snawoot/postfix-mta-sts-resolver... smtp_tls_policy_maps = socketmap:inet:mta-sts-resolver.example:8461:postfix this works, but ... the MTA

Re: MTA-STS when?

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

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

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:

Re: MTA-STS when?

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

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

Re: MTA-STS when?

> 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

Re: MTA-STS when?

> On Feb 19, 2018, at 1:58 PM, Jonathan Sélea 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

Re: MTA-STS when?

> 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 >

Re: MTA-STS when?

> On Feb 19, 2018, at 1:43 PM, Jonathan Sélea 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

Re: MTA-STS when?

>> [...]. 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

Re: MTA-STS when?

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

Re: MTA-STS when?

> On Feb 17, 2018, at 2:35 PM, Scott Kitterman <post...@kitterman.com> 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

Re: MTA-STS when?

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 M

MTA-STS when?

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

Re: [Uta] STS and SNI (was Re: Interaction between MTA-STS and DANE)

> On Oct 27, 2017, at 12:39 PM, Alberto Bertogli > wrote: > > > So to me you are arguing to add a non trivial amount of complexity to > certificate validation, and make it differ significantly from widely > used and tested logic; in exchange for making it easier for

Re: [Uta] Interaction between MTA-STS and DANE

> On Oct 23, 2017, at 12:17 PM, Ivan Ristic wrote: > > Not in practice. If you're not using vanity MX, it's obvious where the email > is going. Actually (ignoring for the moment the clear-text DNS query leak, which DNSPRIV is supposed to address) the opposite is true.