[pfx] Implementing From: field heuristic when sending messages?
Dear Postfix users, A user had their password guessed/leaked, and the account was used to send spam/phishing messages – but only once an hour or so, so it wasn’t detected as abnormal traffic. One thing detectable thing would have been, that the sent unsolicited messages used a different name than the user in the From: field. Jennifer Wood To detect phishing messages on the receiving end, we already maintain a list in regexp-header for “important” people, so names used in From: have to match certain email addresses. The names are already present in the user name or comment field in `/etc/passwd` but also some LDAP database. Has somebody already experience with implementing such a heuristic, and is it useful¹? If it is useful, how could I do it? Probably an exact match would cause too much trouble, as some users want to put their academic title to the field too. Kind regards, Paul ¹ After a while the criminals are going to adapt, and just use the correct name for the account. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: How to reject messages on submission with typo in To address?
Dear Viktor,
Thank you for the quick reply with a solution.
Am 21.01.24 um 16:55 schrieb Viktor Dukhovni via Postfix-users:
On Sun, Jan 21, 2024 at 09:39:06AM +0100, Paul Menzel wrote:
pg.de is currently a parked domain, so our users will not going to
email there, and I would like to reject such messages submitted to us,
that the email client shows an error as it’s done, when, for example,
users submit a message to a colleague at our institute, and we now
that address does not exist, because the account was closed or it does
not exist.
Could you recommend a way how to best set this up, best with a custom error
message per domain? For example:
Reject: Address has a typo: Should .pg.de .mpg.de?
`master.cf` currently contains:
141.14.17.8:submission inetn - n - - smtpd
-o myhostname=mx.molgen.mpg.de
-o smtpd_recipient_restrictions=$mx_smtpd_recipient_restrictions
-o smtpd_client_recipient_rate_limit=50
main.cf:
indexed = ${default_database_type}:${config_directory}/
transport_maps = ${indexed}transport
transport:
.pg.de error:5.1.2 Typo domain .pg.de should be .mpg.de
Thank you. Indeed. I added it to our existing transport map:
# postconf transport_maps
transport_maps = hash:/project/mx/etc/transport
# grep -E ^.?pg\.de /project/mx/etc/transport
pg.de error:5.1.2 Typo in domain pg.de -- should
be mpg.de
.pg.de error:5.1.2 Typo in domain .pg.de -- should
be .mpg.de
Thank you again and kind regards,
Paul
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] How to reject messages on submission with typo in To address?
Dear Postfix users, The Max Planck Society consists of several institutes/organizations each running their own email infrastructure (which is good, as it’s decentralized. Most of them have the a subdomain under mpg.de, and sometimes we notice users from our institute sending emails to colleagues with a typo, for example, xy.pg.de with a missing *m*. pg.de is currently a parked domain, so our users will not going to email there, and I would like to reject such messages submitted to us, that the email client shows an error as it’s done, when, for example, users submit a message to a colleague at our institute, and we now that address does not exist, because the account was closed or it does not exist. Could you recommend a way how to best set this up, best with a custom error message per domain? For example: Reject: Address has a typo: Should .pg.de .mpg.de? `master.cf` currently contains: 141.14.17.8:submission inetn - n - - smtpd -o myhostname=mx.molgen.mpg.de -o smtpd_recipient_restrictions=$mx_smtpd_recipient_restrictions -o smtpd_client_recipient_rate_limit=50 Kind regards, Paul ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: (Patch "half-dane" logging corner case) Untrusted TLS connections where email domain does not support DNSSEC but MX server has DNSSEC/DANE records
Dear Viktor, dear Wietse,
Am 25.11.22 um 17:25 schrieb Viktor Dukhovni:
On Fri, Nov 25, 2022 at 09:35:28AM -0500, Wietse Venema wrote:
Viktor Dukhovni:
However, in this case the issue is a minor oversight in the Postfix TLS
client code. The intended logging behaviour does not happen. Patch
below:
Is there an equivalent for the still supported Postfix version 3.5?
That would also fix Postfix version 3.4 which has the same code.
An alternative (equivalent) form of the patch for 3.6+ could be the
below, which is perhaps closer to the 3.5 logic:
--- src/tls/tls_client.c
+++ src/tls/tls_client.c
@@ -324,6 +324,7 @@ static void verify_extract_name(TLS_SESS_STATE *TLScontext,
X509 *peercert,
* checks are now performed internally in OpenSSL.
*/
if (SSL_get_verify_result(TLScontext->con) == X509_V_OK) {
+ TLScontext->peer_status |= TLS_CERT_FLAG_TRUSTED;
if (TLScontext->must_fail) {
msg_panic("%s: cert valid despite trust init failure",
TLScontext->namaddr);
@@ -352,8 +353,7 @@ static void verify_extract_name(TLS_SESS_STATE *TLScontext,
X509 *peercert,
TLScontext->namaddr, peername);
tls_dane_log(TLScontext);
}
- } else
- TLScontext->peer_status |= TLS_CERT_FLAG_TRUSTED;
+ }
}
/*
Just a late note, that this diff was applied in on 20221125. Thank you all.
Kind regards,
Paul
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: logging username in a failed smtp attemps
Dear Eric, Am 24.10.23 um 11:32 schrieb Eric Doutreleau via Postfix-users: i m using on my server postfix-3.5.8 and cyrus-sasl-2.1.27 I m using fail2ban too to prevent brute force attack. my problem is that when a connection failed because of wrong password i don't know what account is targeted the line is Oct 5 11:07:52 hermes postfix/smtpd[277411]: warning: unknown[122.179.129.110]: SASL LOGIN authentication failed: authentication failure There s no username logged. Is there a way to log this username? Jozsef Kadlecsik submitted a patch, and it was accepted and is going to be available in the 3.9 release [1]. 20231006 Cleanup: attempt to log the SASL username after authentication failure. This appends ", sasl_username=xxx" to SASL authentication failure logging. Based on code by Jozsef Kadlecsik. Files: xsasl/xsasl_server.c, xsasl/xsasl_cyrus_server.c, smtpd/smtpd_sasl_glue.c. Kind regards, Paul [1]: https://de.postfix.org/ftpmirror/experimental/postfix-3.9-20231012.HISTORY ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] How to hide Exim behind Postfix (Configuring Postfix as a proxy in front of Exim MTAs) (was: Possible (indirect) libspf2 security issues)
Dear Postfix, Am 30.09.23 um 22:47 schrieb Viktor Dukhovni via Postfix-users: Recent news of security issues in Exim appear to in part implicate libspf2. […] Off-topic for Postfix users, but Tobias Fiebig published the article *Configuring Postfix as a proxy in front of Exim MTAs* [1]. Kind regards, Paul [1]: https://doing-stupid-things.as59645.net/mail/2023/09/30/postfix-proxy-setup.html ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: email being flagged a spam for using localhost [127.0.0.1] as first hop
Dear Fourhundred, Am 09.08.23 um 07:34 schrieb Fourhundred Thecat via Postfix-users: my email was flagged as spam by Microsoft. I have the received email, together with all the headers that Microsoft added. Specifically the item: X-Microsoft-Antispam-Message-Info: I have found a tool on github, which attempts to decode this convoluted item (https://github.com/mgeeky/decode-spam-headers) And one of the decoded lines says: (5880045) - (GUESSING) Somehow related to First Hop server reputation, it's reverse-PTR resolution or domain impersonation I am using header rewrite to hide my own IP address, and use localhost [127.0.0.1] instead. So that the first hop looks like this: Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.xxx.yyy (Postfix) with ESMTPSA id 7E011B0 for ; Wed, 9 Aug 2023 07:04:42 +0200 (CEST) is this considered bad practice? Or why am I being penalized for this? All I am trying to achieve is not to disclose from where I am sending my emails Sounds like something spammers also would like to do, so it’s considered bad practice. But, it is also not feasible, as the accepting host often logs the IP address. So your strategy would only work, if you use a smarthost (SMTP relay server), deleting the `Received:` records from the header. So the receiver would only see the IP address of the smart host. As an example for your message to the list from GMX: Received: from [10.1.2.16] ([212.25.11.75]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M3DJl-1qWda038fN-003eVr for ; Wed, 09 Aug 2023 07:34:49 +0200 mail.gmx.net is the smarthost, and would need to support to not add that Received entry (and remove possible other ones). Kind regards, Paul ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] OT: Does the GPDR require mandatory/verified TLS encryption? (was: SMTP client: How to log reason for untrusted TLS connection to MX?)
Dear Jaroslow, Am 24.07.23 um 19:02 schrieb Jaroslaw Rafa via Postfix-users: Dnia 24.07.2023 o godz. 17:05:40 Paul Menzel via Postfix-users pisze: (Also from the legal perspective, without being a lawyer, I’d say, that actually all German (European) companies are required to only transmit messages over a verified TLS connection.) Never heard of such a requirement in any EU law. Article 32 of the GPDR [1] says: Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate: a) the pseudonymisation and encryption of personal data; b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services; c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident; d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing. (The German translation is “Stand der Technik“.) I claim, that using mandatory and verified TLS encryption is state of the art, and has basically no cost of implementation thanks to Let’s Encrypt, so is required especially for confidentiality. Kind regards, Paul [1]: https://gdpr-info.eu/art-32-gdpr/ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: SMTP client: How to log reason for untrusted TLS connection to MX?
Dear Viktor, Thank you for your reply. Am 23.07.23 um 23:42 schrieb Viktor Dukhovni via Postfix-users: On Sun, Jul 23, 2023 at 11:22:26PM +0200, Paul Menzel wrote: Does it really matter why some site offering opportunistic STARTTLS does not have a validatable certificate? The connection can be trivially downgraded by an on-path attacker (stripping STARTTLS) to just be cleartext. Or the MX records could be forged (absent DNSSEC). As these are only a few, I’d take up the task of contacting these postmasters, so having the reason at hand would ease that task. Doing this manually, these steps would be done later, where the setup could change, and the result/behavior might be different. So having the reason at hand would also make it easier to clear up these situations. My point is that even the sites that are logged as "Trusted" are not fully validated (no hostname checkes are attempted or even entirely possible, given insecure MX indirection). With "Trusted" easily downgraded. What is the point of caring whether the MX host did or not present some random certificate from some random CA in your CA bundle? What actual problem are you solving? I don't see any value in certificate chain trust validation for its own sake, if no real security goals are met as a result. Ah, sorry for missing to clarify that. My goal is of course to set the level to *verify* in the future. With so few exceptions, that goal gets closer and closer. (Also from the legal perspective, without being a lawyer, I’d say, that actually all German (European) companies are required to only transmit messages over a verified TLS connection.) If you choose to use the unsupported (therefore not subject to Postfix stability guarantees) "smtp_tls_loglevel = certmatch, summary" setting, the additional lines are logged for every TLS handshake involving certificates, not just those that are "Untrusted". We build Postfix ourselves. If somebody has a (hackish) patch to achieve this, we could add it to our installation. I don't recommend attempting such a patch. If you *strongly* want the extra logging, just accept it even for valid connections. The "certmatch" logging becomes more succinct when raw public keys are supported and used by the peer. Line 1 shows the public key details, and line 2 the usual summary (signalling RPK use in a comment for the server signature). The "-x" flag would turn off mandatory X.509, enabling use of raw public keys. $ posttls-finger -x -F /etc/ssl/cert.pem -c -Lcertmatch,summary -lmay -o 'tls_medium_cipherlist = DEFAULT' dnssec-stats.ant.isi.edu 1 ->posttls-finger: dnssec-stats.ant.isi.edu[2001:1878:401::8009:1dfe]:25: raw public key fingerprint=B1:E7:FA:AF:6E:48:2E:2A:FB:C6:53:C8:E3:B6:BE:F0:E3:35:24:24:AE:BD:24:D2:B4:80:09:29:51:BC:60:97 2 ->posttls-finger: Untrusted TLS connection established to dnssec-stats.ant.isi.edu[2001:1878:401::8009:1dfe]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bit raw public key) server-digest SHA256 It sounds interesting, but unfortunately, I have no idea about raw public keys. I quickly read the introduction of the RFC 7250 [1], but do not understand yet, why it shows *Untrusted* in your example, and how it’d would solve my original problem. It does not solve your "original problem", this is just a caveat to let future readers know that the logging from "certmatch" may become a one-liner in some configurations that with cause don't care much about certificates, when they aren't used to ensure connection security. In fact, enabling raw public keys would take you further away from your puzzling goal of logging certificate trust chain validity issues (for certificates that may or may be legitimately for the host that you expect to connect to, which may or may not be the legitimate MX host of the destination domain). Perhaps for "opportunsitic" TLS connections we should stop routine and largely futile logging of whether the chain is "Trusted" or "Untrusted", to avoid encouraging users to try to read the tea-leaves? The summary log message for unauthenticated connections (may, encrypt or dane in the absense of TLSA records) might then take the form: TLS connection established to dnssec-stats.ant.isi.edu[2001:1878:401::8009:1dfe]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bit raw public key) server-digest SHA256 And then, all temptation to fix "problems" with sites whose certificate trust chains are "invalid" go away. The trust status would then only be logged for destinations that require connection security (fingerprint, dane with TLSA, verify or secure). I see your point. No idea, how often these questions come
[pfx] Re: How to verify that DH key generation parameters from RFC 7919 are used?
Dear Ivan, Thank you very much for your reply. Am 12.07.23 um 10:16 schrieb Ivan Hadzhiev: You can copy from here: https://github.com/internetstandards/dhe_groups/blob/main/ffdhe4096.pem or you can create it openssl genpkey -genparam -algorithm DH -pkeyopt dh_param:ffdhe4096 -out /etc/postfix/ffdhe4096.dh.param I downloaded the 3072 bit file and set it up: # wget -O /project/mx/etc/ffdhe3072.pem https://github.com/internetstandards/dhe_groups/blob/main/ffdhe3072.pem # postconf -n smtpd_tls_dh1024_param_file smtpd_tls_dh1024_param_file = /project/mx/etc/ffdhe3072.pem # postfix reload But the Internet.nl email test still says that DH 2048 is offered by mx3.molgen.mpg.de [1]. mx3.molgen.mpg.de. DH-2048 insufficient So I am still curious, how to verify that. Kind regards, Paul [1]: https://www.internet.nl/mail/recomb.org/972775/ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] How to verify that DH key generation parameters from RFC 7919 are used?
Dear Postfix folks, The Internet.nl email test, reports for molgen.mpg.de [1]: Key exchange parameters Verdict: At least one of your mail servers supports insufficiently secure parameters for Diffie-Hellman key exchange. Technical details: c1241.mx.srv.dfn.de.DH-2048 insufficient b1241.mx.srv.dfn.de.DH-2048 insufficient a1241.mx.srv.dfn.de.DH-2048 insufficient DHE: The security of Diffie-Hellman Ephemeral (DHE) key exchange depends on the lengths of the public and secret keys used within the chosen finite field group. We test if your DHE public key material uses one of the predefined finite field groups that are specified in RFC 7919. Self-generated groups are 'Insufficient'. The test seems to follow Dutch recommendations: See 'IT Security Guidelines for Transport Layer Security (TLS) v2.1' from NCSC-NL [2], guideline B5-1 and table 9 for ECDHE, and guideline B6-1 and table 10 for DHE (in English). How can I check myself, what “DHE public key material“ is used to compare it with the ones specified in RFC 7919 [3]? Postfix’ *TLS Forward Secrecy in Postfix* [4] says: Postfix ≥ 3.1 supports 2048-bit-prime FFDHE out of the box, with no additional configuration. Where in the code would I find the key material? `tlsproxy/tlsproxy.c` calls `TLS_SERVER_INIT()`, and `tls_server_init()` in `tls/tls_server.c` contains: if (*props->dh1024_param_file != 0) tls_set_dh_from_file(props->dh1024_param_file); tls_tmp_dh(server_ctx, 1); That then seems to use the OpenSSL function d2i_DHparams? tls/tls_dh.c:if (d2i_DHparams(, , sizeof(builtin_der)) Kind regards, Paul PS: Is the “preferred” in the comment in `tls/tls_server.c` outdated? * Diffie-Hellman key generation parameters can either be loaded from * files (preferred) or taken from compiled in values. First, set the [1]: https://www.internet.nl/mail/molgen.mpg.de/968847/ [2]: https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1 [3]: https://www.rfc-editor.org/rfc/rfc7919.html [4]: https://www.postfix.org/FORWARD_SECRECY_README.html ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Detect/extract attachments in broken messages composed by Apple Mail
Dear Postfix folks, Apple Mail violates the standard [1], resulting in attachments only being shown in the HTML view. This behaviour is to be expected given the incorrect MIME structure of the message. It is: multipart/alternative text/plain multipart/mixed text/html attachment So when selecting the plain part, you don't see the attachment associated with the alternative part. The message structure should be: multipart/mixed multipart/alternative text/plain text/html attachment If we wanted to detect such messages, and add a notification or extract the attachment, what component would be the right part for such message alteration? A milter? (I am aware, that this will break with end-to-end encryption (GPG or S/MIME).) Kind regards, Paul [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1362539#c3 ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[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]: ### Warning: MTA-STS policy overrides DANE TLS authentication Due to Postfix's limitations, a resolved MTA-STS policy overrides DANE TLS authentication ([RFC 6698](https://www.rfc-editor.org/rfc/rfc6698)), because DANE is an internal feature of Postfix, and the postfix-mta-sts-resolver always responds with a ([`smtp_tls_policy_maps`](https://www.postfix.org/postconf.5.html#smtp_tls_policy_maps)) lookup result `secure` for [Secure server certificate verification](https://www.postfix.org/TLS_README.html#client_tls_secure). * The resulting behaviour is against [RFC 8461, 2](https://www.rfc-editor.org/rfc/rfc8461#section-2): > However, MTA-STS is designed not to interfere with DANE deployments when the two overlap; in particular, senders who implement MTA-STS validation MUST NOT allow MTA-STS Policy validation to override a failing DANE validation. Domains implementing both MTA-STS and DANE probably want DANE to be preferred: * DANE allows strict binding of certificates; the policy can authorize only a certain certificate or certificates from a certain CA. With MTA-STS, a certificate from any trusted CA is automatically trusted; [RFC 8461, 10.1](https://www.rfc-editor.org/rfc/rfc8461#section-10.1): > SMTP MTA-STS relies on certificate validation via PKIX-based TLS identity checking [RFC6125]. Attackers who are able to obtain a valid certificate for the targeted recipient mail service (e.g., by compromising a CA) are thus able to circumvent STS authentication. * Based on DNSSEC, DANE not vulnerable to downgrade attack that could prevent policy discovery. MTA-STS security considerations acknowledges this weakness in [RFC 8461, 10.2](https://www.rfc-editor.org/rfc/rfc8461#section-10.2): > Since MTA-STS uses DNS TXT records for policy discovery, an attacker who is able to block DNS responses can suppress the discovery of an MTA-STS Policy, making the Policy Domain appear not to have an MTA-STS Policy. > Resistance to downgrade attacks of this nature -- due to the ability to authoritatively determine "lack of a record" even for non-participating recipients -- is a feature of DANE, due to its use of DNSSEC for policy discovery. * The postfix-mta-sts-resolver does not intent to implement policy lookups for DANE, and responses other than `secure` with `match=` would not verify the TLS certificate as required by [RFC 8461, 4,2](https://www.rfc-editor.org/rfc/rfc8461#section-4.2). If you wish to meet this requirement: * List a DANE policy resolver responding with `dane-only` (for [Mandatory DANE](https://www.postfix.org/TLS_README.html#client_tls_dane)) before postfix-mta-sts-resolver in `smtp_tls_policy_maps` lookup table list. * Alternatively, you could use a static lookup table for domains known to implement both MTA-STS & DANE, e.g., ``` smtp_tls_policy_maps = hash:/etc/postfix/tls_policy,socketmap:inet:127.0.0.1:8461:postfix ``` Do you know of other solutions? Kind regards, Paul [1]: https://www.email-security-scans.org/ [2]: https://github.com/Snawoot/postfix-mta-sts-resolver [3]: https://raw.githubusercontent.com/Snawoot/postfix-mta-sts-resolver/master/README.md ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: relocated: Allow custom message
Dear Matus, Thank you for your reply. Am 03.05.23 um 15:02 schrieb Matus UHLAR - fantomas via Postfix-users: On 03.05.23 14:53, Paul Menzel via Postfix-users wrote: Some of our users, that relocate, ask for a custom message over the current one: user has moved to new_location For example: This address is out of service. For business please contact funct...@company.example.net, or n...@private.example.net for private contact. I guess, it could be reworded to user has moved to n...@private.example.net, please contact funct...@company.example.net for business and use the current mechanism. Could a third column for a custom message be added to satisfy everybody? third column where? you can set up your mailserver to reject recipient address with e.g. by setting access map to: m...@example.com 551 moved to newm...@example.net Thank you for the hint. how do you currently implement the redirect mentioned above? # postconf -n relocated_maps relocated_maps = hash:/project/mx/etc/relocated relocated(5) [1] describes this mechanism [1]. Kind regards, Paul [1]: http://www.postfix.org/relocated.5.html ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] relocated: Allow custom message
Dear Postfix users, Some of our users, that relocate, ask for a custom message over the current one: user has moved to new_location For example: This address is out of service. For business please contact funct...@company.example.net, or n...@private.example.net for private contact. I guess, it could be reworded to user has moved to n...@private.example.net, please contact funct...@company.example.net for business and use the current mechanism. Could a third column for a custom message be added to satisfy everybody? Kind regards, Paul ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
TLS: Do hostname verification, but still deliver email on mismatch?
Dear Postfix users, We are using smtp_tls_security_level = dane smtp_tls_policy_maps = hash:/project/mx/etc/tls_policy where the file `tls_policy` contains the domains of several research institutions to use the security level `verify` or even `secure`. All other TLS connections without DNSSEC/DANE but still a correct certificate setup, that could be verified, are marked as just *Trusted*, as documented in *What do "Anonymous", "Untrusted", etc. in Postfix logging mean?* [1]. Is there a way to have some verification level `dane-verify-log`, which would, for no “DANE connections”, also try to verify the hostname, and log Verified TLS connection established to … if the remote SMTP server’s certificate was signed by a CA, trusted by the Postfix SMTP client, and the certificate name matches the destination or server name(s). Messages would still delivered to SMTP servers, where the certificate name does *not* match the destination or server name. I think, it would be useful to extract communication partners from the log, where the TLS setup could be improved. Especially, as the GDPR [2] states [3]: Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate: […] (b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services; […] So, as end-to-end encryption is not adopted, not verifying the hostname of the SMTP server might be a violation. (Best would be, if everybody would be required to use DNSSEC/DANE, but people might argue it’s *Stand von Wissenschaft und Technik*, though at least in Germany, where United Media (Web.de, GMX), mailbox.org, and Posteo use DNSSEC/DANE, at least I would disagree, and call it state of the art.) Kind regards, Paul [1]: https://www.postfix.org/FORWARD_SECRECY_README.html#status [2]: https://en.wikipedia.org/wiki/General_Data_Protection_Regulation [3]: https://gdpr-info.eu/art-32-gdpr/
Re: Untrusted TLS connections where email domain does not support DNSSEC but MX server has DNSSEC/DANE records
Dear Bill, Thank you for your reply. Am 21.11.22 um 19:05 schrieb Bill Cole: On 2022-11-21 at 12:18:33 UTC-0500 (Mon, 21 Nov 2022 18:18:33 +0100) Paul Menzel is rumored to have said: With Postfix 3.6.0-RC1 and # postconf -n smtp_tls_security_level smtp_tls_security_level = dane the Postfix SMTP client logs several untrusted TLS connections for hosts with a good TLS certificate setup. [...] I have no answer to your main question but I think I see the issue in the log below. The server sends a certificate with "issuer_CN=GEANT OV RSA CA 4" but it doesn't seem to send any intermediate certificate to build a chain back to a known root, so unless you have a trusted root locally for that issuer, the chain can't be verified. which SMTP server do you refer to? Both the mx1.bund.de and c1491.mx.srv.dfn.de return the full chain [1][2]. Kind regards, Paul [1]: https://www.hardenize.com/report/rki.de/1669019771 [2]: https://www.hardenize.com/report/helmholtz-muenchen.de PPPS: OpenSSL output: ``` $ openssl s_client -connect mx1.bund.de.:25 -starttls smtp CONNECTED(0003) Can't use SSL_get_servername depth=2 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2 verify return:1 depth=1 C = DE, O = T-Systems International GmbH, OU = T-Systems Trust Center, ST = Nordrhein Westfalen, postalCode = 57250, L = Netphen, street = Untere Industriestr. 20, CN = TeleSec ServerPass Class 2 CA verify return:1 depth=0 C = DE, O = Bundesverwaltungsamt Koeln, OU = BUND, OU = SERVICE, ST = Nordrhein-Westfalen, L = Koeln, CN = mx1.bund.de verify return:1 --- Certificate chain 0 s:C = DE, O = Bundesverwaltungsamt Koeln, OU = BUND, OU = SERVICE, ST = Nordrhein-Westfalen, L = Koeln, CN = mx1.bund.de i:C = DE, O = T-Systems International GmbH, OU = T-Systems Trust Center, ST = Nordrhein Westfalen, postalCode = 57250, L = Netphen, street = Untere Industriestr. 20, CN = TeleSec ServerPass Class 2 CA a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256 v:NotBefore: Aug 24 11:35:10 2022 GMT; NotAfter: Aug 28 23:59:59 2023 GMT 1 s:C = DE, O = T-Systems International GmbH, OU = T-Systems Trust Center, ST = Nordrhein Westfalen, postalCode = 57250, L = Netphen, street = Untere Industriestr. 20, CN = TeleSec ServerPass Class 2 CA i:C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Feb 11 14:39:10 2014 GMT; NotAfter: Feb 11 23:59:59 2024 GMT 2 s:C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2 i:C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Oct 1 10:40:14 2008 GMT; NotAfter: Oct 1 23:59:59 2033 GMT --- Server certificate -BEGIN CERTIFICATE- MIIJ8TCCCNmgAwIBAgIQIKyFpxYJvhHPIJjx7MBJ+TANBgkqhkiG9w0BAQsFADCB 3zELMAkGA1UEBhMCREUxJTAjBgNVBAoMHFQtU3lzdGVtcyBJbnRlcm5hdGlvbmFs IEdtYkgxHzAdBgNVBAsMFlQtU3lzdGVtcyBUcnVzdCBDZW50ZXIxHDAaBgNVBAgM E05vcmRyaGVpbiBXZXN0ZmFsZW4xDjAMBgNVBBEMBTU3MjUwMRAwDgYDVQQHDAdO ZXRwaGVuMSAwHgYDVQQJDBdVbnRlcmUgSW5kdXN0cmllc3RyLiAyMDEmMCQGA1UE AwwdVGVsZVNlYyBTZXJ2ZXJQYXNzIENsYXNzIDIgQ0EwHhcNMjIwODI0MTEzNTEw WhcNMjMwODI4MjM1OTU5WjCBlzELMAkGA1UEBhMCREUxIzAhBgNVBAoTGkJ1bmRl c3ZlcndhbHR1bmdzYW10IEtvZWxuMQ0wCwYDVQQLEwRCVU5EMRAwDgYDVQQLEwdT RVJWSUNFMRwwGgYDVQQIExNOb3JkcmhlaW4tV2VzdGZhbGVuMQ4wDAYDVQQHEwVL b2VsbjEUMBIGA1UEAxMLbXgxLmJ1bmQuZGUwggIiMA0GCSqGSIb3DQEBAQUAA4IC DwAwggIKAoICAQDCUMRjT8RTr1Z/Dm1zoe8NV9+vjYsueoF0AAdWRB5HsLFmQI65 xiuNWfgCrUWPrpbbutLE1RAf1WQ003l82WskUdePCVIFy4GaEDe8Y4URzhF1ujKd oEbEcjpG+SCUWFdCvQmzvKf3+x/K2nIAczMwMQ4/CXDXEvhZP9nyi4/NKtEAWb6L 3j22mVudg+UO6qQ6gTf9vh13lzOoicO5WBbA1+nD8kmh+GuE9sejGD1fQPsx5whI Zwbbfl7+xD4D227PmmNGsm9IOgrUDgU0a+tQH9kE6mqb1nwv/0voMHZesRB4Q0UV lec1uV7Y21piHu1+3/cNzfz7aDHlq+D/ppRk+zNDR3SgjA4fQ+DbmoHwEV16ZIR/ yypfpqfEHUJ9to3GRHjpI3shiXuuMNY+e0HAGRbRimGbOydkQ1tqcylK1HSS1AJV 9cEE1OFd2h5LxBs5kBLwYhJAXks8k1ulIujvoTj0hyVQfIlFaJ/RV8cZ+ycL1k4L Xkrt54PBkY7AAlh8fPjCXFiRryHsiwPLKkmtO/vyf9rfhi5L+7Q1PIyxc7B7O60W Cq4LVwjkS07xU5bOT2w1wxeJne0QKMRJwf+pZul04/gAMTxeL27pnv+vuhqkvvvm DIUXgeqYLiS2A6FfBUa0KYclHpMMgw7moLXneEifQflDNPiKyQO0ZXXSCwIDAQAB o4IE7TCCBOkwHwYDVR0jBBgwFoAUlMh0RvU6tEZIJvgryjQeViYEEgAwDgYDVR0P AQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATAdBgNVHQ4E FgQU9cN3EN1qX6S3h7SKduRlNoCX+kEwZQYDVR0gBF4wXDBQBgorBgEEAb1HDRcB MEIwQAYIKwYBBQUHAgEWNGh0dHA6Ly9kb2NzLnNlcnZlcnBhc3MudGVsZXNlYy5k ZS9jcHMvc2VydmVycGFzcy5odG0wCAYGZ4EMAQICMEsGA1UdHwREMEIwQKA+oDyG Omh0dHA6Ly9jcmwuc2VydmVycGFzcy50ZWxlc2VjLmRlL3JsL1NlcnZlclBhc3Nf Q2xhc3NfMi5jcmwwgZkGCCsGAQUFBwEBBIGMMIGJMDMGCCsGAQUFBzABhidodHRw Oi8vb2NzcC5zZXJ2ZXJwYXNzLnRlbGVzZWMuZGUvb2NzcHIwUgYIKwYBBQUHMAKG Rmh0dHA6Ly9jcmwuc2VydmVycGFzcy50ZWxlc2VjLmRlL2NydC9UZW
Untrusted TLS connections where email domain does not support DNSSEC but MX server has DNSSEC/DANE records
Dear Postfix folks, With Postfix 3.6.0-RC1 and # postconf -n smtp_tls_security_level smtp_tls_security_level = dane the Postfix SMTP client logs several untrusted TLS connections for hosts with a good TLS certificate setup. It’s mainly German research organizations using the DFN-MailSupport, but also the ones using the SMTP servers of bund.de. postfix/smtp[27147]: Untrusted TLS connection established to mx1.bund.de[77.87.224.131]: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 postfix/smtp[27147]: X: to=, relay=mx1.bund.de[77.87.224.131]:25, delay=0.29, delays=0.04/0/0.07/0.18, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as XXXsomehash) posttls-finger works with level `verify`: $ posttls-finger -c -l verify -P /etc/ssl/certs rki.de posttls-finger: mx1.bund.de[77.87.224.131]:25: matched peername: mx1.bund.de posttls-finger: mx1.bund.de[77.87.224.131]:25: subject_CN=mx1.bund.de, issuer_CN=TeleSec ServerPass Class 2 CA, fingerprint=22:71:E5:D4:DB:06:07:74:0B:C5:D4:F9:7C:39:C1:C9, pkey_fingerprint=39:6E:16:A6:B6:42:14:9A:64:07:D2:E0:F6:B1:86:CF posttls-finger: Verified TLS connection established to mx1.bund.de[77.87.224.131]: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 After a while of head scratching, I thought it might have to do with the SMTP servers publishing TLSA records, but the domain in the email address does not support DNSSEC. Testing with level `dane` it indeed does mark the TLS connection as untrusted: $ posttls-finger -c -l dane -P /etc/ssl/certs rki.de posttls-finger: MX RRset insecure: log verified as trusted posttls-finger: mx1.bund.de[77.87.224.131]:25: Matched DANE EE certificate at depth 0: 3 0 1 2E5543C7522EDC151C65602F4541DC14D66182B49EA687EE9EFA2F6E3990186E posttls-finger: mx1.bund.de[77.87.224.131]:25: subject_CN=mx1.bund.de, issuer_CN=TeleSec ServerPass Class 2 CA, fingerprint=22:71:E5:D4:DB:06:07:74:0B:C5:D4:F9:7C:39:C1:C9, pkey_fingerprint=39:6E:16:A6:B6:42:14:9A:64:07:D2:E0:F6:B1:86:CF posttls-finger: Untrusted TLS connection established to mx1.bund.de[77.87.224.131]: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 My naive assumption would have been, if no DNSSEC is set up for the domain in the email address, that DANE would not be tried. The DANE SMTP Validator [1] seems to use that ordering too. Do you have suggestions how to deal with this issue? Kind regards, Paul [1]: https://dane.sys4.de/ PS: Best would be, if the operators would set up DNSSEC, but unfortunately, my attempts to convince them has been unsuccessful so far. PPS: Postfix log for helmholtz-muenchen.de with `smtp_tls_loglevel=2`: ``` 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: setting up TLS connection to c1491.mx.srv.dfn.de[194.95.238.86]:25 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: c1491.mx.srv.dfn.de[194.95.238.86]:25: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH:!RC4:!aNULL:!aNULL" 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: c1491.mx.srv.dfn.de[194.95.238.86]:25: SNI hostname: c1491.mx.srv.dfn.de 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:before SSL initialization 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS write client hello 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS write client hello 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS read server hello 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS write change cipher spec 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS write client hello 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS write client hello 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS read server hello 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:TLSv1.3 read encrypted extensions 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: c1491.mx.srv.dfn.de[194.95.238.86]:25: depth=0 verify=1 subject=/C=DE/ST=Berlin/O=Verein zur F\xC3\xB6rderung eines Deutschen Forschungsnetzes DFN-Verein/CN=mx .srv.dfn.de 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS read server certificate 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:TLSv1.3 read server certificate verify 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS read finished 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: SSL_connect:SSLv3/TLS write finished 2022-11-21T16:27:13+01:00 tldr postfix/smtp[10759]: c1491.mx.srv.dfn.de[194.95.238.86]:25: Matched DANE EE certificate at depth 0: 3 0 1
Re: [solved] DNSSEC/DANE: TLSA records looked up for parent domain
Dear Postfix folks, Am 17.02.22 um 15:56 schrieb Paul Menzel: Am 17.02.22 um 10:57 schrieb Paul Menzel: Using Postfix 3.6.0-rc1, for an email sent to x.y.molgen.mpg.de it looks up the TLSA records for y.molgen.mpg.de instead of x.y.molgen.mpg.de: 2022-02-12T12:02:21+01:00 tldr postfix/smtp[25656]: warning: TLS policy lookup for github.molgen.mpg.de/github.molgen.mpg.de: no TLSA records found 2022-02-12T12:02:21+01:00 tldr postfix/smtp[25656]: 6D99D61E6478B: to=, relay=none, delay=0.3, delays=0.28/0.02/0/0, dsn=4.7.5, status=deferred (no TLSA records found) I forgot to mention, that this is all handled internally. I haven’t tried from another domain. Not that we have dane-only TLS policy configured for our domains, as we use DNSSEC and the MTAs all have TLSA records published. (And dane TLS policy unfortunately falls back to encrypt and not secure.) Indeed for github.molgen.mpg.de no MX record exists, but there shouldn’t as the message goes to reply.github.molgen.mpg.de: $ dig mx reply.github.molgen.mpg.de +dnssec +short 5 mx3.molgen.mpg.de. MX 7 5 7200 20220318110038 20220216110038 14960 molgen.mpg.de. kTDvX9PKXC9sk96QViR09wUATN3m96sz6Ha6FrMRBrjxUa1OU1AdhvVj cJbRyetiHy3v+uOPdrng4NLVAow/omnF7Ph0twfz9p9EXUfOBBC/6QJJ Ym5JfxgjDWReHVFw5Y+duQSXtvSOjJR0KwHECtcAClWxO0e98/EtvEmP TQajwIkw5sA8wOmcIMu6BKIjaEZvEVB6NQxT72HrEpNbsKWnbBWfj71k qYag1hsmuVWzjLtN8E2AtPYic13x55t8tV1hEnlHcgFAp2Fya1y+o6hA okDMrg9JUf3/qSjjox3hY78IKAcw8KDz8DEwvjBnr76/6ut9zQ2oIc+P XA7N+w== $ dig _25._tcp.mx3.molgen.mpg.de IN TLSA +short 3 1 2 7AAD43A0FDFF34452CA695A2B510F613A2997077E4C2EDFF2B32DE36 26552C2832EF72F5DC12B5FE3984BAFE1B87406207EDAD34A4F3E11F 49CD4A23DB83374C The DANE SMTP Validator verifies, that it should work for reply.github.molgen.mpg.de [1]. Any idea, why github.molgen.mpg.de is looked at? Brown paper back. We have an entry in the transport table: reply.github.molgen.mpg.de smtp:github.molgen.mpg.de Kind regards, Paul [1]: https://dane.sys4.de/smtp/reply.github.molgen.mpg.de
Re: DNSSEC/DANE: TLSA records looked up for parent domain
Dear Postfix folks, Am 17.02.22 um 10:57 schrieb Paul Menzel: Using Postfix 3.6.0-rc1, for an email sent to x.y.molgen.mpg.de it looks up the TLSA records for y.molgen.mpg.de instead of x.y.molgen.mpg.de: 2022-02-12T12:02:21+01:00 tldr postfix/smtp[25656]: warning: TLS policy lookup for github.molgen.mpg.de/github.molgen.mpg.de: no TLSA records found 2022-02-12T12:02:21+01:00 tldr postfix/smtp[25656]: 6D99D61E6478B: to=, relay=none, delay=0.3, delays=0.28/0.02/0/0, dsn=4.7.5, status=deferred (no TLSA records found) I forgot to mention, that this is all handled internally. I haven’t tried from another domain. Not that we have dane-only TLS policy configured for our domains, as we use DNSSEC and the MTAs all have TLSA records published. (And dane TLS policy unfortunately falls back to encrypt and not secure.) Indeed for github.molgen.mpg.de no MX record exists, but there shouldn’t as the message goes to reply.github.molgen.mpg.de: $ dig mx reply.github.molgen.mpg.de +dnssec +short 5 mx3.molgen.mpg.de. MX 7 5 7200 20220318110038 20220216110038 14960 molgen.mpg.de. kTDvX9PKXC9sk96QViR09wUATN3m96sz6Ha6FrMRBrjxUa1OU1AdhvVj cJbRyetiHy3v+uOPdrng4NLVAow/omnF7Ph0twfz9p9EXUfOBBC/6QJJ Ym5JfxgjDWReHVFw5Y+duQSXtvSOjJR0KwHECtcAClWxO0e98/EtvEmP TQajwIkw5sA8wOmcIMu6BKIjaEZvEVB6NQxT72HrEpNbsKWnbBWfj71k qYag1hsmuVWzjLtN8E2AtPYic13x55t8tV1hEnlHcgFAp2Fya1y+o6hA okDMrg9JUf3/qSjjox3hY78IKAcw8KDz8DEwvjBnr76/6ut9zQ2oIc+P XA7N+w== $ dig _25._tcp.mx3.molgen.mpg.de IN TLSA +short 3 1 2 7AAD43A0FDFF34452CA695A2B510F613A2997077E4C2EDFF2B32DE36 26552C2832EF72F5DC12B5FE3984BAFE1B87406207EDAD34A4F3E11F 49CD4A23DB83374C The DANE SMTP Validator verifies, that it should work for reply.github.molgen.mpg.de [1]. Any idea, why github.molgen.mpg.de is looked at? Kind regards, Paul [1]: https://dane.sys4.de/smtp/reply.github.molgen.mpg.de
DNSSEC/DANE: TLSA records looked up for parent domain
Dear Postfix folks, Using Postfix 3.6.0-rc1, for an email sent to x.y.molgen.mpg.de it looks up the TLSA records for y.molgen.mpg.de instead of x.y.molgen.mpg.de: 2022-02-12T12:02:21+01:00 tldr postfix/smtp[25656]: warning: TLS policy lookup for github.molgen.mpg.de/github.molgen.mpg.de: no TLSA records found 2022-02-12T12:02:21+01:00 tldr postfix/smtp[25656]: 6D99D61E6478B: to=, relay=none, delay=0.3, delays=0.28/0.02/0/0, dsn=4.7.5, status=deferred (no TLSA records found) Indeed for github.molgen.mpg.de no MX record exists, but there shouldn’t as the message goes to reply.github.molgen.mpg.de: $ dig mx reply.github.molgen.mpg.de +dnssec +short 5 mx3.molgen.mpg.de. MX 7 5 7200 20220318110038 20220216110038 14960 molgen.mpg.de. kTDvX9PKXC9sk96QViR09wUATN3m96sz6Ha6FrMRBrjxUa1OU1AdhvVj cJbRyetiHy3v+uOPdrng4NLVAow/omnF7Ph0twfz9p9EXUfOBBC/6QJJ Ym5JfxgjDWReHVFw5Y+duQSXtvSOjJR0KwHECtcAClWxO0e98/EtvEmP TQajwIkw5sA8wOmcIMu6BKIjaEZvEVB6NQxT72HrEpNbsKWnbBWfj71k qYag1hsmuVWzjLtN8E2AtPYic13x55t8tV1hEnlHcgFAp2Fya1y+o6hA okDMrg9JUf3/qSjjox3hY78IKAcw8KDz8DEwvjBnr76/6ut9zQ2oIc+P XA7N+w== $ dig _25._tcp.mx3.molgen.mpg.de IN TLSA +short 3 1 2 7AAD43A0FDFF34452CA695A2B510F613A2997077E4C2EDFF2B32DE36 26552C2832EF72F5DC12B5FE3984BAFE1B87406207EDAD34A4F3E11F 49CD4A23DB83374C The DANE SMTP Validator verifies, that it should work for reply.github.molgen.mpg.de [1]. Any idea, why github.molgen.mpg.de is looked at? Kind regards, Paul [1]: https://dane.sys4.de/smtp/reply.github.molgen.mpg.de
Make rule to install posttls-finger?
Dear Postfix users, I couldn’t find a Make rule to install `posttls-finger`? Did I overlook something, or would I need to copy it manually? Kind regards, Paul
Re: Building and running Postfix as unprivileged user
Dear Wietse, Am 27.04.21 um 14:49 schrieb Wietse Venema: Paul Menzel: In our infrastructure, we are building Postfix from source with an unprivileged user, and also try to run most services as an unprivileged user. Privileged ports are forwarded to unprivileged ports, used by the service, by configuring Linux? packet filter rules with *iptables*. Unprivileged Postfix comes up about once a year in this mailing list. Rather than hashing out the arguments here again, please use a search engine, or visit mailing list archives. Thank you for your prompt reply. Searching for *unprivileged* in the mailing list archives, I actually only found discussion of containers, and Victor’s reply in the thread *Should I be root or postfix user to execute postfix commands?* [1]: Because the Postfix system (master and some delivery agents) can run commands under multiple user identities, Postfix management requires root privileges, and most of the content of /etc/postfix needs to be owned by root and not writable by any other user. The "postfix" user is an unprivileged service account (think of it as a Postfix-specific "nobody" account) used to run internal services at low-privilege (optionally chrooted with root permissions revoked). While it is possible to perform some tasks as "postfix", you're not expected to use that account directly, it is used internally by the Postfix system as appropriate. I am still wondering, why for example the files in `/etc/postfix` have to be owned by root. If you have a search term, I should use, I happily search through the list archive. Kind regards, Paul [1]: https://marc.info/?l=postfix-devel=1=202104=2
Building and running Postfix as unprivileged user
Dear Postfix folks, In our infrastructure, we are building Postfix from source with an unprivileged user, and also try to run most services as an unprivileged user. Privileged ports are forwarded to unprivileged ports, used by the service, by configuring Linux’ packet filter rules with *iptables*. Currently, Postfix checks file ownership at startup according to `postfix-files`, which lists several files to be owned by the user *root* [1], for example: $config_directory:d:root:-:755:u Postfix warns about mismatches at startup. The mail owner and setgid group are already configurable, for example: $queue_directory/maildrop:d:$mail_owner:$setgid_group:730:uc $queue_directory/public:d:$mail_owner:$setgid_group:710:uc […] $command_directory/postdrop:f:root:$setgid_group:2755:u $command_directory/postqueue:f:root:$setgid_group:2755:u Could the same be done for the “postfix owner”? Or are there downsides? Kind regards, Paul [1]: https://github.com/vdukhovni/postfix/blob/2595917e491dfe704390b9bf1100bcdd35b21ae8/postfix/conf/postfix-files#L48
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: 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 Description: S/MIME Cryptographic Signature
Re: TLS: Migrate from *encrypt* to *verify* for specific domain
Dear Viktor, On 09/26/18 16:46, Paul Menzel wrote: > On 09/26/18 09:37, Viktor Dukhovni wrote: > >>> On Sep 26, 2018, at 2:57 AM, Bernhard Schmidt wrote: >>> >>> Large parts of the german universities now use the DFN MailSupport >>> (= inbound mailrelaying and filtering by DFN). The MX records are >>> in mx.srv.dfn.de, which is not signed (whole dfn.de is not signed). >>> So you can have your own zone DNSSEC enabled, but not the one with >>> the MX. >> >> Good to know. Thanks. > > Yes, that is what I meant. Bernhard, thank you for answering and > clarifying that. > >>> I heard they are working on this. This is also a blocker of our >>> project to have DANE-secured SMTP transport for all bavarian >>> universities. >> >> I wish them luck (really sound planning and execution, luck has >> little to do with it). > > Unfortunately, to my knowledge, it’s not high on their to-do list. > Only a few of their clients have requested this feature explicitly. > I’ll work on raising awareness. Bernhard, all the Bavarian > institutions should open a support ticket at the DFN mail support. > It’s my understanding, that this would influence the priority. > >> I also hope that the plan includes securing the downstream hop from >> the DFN gateway to the client institution, unless DFN is also >> providing IMAP, Webmail, ... > > I do not know, how the downstream hop is secured currently. Either > hard coding the IP address of the MTA, using certificates or just > DANE would be feasible. We should do that for our mail system. > Thank you for the reminder. My colleagues already set up TLSA records for mx.molgen.mpg.de [3]. So I’ll ask the mail support to enable dane-only for that connection. > For the record, the DFN network has it’s own network infrastructure > with “cables” and network gear operated over Germany, so it’s not > easy for somebody “from the Internet” to eaves drop [1][2]. Common > methods for securing the transfer should be used nevertheless. Kind regards, Paul > [1]: https://www.dfn.de/xwin/faserplattform/ > [2]: https://www.dfn.de/fileadmin/1Dienstleistungen/XWIN/Topologie.pdf [3]: $ /usr/sbin/posttls-finger -t30 -T180 -c -L verbose,summary mx.molgen.mpg.de posttls-finger: initializing the client-side TLS engine posttls-finger: using DANE RR: _25._tcp.mx.molgen.mpg.de IN TLSA 3 1 2 02:E4:F7:97:85:C7:08:1D:84:63:1A:23:A4:EC:B1:B6:26:24:1F:DC:68:D0:FA:80:B1:10:EF:5E:4C:2C:AF:5E:3F:B9:59:9C:6B:EA:D2:50:4E:4A:BB:6E:2A:73:94:14:11:46:65:F1:69:5C:ED:D7:80:E6:40:5F:19:7E:33:D6 posttls-finger: setting up TLS connection to mx.molgen.mpg.de[141.14.17.8]:25 posttls-finger: mx.molgen.mpg.de[141.14.17.8]:25: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH:!aNULL" posttls-finger: mx.molgen.mpg.de[141.14.17.8]:25: depth=3 verify=0 subject=/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2 posttls-finger: mx.molgen.mpg.de[141.14.17.8]:25: depth=3 verify=1 subject=/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2 posttls-finger: mx.molgen.mpg.de[141.14.17.8]:25: depth=2 verify=1 subject=/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Global - G01 posttls-finger: mx.molgen.mpg.de[141.14.17.8]:25: depth=1 verify=1 subject=/C=DE/O=Max-Planck-Gesellschaft/CN=MPG CA/emailAddress=mpg...@mpg.de posttls-finger: mx.molgen.mpg.de[141.14.17.8]:25: depth=0 verify=1 subject=/C=DE/ST=Berlin/L=Berlin/O=Max-Planck-Gesellschaft/OU=Max-Planck-Institut fuer molekulare Genetik/CN=mx.molgen.mpg.de posttls-finger: mx.molgen.mpg.de[141.14.17.8]:25: depth=0 matched end entity public-key sha512 digest=02:E4:F7:97:85:C7:08:1D:84:63:1A:23:A4:EC:B1:B6:26:24:1F:DC:68:D0:FA:80:B1:10:EF:5E:4C:2C:AF:5E:3F:B9:59:9C:6B:EA:D2:50:4E:4A:BB:6E:2A:73:94:14:11:46:65:F1:69:5C:ED:D7:80:E6:40:5F:19:7E:33:D6 posttls-finger: mx.molgen.mpg.de[141.14.17.8]:25: subject_CN=mx.molgen.mpg.de, issuer_CN=MPG CA, fingerprint=76:A9:04:3A:1E:27:1B:3A:28:9A:C1:A8:9A:64:C9:D0:FB:14:7F:D9, pkey_fingerprint=6A:2A:F0:14:CD:75:B2:D2:58:5A:50:83:F2:DF:A4:8A:4A:E9:66:8E posttls-finger: Verified TLS connection established to mx.molgen.mpg.de[141.14.17.8]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) smime.p7s Description: S/MIME Cryptographic Signature
Re: TLS: Migrate from *encrypt* to *verify* for specific domain
Dear Viktor, dear Bernhard, On 09/26/18 09:37, Viktor Dukhovni wrote: >> On Sep 26, 2018, at 2:57 AM, Bernhard Schmidt wrote: >> >> Large parts of the german universities now use the DFN MailSupport >> (= inbound mailrelaying and filtering by DFN). The MX records are >> in mx.srv.dfn.de, which is not signed (whole dfn.de is not signed). >> So you can have your own zone DNSSEC enabled, but not the one with >> the MX. > > Good to know. Thanks. Yes, that is what I meant. Bernhard, thank you for answering and clarifying that. >> I heard they are working on this. This is also a blocker of our >> project to have DANE-secured SMTP transport for all bavarian >> universities. > > I wish them luck (really sound planning and execution, luck has > little to do with it). Unfortunately, to my knowledge, it’s not high on their to-do list. Only a few of their clients have requested this feature explicitly. I’ll work on raising awareness. Bernhard, all the Bavarian institutions should open a support ticket at the DFN mail support. It’s my understanding, that this would influence the priority. > I also hope that the plan includes securing the downstream hop from > the DFN gateway to the client institution, unless DFN is also > providing IMAP, Webmail, ... I do not know, how the downstream hop is secured currently. Either hard coding the IP address of the MTA, using certificates or just DANE would be feasible. We should do that for our mail system. Thank you for the reminder. For the record, the DFN network has it’s own network infrastructure with “cables” and network gear operated over Germany, so it’s not easy for somebody “from the Internet” to eaves drop [1][2]. Common methods for securing the transfer should be used nevertheless. Kind regards, Paul [1]: https://www.dfn.de/xwin/faserplattform/ [2]: https://www.dfn.de/fileadmin/1Dienstleistungen/XWIN/Topologie.pdf smime.p7s Description: S/MIME Cryptographic Signature
Re: TLS: Migrate from *encrypt* to *verify* for specific domain
Dear Viktor, Am 25.09.2018 um 17:42 schrieb Viktor Dukhovni: On Sep 25, 2018, at 11:34 AM, Viktor Dukhovni wrote: The DANE survey finds 21 domains with DFN-Verein certificates and working DANE. There are almost certainly some that don't have DANE TLSA records, but they could if they wanted to. FWIW, the certificates found among DANE-enabled domains with DFN-Verein issued certificates list the below organizations: Subject Organization = Bayerische Akademie der Wissenschaften Subject Organization = Bergische Universitaet Wuppertal Subject Organization = Hochschule Bremen Subject Organization = Hochschule Trier - Trier University of Applied Sciences Subject Organization = Hochschule fuer angewandte Wissenschaften Augsburg Subject Organization = Ludwig-Maximilians-Universitaet Muenchen Subject Organization = Max-Planck-Gesellschaft I assume, that’s mpifr-bonn.mpg.de. That’s the only institute I am aware of using DANE. Subject Organization = Ruhr-Universitaet Bochum Subject Organization = Technische Hochschule Nuernberg Georg Simon Ohm Subject Organization = Technische Universitaet Dresden Subject Organization = Technische Universitaet Hamburg-Harburg Subject Organization = Technische Universitaet Kaiserslautern Subject Organization = Universitaet Erlangen-Nuernberg Subject Organization = Universitaet Passau Subject Organization = Universitaet Regensburg Subject Organization = Universitaet Rostock Thank you for the overview. Kind regards, Paul
TLS: Migrate from *encrypt* to *verify* for specific domain
Dear Postfix folks, Currently, our `/etc/postfix/tls_policy` looks like below to force encryption when sending messages to other servers in our organization. mpg.deencrypt .mpg.de encrypt We want to improve that. Unfortunately, DANE is not an option as the DFN does not support that, and a lot of German research organizations and institutes use that for receiving messages. We do not have control over the other servers, but want to migrate to *verify* [1]. Can you recommend a strategy how to do that? Is there a way to use verify, and then fall back to encrypt, but log that, so that the other postmasters can be informed? Or should we maintain a separate list in some central place, which interested parties contribute to? Kind regards, Paul [1]: http://www.postfix.org/TLS_README.html#client_tls_verify
How to financially support Postfix project?
Dear Postfix folks, Looking at the Postfix Web site [1], I couldn’t find any information if Postfix needs financial support to ensure the maintenance and improvement of the code. As the background, a lot of public organizations use Postfix in their infrastructure, and, as for example with OpenSSL, they do not pay anything for it, but they expect that it is maintained and improved. This is a fatal attitude in my opinion. Additionally, the administrators normally do not need training or support, as a lot of them are quite capable, and know their way around Postfix. Also, public organizations getting tax payer money also have a hard time to donate money. So, can the Postfix project be supported financially? Can “core developers” like Wietse and Viktor be supported? Are their companies providing support contracts, where employees are actively supporting the Postfix development by either sending patches (including documentation) or promising to give a certain amount of that money to the Postfix project? I found for example credativ [2]. Kind regards, Paul [1] http://www.postfix.org/ [2] http://www.credativ.de/software/software%C3%BCbersicht/mail/postfix
Re: How to fall back from `dane-only` to `secure`?
Dear Viktor, On 07/06/17 20:11, Viktor Dukhovni wrote: On Thu, Jul 06, 2017 at 07:37:47PM +0200, Paul Menzel wrote: There are several SMTP servers, where messages should only be sent over a secure channel. But, the postmasters have set up the servers differently. Some use CAs to sign their certificates and some DANE with self-signed certificates. To avoid maintaining two TLS policies, one where for `smtp_tls_security_level` the value `secure` is specified, and another with `dane-only` [1], and keeping an eye out, when SMTP switch to or from DANE, is there a way to maintain one list? So if no DANE records are published, it falls back to secure certificate verification? Like `dane` falls back to `may`? Wietse and I have discussed something along these lines some time back, but nothing of that sort has as yet been implemented. Would paying for the work speed up the implementation? If yes, who could be contracted for that work? Kind regards, Paul
Re: Change of SMTP encryption policy at Google?
Dear Gary, On 09/11/17 11:20, Gary wrote: https://threatpost.com/google-reminding-admins-http-pages-will-be-marked-not-secure-in-october/127709/ This site says Oct 24. I recall Oct 1. Maybe it was pushed back. Please note, this is about the HTTP/HTTPS protocols and not SMTP. […] Kind regards, Paul
Change of SMTP encryption policy at Google? (was: Letsencrypt tip)
Dear Gary, On 09/11/17 10:59, Gary wrote: […] (Fortunately I'm on a test domain, getting ready for the Oct 1st Google > insistence on encryption.) Could you please point me to the relevant announcement about that policy change? […] Kind regards, Paul
Re: TLS on 587
Dear Mohammed, On 08/14/17 12:53, Mohammed Khalid Ansari wrote: I have configured my postfix to run on 587. When I choose connection type as 'STARTTLS' everything is fine but when I choose 'SSL/TLS', the client throws error. Normally, but deprecated, port 465 is used for “direct” SSL/TLS (without STARTTLS) [1] 465 – This port has been deprecated since RFC 2487, after being briefly assigned for secure SMTP in the 1990s. Despite this, it is commonly used by mail providers[20][21] I can configure 'STARTTLS' in outlook and proceed but on my cell phone I don't have don't option and hence not able to connect. That’s client dependent. Which client do you use. You should contact them. Kind regards, Paul [1] https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol
Re: Migrating 2.11 to 3.2
Dear Nikolaos, On 07/27/17 11:54, Nikolaos Milas wrote: We are moving to a new (virtual) server (from CentOS 5 with Postfix 2.11.6 to CentOS 7 with Postfix 3.2.2). I have moved the original configuration to the new server and Postfix won't start; I am getting: # systemctl status postfix postfix.service - Postfix Mail Transport Agent Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Thu 2017-07-27 12:25:14 EEST; 12min ago Process: 21895 ExecStart=/usr/sbin/postfix start (code=exited, status=1/FAILURE) Process: 21893 ExecStartPre=/usr/libexec/postfix/chroot-update (code=exited, status=0/SUCCESS) Process: 21890 ExecStartPre=/usr/libexec/postfix/aliasesdb (code=exited, status=0/SUCCESS) Main PID: 14815 (code=killed, signal=TERM) Jul 27 12:25:12 vmail2.noa.gr postfix[21895]: /usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: 127.0.0.1:10040_time_limit=3600 Jul 27 12:25:12 vmail2.noa.gr postfix[21895]: /usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: 127.0.0.1:10040_time_limit=3600 Jul 27 12:25:12 vmail2.noa.gr postfix[21895]: /usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: 127.0.0.1:10040_time_limit=3600 Jul 27 12:25:12 vmail2.noa.gr postfix[21895]: /usr/libexec/postfix/post-install: Error: /etc/postfix/postfix-files is not a file. Jul 27 12:25:12 vmail2.noa.gr postfix/postfix-script[21913]: fatal: unable to create missing queue directories Jul 27 12:25:13 vmail2.noa.gr postfix/postfix-script[21914]: fatal: Postfix integrity check failed! Jul 27 12:25:14 vmail2.noa.gr systemd[1]: postfix.service: control process exited, code=exited status=1 Jul 27 12:25:14 vmail2.noa.gr systemd[1]: Failed to start Postfix Mail Transport Agent. Jul 27 12:25:14 vmail2.noa.gr systemd[1]: Unit postfix.service entered failed state. Jul 27 12:25:14 vmail2.noa.gr systemd[1]: postfix.service failed. I also tried: # /usr/libexec/postfix/post-install create-missing postconf: warning: /etc/postfix/main.cf: unused parameter: 127.0.0.1:10040_time_limit=3600 /usr/libexec/postfix/post-install: Error: /postfix-files is not a file. Can you please let me know what may be the issue here? Please post the output of the commands below. ``` $ ls -l /etc/postfix/ $ file /etc/postfix/postfix-files ``` […] Kind regards, Paul
Re: Enforce TLS to MX
Dear anonymous, On 07/24/17 14:33, post...@xmas.de wrote: isn't it possible to enforce TLS outbound to an MX ? In the example below, if mx0.example.com isn't offering TLS the email is sent unencrypted !? Enforcing TLS to a domain ist working as expected. > tls_policy: [mx0.example.com] encrypt [4.3.2.1]encrypt What isn’t working as expected? Please provide the log entries. Kind regards, Paul
Re: postfix + selinux - does it make sense ?
Dear Zalezny, On 07/11/17 09:31, Zalezny Niezalezny wrote: I would like to know your opinion about selinux + postfix? Does anyone using it? Does it make sense to set up some policies for postfix? It largely depends on your threat model, but in my opinion, as it doesn’t hurt, I would say it makes a lot of sense to set up SE Linux. Especially as a basic(?) policy is already available, and depending on your setup, you only need to tune a few things. Kind regards, Paul PS: As you only sent plain text, it’d be awesome if you configure your Google Mail account in a way, that it doesn’t include HTML parts in the message [1]. [1] https://www.lifewire.com/how-to-send-a-message-in-plain-text-from-gmail-1171963
