TLS verification problem - ca untrusted, but it shouldn't be
Hello, this is not my only problem with TLS verification - and I'm struggling to debug this: *mail.mail.protection.outlook.com cannot be verified by postfix: posttls-finger: certificate verification failed for blahblahommited.mail.protection.outlook.com[104.47.14.36]:25: untrusted issuer /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA But I do trust this CA: smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt Which I did verify by: openssl s_client -CAfile /var/spool/postfix/etc/ssl/certs/ca-certificates.crt -connect blahblahommited.mail.protection.outlook.com:25 --starttls smtp That gave: ... SSL handshake has read 3975 bytes and written 543 bytes Verification: OK ... SSL-Session: ... Verify return code: 0 (ok) There is an intermediate CA involved: issuer=C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization Validation CA - SHA256 - G3 But this Certificate is signed by above mentioned CA (which posttls-finger says it doesn't trust). My system is a Debian Buster, postfix version 3.4.10-0+deb10u1. Any pointers to resolve this would be appreciated. lg, -- Rainer Ruprechtsberger Volkshilfe Oberösterreich IT 4020 Linz, Glimpfingerstrasse 48 Tel.: +43 732 3405 123 Mobil.: +43 676 8734 1123 ZVR Zahl: 064371505 Volkshilfe. Wir sind für die Menschen da.
Re: TLS verification problem - ca untrusted, but it shouldn't be
On Wed, 8 Jul 2020 09:03:52 +0200 Rainer Ruprechtsberger wrote: > Hello, > > this is not my only problem with TLS verification - and I'm struggling > to debug this: > > *mail.mail.protection.outlook.com cannot be verified by postfix: > posttls-finger: certificate verification failed for > blahblahommited.mail.protection.outlook.com[104.47.14.36]:25: > untrusted issuer /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign > Root CA > > But I do trust this CA: > smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt > > Which I did verify by: > openssl s_client -CAfile > /var/spool/postfix/etc/ssl/certs/ca-certificates.crt -connect > blahblahommited.mail.protection.outlook.com:25 --starttls smtp > > That gave: > ... > SSL handshake has read 3975 bytes and written 543 bytes > Verification: OK > ... > SSL-Session: > ... > Verify return code: 0 (ok) > > There is an intermediate CA involved: > issuer=C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization > Validation CA > - SHA256 - G3 > > But this Certificate is signed by above mentioned CA (which > posttls-finger says it doesn't trust). > > My system is a Debian Buster, postfix version 3.4.10-0+deb10u1. > > Any pointers to resolve this would be appreciated. > > lg, > I'd the same problem, I solved creating a certificate chain with the server certificate and the CA intermediate certificate with: cat server.cer intermediate.cer > server_chain.cer After that in the main.cf you use the server_chain.cer as smtpd_tls_cert_file. -- --- Enrico Morelli System Administrator | Programmer | Web Developer CERM - Polo Scientifico via Sacconi, 6 - 50019 Sesto Fiorentino (FI) - ITALY
Re: TLS verification problem - ca untrusted, but it shouldn't be
Hi, > cat server.cer intermediate.cer > server_chain.cer > > After that in the main.cf you use the server_chain.cer as > smtpd_tls_cert_file. > my problem is the other direction - I want to verify a remote SMTP server. Postfix is a smtp client in this instance.. TLS verification is required for a larger number of domains in my case. It is certainly possible to do match fingerprint and so on.. but all this is subject to changes and running after these changes and keeping the tls_policy map current is one of my headaches. /r
Re: TLS verification problem - ca untrusted, but it shouldn't be
On 2020-07-08 09:03, Rainer Ruprechtsberger wrote: Hello, this is not my only problem with TLS verification - and I'm struggling to debug this: *mail.mail.protection.outlook.com cannot be verified by postfix: posttls-finger: certificate verification failed for blahblahommited.mail.protection.outlook.com[104.47.14.36]:25: untrusted issuer /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA How did you call posttls-finger? Did you use "-F" and point it to /etc/ssl/certs/ca-certificates.crt? But I do trust this CA: smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt This setting does not affect posttls-finger What does postfix log when you send a mail there? -- Christian Kivalo
Re: TLS verification problem - ca untrusted, but it shouldn't be
On 08.07.20 13:12, Christian Kivalo wrote: [...] > How did you call posttls-finger? Did you use "-F" and point it to > /etc/ssl/certs/ca-certificates.crt? > >> But I do trust this CA: >> smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt > This setting does not affect posttls-finger Thanks - I did not understand this. My assumption was that posttls-finger does what postfix would do (unless you tell it to do otherwise). And the original riddle is solved: posttls-finger is able to verify that as well. > > What does postfix log when you send a mail there?postfix/smtp[12220]: > 2EB716002D: Server certificate not veri fied I require 'verify' via tls policy for that domain. Now.. the question is where this originated since apparently the server is able to verify that now. Will instruct my users to re-try sending an email and have a look in the logs with higher loglevel (smtp_tls_loglevel = 1 so far). Thanks, /r
Re: rewrite all but one address
On 07/07/2020 18:32, Wietse Venema wrote: Rewrite the address to itself (this is how recursion stops). Is this covered by your suggestion below? (I'd use virtual_alias_maps, because canonical maps can change message headers which may not be needed). So, http://www.postfix.org/virtual.5.html and like this...? $ cat /etc/postfix/virtual @test.com @example.com joe.blo...@test.com /home/jbloggs/.maildir Do I keep or change any of these? mydestination = mail.test.com, test.com, localhost.localdomain, localhost, localdomain myhostname = mail.test.com myorigin = /etc/mailname (test.com) Thanks, Paul
Re: TLS verification problem - ca untrusted, but it shouldn't be
On Wed, Jul 08, 2020 at 09:03:52AM +0200, Rainer Ruprechtsberger wrote: > this is not my only problem with TLS verification - and I'm struggling > to debug this: > > *mail.mail.protection.outlook.com cannot be verified by postfix: > posttls-finger: certificate verification failed for > blahblahommited.mail.protection.outlook.com[104.47.14.36]:25: untrusted > issuer /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA > > But I do trust this CA: > smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt The posttls-finger(1) utility does not use the "smtp_tls_CAfile" parameter, which is specific to the smtp(8) delivery agent. Its CAfile has to be set explicitly via the "-F" command-line option. > Which I did verify by: > openssl s_client -CAfile > /var/spool/postfix/etc/ssl/certs/ca-certificates.crt -connect > blahblahommited.mail.protection.outlook.com:25 --starttls smtp /var/spool/postfix/etc/ssl/certs/ca-certificates.crt != /etc/ssl/certs/ca-certificates.crt Why are you running s_client with that particular choice of filename? Along with any private keys, DH parameters, ... the CAfile is loaded by Postfix *before* it drops privileges and enters the chroot jail. -- Viktor.
Re: rewrite all but one address
> On Jul 8, 2020, at 6:13 AM, Paul Littlefield wrote: > > $ cat /etc/postfix/virtual > @test.com @example.com > joe.blo...@test.com /home/jbloggs/.maildir NO! The RHS value in virtual(5) tables is an *address*, not a filename. The correct syntax is: @test.com @example.com joe.blo...@test.com joe.blo...@test.com Delivering that to a particular file is done via aliases(5) or virtual_mailbox_maps, depending on whether that address resolves to local(8) or virtual(8). It could also be handed off via LMTP to Cyrus IMAP or Dovecot, in which case the mailbox location is configured outside of Postfix. -- Viktor.
Re: content_filter with external script and virtual_alias_maps
Stats Student: > On Tue, Jul 7, 2020 at 4:19 PM Wietse Venema wrote: > > > > Stats Student: > > > On Tue, Jul 7, 2020 at 2:15 PM Wietse Venema wrote: > > > > > > > > Stats Student: > > > > > Thank you, but I still do not understand why I need to provide > > > > > additional user aliases. If my system receives a message for > > > > > > > > To deliver a message to two destinations > > > > > > > > 1) a script > > > > 2) a maildir file > > > > > > > > That message needs to have (surprise!) two destinations. > > > > > > > > 1) a destination that delivers to the script > > > > 2) a destination that delivers to the maildir file > > > > > > > > You can add that second destination with virtual_alias_maps, > > > > sender_bcc_maps, recipient_bcc_maps, .forward files, and so on. > > > > > > > > Wietse > > > > > > > Could you please show an example of what would go into one of those > > > maps to indicate a maildir destination? > > > > Prerequisites: > > foo@example delivers to script > > bar@example delivers to maildir > > > > Use virtual_alias_maps with: > > foo@example foo@example, bar@example > > > > Now, mail for foo@example goes to script and maildir. > > > > How to deliver to script or maildir? Use transport_maps to select > > a delivery agent that delivers to script (local or pipe delivery > > agent) or maildir (virtual or local delivery agent). > > > > foo@example > > Sorry if I am not explaining the requirement correctly. > > I need the same message addressed to f...@example.com to be delivered > to *two* places - the script AND the mailstore, *not* two different > accounts. I did NOT tell you to use two accounts. I told you to use two email addresses. An email address IS NOT an account. > I do *not* want messages addressed to f...@example.com to also go to > b...@example.com which is what the virtual_alias_maps you showed would > do. Again, an email address IS NOT an account. If it helps to rephrase the example: Prerequisites: foo@example delivers to script foo.maildir@example delivers to maildir Use virtual_alias_maps with: foo@example foo@example, foo.maildir@example Now, mail for foo@example goes to script and maildir. Wietse
Re: lmd support -- available as an 'add on', or just 'compiled in'?
On 7/6/20 2:52 PM, Viktor Dukhovni wrote: > Well, Fedora 31 does provide separate packages for multiple optional > lookup table drivers: > > postfix-cdb.x86_64 : Postfix CDB map support > postfix-ldap.x86_64 : Postfix LDAP map support > postfix-mysql.x86_64 : Postfix MySQL map support > postfix-pcre.x86_64 : Postfix PCRE map support > postfix-pgsql.x86_64 : Postfix PostgreSQL map support > postfix-sqlite.x86_64 : Postfix SQLite map support > > They just seem to have left out LMDB for some reason, don't know why. > You reported opening an issue with the Fedora Postfix maintainers, > that's the right thing to do. For those interested, LMDB support has now been added to Fedora builds of Postfix. https://src.fedoraproject.org/rpms/postfix/blob/master/f/postfix.spec#_787 I haven't yet installed / verified, but looking at the spec, it looks straightforward. Atm, it's pending release; should promote soon-ish ...
Re: TLS verification problem - ca untrusted, but it shouldn't be
On 08.07.20 14:34, Viktor Dukhovni wrote: > > /var/spool/postfix/etc/ssl/certs/ca-certificates.crt != > /etc/ssl/certs/ca-certificates.crt > > Why are you running s_client with that particular choice of filename? > Along with any private keys, DH parameters, ... the CAfile is loaded by > Postfix *before* it drops privileges and enters the chroot jail. > Because smtp has 'y' in 'chroot' in master.cf - therefore I assumed that it looks in its chroot for the CA file. Anyway - I did verify it gets copied correctly at postfix startup. One of the pitfalls I did think of.. ;) Still not sure what actually happened.. but since -F was explained to me there is no longer any difference between posttls-finger and s_client (both verify). So now I do need to look where on earth the can't verify came from since it looks like I can't reproduce it (which I thought I did when I posted on the list). /r
Re: content_filter with external script and virtual_alias_maps
> Again, an email address IS NOT an account. > Ok, understood. > If it helps to rephrase the example: > > Prerequisites: > foo@example delivers to script > foo.maildir@example delivers to maildir I don't know how to satisfy the last prerequisite. Can you help? Currently have the following configuration - virtual_mailbox_maps = pgsql:/etc/postfix/pgsql_virtual_mailbox_maps.cf /etc/postfix/pgsql_virtual_mailbox_maps.cf - query = SELECT login FROM usr WHERE login = '%u I also tried changing the output of the query which didn't make a difference (I think I read somewhere that Postfix treats the return as a boolean) query = SELECT login || '\t' || login||'/' FROM usr WHERE login = '%u I tried setting these options, as well, but that didn't work either - virtual_mailbox_base = /var/mail home_mailbox = Maildir/ > > Use virtual_alias_maps with: > foo@example foo@example, foo.maildir@example > If I understand correctly, I need to effectively "make up" two emails for each account and somehow configure separate deliveries for each email. I would think the delivery configuration would be based on the domain, but I guess you are suggesting it be done using the login part - foo vs foo.maildir (using "login" loosely here). > Now, mail for foo@example goes to script and maildir. > > Wietse
Re: rewrite all but one address
On 08/07/2020 13:57, Viktor Dukhovni wrote: NO! The RHS value in virtual(5) tables is an*address*, not a filename. The correct syntax is: @test.com @example.com joe.blo...@test.com joe.blo...@test.com Delivering that to a particular file is done via aliases(5) or virtual_mailbox_maps, depending on whether that address resolves to local(8) or virtual(8). It could also be handed off via LMTP to Cyrus IMAP or Dovecot, in which case the mailbox location is configured outside of Postfix. Got it. Do I keep or change any of these? mydestination = mail.test.com, test.com, localhost.localdomain, localhost, localdomain myhostname = mail.test.com myorigin = /etc/mailname (test.com) Thanks, Paul
Re: content_filter with external script and virtual_alias_maps
Stats Student: > > Again, an email address IS NOT an account. > > > > Ok, understood. > > > If it helps to rephrase the example: > > > > Prerequisites: > > foo@example delivers to script > > foo.maildir@example delivers to maildir > > I don't know how to satisfy the last prerequisite. Can you help? There are so many ways. One is to use transport_maps to route foo.maildir@example to the virtual delivery agent, and then configure virtual_uid_maps, virtual_gid_maps, and virtual_mailbox_maps. > Currently have the following configuration - > > virtual_mailbox_maps = pgsql:/etc/postfix/pgsql_virtual_mailbox_maps.cf The result must be a pathname that ends in '/'. That is what enables maildir delivery. You can test that with the postmap command. Wietse
Re: content_filter with external script and virtual_alias_maps
On Wed, Jul 8, 2020 at 1:10 PM Wietse Venema wrote: > > Stats Student: > > > Again, an email address IS NOT an account. > > > > > > > Ok, understood. > > > > > If it helps to rephrase the example: > > > > > > Prerequisites: > > > foo@example delivers to script > > > foo.maildir@example delivers to maildir > > > > I don't know how to satisfy the last prerequisite. Can you help? > > There are so many ways. One is to use transport_maps to route > foo.maildir@example to the virtual delivery agent, and then configure > virtual_uid_maps, virtual_gid_maps, and virtual_mailbox_maps. I don't use transport_maps currently so it's unclear to me how this would work with the existing setup which I assume already uses the virtual delivery agent with virtual_transport. Can you please show an example of the transport_maps with two routes?
Re: content_filter with external script and virtual_alias_maps
Stats Student: > On Wed, Jul 8, 2020 at 1:10 PM Wietse Venema wrote: > > > > Stats Student: > > > > Again, an email address IS NOT an account. > > > > > > > > > > Ok, understood. > > > > > > > If it helps to rephrase the example: > > > > > > > > Prerequisites: > > > > foo@example delivers to script > > > > foo.maildir@example delivers to maildir > > > > > > I don't know how to satisfy the last prerequisite. Can you help? > > > > There are so many ways. One is to use transport_maps to route > > foo.maildir@example to the virtual delivery agent, and then configure > > virtual_uid_maps, virtual_gid_maps, and virtual_mailbox_maps. > > I don't use transport_maps currently so it's unclear to me how this > would work with the existing setup which I assume already uses the > virtual delivery agent with virtual_transport. Can you please show an > example of the transport_maps with two routes? In that case you already have maildir delivery, no transport map needed as long as foo.maildir has an entry in virtual_*_maps, and virtual_mailbox_maps for foo.maildir returns a pathname ending in '/'. Wietse
Re: content_filter with external script and virtual_alias_maps
> > > > I don't use transport_maps currently so it's unclear to me how this > > would work with the existing setup which I assume already uses the > > virtual delivery agent with virtual_transport. Can you please show an > > example of the transport_maps with two routes? > > In that case you already have maildir delivery, no transport map > needed as long as foo.maildir has an entry in virtual_*_maps, and > virtual_mailbox_maps for foo.maildir returns a pathname ending in > '/'. I don't have Maildir delivery, the virtual_transport points to a custom defined delivery agent with pipe which executes a script (which you suggested at the beginning of this exchange) and that works fine. What I need is an additional "route" that would send the message to Maildir *in addition* to the pipe/script. I am guessing this is done through transport_maps but as I said before, I don't know how. Let me know if what I am asking isn't clear and I'll be happy to provide further details. I did post all of my configuration last week but can include it in the email, if that's the preferred method.
Re: content_filter with external script and virtual_alias_maps
On Wed, Jul 08, 2020 at 04:12:24PM -0700, Stats Student wrote: > Let me know if what I am asking isn't clear and I'll be happy to > provide further details. I did post all of my configuration last week > but can include it in the email, if that's the preferred method. This list is no substitute for a basic working knowledge of system administration, and a working knowledge of the Postfix architecture as described in the No Starch or O'Reilly books. You can get answers to specific focused questions here, but likely not extensive hand-holding to produce a working configuration if you're unfamiliar with the basics. -- Viktor.
Re: content_filter with external script and virtual_alias_maps
On Wed, Jul 8, 2020 at 4:18 PM Viktor Dukhovni wrote: > > On Wed, Jul 08, 2020 at 04:12:24PM -0700, Stats Student wrote: > > > Let me know if what I am asking isn't clear and I'll be happy to > > provide further details. I did post all of my configuration last week > > but can include it in the email, if that's the preferred method. > > This list is no substitute for a basic working knowledge of system > administration, and a working knowledge of the Postfix architecture as > described in the No Starch or O'Reilly books. > > You can get answers to specific focused questions here, but likely not > extensive hand-holding to produce a working configuration if you're > unfamiliar with the basics. > > -- > Viktor. So you know, I bought the O'Reilly book 18 years ago, used it for 10 years, then donated it to a library. I don't think what I am asking is "basic", but then again I don't configure Postfix every day. Regards.
