qmail/Makefile, branch master qmail remove readwrite.h 2026-06-25T12:10:06+00:00 Manuel Mausz manuel@mausz.at 2026-06-25T12:10:06+00:00 dc0a1c3474656cc7fbeadcdb9316a8a517ca7eb0 






Fix `implicit declaration of function` in install-big/hier
2024-11-28T12:32:32+00:00

manuel
manuel@mausz.at

2024-11-28T12:32:32+00:00

ec29722d8b6b90d1a0368542a5de991599e30adc












Make qmail openssl 3.0 compatible
2023-08-08T21:37:39+00:00

manuel
manuel@mausz.at

2023-08-08T21:37:39+00:00

2ae3dd41c6d46d80574c59eec9689c16093edf2b

- remove support for loading custom DH params from pem.
  use opensslconf if really required
- remove support for loading custom ec group from params
- reimplement DANE support using openssl DANE functions





- remove support for loading custom DH params from pem.
  use opensslconf if really required
- remove support for loading custom ec group from params
- reimplement DANE support using openssl DANE functions







remove "shar"-support
2023-08-07T14:34:15+00:00

manuel
manuel@mausz.at

2023-08-07T14:34:15+00:00

48bb6bb431c4ea1d03f27c49a8377ec8fde45302












add dns_tlsa(...) and dnstlsa utility
2023-08-07T14:33:27+00:00

manuel
manuel@mausz.at

2023-08-07T14:33:27+00:00

696792f08106e5bea4a8847e394401c1a68ecf9c












Add X-UD-Smtp-Session to qmail-inject
2020-11-20T10:46:57+00:00

manuel
manuel@mausz.at

2020-11-20T10:46:57+00:00

8415020b0391fdfb500f95ce6cf30e7628556e3f












SMTPUTF8: convert UTF-8 domains to IDNA
2017-08-18T13:03:50+00:00

manuel
manuel@mausz.at

2017-08-18T13:03:50+00:00

379571c25966786b4852f0551a645f3b447c90f0

This isn't entirely correct according to RFC 6531 as it's better to not
convert at all. However this would require we additionally add the UTF-8
form to qmails local recipient users/domains.

Plus our SMTPUTF8 implementation doesn't convert outgoing UTF-8 mails if
receiving MTA doesn't support SMTPUTF8. So mail forwarding might generate
a bounce the user very likely doesn't understand.

As MTAs who support SMTPUTF8 most likely also support the IDNA form,
always converting is probably a good trade-off.





This isn't entirely correct according to RFC 6531 as it's better to not
convert at all. However this would require we additionally add the UTF-8
form to qmails local recipient users/domains.

Plus our SMTPUTF8 implementation doesn't convert outgoing UTF-8 mails if
receiving MTA doesn't support SMTPUTF8. So mail forwarding might generate
a bounce the user very likely doesn't understand.

As MTAs who support SMTPUTF8 most likely also support the IDNA form,
always converting is probably a good trade-off.







add support for SMTPUTF8
2017-08-17T11:17:22+00:00

manuel
manuel@mausz.at

2017-08-17T11:17:22+00:00

1cafb5eab0b30e5f5a05737a075123af53153cb1












add SMTP DANE support
2015-07-04T17:28:30+00:00

manuel
manuel@mausz.at

2015-07-04T17:28:30+00:00

8f9afec35595f7c376876aa04dee08666614103c












opportunistic TLS
2015-06-30T12:00:01+00:00

manuel
manuel@mausz.at

2015-06-30T12:00:01+00:00

c76a0244565136c708d945f3ef1d4e14c7d3e1f8

When the TLS handshake fails, retry delivery with TLS disabled





When the TLS handshake fails, retry delivery with TLS disabled