search

Snawoot / postfix-mta-sts-resolver

Daemon which provides TLS client policy for Postfix via socketmap, according to domain MTA-STS policy
MIT License
117 stars 23 forks source link

Postfix client TLS configuration problem when sending emails to google.com #66

Closed Frederick888 closed 4 years ago

Frederick888 commented 4 years ago

Describe the bug Postfix shows client TLS configuration problem when sending emails to google.com and postfix-mta-sts-resolver is enabled.

To Reproduce Steps to reproduce the behavior:

  1. Enable postfix-mta-sts-resolver
  2. Send an email to google.com
  3. Postfix shows client TLS configuration problem and emails are deferred

Expected behavior No errors.

Output listings Postfix configuration:

smtp_tls_CAfile =
smtp_tls_CApath = /etc/ssl/certs
smtpd_tls_CAfile =
smtpd_tls_CApath =
smtp_tls_policy_maps = socketmap:inet:127.0.0.1:8461:postfix

postfix-mta-sts-resolver (Docker) configuration:

host: 0.0.0.0
port: 8461
reuse_port: true
shutdown_timeout: 20
cache:
  type: redis
  options:
    address: "redis://172.17.0.1/1?timeout=5"
    minsize: 2
    maxsize: 25
default_zone:
  strict_testing: false
  timeout: 4

Postfix logs:

Jun 22 10:27:40 Fred-Linode postfix/smtp[28944]: warning: smtp_tls_policy_maps, next-hop destination "gmail.com": invalid attribute name: "servername"
Jun 22 10:27:40 Fred-Linode postfix/smtp[28944]: warning: TLS policy lookup for gmail.com/gmail-smtp-in.l.google.com: client TLS configuration problem
Jun 22 10:27:40 Fred-Linode postfix/smtp[28944]: warning: TLS policy lookup for gmail.com/gmail-smtp-in.l.google.com: client TLS configuration problem
Jun 22 10:27:40 Fred-Linode postfix/smtp[28944]: warning: smtp_tls_policy_maps, next-hop destination "gmail.com": invalid attribute name: "servername"
Jun 22 10:27:40 Fred-Linode postfix/smtp[28944]: warning: TLS policy lookup for gmail.com/alt1.gmail-smtp-in.l.google.com: client TLS configuration problem
Jun 22 10:27:40 Fred-Linode postfix/smtp[28944]: warning: TLS policy lookup for gmail.com/alt1.gmail-smtp-in.l.google.com: client TLS configuration problem
Jun 22 10:27:40 Fred-Linode postfix/smtp[28944]: warning: smtp_tls_policy_maps, next-hop destination "gmail.com": invalid attribute name: "servername"
Jun 22 10:27:40 Fred-Linode postfix/smtp[28944]: warning: TLS policy lookup for gmail.com/alt2.gmail-smtp-in.l.google.com: client TLS configuration problem
Jun 22 10:27:40 Fred-Linode postfix/smtp[28944]: 5DA2A181C5: to=<xxxx@gmail.com>, relay=none, delay=3.9, delays=0.76/0.01/3.2/0, dsn=4.7.5, status=deferred (client TLS configuration problem)

postfix-mta-sts-resolver logs:

2020-06-22 10:27:36 DEBUG    STS: len(self._children) = 1
2020-06-22 10:27:36 DEBUG    STS: Read: b'17:postfix gmail.com,'
2020-06-22 10:27:36 DEBUG    STS: Enq request: b'postfix gmail.com'
2020-06-22 10:27:36 DEBUG    STS: Got new future from queue
2020-06-22 10:27:36 DEBUG    STS: Lookup PERFORMED: domain = gmail.com
2020-06-22 10:27:36 DEBUG    RES: Got STS resolve request: sts_txt_domain=_mta-sts.gmail.com, known_id=20190429T010101
2020-06-22 10:27:40 DEBUG    RES: Parsed STS record for domain 'gmail.com': {'v': 'STSv1', 'id': '20190429T010101'}
2020-06-22 10:27:40 DEBUG    STS: Future await complete: data=b'90:OK secure match=.gmail-smtp-in.l.google.com:gmail-smtp-in.l.google.com servername=hostname,'
2020-06-22 10:27:40 DEBUG    STS: Wrote: b'90:OK secure match=.gmail-smtp-in.l.google.com:gmail-smtp-in.l.google.com servername=hostname,'
2020-06-22 10:27:40 DEBUG    STS: Read: b'17:postfix gmail.com,'
2020-06-22 10:27:40 DEBUG    STS: Enq request: b'postfix gmail.com'
2020-06-22 10:27:40 DEBUG    STS: Got new future from queue
2020-06-22 10:27:40 DEBUG    STS: Lookup skipped: domain = gmail.com
2020-06-22 10:27:40 DEBUG    STS: Future await complete: data=b'90:OK secure match=.gmail-smtp-in.l.google.com:gmail-smtp-in.l.google.com servername=hostname,'
2020-06-22 10:27:40 DEBUG    STS: Wrote: b'90:OK secure match=.gmail-smtp-in.l.google.com:gmail-smtp-in.l.google.com servername=hostname,'
2020-06-22 10:27:40 DEBUG    STS: Read: b'17:postfix gmail.com,'
2020-06-22 10:27:40 DEBUG    STS: Enq request: b'postfix gmail.com'
2020-06-22 10:27:40 DEBUG    STS: Got new future from queue
2020-06-22 10:27:40 DEBUG    STS: Lookup skipped: domain = gmail.com
2020-06-22 10:27:40 DEBUG    STS: Future await complete: data=b'90:OK secure match=.gmail-smtp-in.l.google.com:gmail-smtp-in.l.google.com servername=hostname,'
2020-06-22 10:27:40 DEBUG    STS: Wrote: b'90:OK secure match=.gmail-smtp-in.l.google.com:gmail-smtp-in.l.google.com servername=hostname,'
2020-06-22 10:27:50 DEBUG    STS: Client disconnected

Redis:

172.17.0.1:6379[1]> ZRANGE "google.com" 0 -1
1) "R\xc7\x11;T\xfcJ\x8c\xaa\xd5\xaa\x91\x0fx\x83\xc4[\"20190429T010101\", {\"mx\": [\"aspmx.l.google.com\", \"*.aspmx.l.google.com\"], \"version\": \"STSv1\", \"mode\": \"enforce\", \"max_age\": 86400}]"

Tests:

$ postmap -q dismail.de socketmap:inet:127.0.0.1:8461:postfix
secure match=mx1.dismail.de:mx2.dismail.de servername=hostname
$ postmap -q google.com socketmap:inet:127.0.0.1:8461:postfix
secure match=aspmx.l.google.com:.aspmx.l.google.com servername=hostname

Environment (please complete the following information):

Snawoot commented 4 years ago

Hello!

This is expected and documented behaviour.

Long story short: MTA-STS standard implies MTA has to support SNI. Otherwise there may be issues with TLS connectivity leading to permanent delivery failure to domains using multiple certificates on single MX address. Postfix prior to 3.4 doesn't support SNI at all. Postfix 3.4+ has SNI support, but doesn't send it by default. In order to comply with RFC 8461, postfix-mta-sts-resolver 1.0.0+ instructs Postfix 3.4+ to send server name indication with each returned valid STS policy.

This change was introduced in postfix-mta-sts-resolver version 1.0.0 and correct behaviour is enabled by default.

Only completely valid configuration for MTA-STS (from standards point of view) is Postfix 3.4+ and postfix-mta-sts-resolver 1.0.0 and above.

There are two ways for you to resolve this issue:

SNI requirement can be disabled in your mta-sts-daemon.yml with require_sni option like this:

--- a/mta-sts-daemon.yml
+++ b/mta-sts-daemon.yml
@@ -11,3 +11,4 @@ cache:
 default_zone:
   strict_testing: false
   timeout: 4
+  require_sni: false
Frederick888 commented 4 years ago

Ah, I was wondering why it suddenly started to fail. Thanks a lot for the quick response!

xcodxcod commented 3 years ago

Hi! I have same issue with gmail.com and mail.ru, but i added require_sni: false.

My environment:

Linux CentOS x64 7.9.2009 + last upd
Postfix 2.10.1 (postfix.x86_64 2:2.10.1-9.el7)

Installation method 4. Docker. Run:

docker run -d --security-opt no-new-privileges -v /etc/postfix/mta-sts-cfg.yml:/etc/mta-sta-daemon.yml -v mta-sts-cache:/var/lib/mta-sts -p 127.0.0.1:8461:8461 --restart unless-stopped --name postfix-mta-sts-resolver yarmak/postfix-mta-sts-resolver

/etc/postfix/mta-sts-cfg.yml

host: 0.0.0.0
port: 8461
reuse_port: true
shutdown_timeout: 20
cache:
  type: sqlite
  options:
    filename: "/var/lib/mta-sts/cache.db"
default_zone:
  strict_testing: false
  timeout: 4
  require_sni: false

Sorry my English...

Snawoot commented 3 years ago

Hi!

@xcodxcod

Please check if you are running latest version of docker image.

Please tell me output of following command:

/usr/sbin/postmap -q gmail.com  socketmap:inet:127.0.0.1:8461:test
xcodxcod commented 3 years ago

# docker images

REPOSITORY                        TAG                 IMAGE ID            CREATED             SIZE
yarmak/postfix-mta-sts-resolver   latest              cda7cbfb8cb5        6 months ago        72MB

/usr/sbin/postmap -q gmail.com socketmap:inet:127.0.0.1:8461:test secure match=gmail-smtp-in.l.google.com:.gmail-smtp-in.l.google.com servername=hostname

Snawoot commented 3 years ago

@xcodxcod

Thanks! You have typo in your docker command: /etc/mta-sta-daemon.yml. Correct option will look like this: -v /etc/postfix/mta-sts-cfg.yml:/etc/mta-sts-daemon.yml