snawoot / postfix-mta-sts-resolver Goto Github PK

Is your feature request related to a problem? Please describe.
From the docs of v2: As of December, 2019, this library had been abandoned

v2 started hitting repos of rolling release distros (e.g. Archlinux) a while ago. I'd prefer to install that instead of an outdated and unmaintained version from two years ago which conflicts with the current version unless docker or pyenv is used.

Describe the solution you'd like
make a clear brake and adapt to new aioredis API

Describe alternatives you've considered
support both aioredis versions

Additional context
I've managed to do the necessary changes in redis_cache.py. Please let me what solution is preferred so that I may prepare a pull request.

I came across some traces of a CERT-Bund vulnerability report:

From postfix-devel  Tue Oct 24 11:58:20 2023
From: Wietse Venema via Postfix-devel <postfix-devel () postfix ! org>
Date: Tue, 24 Oct 2023 11:58:20 +0000
To: postfix-devel
Subject: [pfx-dev] Re: [CERT-Bund#2023092728001552] Vulnerability report regarding postfix and postfix-mta-sts-resolver
Message-Id: <4SF9cx74KKzJrP1 () spike ! porcupine ! org>
X-MARC-Message: https://marc.info/?l=postfix-devel&m=169814870008296

see also:

• https://marc.info/?t=169814871600002&r=1&w=2
• https://www.mail-archive.com/[email protected]/msg01148.html

Since I found nothing in the issues/pull-requests tracker/readme I'm wondering whether they managed to contact you and whether current postfix-meta-sts-resolver is vulnerable (if it was a valid report, in the first place).

Describe the bug
I installed mta-sts-daemon with sudo python3 -m pip install postfix-mta-sts-resolver[redis] and installed the systemd files.

If i run mta-sts-daemon on command line i get:

2022-05-30 20:28:25 INFO MAIN: MTA-STS daemon starting...
2022-05-30 20:28:25 INFO MAIN: Starting eventloop...
2022-05-30 20:28:25 INFO MAIN: uvloop enabled.
2022-05-30 20:28:25 INFO MAIN: Eventloop started.
Traceback (most recent call last):
File "/usr/local/bin/mta-sts-daemon", line 10, in
sys.exit(main())
File "/usr/local/lib/python3.7/dist-packages/postfix_mta_sts_resolver/daemon.py", line 123, in main
evloop.run_until_complete(amain(cfg, evloop))
File "uvloop/loop.pyx", line 1448, in uvloop.loop.Loop.run_until_complete
File "/usr/local/lib/python3.7/dist-packages/postfix_mta_sts_resolver/daemon.py", line 65, in amain
await cache.setup()
File "/usr/local/lib/python3.7/dist-packages/postfix_mta_sts_resolver/redis_cache.py", line 38, in setup
url = self._opts['url']
KeyError: 'url'

Expected behavior
I expected no crash ;)

Environment (please complete the following information):

• OS: Linux
• Distro: Debian
• Distro version: Buster (10)
• Python version: 3.7

Is your feature request related to a problem? Please describe.

By default the socket is created with the permissions 0o755 on my system and postfix won't be able to connect since it runs as a different user. Putting the postfix user in the mta-sts group won't help either.

Describe the solution you'd like

I'd be nice to be able to configure the permissions via the config file.

Describe alternatives you've considered

For now I've added ExecStartPost=/usr/bin/chmod 666 socketfd to the systemd unit file. This works, but you have to configure the socket twice, once in the config, once in the systemd file.

Is your feature request related to a problem? Please describe.
We would like to be able to connect to Redis sentinel cluster that we are already have in place for rspamd. But it looks like this is currently not implemented/supported. (Please correct me if I am wrong).

Describe the solution you'd like
The option to discover the current (r/w) master instance of Redis. It looks like this is possible using the library already in use. https://aioredis.readthedocs.io/en/latest/api/high-level/#aioredis.client maybe implemented via an alternative connection string.

Describe alternatives you've considered
At the moment, we can absolutely live with a single redis instance or sqlite for the cache, but still would be nice to have this.

Additional context
thanks for this project and your work!

Is your feature request related to a problem? Please describe.
systemd is only available on GNU/Linux systems, but users of other kernels / operating systems (e.g. FreeBSD) might still get benefits from this software.

Describe the solution you'd like
The sdnotify dependency added in #16 is unconditional: if sdnotify cannot be used, the daemon will not run. Making this an optional dependency would allow to run the software on FreeBSD unpatched.

Thanks !

There is a bug in Postfix 3.4+ which makes Postfix unable to load the key+cert+chain.

Make sure you have smtpd_tls_eecdh_grade in it's default value auto or you have Postfix version which contains fix for this bug.

Describe the bug
In 1.1.0 TypeError occurred.

To Reproduce
Steps to reproduce the behavior:

1. pip install postfix-mta-sts-resolver[redis,sqlite]
2. mta-sts-daemon --config $HOME/daemon.yml --logfile $HOME/logs/daemon.log

Expected behavior
Run successfully.

Output listings

Traceback (most recent call last):
  File "/srv/mta-sts/.pyenv/versions/3.9.9/bin/mta-sts-daemon", line 8, in <module>
    sys.exit(main())
  File "/srv/mta-sts/.pyenv/versions/3.9.9/lib/python3.9/site-packages/postfix_mta_sts_resolver/daemon.py", line 123, in main
    evloop.run_until_complete(amain(cfg, evloop))
  File "uvloop/loop.pyx", line 1501, in uvloop.loop.Loop.run_until_complete
  File "/srv/mta-sts/.pyenv/versions/3.9.9/lib/python3.9/site-packages/postfix_mta_sts_resolver/daemon.py", line 65, in amain
    await cache.setup()
import json
import uuid
  File "/srv/mta-sts/.pyenv/versions/3.9.9/lib/python3.9/site-packages/postfix_mta_sts_resolver/redis_cache.py", line 39, in setup
    self._pool = await aioredis.from_url(**self._opts)
TypeError: from_url() missing 1 required positional argument: 'url'

Environment (please complete the following information):

• OS: GNU/Linux
• Distro: Debian
• Distro version: 11.1
• Python version: 3.9.9

Additional context

• daemon.yml

host: 127.0.0.1
port: 8461
reuse_port: true
shutdown_timeout: 20
proactive_policy_fetching:
  enabled: true
cache:
  type: redis
  options:
    address: "redis://127.0.0.1:6379/5?timeout=5"
    minsize: 5
    maxsize: 25
default_zone:
  strict_testing: false
  timeout: 4
zones:
  mail-services.net:
    strict_testing: false
    timeout: 4

• Fixed?
  I add a line to add url argument, it seems good...?

--- redis_cache.py.orig	2021-12-18 14:22:14.674578264 +0900
+++ redis_cache.py	2021-12-18 14:21:50.126583375 +0900
@@ -35,7 +35,8 @@
         self._pool = None

     async def setup(self):
-        self._pool = await aioredis.from_url(**self._opts)
+        url = self._opts['address']
+        self._pool = await aioredis.from_url(url, **self._opts)

     async def get(self, key):
         assert self._pool is not None

Is this correct?

Describe the bug
When a client is configured to use a smarthost/relay/relayhost for its mail delivery, the policy lookup (and validation) is not initiated.

To Reproduce
Steps to reproduce the behavior:

1. configure postfix to use a relay (example config line in main.cf: relayhost = [myrelayhost.example.com]:123)
2. attempt to send a valid email to someone/somewhere
3. mail.log says Trusted TLS connection established (but not Verified as it should be) and there are no logs in mta-sts.log to signify a lookup on a domain for policies.

Expected behavior
The proposed MTA-STS standard (RFC 8461) section 3.4. Policy Selection for Smart Hosts and Subdomainsin section (link) states:

When sending mail via a "smart host" -- an administratively configured intermediate SMTP relay, which is different from the message recipient's server as determined from DNS -- compliant senders MUST treat the smart host domain as the Policy Domain for the purposes of policy discovery and application.

My understanding is that there should be a policy lookup and validation for the example.com domain in this case.

Note: had the configuration been without the brackets (like relayhost = myrelayhost.example.com:123), I would expect for myrelayhost.example.com to be looked up and validated (since myrelayhost isn't really a host then but rather a subdomain due to the allowed MX lookups from the absence of []).

Output listings
mta-sts.log:
STS: Enq request: b'postfix [myrelayhost.example.com]:123'

Environment (please complete the following information):

• OS: Linux
• Distro: Ubuntu
• Distro version: 18.04.3 LTS
• Python version: 3.6.9

Additional context
I found the short-circuit code responsible for this behaviour here: link. If I hack around this (extract the host's domain), the TLS connection shows as verified and the lookups & validations are done as expected.

P.S. Thank you for the work put into this project!

As far as I know, most people run at the smtp_tls_security_level = may, and some at dane. As far as I know, that will never result in a "Trusted TLS connection established to" message. I get Untrusted and Anonymous connections, and Verified for the DANE enabled domains. Could you please update README.md to not suggest that people should already get Trusted connections?

Describe the bug
mta-sts-query documentation mentions verbosity, but it's not implemented

client's ArgParse setup lacks -v, but daemon's clearly has it.

and using docker to run the client, -h output shows that -v is not implemented.

# docker exec postfix-mta-sts-resolver mta-sts-query -h
usage: mta-sts-query [-h] domain [known_version]

positional arguments:
  domain         domain to fetch MTA-STS policy from
  known_version  latest known version (default: None)

optional arguments:
  -h, --help     show this help message and exit

Probably the docs should be fixed first, and later the client could be enhanced to support debug logging.

Sending mail to Google
It is not possible with mta-sts to send mail to Google, it is remaining in the mail queue.

To Reproduce

1. Redis enabled MTA-STS installed using method 2 including Redis: postfix-mta-sts-resolver (1.0.1)
2. Postfix mail_version = 3.3.0
3. /usr/sbin/postmap -q gmail.com socketmap:inet:127.0.0.1:8461:postfix

secure match=.gmail-smtp-in.l.google.com:gmail-smtp-in.l.google.com servername=hostname

Expected behavior
It works with MS/Outlook but not with Google (see Output)

Output listings

1. maillog

Steps to reproduce the behavior:
Oct 17 20:55:42 smtp.<myserver>.com postfix/smtp[22718]: warning: smtp_tls_policy_maps, next-hop destination "gmail.com": invalid attribute name: "servername"
Oct 17 20:55:42 smtp.<myserver>.com postfix/smtp[22718]: warning: TLS policy lookup for gmail.com/gmail-smtp-in.l.google.com: client TLS configuration problem

2. mta-sts.log

2021-10-17 20:55:42 DEBUG    STS: Lookup skipped: domain = gmail.com
2021-10-17 20:55:42 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,'
2021-10-17 20:55:42 DEBUG    STS: Wrote: b'90:OK secure match=gmail-smtp-in.l.google.com:.gmail-smtp-in.l.google.com servername=hostname,'

Environment (please complete the following information):

• OS: [GNU/Linux]
• Distro: [Ubuntu]
• Distro version: [18.04.6]
• Python version: [3.6.9]

shuttdown_timeout is currently not documented.

Adding adding a description of the shutdown_timeout parameter would be helpful complete the documentation.

I just installed Sendmail 8.17.2 and postfix-mta-sts-resolver . I want to verity my setup, by sending to a site, which announces MTA-STS support but does not offer STARTTLS. The only site I found was https://mtasts.xyz/ , however its policy cannot be fetched, as the certificate for the web and smtp servers are expired. As such the policy is ignored. The site writes “Please send more suggestions so we can list them here!” and “If you know of anything else similar, please let us know!”, without saying how to contact the site owners.

Please extend the setup instructions for postfix-mta-sts-resolver, clarifying how the setup can be validated. E.g. by mentioning a misconfigured mail domain, which announces MTA-STS, but not not offer MTA-STS.

setup.py and requirements.txt have diverging dependency information. It's not a problem for me, but perhaps it's an oversight and these should be kept in sync?

Right now, the config supports host and port options for the responder. It makes sense to also offer a path option for unix sockets. This wouldn't be too hard, as the only thing that really needs to be changed is the create_custom_socket function in utils.py and its call in responder.py`.

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=<[email protected]>, 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):

• OS: Linux
• Distro: Ubuntu
• Distro version: 18.04
• Python version: 3.8 (I'm using yarmak/postfix-mta-sts-resolver ba7ca013cc35)
• Postfix 3.3.0-1ubuntu0.2

Is your feature request related to a problem? Please describe.
Similar to #45 I'd like to implement finer access to the mta-sts-daemon's unix socket. Right now I must add Postfix to the primary group of the user running mta-sts-daemon to use more restricted permissions like 660 for the socket. However, this still gives Postfix more access than it actually needs, because Postfix can then not just access the socket, but any other group-accessible file - i.e. usually all files of the user running mta-sts-daemon.

Following the principle of least privilege (POLP), I'd like to change the unix socket's owner and group, not just its mode.

Describe the solution you'd like
Since chowning files isn't possible for unprivileged users, it must be possible to start mta-sts-daemon with root privileges and let the daemon drop its permissions to a configurable unprivileged user after creating the socket. As a side effect, this also allows users to bind to ports < 1024 without permanently running the daemon as root.

Accordingly there should be three more config options: Two options to set the unix socket's owner and group respectively, and another option to set the unprivileged user to run the daemon with. Since the naming of the config options will likely cause confusion (owner of the unix socket vs. unprivileged user running the daemon), I'd recommend to change the config structure as follows (also move host, port, and reuse_port to the listen_on section, but still support the old configs to preserve BC):

listen_on:
    path: /path/to/unix.sock
    user: mta-sts-sock
    group: mta-sts-sock
    mode: 0660
user: mta-sts

When running mta-sts-daemon as root, it will first create the socket /path/to/unix.sock (owned by mta-sts-sock:mta-sts-sock, mode 0600) and then drop its privileges to user mta-sts. When trying to start mta-sts-daemon as an unprivileged user, the daemon should bail, unless the executing user matches both user and listen_on.user.

Describe alternatives you've considered
In theory, one could add the mta-sts user to the mta-sts-sock group and then add ExecStartPost=/usr/bin/chown mta-sts-sock:mta-sts-sock /path/to/unix.sock to the Systemd unit file, but I didn't test it.

On a side note, when using the fork syscall for a native implementation as suggested before, the mta-sts user isn't required to be a member of the mta-sts-sock group, because the unprivileged child process would inherit the open socket from the privileged root process.

Additional context
A lot of ❤️ for your awesome project, keep up the great work, thank you! 👍

Describe the bug
When invalid DNS server is set or if DNS server is not responding, error mta-sts-query returns STSFetchResult.NONE instead of STSFetchResult.FETCH_ERROR

To Reproduce
Steps to reproduce the behavior:

1. Set invalid DNS server in /etc/resolv.conf
2. Run for example mta-sts-query dismail.de
3. Check command output

Expected behavior
(<STSFetchResult.FETCH_ERROR: 2>, None)

Output listings
(<STSFetchResult.NONE: 0>, None)

Environment (please complete the following information):

• OS: GNU/Linux
• Distro: Ubuntu
• Distro version: 20.04
• Python version: 3.8

Additional context
Error returned for DNS request:
(11, 'Could not contact DNS servers')

Version installed from Ubuntu repo.

# apt info postfix-mta-sts-resolver
Package: postfix-mta-sts-resolver
Version: 0.7.5-1
Priority: optional
Section: universe/mail
Origin: Ubuntu
Maintainer: Ubuntu Developers <[email protected]>
Original-Maintainer: Benjamin Hof <[email protected]>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 124 kB
Pre-Depends: init-system-helpers (>= 1.54~)
Depends: python3-aiodns, python3-aiohttp, python3-yaml, python3:any, adduser, ca-certificates, python3-aiosqlite, python3-aioredis
Recommends: python3-uvloop
Enhances: postfix
Homepage: https://github.com/Snawoot/postfix-mta-sts-resolver
Download-Size: 30.0 kB
APT-Manual-Installed: yes
APT-Sources: http://archive.ubuntu.com/ubuntu focal/universe amd64 Packages
Description: Daemon providing MTA-STS map to Postfix

Describe the bug
I've installed postfix-mta-sts-resolver on my iRedMail email server but email deliverability fails when I send an email to ProtonMail, however I can send emails with a verified TLS connection to Gmail and Outlook.
I tried to install via pip and snap but both versions don't work, /etc/mta-sts-daemon.yml is missing, no systemd service is created and nothing is listening on port 8461 in both cases so I'm not sure if this is an issue with my installation method or an actual bug.

To Reproduce
Steps to reproduce the behavior:

1. Install via apt sudo apt install postfix-mta-sts-resolver on Ubuntu 22.04 with iRedMail
2. Add smtp_tls_policy_maps = socketmap:inet:127.0.0.1:8461:postfix into postfix main.cf
3. Use postfix-mta-sts-resolver config provided below
4. Send an email to protonmail

postfix-mta-sts-resolver config

host: 127.0.0.1
port: 8461
reuse_port: true
shutdown_timeout: 20
cache:
  type: internal
  options:
    cache_size: 10000
default_zone:
  strict_testing: false
  timeout: 20
proactive_policy_fetching:
  enabled: true

Expected behavior
I should be able to send emails to protonmail no problem, according to hardenize mta-sts is setup correctly for protonmail.com.

Output listings

Logs

May 26 22:06:22 mail postfix/smtp[80090]: CA certificate verification failed for mail.protonmail.ch[176.119.200.128]:25: num=2:unable to get issuer certificate
May 26 22:06:22 mail postfix/smtp[80090]: Untrusted TLS connection established to mail.protonmail.ch[176.119.200.128]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
May 26 22:06:22 mail postfix/smtp[80090]: 4QSNgT0FWpz9wJP: Server certificate not verified

mta-sts-query domain protonmail.com

(<STSFetchResult.NONE: 0>, None)

Environment (please complete the following information):

• OS: [Ubuntu 22.04]
• Python version: [Unknown]

I don't know of a good domain to generate a test-case for, sadly, so apologies if this isn't true, but from my understanding of the integration flow, it seems like using this in smtp_tls_policy_maps would result in MTA-STS overriding DANE, which seems like a pretty severe security downgrade for domains which use both (eg protonmail). Doing a DANE lookup in postfix-mta-sts-resolver before returning MTA-STS results seems somewhat overcomplicated, so it would certainly be more ideal if postfix had a way to capture this policy in its config (ie "DANE-but-fall-back-to-verify"), but presuming both use the same (caching) DNS resolver and the TLSA record has a reasonable TTL, doing a DANE check first shouldn't have much of a performance hit nor be too brittle.

Hello,

currently the code try to connect a remote https://mta-sts.$domain only direct.
There seem to be no support for a proxy implemented while aiohttp do provide support

what is the suggested way to tun the resolver behind a proxy?

Andreas

Hi,

When i use the standard inet configuration everything works ok, the daemon runs ok and i can send/receive emails fine. /usr/sbin/postmap -q dismail.de socketmap:inet:127.0.0.1:8461:postfix returns the correct response.

When i configure the daemon to use a unix socket instead of inet tcp i get a client tls configuration error and i cannot send email.

-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
865A235FB 2902 Mon Jun 12 10:40:38 [email protected]
(client TLS configuration problem)
[email protected]

However when i run /usr/sbin/postmap -q dismail.de socketmap:unix:/var/spool/postfix/run/mta-sts/mta-sts-resolver.sock:postfix it returns the same response as the above inet command, indicating it's working ok.

My mta-sts daemon file has the below config parameters for the socket:
path: /var/spool/postfix/run/mta-sts/mta-sts-resolver.sock
mode: 0666

And my postfix main.cf has the line (when trying to use the unix socket instead of inet):
smtp_tls_policy_maps = socketmap:unix:/var/spool/postfix/run/mta-sts/mta-sts-resolver.sock:postfix
I've also tried just using run/mta-sts-mta-sts-resolver.sock as the path but got the same result.

I'm assuming it's a configuration problem but i'm not sure what i could have done wrong.

I'm using the inet socket for now as that is working ok.

Thank you for your time!

Describe the bug
When querying an IDN domain with utf-8 characters in them, the connection gets closed prematurely and an error gets logged.

To Reproduce
Steps to reproduce the behavior:

1. Run a lookup with a domain that has an utf-8 character in it: /usr/sbin/postmap -q ätsch.de socketmap:inet:127.0.0.1:8461:postfix

Expected behavior
The domain should be converted to it's ascii counterpart (in this example xn--tsch-koa.de) and resolved correctly.

Output listings

Aug 20 18:52:28 proxy mta-sts-daemon[283]: 2022-08-20 18:52:28 ERROR    STS: Exception in sender coro: 'ascii' codec can't decode byte 0xc3 in position 8: ordinal not in range(128)
Aug 20 18:52:28 proxy mta-sts-daemon[283]: Traceback (most recent call last):
Aug 20 18:52:28 proxy mta-sts-daemon[283]:   File "/usr/lib/python3/dist-packages/postfix_mta_sts_resolver/responder.py", line 149, in sender
Aug 20 18:52:28 proxy mta-sts-daemon[283]:     data = await fut
Aug 20 18:52:28 proxy mta-sts-daemon[283]:   File "/usr/lib/python3/dist-packages/postfix_mta_sts_resolver/responder.py", line 167, in process_request
Aug 20 18:52:28 proxy mta-sts-daemon[283]:     req_zone, _, req_domain = raw_req.decode('ascii').partition(' ')
Aug 20 18:52:28 proxy mta-sts-daemon[283]: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 8: ordinal not in range(128)
Aug 20 18:52:28 proxy mta-sts-daemon[283]: 2022-08-20 18:52:28 ERROR    STS: Exception in sender coro: 'ascii' codec can't decode byte 0xc3 in position 8: ordinal not in range(128)
Aug 20 18:52:28 proxy mta-sts-daemon[283]: Traceback (most recent call last):
Aug 20 18:52:28 proxy mta-sts-daemon[283]:   File "/usr/lib/python3/dist-packages/postfix_mta_sts_resolver/responder.py", line 149, in sender
Aug 20 18:52:28 proxy mta-sts-daemon[283]:     data = await fut
Aug 20 18:52:28 proxy mta-sts-daemon[283]:   File "/usr/lib/python3/dist-packages/postfix_mta_sts_resolver/responder.py", line 167, in process_request
Aug 20 18:52:28 proxy mta-sts-daemon[283]:     req_zone, _, req_domain = raw_req.decode('ascii').partition(' ')
Aug 20 18:52:28 proxy mta-sts-daemon[283]: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 8: ordinal not in range(128)
Aug 20 18:52:28 proxy postfix/postmap[11247]: warning: table socketmap:inet:127.0.0.1:8461:postfix lookup error: unexpected disconnect
Aug 20 18:52:28 proxy postfix/postmap[11247]: fatal: table socketmap:inet:127.0.0.1:8461:postfix: query error: Operation now in progress

Environment (please complete the following information):

• OS: GNU/Linux
• Distro: Debian
• Distro version: sid
• Python version: 3.10