Re: GhettoForge Postfix3
On Tue, Jan 18, 2022 at 11:14 PM wrote: > > likely at least a minimal attempt to avoid naming conflicts. renaming > > forked the code (hopefully) helps avoid blaming Wietse for whatever gets > > broken in that fork. > > Wait, so its a fork of Postfix? > No. > And not the same code as what Wietse releases for the same version? > They provide srpms, you can easily open it and see for yourself. All the patches are included, the .spec file is included and postfix source is included (it's official postfix source, i verified the checksums). I use the repo on some installations and I am very happy with it. I do not know about the name, but if I had to GUESS, it's called postfix3 because rhel7 has postfix 2.10 (or something) by default. So the name indicates a major version bump. It's pretty common in rhel world. And it remained named this way rhel 8 for convenience? Just ask the maintainers. They include a contacts and mailing list, irc channel. There is also email in specfile changelog. Please don't speculate. J.
Re: GhettoForge Postfix3
On 2022-01-19 01:00, jdebert wrote: On Tue, 18 Jan 2022 17:13:32 -0500 post...@ptld.com wrote: Wait, so its a fork of Postfix? It is not. It was intended to be a way for Red Hat / derivate users to be able to have up-to-date Postfix features. Users' needs are being actively addressed here, in the upstream project, but not in Red Hat Enterprise Linux. And not the same code as what Wietse releases for the same version? To my knowledge, it is the same code, unpatched. It's whatever the maintainer of that code wants, intends, etc. Why not ask the maintainer? The maintainer is on this list, but due to time zones and perhaps personal circumstances has not been able to reply yet. You can also find him in irc.libera.chat/#postfix as "pj". -- http://rob0.nodns4.us/
Routing Gmail/Workspace mail through postfix first
Hi, I'm using postfix-3.5.10 and would like to use it to front-end a domain currently being managed by Google Workspace to be able to send mail through our filters first. I know I'll need to redirect the MX, but how do I obtain a user list so I'm not just forwarding all email received for the domain through as a relay, and instead only to those users with current accounts? In the past, I believe it was using LDAP, but perhaps that's changed now? All references I currently see are using SASL and require the username/password combination of the user accounts. Any guidance on how best to do this would be appreciated. Thanks, Alex
Re: Adding Additional domains and outgoing email
On Tue, Jan 18, 2022 at 11:14:58AM -0500, Ruben Safir wrote: > On Tue, Jan 18, 2022 at 04:50:11PM +0100, Matus UHLAR - fantomas wrote: > > On 18.01.22 10:32, Ruben Safir wrote: > > >I am sorry, that is wrong. I am getting main and master confused. > > [...] How do I know that dovecot is being querried for authentication via sasl and how would I debug that? I think it is not being seen. > > > > >THIS is in Master > > >www2:/etc/postfix # grep "smtpd" master.cf|grep -v "#" > > > > don't use grep for master.cf, there are usuallu options on next lines > > > > >smtp inet n - n - - smtpd > > >submission inet n - n - - smtpd > > > -o smtpd_tls_security_level=encrypt > > > > > >So it looks I have work to do in master. > > > > # postconf -M smtps submission > > submission inet n - y - - smtpd -o > > syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o > > smtpd_sasl_auth_enable=yes -o smtpd_tls_auth_only=yes -o > > smtpd_client_restrictions=$mua_client_restrictions -o > > smtpd_helo_restrictions=$mua_helo_restrictions -o > > smtpd_relay_restrictions=permit_sasl_authenticated,reject -o > > milter_macro_daemon_name=ORIGINATING > > smtps inet n - y - - smtpd -o > > syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes -o > > smtpd_sasl_auth_enable=yes -o > > smtpd_client_restrictions=$mua_client_restrictions -o > > smtpd_helo_restrictions=$mua_helo_restrictions -o > > smtpd_relay_restrictions=permit_sasl_authenticated,reject -o > > milter_macro_daemon_name=ORIGINATING > > > > > > www2:~ # postconf -M submission > submission inet n - n - - smtpd -o > syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o > smtpd_sasl_auth_enable=yes -o smtpd_sasl_auth_enable=yes -o > smtpd_recipient_restrictions=permit_sasl_authenticated,reject > > www2:~ # postconf -M smtp > smtp inet n - n - - smtpd > smtp unix - - n - - smtp > > although this doesn't really say what the files say or which files are > being edited. > > > > > > > > > -- > > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > > Warning: I wish NOT to receive e-mail advertising to this address. > > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > > "To Boot or not to Boot, that's the question." [WD1270 Caviar] > > -- > So many immigrant groups have swept through our town > that Brooklyn, like Atlantis, reaches mythological > proportions in the mind of the world - RI Safir 1998 > http://www.mrbrklyn.com > > DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 > http://www.nylxs.com - Leadership Development in Free Software > http://www2.mrbrklyn.com/resources - Unpublished Archive > http://www.coinhangout.com - coins! > http://www.brooklyn-living.com > > Being so tracked is for FARM ANIMALS and extermination camps, > but incompatible with living as a free human being. -RI Safir 2013 -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and extermination camps, but incompatible with living as a free human being. -RI Safir 2013
Re: Routing Gmail/Workspace mail through postfix first
Alex: > Hi, > > I'm using postfix-3.5.10 and would like to use it to front-end a > domain currently being managed by Google Workspace to be able to send > mail through our filters first. Is this for - Email from "users inside the domain" to Google Workspace? This is like a relayhost for authenticated users, configured to forward email for its domain to Google Workspace, and to send other email directly. - Email from "users in other domains" to Google Workspace? There is no user authentication here, and the Postfix server has to figure out what addresses are valid. This is like a primary MX that forwards email for its domain a backend service (in this case Google). Both can be implemented with the same Postfix configuration. Wietse > I know I'll need to redirect the MX, but how do I obtain a user list > so I'm not just forwarding all email received for the domain through > as a relay, and instead only to those users with current accounts? > > In the past, I believe it was using LDAP, but perhaps that's changed > now? All references I currently see are using SASL and require the > username/password combination of the user accounts. > > Any guidance on how best to do this would be appreciated. > Thanks, > Alex >
Re: Routing Gmail/Workspace mail through postfix first
On 2022-01-19 at 08:23:45 UTC-0500 (Wed, 19 Jan 2022 08:23:45 -0500) Alex is rumored to have said: Hi, I'm using postfix-3.5.10 and would like to use it to front-end a domain currently being managed by Google Workspace to be able to send mail through our filters first. I know I'll need to redirect the MX, but how do I obtain a user list so I'm not just forwarding all email received for the domain through as a relay, and instead only to those users with current accounts? Forward address verification works well for this. See the ADDRESS_VERIFICATION_README and the documentation of reject_unverified_recipient. Note that while doing sender (i.e. reverse-path) verification is a highly problematic tactic, forward recipient verification of users in domains you are the MX for is generally safe. In the past, I believe it was using LDAP, but perhaps that's changed now? In an environment with comprehensive LDAP (e.g. Windows AD realms) you can use it, but forward SMTP verification can be better as it is a 'ground truth' check of whether an address can accept mail. It also works in a broader range of circumstances without requiring anything other than working SMTP relay. All references I currently see are using SASL and require the username/password combination of the user accounts. It's not at all clear to me how/why one would use/need user authentication in this scenario... -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
TLS returning self-signed cert
My Postfix Server 3.6.2 running on a newly created Fedora 35 is returning self-signed SSL certs, where none were configured. We're using a multi-cert Entrust certificate. All domains on the box get email from one single mx domain. To be clear TLS works, but if I run SSL Labs report it comes back as Not being Trusted. Running CheckTLS.com, this is the error Certificate #1 of 1 (sent by MX): Cert VALIDATION ERROR(S): unable to get local issuer certificate This may help: What Is An Intermediate Certificate So email is encrypted but the recipient domain is not verified ... TLS successfully started on this server I have all files in the same directory, ServerCert.pem (from Entrust), Bundle2.crt (from Entrust), CA-combines (private key/Server Cert). No other file is configured in either Dovecot 2.3.17.1 (476cd46418) points to the same directory and files. The Cert serial number is coming back wrong using SSL Labs, but a web site (on same server) returns the correct serial number (remember everything points to the same files) I've confirmed the Cert is correct and the private key as well. I've tried changing the CAFile to include/not include Server Certificate, Intermediate, Root, Private Key and either TLS dies, or it "works", but the above error is obtained. I'm at a dead-end as far as researching the error goes. Where am I going wrong..
Re: TLS returning self-signed cert
Wayne Spivak: > My Postfix Server 3.6.2 running on a newly created Fedora 35 is returning > self-signed SSL certs, where none were configured. Why do you believe that this is a self-signed certifcate? Isn't this an issue where the server returns a leaf certificate without intermediate certificates? Wietse > We're using a multi-cert Entrust certificate. All domains on the box get > email from one single mx domain. > > To be clear TLS works, but if I run SSL Labs report it comes back as Not > being Trusted. > > Running CheckTLS.com, this is the error > > Certificate #1 of 1 (sent by MX): >Cert VALIDATION ERROR(S): unable to get local issuer certificate > This may help: What Is An Intermediate Certificate >So email is encrypted but the recipient domain is not verified >... >TLS successfully started on this server > > I have all files in the same directory, ServerCert.pem (from Entrust), > Bundle2.crt (from Entrust), CA-combines (private key/Server Cert). > > No other file is configured in either Dovecot 2.3.17.1 (476cd46418) points > to the same directory and files. > > The Cert serial number is coming back wrong using SSL Labs, but a web site > (on same server) returns the correct serial number (remember everything > points to the same files) > > I've confirmed the Cert is correct and the private key as well. > > I've tried changing the CAFile to include/not include Server Certificate, > Intermediate, Root, Private Key and either TLS dies, or it "works", but the > above error is obtained. > > I'm at a dead-end as far as researching the error goes. > > Where am I going wrong.. > > > >
RE: TLS returning self-signed cert
Hi Wietse, It's been a very long time since we communicated. This from SSL Labs states "self-signed": Path #1: Not trusted (path does not chain to a trusted anchor) 1 Sent by server mcq.sbanetweb.com Fingerprint SHA256: 1b48d54fd173fa980ca0ba8e2bbb5aabce3bbb9faf67bae4f375816155699efe Pin SHA256: D9BrKzFpjkpGhv91bgkZqQIWlqPNIHPHmIhYYwDChGY= RSA 2048 bits (e 65537) / SHA256withRSA 2 Sent by server Not in trust storemcq.sbanetweb.com Self-signed Fingerprint SHA256: 1ff50fe2d898b639ee07e668b4a4acf5c3f878539a24be6edc3cc011991a9db3 Pin SHA256: 2gJ7C4jfxgMQJMF09EznMu8UGd5sdBmQDyPrv5pIcHU= RSA 4096 bits (e 65537) / SHA256withRSA If it is an Intermediate, I refer to my orginal email, "where am I going wrong". Thank you! Wayne -Original Message- From: owner-postfix-us...@postfix.org On Behalf Of Wietse Venema Sent: Wednesday, January 19, 2022 1:03 PM To: Wayne Spivak Cc: postfix-users@postfix.org Subject: Re: TLS returning self-signed cert Wayne Spivak: > My Postfix Server 3.6.2 running on a newly created Fedora 35 is > returning self-signed SSL certs, where none were configured. Why do you believe that this is a self-signed certifcate? Isn't this an issue where the server returns a leaf certificate without intermediate certificates? Wietse > We're using a multi-cert Entrust certificate. All domains on the box > get email from one single mx domain. > > To be clear TLS works, but if I run SSL Labs report it comes back as > Not being Trusted. > > Running CheckTLS.com, this is the error > > Certificate #1 of 1 (sent by MX): >Cert VALIDATION ERROR(S): unable to get local issuer > certificate This may help: What Is An Intermediate Certificate >So email is encrypted but the recipient domain is not verified >... >TLS successfully started on this server > > I have all files in the same directory, ServerCert.pem (from Entrust), > Bundle2.crt (from Entrust), CA-combines (private key/Server Cert). > > No other file is configured in either Dovecot 2.3.17.1 (476cd46418) > points to the same directory and files. > > The Cert serial number is coming back wrong using SSL Labs, but a web > site (on same server) returns the correct serial number (remember > everything points to the same files) > > I've confirmed the Cert is correct and the private key as well. > > I've tried changing the CAFile to include/not include Server > Certificate, Intermediate, Root, Private Key and either TLS dies, or > it "works", but the above error is obtained. > > I'm at a dead-end as far as researching the error goes. > > Where am I going wrong.. > > > >
Appricate some help in understanding a connection refused situation.
postconf mail_version mail_version = 3.6.3 OS FreeBSD-13.0p5 I am in the process of transferring one of our MX services to a new host. During one of the test sessions against live traffic a connection to the final delivery host from the test service could be made. In consequence several messages resulted in a delayed delivery notice. It is these messages for which I am seeing SMTP connection refused from the original sending hosts. The diagnostic information that I have respecting a representative message is reproduced below. I just need to know if this is caused by something I can fix at my end or not. And if so then what the problem is. And if not then why these messages are being refused. In the maillog I see this: Jan 19 12:49:29 mx31 postfix/smtp[81175]: 14FDA745F9: to=, relay=none, delay=2877, delays=2877/0.02/0.13/0, dsn=4.4.1, status=deferred (connect to alt4.gmail-smtp-in.l.google.com[66.102.1.27]:25: Connection refused) In the defer queue I see this: cat /var/spool/postfix/defer/1/14FDA745F9 : connect to alt4.gmail-smtp-in.l.google.com[66.102.1.27]:25: Connection refused recipient=info.nafsyst...@gmail.com offset=272 dsn_orig_rcpt=rfc822;info.nafsyst...@gmail.com status=4.4.1 action=delayed reason=connect to alt4.gmail-smtp-in.l.google.com[66.102.1.27]:25: Connection refused In the deferred queue I see this: postcat -vq 14FDA745F9 postcat: name_mask: ipv4 postcat: inet_addr_local: configured 3 IPv4 addresses *** ENVELOPE RECORDS deferred/1/14FDA745F9 *** message_size:7007 318 1 0 7007 0 message_arrival_time: Wed Jan 19 12:01:32 2022 create_time: Wed Jan 19 12:01:32 2022 named_attribute: log_message_origin=local named_attribute: trace_flags=0 sender: pointer_record: 0 named_attribute: dsn_orig_rcpt=rfc822;info.nafsyst...@gmail.com original_recipient: info.nafsyst...@gmail.com recipient: info.nafsyst...@gmail.com pointer_record: 0 *** MESSAGE CONTENTS deferred/1/14FDA745F9 *** regular_text: Received: by mx31.harte-lyne.ca (Postfix) regular_text: id 14FDA745F9; Wed, 19 Jan 2022 12:01:32 -0500 (EST) regular_text: Date: Wed, 19 Jan 2022 12:01:32 -0500 (EST) regular_text: From: mailer-dae...@harte-lyne.ca (Mail Delivery System) regular_text: Subject: Delayed Mail (still being retried) regular_text: To: info.nafsyst...@gmail.com regular_text: Auto-Submitted: auto-replied regular_text: MIME-Version: 1.0 regular_text: Content-Type: multipart/report; report-type=delivery-status; regular_text: boundary="11ACD744F0.1642611692/mx31.harte-lyne.ca" regular_text: Content-Transfer-Encoding: 8bit regular_text: Message-Id: <20220119170132.14fda74...@mx31.harte-lyne.ca> pointer_record: 0 regular_text: regular_text: This is a MIME-encapsulated message. regular_text: regular_text: --11ACD744F0.1642611692/mx31.harte-lyne.ca regular_text: Content-Description: Notification regular_text: Content-Type: text/plain; charset=utf-8 regular_text: Content-Transfer-Encoding: 8bit regular_text: regular_text: This is the mail system at host mx31.harte-lyne.ca. regular_text: regular_text: regular_text: # THIS IS A WARNING ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE. # regular_text: regular_text: regular_text: Your message could not be delivered for more than 0 hour(s). regular_text: It will be retried until it is 5 day(s) old. regular_text: regular_text: For further assistance, please send mail to postmaster. regular_text: regular_text: If you do so, please include this problem report. You can regular_text: delete your own text from the attached returned message. regular_text: regular_text:The mail system regular_text: regular_text: : connect to mail.agtt.ca[216.8.180.31]:25: Connection refused regular_text: regular_text: --11ACD744F0.1642611692/mx31.harte-lyne.ca regular_text: Content-Description: Delivery report regular_text: Content-Type: message/delivery-status regular_text: regular_text: Reporting-MTA: dns; mx31.harte-lyne.ca regular_text: X-Postfix-Queue-ID: 11ACD744F0 regular_text: X-Postfix-Sender: rfc822; info.nafsyst...@gmail.com regular_text: Arrival-Date: Wed, 19 Jan 2022 11:43:05 -0500 (EST) regular_text: regular_text: Final-Recipient: rfc822; h...@agtt.ca regular_text: Original-Recipient: rfc822;p...@harte-lyne.ca regular_text: Action: delayed regular_text: Status: 4.4.1 regular_text: Diagnostic-Code: X-Postfix; connect to mail.agtt.ca[216.8.180.31]:25: regular_text: Connection refused regular_text: Will-Retry-Until: Mon, 24 Jan 2022 11:43:05 -0500 (EST) regular_text: regular_text: --11ACD744F0.1642611692/mx31.harte-lyne.ca regular_text: Content-Description: Undelivered Message Headers regular_text: Content-Type: text/rfc822-headers regular_text: Content-Transfer-Encoding: 8bit regular_text: regular_text: Return-Path:
Re: TLS returning self-signed cert
Wayne Spivak: > Hi Wietse, > > It's been a very long time since we communicated. > > This from SSL Labs states "self-signed": > > Path #1: Not trusted (path does not chain to a trusted anchor) > 1 Sent by server mcq.sbanetweb.com > Fingerprint SHA256: > 1b48d54fd173fa980ca0ba8e2bbb5aabce3bbb9faf67bae4f375816155699efe > Pin SHA256: D9BrKzFpjkpGhv91bgkZqQIWlqPNIHPHmIhYYwDChGY= > RSA 2048 bits (e 65537) / SHA256withRSA > 2 Sent by server > Not in trust store mcq.sbanetweb.com Self-signed > Fingerprint SHA256: > 1ff50fe2d898b639ee07e668b4a4acf5c3f878539a24be6edc3cc011991a9db3 > Pin SHA256: 2gJ7C4jfxgMQJMF09EznMu8UGd5sdBmQDyPrv5pIcHU= > RSA 4096 bits (e 65537) / SHA256withRSA > > If it is an Intermediate, I refer to my orginal email, "where am I going > wrong". Are you sure that this test connected to port 25, not 443? Wietse > Wayne > > -Original Message- > From: owner-postfix-us...@postfix.org On > Behalf Of Wietse Venema > Sent: Wednesday, January 19, 2022 1:03 PM > To: Wayne Spivak > Cc: postfix-users@postfix.org > Subject: Re: TLS returning self-signed cert > > Wayne Spivak: > > My Postfix Server 3.6.2 running on a newly created Fedora 35 is > > returning self-signed SSL certs, where none were configured. > > Why do you believe that this is a self-signed certifcate? > > Isn't this an issue where the server returns a leaf certificate without > intermediate certificates? > > Wietse > > > We're using a multi-cert Entrust certificate. All domains on the box > > get email from one single mx domain. > > > > To be clear TLS works, but if I run SSL Labs report it comes back as > > Not being Trusted. > > > > Running CheckTLS.com, this is the error > > > > Certificate #1 of 1 (sent by MX): > >Cert VALIDATION ERROR(S): unable to get local issuer > > certificate This may help: What Is An Intermediate Certificate > >So email is encrypted but the recipient domain is not verified > >... > >TLS successfully started on this server > > > > I have all files in the same directory, ServerCert.pem (from Entrust), > > Bundle2.crt (from Entrust), CA-combines (private key/Server Cert). > > > > No other file is configured in either Dovecot 2.3.17.1 (476cd46418) > > points to the same directory and files. > > > > The Cert serial number is coming back wrong using SSL Labs, but a web > > site (on same server) returns the correct serial number (remember > > everything points to the same files) > > > > I've confirmed the Cert is correct and the private key as well. > > > > I've tried changing the CAFile to include/not include Server > > Certificate, Intermediate, Root, Private Key and either TLS dies, or > > it "works", but the above error is obtained. > > > > I'm at a dead-end as far as researching the error goes. > > > > Where am I going wrong.. > > > > > > > > > >
Re: TLS returning self-signed cert
On Wed, Jan 19, 2022 at 01:09:09PM -0500, Wayne Spivak wrote: > This from SSL Labs states "self-signed": Their report is misleading. > 1 Sent by server mcq.sbanetweb.com > Fingerprint SHA256: > 1b48d54fd173fa980ca0ba8e2bbb5aabce3bbb9faf67bae4f375816155699efe > Pin SHA256: D9BrKzFpjkpGhv91bgkZqQIWlqPNIHPHmIhYYwDChGY= > RSA 2048 bits (e 65537) / SHA256withRSA The actual certificate list returned consists of just the server certificate, and is missing the intermediate issuer(s). See below. > If it is an Intermediate, I refer to my orginal email, "where am I going > wrong". Your certificate file contains only the server certificate, it should, after the server certificate, which must be listed first, also contain the certificates of any intermediate or cross certificates needed to complete the chain to a trusted root CA. You're missing at least the certificate of the intermediate issuer CA with a "CommonName" of "Entrust Certification Authority - L1K": $ posttls-finger -cC -lsecure '[mcq.sbanetweb.com]' posttls-finger: certificate verification failed for mcq.sbanetweb.com[96.224.250.24]:25: untrusted issuer /C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2012 Entrust, Inc. - for authorized use only/CN=Entrust Certification Authority - L1K posttls-finger: mcq.sbanetweb.com[96.224.250.24]:25: subject_CN=mcq.sbanetweb.com, issuer_CN=Entrust Certification Authority - L1K, fingerprint=1E:69:25:44:74:52:B4:C5:AA:C4:9F:7C:E8:F7:0B:96:A7:35:A9:F6:60:1F:D4:07:30:CD:B3:6B:99:69:88:EC, pkey_fingerprint=89:F7:3F:9B:2F:6F:F1:51:7B:4E:4C:CD:D5:5D:CB:C7:CE:CA:75:C9:CF:D8:73:EB:08:D2:71:1A:48:8E:FC:CD posttls-finger: Untrusted TLS connection established to mcq.sbanetweb.com[96.224.250.24]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 --- Certificate chain 0 subject: /C=US/ST=New York/L=Bellmore/O=SBA Consulting LTD/CN=mcq.sbanetweb.com issuer: /C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2012 Entrust, Inc. - for authorized use only/CN=Entrust Certification Authority - L1K cert digest=1E:69:25:44:74:52:B4:C5:AA:C4:9F:7C:E8:F7:0B:96:A7:35:A9:F6:60:1F:D4:07:30:CD:B3:6B:99:69:88:EC pkey digest=89:F7:3F:9B:2F:6F:F1:51:7B:4E:4C:CD:D5:5D:CB:C7:CE:CA:75:C9:CF:D8:73:EB:08:D2:71:1A:48:8E:FC:CD -BEGIN CERTIFICATE- MIIHFTCCBf2gAwIBAgIQZGafF9rIwqdWMecTQCvgOTANBgkqhkiG9w0BAQsFADCB ujELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUVudHJ1c3QsIEluYy4xKDAmBgNVBAsT H1NlZSB3d3cuZW50cnVzdC5uZXQvbGVnYWwtdGVybXMxOTA3BgNVBAsTMChjKSAy MDEyIEVudHJ1c3QsIEluYy4gLSBmb3IgYXV0aG9yaXplZCB1c2Ugb25seTEuMCwG A1UEAxMlRW50cnVzdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEwxSzAeFw0y MjAxMTIxMjQzNTBaFw0yMjAzMjIxMjQzNTBaMG0xCzAJBgNVBAYTAlVTMREwDwYD VQQIEwhOZXcgWW9yazERMA8GA1UEBxMIQmVsbG1vcmUxHDAaBgNVBAoTE1NCQSAg Q29uc3VsdGluZyBMVEQxGjAYBgNVBAMTEW1jcS5zYmFuZXR3ZWIuY29tMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwpoaW8GGUK4hUeeQvIpbRowTdIsN U9DahAIqRRyI6xo50usgMjd0HqeYbqio+bYwOiKMAxwvc1Bg8w7mvKaBqGsXI1zU bOkQkvbIMQIh+CPnpmX8Z7A70bzjC7jlEQ2QoqOeYXLklGZW+FgGFzaii0/z+V+l G+UtG+NcSV4rq2ZpagKL4ICcKMwbldmJPsYUqa9n1XqS4f8SYMNIAc6kzbaStcsu bHyr0wqnaEOb9U+6cVrmTApdr0qCMqj0/yVYkjqrQri2+1qKrvT96GktDL1tGuef BaY3kKIHBlt0MmhOBvsw14+uLCwtlqX3zFxDbUYdRHKOeUZJ6IcXpOUccQIDAQAB o4IDYTCCA10wDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQU04vZQ7LHBFMI/pT0jlBz GH+cjOIwHwYDVR0jBBgwFoAUgqJwdN28Uz/Pe9T3zX+nYMYKTL8waAYIKwYBBQUH AQEEXDBaMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5lbnRydXN0Lm5ldDAzBggr BgEFBQcwAoYnaHR0cDovL2FpYS5lbnRydXN0Lm5ldC9sMWstY2hhaW4yNTYuY2Vy MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwuZW50cnVzdC5uZXQvbGV2ZWwx ay5jcmwwcQYDVR0RBGowaIIRbWNxLnNiYW5ldHdlYi5jb22CFXd3dy5tY3Euc2Jh bmV0d2ViLmNvbYINd3d3LmNpbWF0Lm5ldIIVd3d3LnNiYWNvbnN1bHRpbmcuY29t ghZ3d3cuYWhlYWRlcXVpcG1lbnQuY29tMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUE FjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwTAYDVR0gBEUwQzA3BgpghkgBhvpsCgEF MCkwJwYIKwYBBQUHAgEWG2h0dHBzOi8vd3d3LmVudHJ1c3QubmV0L3JwYTAIBgZn gQwBAgIwggF8BgorBgEEAdZ5AgQCBIIBbASCAWgBZgB1AN+lXqtogk8fbK3uuF9O PlrqzaISpGpejjsSwCBEXCpzAAABfk5Q5HwAAAQDAEYwRAIgFKWUj7OFmelLjXZU Y3c24OrpomgfudS/1uKDuqKCIyMCIF1Lecz2SGFrHWBrhG2IlIogq6xQ0+J8/V6Q x3qOy8p1AHYAVYHUwhaQNgFK6gubVzxT8MDkOHhwJQgXL6OqHQcT0wwAAAF+TlDk rwAABAMARzBFAiAKTUI9H3/L3qZUDd6bfGfmLMDa6BJ1sT3Uf6aG1VlfnAIhAOYR T0Zm9z1qiNI/wytoBOa5WxyBhBtiVke1B9oA6YPzAHUARqVV63X6kSAwtaKJafTz fREsQXS+/Um4havy/HD+bUcAAAF+TlDkegAABAMARjBEAiB9spsTk2OW6zlTN3xV CvKjcaczgik9mginjshN0gRHHQIgNX6W9MRJ2csFpHcIiiVJcpPZKUvWBu3yJ4uZ aucARC8wDQYJKoZIhvcNAQELBQADggEBAMFuvTltc7HNxN3/4DdC40Ul6J4XKIJK LHjHwt0BcGWobTklFa8vC59sbT8/W4cDnelovJ3sR0E13aBH3B2iLubrby6NXHJV UtwLJ+ny3/j2q6qEczSvqX7XAE2kHQge7eWspZJqHjsr5jjT5IdktnsMREDW/eRy 0cv5GYR87RPMADayqogyUPEsyxmVfUcxVMeribF7B/MSbUR5F5IP1fLyvizrKDol e9iPLqsSkFcRygTkxftGD2/UrTI0qKWHLmLRt4ZPjy3jv+V3dXSxP4q/A7Ab11tv
Re: Appricate some help in understanding a connection refused situation.
James B. Byrne: > postconf mail_version > mail_version = 3.6.3 > > OS FreeBSD-13.0p5 > > I am in the process of transferring one of our MX services to a > new host. During one of the test sessions against live traffic a > connection to the final delivery host from the test service could > be made. In consequence several messages resulted in a delayed > delivery notice. > > It is these messages for which I am seeing SMTP connection refused > from the original sending hosts. > > The diagnostic information that I have respecting a representative > message is reproduced below. I just need to know if this is caused > by something I can fix at my end or not. And if so then what the > problem is. And if not then why these messages are being refused. > > In the maillog I see this: > > Jan 19 12:49:29 mx31 postfix/smtp[81175]: 14FDA745F9: > to=, relay=none, delay=2877, > delays=2877/0.02/0.13/0, dsn=4.4.1, status=deferred (connect to > alt4.gmail-smtp-in.l.google.com[66.102.1.27]:25: Connection refused) The connect(2) system call returned ECONNREFUSED, which normally means that the TCP SYN request got a TCP RST response. > In the defer queue I see this: Same information as logged. For me, alt4.gmail-smtp-in.l.google.com does not resolve to 66.102.1.27, but instead to 142.250.153.26 (and some IPv6). Wietse
Re: TLS returning self-signed cert
Thank you Victor. I will update the CAFile and report back. I think you answered weistse question. Regards, Wayne Sent from my iPhone; typos expected and endorsed by Apple > On Jan 19, 2022, at 1:28 PM, Viktor Dukhovni > wrote: > > On Wed, Jan 19, 2022 at 01:09:09PM -0500, Wayne Spivak wrote: > >> This from SSL Labs states "self-signed": > > Their report is misleading. > >> 1Sent by servermcq.sbanetweb.com >> Fingerprint SHA256: >> 1b48d54fd173fa980ca0ba8e2bbb5aabce3bbb9faf67bae4f375816155699efe >> Pin SHA256: D9BrKzFpjkpGhv91bgkZqQIWlqPNIHPHmIhYYwDChGY= >> RSA 2048 bits (e 65537) / SHA256withRSA > > The actual certificate list returned consists of just the server > certificate, and is missing the intermediate issuer(s). See below. > >> If it is an Intermediate, I refer to my orginal email, "where am I going >> wrong". > > Your certificate file contains only the server certificate, it should, > after the server certificate, which must be listed first, also contain > the certificates of any intermediate or cross certificates needed to > complete the chain to a trusted root CA. > > You're missing at least the certificate of the intermediate issuer CA > with a "CommonName" of "Entrust Certification Authority - L1K": > >$ posttls-finger -cC -lsecure '[mcq.sbanetweb.com]' >posttls-finger: certificate verification failed for > mcq.sbanetweb.com[96.224.250.24]:25: untrusted issuer /C=US/O=Entrust, > Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2012 Entrust, Inc. - for > authorized use only/CN=Entrust Certification Authority - L1K >posttls-finger: mcq.sbanetweb.com[96.224.250.24]:25: > subject_CN=mcq.sbanetweb.com, issuer_CN=Entrust Certification Authority - > L1K, > fingerprint=1E:69:25:44:74:52:B4:C5:AA:C4:9F:7C:E8:F7:0B:96:A7:35:A9:F6:60:1F:D4:07:30:CD:B3:6B:99:69:88:EC, > > pkey_fingerprint=89:F7:3F:9B:2F:6F:F1:51:7B:4E:4C:CD:D5:5D:CB:C7:CE:CA:75:C9:CF:D8:73:EB:08:D2:71:1A:48:8E:FC:CD >posttls-finger: Untrusted TLS connection established to > mcq.sbanetweb.com[96.224.250.24]:25: TLSv1.3 with cipher > TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature > RSA-PSS (2048 bits) server-digest SHA256 > >--- >Certificate chain > 0 subject: /C=US/ST=New York/L=Bellmore/O=SBA Consulting > LTD/CN=mcq.sbanetweb.com >issuer: /C=US/O=Entrust, Inc./OU=See > www.entrust.net/legal-terms/OU=(c) 2012 Entrust, Inc. - for authorized use > only/CN=Entrust Certification Authority - L1K > cert > digest=1E:69:25:44:74:52:B4:C5:AA:C4:9F:7C:E8:F7:0B:96:A7:35:A9:F6:60:1F:D4:07:30:CD:B3:6B:99:69:88:EC > pkey > digest=89:F7:3F:9B:2F:6F:F1:51:7B:4E:4C:CD:D5:5D:CB:C7:CE:CA:75:C9:CF:D8:73:EB:08:D2:71:1A:48:8E:FC:CD >-BEGIN CERTIFICATE- >MIIHFTCCBf2gAwIBAgIQZGafF9rIwqdWMecTQCvgOTANBgkqhkiG9w0BAQsFADCB >ujELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUVudHJ1c3QsIEluYy4xKDAmBgNVBAsT >H1NlZSB3d3cuZW50cnVzdC5uZXQvbGVnYWwtdGVybXMxOTA3BgNVBAsTMChjKSAy >MDEyIEVudHJ1c3QsIEluYy4gLSBmb3IgYXV0aG9yaXplZCB1c2Ugb25seTEuMCwG >A1UEAxMlRW50cnVzdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEwxSzAeFw0y >MjAxMTIxMjQzNTBaFw0yMjAzMjIxMjQzNTBaMG0xCzAJBgNVBAYTAlVTMREwDwYD >VQQIEwhOZXcgWW9yazERMA8GA1UEBxMIQmVsbG1vcmUxHDAaBgNVBAoTE1NCQSAg >Q29uc3VsdGluZyBMVEQxGjAYBgNVBAMTEW1jcS5zYmFuZXR3ZWIuY29tMIIBIjAN >BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwpoaW8GGUK4hUeeQvIpbRowTdIsN >U9DahAIqRRyI6xo50usgMjd0HqeYbqio+bYwOiKMAxwvc1Bg8w7mvKaBqGsXI1zU >bOkQkvbIMQIh+CPnpmX8Z7A70bzjC7jlEQ2QoqOeYXLklGZW+FgGFzaii0/z+V+l >G+UtG+NcSV4rq2ZpagKL4ICcKMwbldmJPsYUqa9n1XqS4f8SYMNIAc6kzbaStcsu >bHyr0wqnaEOb9U+6cVrmTApdr0qCMqj0/yVYkjqrQri2+1qKrvT96GktDL1tGuef >BaY3kKIHBlt0MmhOBvsw14+uLCwtlqX3zFxDbUYdRHKOeUZJ6IcXpOUccQIDAQAB >o4IDYTCCA10wDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQU04vZQ7LHBFMI/pT0jlBz >GH+cjOIwHwYDVR0jBBgwFoAUgqJwdN28Uz/Pe9T3zX+nYMYKTL8waAYIKwYBBQUH >AQEEXDBaMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5lbnRydXN0Lm5ldDAzBggr >BgEFBQcwAoYnaHR0cDovL2FpYS5lbnRydXN0Lm5ldC9sMWstY2hhaW4yNTYuY2Vy >MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwuZW50cnVzdC5uZXQvbGV2ZWwx >ay5jcmwwcQYDVR0RBGowaIIRbWNxLnNiYW5ldHdlYi5jb22CFXd3dy5tY3Euc2Jh >bmV0d2ViLmNvbYINd3d3LmNpbWF0Lm5ldIIVd3d3LnNiYWNvbnN1bHRpbmcuY29t >ghZ3d3cuYWhlYWRlcXVpcG1lbnQuY29tMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUE >FjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwTAYDVR0gBEUwQzA3BgpghkgBhvpsCgEF >MCkwJwYIKwYBBQUHAgEWG2h0dHBzOi8vd3d3LmVudHJ1c3QubmV0L3JwYTAIBgZn >gQwBAgIwggF8BgorBgEEAdZ5AgQCBIIBbASCAWgBZgB1AN+lXqtogk8fbK3uuF9O >PlrqzaISpGpejjsSwCBEXCpzAAABfk5Q5HwAAAQDAEYwRAIgFKWUj7OFmelLjXZU >Y3c24OrpomgfudS/1uKDuqKCIyMCIF1Lecz2SGFrHWBrhG2IlIogq6xQ0+J8/V6Q >x3qOy8p1AHYAVYHUwhaQNgFK6gubVzxT8MDkOHhwJQgXL6OqHQcT0wwAAAF+TlDk >rwAABAMARzBFAiAKTUI9H3/L3qZUDd6bfGfmLMDa6BJ1sT3Uf6aG1VlfnAIhAOYR >T0Zm9z1qiNI/wytoBOa5WxyBhBtiVke1B9oA6YPzAHUARqVV63X6kSAwtaKJafTz >fREsQXS+/Um4havy/HD+bUcAAAF+TlDkegAABAMARjBEAiB9spsTk2OW6zlTN3xV >CvKjcaczgik9mginjshN0gRHHQIgNX6W9MRJ2cs
Re: Appricate some help in understanding a connection refused situation.
On Wed, Jan 19, 2022 at 01:13:56PM -0500, James B. Byrne wrote: > Jan 19 12:49:29 mx31 postfix/smtp[81175]: 14FDA745F9: > to=, relay=none, delay=2877, > delays=2877/0.02/0.13/0, dsn=4.4.1, status=deferred (connect to > alt4.gmail-smtp-in.l.google.com[66.102.1.27]:25: Connection refused) Note that this is the *last* connection attempt for this delivery, earlier connection attempts (possibly successful with an SMTP-layer 4XX result) may provide more information. You need to find all relevant log entries for this delivery. Look for earlier messages in the log from "postfix/smtp[81175]". > In the deferred queue I see this: > > postcat -vq 14FDA745F9 The "-v" is not useful. > sender: This looks like a locally-generated DSN with an empty sender. > named_attribute: dsn_orig_rcpt=rfc822;info.nafsyst...@gmail.com > From: mailer-dae...@harte-lyne.ca (Mail Delivery System) > Subject: Delayed Mail (still being retried) > To: info.nafsyst...@gmail.com > Auto-Submitted: auto-replied You're sending delay notices to outside recipients. This is may not be a good idea. Consider disabling delay warnings in the Postfix instances that handle inbound mail. If inbound and outbound mail transit the same Postfix instance (queue) then perhaps you can live without delay notices in either direction... > : connect to mail.agtt.ca[216.8.180.31]:25: Connection refused The original message could not be delivered to that address in a timely manner. > Reporting-MTA: dns; mx31.harte-lyne.ca > X-Postfix-Queue-ID: 11ACD744F0 Above is the MTA stuck holding the message. > regular_text: Final-Recipient: rfc822; h...@agtt.ca > regular_text: Original-Recipient: rfc822;p...@harte-lyne.ca The original recipient got rewritten to an external domain, which is perhaps now no longer in service. > regular_text: From: NAF SYSTEMS > regular_text: Date: Wed, 19 Jan 2022 11:42:48 -0500 > regular_text: Message-ID: > > regular_text: Subject: Re: > regular_text: To: impo...@harte-lyne.ca > regular_text: Cc: p...@harte-lyne.ca > regular_text: Content-Type: multipart/alternative; > boundary="18a8e005d5f21490" > regular_text: > regular_text: --11ACD744F0.1642611692/mx31.harte-lyne.ca-- The original message was possibly spam. You might also consider sending header-only DSNs, by setting: bounce_size_limit = 1 This will reduce the odds of remote sites rejecting the bounce based on content. -- Viktor.
Re: TLS returning self-signed cert
On Wed, Jan 19, 2022 at 01:37:59PM -0500, Wayne Spivak wrote: > Thank you Victor. > > I will update the CAFile and report back. Updating the CAfile probably won't help you. You need to add append the intermediate certificates in questio to the server certificate file. -- Viktor.
RE: TLS returning self-signed cert
Thank you, you just saved me an email 😊 -Original Message- From: owner-postfix-us...@postfix.org On Behalf Of Viktor Dukhovni Sent: Wednesday, January 19, 2022 1:47 PM To: postfix-users@postfix.org Subject: Re: TLS returning self-signed cert On Wed, Jan 19, 2022 at 01:37:59PM -0500, Wayne Spivak wrote: > Thank you Victor. > > I will update the CAFile and report back. Updating the CAfile probably won't help you. You need to add append the intermediate certificates in questio to the server certificate file. -- Viktor.
Re: Appricate some help in understanding a connection refused situation.
On Wed, January 19, 2022 13:29, Wietse Venema wrote: > James B. Byrne: > > > For me, alt4.gmail-smtp-in.l.google.com does not resolve to > 66.102.1.27, but instead to 142.250.153.26 (and some IPv6). > > Wietse > Repeated dns lookups of alt4.gmail-smtp-in.l.google.com return a different ip4 address for each query. I infer that google.com uses a round-robin set of A records for that domain; and likely multiple MX hosts for sending. Although the returns I get seem to be in the 64.233.184 netblock and usually one of either 64.233.184.26 or 64.233.184.27, neither of which are a PRT record to alt4.gmail-smtp-in.l.google.com. Neither does 142.250.153.26 point back to alt4.gmail-smtp-in.l.google.com for that matter. However that may be, google's dns records are outside my span of control. I still do not understand why a DSN delay message cannot be sent back to the origin. Has google configured their mail servers to prevent this? Are the bounces supposed to be sent somewhere else (aspmx.l.google.com.)? Do I have some sort of configuration error? -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Unencrypted messages have no legal claim to privacy Do NOT open attachments nor follow links sent by e-Mail James B. Byrnemailto:byrn...@harte-lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
Re: Appricate some help in understanding a connection refused situation.
James B. Byrne: [ Charset ISO-8859-1 converted... ] > > > On Wed, January 19, 2022 13:29, Wietse Venema wrote: > > James B. Byrne: > > > > > > For me, alt4.gmail-smtp-in.l.google.com does not resolve to > > 66.102.1.27, but instead to 142.250.153.26 (and some IPv6). > > > > Wietse > > > > Repeated dns lookups of alt4.gmail-smtp-in.l.google.com return a different ip4 > address for each query. I infer that google.com uses a round-robin set of A > records for that domain; and likely multiple MX hosts for sending. > > Although the returns I get seem to be in the 64.233.184 netblock and usually > one of either 64.233.184.26 or 64.233.184.27, neither of which are a PRT > record > to alt4.gmail-smtp-in.l.google.com. Neither does 142.250.153.26 point back to > alt4.gmail-smtp-in.l.google.com for that matter. > > However that may be, google's dns records are outside my span of control. I > still do not understand why a DSN delay message cannot be sent back to the > origin. Has google configured their mail servers to prevent this? Are the > bounces supposed to be sent somewhere else (aspmx.l.google.com.)? Do I have > some sort of configuration error? "Connection refused" means that the TCP SYN request from your system got a TCP RST response. This response could be for a variety of reasons. One is that the host accepted no TCP connections on port 25, but that seems unlikely. More likely, some "bump in the wire" blocked the conection attempt before it even reached a mail server. As Victor noted, what Postfix stores is the last attempt. You may see other connection failures from the same Postfix SMTP client process to different gmail MX hosts. Wietse
Re: Doing something wrong.
On Wed, Jan 19, 2022 at 03:07:29PM -0500, Wayne Spivak wrote: > Still not working... That's not particularly illuminating. You'll need to reply with "postconf -nf" and "postconf -Mf" output (inserted verbatim without any changes in linebreaks or other whitespace). Also with the output of (assuming bash-compatible shell): openssl crl2pkcs7 -nocrl -certfile $(postconf -xh smtpd_tls_cert_file) | openssl pkcs7 -print_certs -noout | grep subject= Your SMTP server is still responding with just the leaf (a.k.a. EE or end-entity) certificate. -- Viktor.
RE: Doing something wrong.
I set the server back, because otherwise my email wasn't working properly.
[root@mcq postfix]# postconf -nf
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
compatibility_level = 3.6
content_filter = smtp-amavis:[127.0.0.1]:10024 meta_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 1
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
$daemon_directory/$process_name $process_id & sleep 5
default_destination_concurrency_limit = 20
fast_flush_domains = $relay_domains
header_checks = pcre:/etc/postfix/maps/header_checks
home_mailbox = Maildir/
html_directory = no
in_flow_delay = 1s
inet_interfaces = all
inet_protocols = all
local_destination_concurrency_limit = 2
mail_owner = postfix
mail_spool_directory = /var/spool/mail
maillog_file = /var/log/maillog
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
milter_default_action = accept
milter_protocol = 2
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
mydomain = sbanetweb.com
myhostname = mcq.sbanetweb.com
mynetworks = 96.224.250.24 127.0.0.1
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = $smtpd_milters
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix/README_FILES
sample_directory = /usr/share/doc/postfix/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
shlib_directory = /usr/lib64/postfix
smtp_tls_CAfile = /etc/postfix/tls/ChainBundle.pem
smtp_tls_CApath = /etc/postfix/tls/
smtp_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtp_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtp_tls_security_level = may
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated
reject_unauth_destination reject_unauth_pipelining
reject_unknown_client_hostname permit
smtpd_data_restrictions = permit_sasl_authenticated,
reject_unauth_pipelining
smtpd_delay_reject = yes
smtpd_error_sleep_time = 1s
smtpd_etrn_restrictions = check_client_access hash:/etc/postfix/maps/access
reject
smtpd_hard_error_limit = 20
smtpd_helo_required = yes
smtpd_helo_restrictions = reject_invalid_hostname reject_non_fqdn_sender
reject_non_fqdn_recipient reject_unknown_recipient_domain permit
smtpd_junk_command_limit = 10
smtpd_milters = inet:localhost:8891, inet:localhost:8893
smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks
check_recipient_access hash:/etc/postfix/maps/rejected_recips
reject_unauth_destination check_policy_service inet:127.0.0.1:2501
check_policy_service unix:private/policyd-spf
smtpd_relay_restrictions = permit_sasl_authenticated permit_mynetworks
reject_unauth_destination reject_unknown_recipient_domain
reject_unverified_recipient
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = permit_mynetworks permit_sasl_authenticated
check_sender_access hash:/etc/postfix/maps/sender_access
reject_unknown_sender_domain warn_if_reject reject_unverified_sender
reject_unknown_reverse_client_hostname reject_unknown_client_hostname
smtpd_soft_error_limit = 10
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/postfix/tls/ServerCert-combined.pem
smtpd_tls_dh1024_param_file = /etc/postfix/tls/dh.pem
smtpd_tls_loglevel = 1
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_security_level = may
soft_bounce = no
transport_maps = hash:/etc/postfix/maps/transport
unknown_local_recipient_reject_code = 550
virtual_alias_domains = /etc/postfix/maps/localdomains
virtual_alias_maps = hash:/etc/postfix/maps/virtual
[root@mcq postfix]# postconf -Mf
smtp inet n - n - - smtpd
spamassassin unix - n n - - pipe user=spamd
argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender}
${recipient}
policyd-spf unix - n n - 0 spawn
user=policyd-spf
argv=/usr/bin/python /usr/libexec/postfix/policyd-spf
submission inet n - n - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated
-o milter_macro_daemon_name=ORIGINATING
smtps inet n - n - - smtpd
-o syslog_name=postfix/smtps
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_reject_unlisted_recipient=no
-o smtpd_recipient_restrictions=
-o smtpd_client_restrictions=permit_sasl_authenticated
smtp-amavis unix - - n - 2 smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
Re: Routing Gmail/Workspace mail through postfix first
On Wed, Jan 19, 2022 at 08:23:45AM -0500, Alex wrote: > I'm using postfix-3.5.10 and would like to use it to front-end a > domain currently being managed by Google Workspace to be able to send > mail through our filters first. I take it this means *inbound* mail sent from outside users to your users, whose mailboxes are ultimately hosted by Gmail, but you want to process the mail on your MX hosts first. > I know I'll need to redirect the MX, but how do I obtain a user list > so I'm not just forwarding all email received for the domain through > as a relay, and instead only to those users with current accounts? You'll need more than just a user list, you'll need to make an arrangement with Gmail to whitelist the hosts that will relay the mail for storage back to Gmail. This may be by IP address, or perhaps via SASL or client certs. You'll need to negotiate that with your Google support reps. Otherwise, any spam you forward will impact the "reputation" of these hosts, potentially impeding future email delivery. More importantly, absent above whitelist, if some of the sender domains have SPF records and/or DMARC policies in place, Google may reject or file as spam any mail you forward. Making sure you reject invalid users is the simpler problem. I'd normally expect that you'd know in advance which users you've provisioned on your G-suite domain, but if for some reason that information is not available internally, you'll need to also discuss that with the support reps. Recipient verification (via active probes) is an imperfect last-resort option. -- Viktor.
Re: Doing something wrong.
On Wed, Jan 19, 2022 at 03:22:36PM -0500, Wayne Spivak wrote: > I set the server back, because otherwise my email wasn't working properly. And for some reason decided to not explain (show logs, ...) of what "not working properly" means. :-( Crystal ball very cloudy on my end... > smtp_tls_CAfile = /etc/postfix/tls/ChainBundle.pem > smtp_tls_CApath = /etc/postfix/tls/ > smtp_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1 > smtp_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1 > smtp_tls_security_level = may Add: smtp_tls_loglevel = 1 > smtpd_tls_cert_file = /etc/postfix/tls/ServerCert-combined.pem This file contains just the server certificate. Did you append the (PEM formatted) issuer certificate(s)? > smtp inet n - n - - smtpd > submission inet n - n - - smtpd > -o syslog_name=postfix/submission > -o smtpd_tls_security_level=encrypt > -o smtpd_sasl_auth_enable=yes > -o smtpd_client_restrictions=permit_sasl_authenticated > -o milter_macro_daemon_name=ORIGINATING The client restrictions are missing a default deny, so are basically a slower variant of "permit". And you don't reset the other restrictions. Start with the stock templates: submission inet n - n - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_tls_auth_only=yes -o smtpd_reject_unlisted_recipient=no -o smtpd_client_restrictions=$mua_client_restrictions -o smtpd_helo_restrictions=$mua_helo_restrictions -o smtpd_sender_restrictions=$mua_sender_restrictions -o smtpd_recipient_restrictions= -o smtpd_relay_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING smtps inet n - n - - smtpd -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_reject_unlisted_recipient=no -o smtpd_client_restrictions=$mua_client_restrictions -o smtpd_helo_restrictions=$mua_helo_restrictions -o smtpd_sender_restrictions=$mua_sender_restrictions -o smtpd_recipient_restrictions= -o smtpd_relay_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING > [root@mcq postfix]# openssl crl2pkcs7 -nocrl -certfile $(postconf -xh > smtpd_tls_cert_file) | > openssl pkcs7 -print_certs -noout | > grep subject= > subject=C = US, ST = New York, L = Bellmore, O = SBA Consulting LTD, CN = > mcq.sbanetweb.com Just the one certificate. You need to append the intermediate CA certificates. PEM format, each starts with "-BEGIN CERTIFICATE-" line and ends with an "-END CERTIFICATE-" line. In my case: # grep '^---' /...full-path.../combo.pem -BEGIN PRIVATE KEY- -END PRIVATE KEY- -BEGIN CERTIFICATE- -END CERTIFICATE- -BEGIN CERTIFICATE- -END CERTIFICATE- -BEGIN CERTIFICATE- -END CERTIFICATE- -- Viktor.
Re: Appricate some help in understanding a connection refused situation.
On Wed, January 19, 2022 14:45, Wietse Venema wrote: > > "Connection refused" means that the TCP SYN request from your system > got a TCP RST response. This response could be for a variety of > reasons. One is that the host accepted no TCP connections on port > 25, but that seems unlikely. More likely, some "bump in the wire" > blocked the conection attempt before it even reached a mail server. > > As Victor noted, what Postfix stores is the last attempt. You may > see other connection failures from the same Postfix SMTP client > process to different gmail MX hosts. > > Wietse > I discovered my error. Or, perhaps an idiosyncrasy of FreeBSD jails. The issue appears to be related to the order in which the IP4 addresses are assigned to jails. In our setup we use a 192.168 address for internal communication between hosts and only assign routable addresses to host with public services. This includes SMTP services for system generated email notices. Postfix is configured to listen on both the public and the private addresses. On the original MX host's jail these were set as em0|216.185.71.31,em0|192.168.216.31. This host did not report connection errors. On the host jail with the connection problems these were set to em0|192.168.216.31,em0|216.185.71.31. When I reversed the ip4 settings to match the original then the problem stopped and the backlog of queued messages cleared almost immediately. Thank you for the assistance. I appreciate it very much. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Unencrypted messages have no legal claim to privacy Do NOT open attachments nor follow links sent by e-Mail James B. Byrnemailto:byrn...@harte-lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
RE: Doing something wrong.
I'll do this one step at a time (I need to do other things).. Again, thank you. I created the combo with -- Begin Priviate --End Private --Begin Certificate --End Certificate -- Begin Intermediate -- End Intermediate I have one multi-domain certificate, however for email all the emails on server, for mx purposes have the dns mx = mcq.sbanetweb.com. Those who send email through my server have the smtp and imap point to mcq.sba Just the one certificate. You need to append the intermediate CA certificates. PEM format, each starts with "-BEGIN CERTIFICATE-" line and ends with an "-END CERTIFICATE-" line. In my case: # grep '^---' /...full-path.../combo.pem -BEGIN PRIVATE KEY- -END PRIVATE KEY- -BEGIN CERTIFICATE- -END CERTIFICATE- -BEGIN CERTIFICATE- -END CERTIFICATE- -BEGIN CERTIFICATE- -END CERTIFICATE- -- Viktor.
Re: Doing something wrong.
following along & just curious, i checked a postfix 3.6.3 here that's using LetsEncrypt certs, where conf includes smtpd_tls_cert_file = /usr/local/etc/postfix/sec/fullchain.rsa.crt.pem smtpd_tls_eccert_file = /usr/local/etc/postfix/sec/fullchain.ec.crt.pem smtpd_tls_eckey_file = /usr/local/etc/postfix/sec/priv.ec.key smtpd_tls_key_file = /usr/local/etc/postfix/sec/priv.rsa.key cert verification FAILs posttls-finger -cC -lsecure '[mx.example.com]' posttls-finger: certificate verification failed for mx.example.com[XX.XX.XX.3]:25: untrusted issuer /O=Digital Signature Trust Co./CN=DST Root CA X3 ... checking openssl crl2pkcs7 -nocrl -certfile fullchain.ec.crt.pem | openssl pkcs7 -print_certs -text -noout | grep CN= Issuer: C=US, O=Let's Encrypt, CN=R3 Subject: CN=mx.example.com Issuer: C=US, O=Internet Security Research Group, CN=ISRG Root X1 Subject: C=US, O=Let's Encrypt, CN=R3 Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3 Subject: C=US, O=Internet Security Research Group, CN=ISRG Root X1 openssl crl2pkcs7 -nocrl -certfile fullchain.rsa.crt.pem | openssl pkcs7 -print_certs -text -noout | grep CN= Issuer: C=US, O=Let's Encrypt, CN=R3 Subject: CN=mx.example.com Issuer: C=US, O=Internet Security Research Group, CN=ISRG Root X1 Subject: C=US, O=Let's Encrypt, CN=R3 Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3 Subject: C=US, O=Internet Security Research Group, CN=ISRG Root X1 reading @ https://letsencrypt.org/certificates/, the LE cert's cross-signed by the DST root, Root Certificates Active ISRG Root X1 (RSA 4096, O = Internet Security Research Group, CN = ISRG Root X1) Self-signed: der, pem, txt !!! Cross-signed by DST Root CA X3: der, pem, txt and that appears in standard CA system certs, openssl crl2pkcs7 -nocrl -certfile /etc/ssl/certs/ca-bundle.crt | openssl pkcs7 -print_certs -text -noout | grep CN=DST Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3 Subject: O=Digital Signature Trust Co., CN=DST Root CA X3 openssl crl2pkcs7 -nocrl -certfile /etc/ssl/certs/ca-bundle.trust.crt | openssl pkcs7 -print_certs -text -noout | grep CN=DST Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3 Subject: O=Digital Signature Trust Co., CN=DST Root CA X3 You need to append the intermediate CA certificates. also @ https://letsencrypt.org/certificates/ Intermediate Certificates We do not use the X1, X2, X3, and X4 intermediates anymore. Cross Signing Intermediates Our RSA intermediates are signed by ISRG Root X1. ISRG Root X1 is widely trusted at this point, but our RSA intermediates are still cross-signed by IdenTrust’s “DST Root CA X3” (now called “TrustID X3 Root”) for additional client compatibility ... Almost all server operators will choose to serve a chain including the intermediate certificate with Subject “R3” and Issuer “ISRG Root X1”. The recommended Let’s Encrypt client software, Certbot, will make this configuration seamlessly. iiuc, the certbot-retrieved LE 'fullchain' cert chains correctly include those two, and should be sufficient for cert validity checks. but posttls-finger appears to also need the cross-signing root in the chain, and does not check/retrive OS cert paths? i suspect i'm misunderstanding requirements &/or config here, as well
RE: Doing something wrong.
Missing logs: This is with the new combo certificate Mail log: Jan 19 14:52:55 mcq postfix/smtpd[156224]: warning: TLS library problem: error:0908F066:PEM routines:get_header_and_data:bad end line:crypto/pem/pem_lib.c:856: Jan 19 14:52:55 mcq postfix/smtpd[156224]: warning: error loading private keys and certificates from: /etc/postfix/tls/ws.pem: disabling TLS support Jan 19 14:52:55 mcq postfix/smtpd[156224]: connect from _gateway[192.168.1.1] Jan 19 14:52:55 mcq postfix/smtpd[156224]: lost connection after STARTTLS from _gateway[192.168.1.1] Jan 19 14:52:55 mcq postfix/cleanup[156230]: 12CF610BC904: message-id=<20220119195255.12cf610bc...@mcq.sbanetweb.com> Jan 19 14:52:55 mcq postfix/qmgr[156204]: 12CF610BC904: from=, size=914, nrcpt=1 (queue active) Jan 19 14:52:55 mcq postfix/smtpd[156224]: disconnect from _gateway[192.168.1.1] ehlo=1 starttls=0/1 commands=1/2 Jan 19 14:52:55 mcq postfix/local[156232]: 12CF610BC904: to=< >, orig_to=, relay=local, delay=0.07, delays=0.04/0.01/0/0.02, dsn=2.0.0, status=sent (delivered to maildir) Jan 19 14:52:55 mcq postfix/qmgr[156204]: 12CF610BC904: removed Messages: Jan 19 13:51:53 mcq postfix[151328]: /usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: $smtp_tls_key_file=/etc/postfix/tls/.key Jan 19 13:51:53 mcq postfix[151328]: /usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: $smtpd_tls_cert_file=/etc/postfix/tls/ws.pem Jan 19 13:51:53 mcq postfix[151335]: /usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: $smtp_tls_key_file=/etc/postfix/tls/ key Jan 19 13:51:53 mcq postfix[151335]: /usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: $smtpd_tls_cert_file=/etc/postfix/tls/ws.pem Jan 19 13:51:53 mcq postfix[151328]: /usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: $smtp_tls_key_file=/etc/postfix/tls/ key Email from Postfix SMTP Error: Transcript of session follows. Out: 220 mcq.sbanetweb.com ESMTP Postfix In: EHLO sonic309-21.consmr.mail.ne1.yahoo.com Out: 250-mcq.sbanetweb.com Out: 250-PIPELINING Out: 250-SIZE 1024 Out: 250-VRFY Out: 250-ETRN Out: 250-STARTTLS Out: 250-ENHANCEDSTATUSCODES Out: 250-8BITMIME Out: 250-DSN Out: 250-SMTPUTF8 Out: 250 CHUNKING In: STARTTLS Out: 454 4.7.0 TLS not available due to local problem In: MAIL FROM:< > Out: 250 2.1.0 Ok In: RCPT TO:< > Out: 450 4.7.1 < >: Recipient address rejected: Greylisted for 10 minutes In: QUIT Out: 221 2.0.0 Bye You asked : set smtp_tls_loglevel = 1, which I did (see prior email) You asked: > smtpd_tls_cert_file = /etc/postfix/tls/ServerCert-combined.pem This file contains just the server certificate. Did you append the (PEM formatted) issuer certificate(s)? I said I tried it two different ways, but one way was Private Key Server certificate, Intermediate Certificate. When I did that, that is when all the error message begin. Lastly, you want me to change the submission and smtps entries in master.cf, which I have done as of this email.
Re: Doing something wrong.
On Wed, Jan 19, 2022 at 04:23:58PM -0500, Wayne Spivak wrote: > This is with the new combo certificate > > Mail log: > Jan 19 14:52:55 mcq postfix/smtpd[156224]: warning: TLS library problem: > error:0908F066:PEM routines:get_header_and_data:bad end > line:crypto/pem/pem_lib.c:856: > Jan 19 14:52:55 mcq postfix/smtpd[156224]: warning: error loading private > keys and certificates from: /etc/postfix/tls/ws.pem: disabling TLS support Clearly /etc/postfix/tls/ws.pem is malformed. How are you constructing this file? It should look like (each line should end with a newline character, i.e. LF not CR or CR+LF): # EE private key -BEGIN PRIVATE KEY- ... base64 data ... -END PRIVATE KEY- # EE certificate -BEGIN CERTIFICATE- ... base64 data ... -END CERTIFICATE- # Issuer of EE certificate -BEGIN CERTIFICATE- ... base64 data ... -END CERTIFICATE- # Any issuer(s) of above issuer ... [ The lines starting with "#" are optional and can contain "comments" in various other formats, so long as they don't start with five "-" characters, they're ignored. ] > Jan 19 13:51:53 mcq postfix[151328]: /usr/sbin/postconf: warning: > /etc/postfix/main.cf: unused parameter: > $smtp_tls_key_file=/etc/postfix/tls/.key The LHS parameter names in main.cf don't start with "$". Also why is the file named ".key" and not ".key"? > Jan 19 13:51:53 mcq postfix[151328]: /usr/sbin/postconf: warning: > /etc/postfix/main.cf: unused parameter: > $smtpd_tls_cert_file=/etc/postfix/tls/ws.pem > Jan 19 13:51:53 mcq postfix[151335]: /usr/sbin/postconf: warning: > /etc/postfix/main.cf: unused parameter: > $smtp_tls_key_file=/etc/postfix/tls/.key Fix these. -- Viktor.
RE: Doing something wrong.
I am creating the file by using cat file1 file2 file3 > ws.pem (which is my test combo file) I noticed the "$", not sure why they were there and removed them. Tested again, without effect. The "key" is a filename, I just removed the root part of the file name (too much of short hand, sorry) -Original Message- From: owner-postfix-us...@postfix.org On Behalf Of Viktor Dukhovni Sent: Wednesday, January 19, 2022 4:37 PM To: postfix-users@postfix.org Subject: Re: Doing something wrong. On Wed, Jan 19, 2022 at 04:23:58PM -0500, Wayne Spivak wrote: > This is with the new combo certificate > > Mail log: > Jan 19 14:52:55 mcq postfix/smtpd[156224]: warning: TLS library problem: error:0908F066:PEM routines:get_header_and_data:bad end line:crypto/pem/pem_lib.c:856: > Jan 19 14:52:55 mcq postfix/smtpd[156224]: warning: error loading > private keys and certificates from: /etc/postfix/tls/ws.pem: disabling > TLS support Clearly /etc/postfix/tls/ws.pem is malformed. How are you constructing this file? It should look like (each line should end with a newline character, i.e. LF not CR or CR+LF): # EE private key -BEGIN PRIVATE KEY- ... base64 data ... -END PRIVATE KEY- # EE certificate -BEGIN CERTIFICATE- ... base64 data ... -END CERTIFICATE- # Issuer of EE certificate -BEGIN CERTIFICATE- ... base64 data ... -END CERTIFICATE- # Any issuer(s) of above issuer ... [ The lines starting with "#" are optional and can contain "comments" in various other formats, so long as they don't start with five "-" characters, they're ignored. ] > Jan 19 13:51:53 mcq postfix[151328]: /usr/sbin/postconf: warning: > /etc/postfix/main.cf: unused parameter: > $smtp_tls_key_file=/etc/postfix/tls/.key The LHS parameter names in main.cf don't start with "$". Also why is the file named ".key" and not ".key"? > Jan 19 13:51:53 mcq postfix[151328]: /usr/sbin/postconf: warning: > /etc/postfix/main.cf: unused parameter: > $smtpd_tls_cert_file=/etc/postfix/tls/ws.pem > Jan 19 13:51:53 mcq postfix[151335]: /usr/sbin/postconf: warning: > /etc/postfix/main.cf: unused parameter: > $smtp_tls_key_file=/etc/postfix/tls/.key Fix these. -- Viktor.
Re: Doing something wrong.
On Wed, Jan 19, 2022 at 04:21:13PM -0500, PGNet Dev wrote: > following along & just curious, i checked a postfix 3.6.3 here that's using > LetsEncrypt certs, where conf includes > > smtpd_tls_cert_file = /usr/local/etc/postfix/sec/fullchain.rsa.crt.pem > smtpd_tls_eccert_file = /usr/local/etc/postfix/sec/fullchain.ec.crt.pem > smtpd_tls_eckey_file = /usr/local/etc/postfix/sec/priv.ec.key > smtpd_tls_key_file = /usr/local/etc/postfix/sec/priv.rsa.key > > cert verification FAILs > > posttls-finger -cC -lsecure '[mx.example.com]' > posttls-finger: certificate verification failed for > mx.example.com[XX.XX.XX.3]:25: untrusted issuer /O=Digital Signature Trust > Co./CN=DST Root CA X3 > ... This is expected, you haven't specified a CAfile with "-F filename" and the default is to not trust any CAs. Only "-l dane" can produce a "Verified" result with no explicit trust anchors in the Postfix configuration, and only of course if the nexthop domain is DNSSEC-signed, and the SMTP server has usable TLSA records. The actual trust-anchor (root zone KSK) is configured in your local validating resolver. -- Viktor.
RE: Doing something wrong.
Clearly /etc/postfix/tls/ws.pem is malformed. How are you constructing this file? It should look like (each line should end with a newline character, i.e. LF not CR or CR+LF): >My file looks like -BEGIN PRIVATE KEY- ... base64 data ... -END PRIVATE KEY- -BEGIN CERTIFICATE- ... base64 data ... -END CERTIFICATE--BEGIN CERTIFICATE- (THIS IS HOW IT LOOKS) ... base64 data ... -END CERTIFICATE- >> # EE private key -BEGIN PRIVATE KEY- ... base64 data ... -END PRIVATE KEY- # EE certificate -BEGIN CERTIFICATE- ... base64 data ... -END CERTIFICATE- # Issuer of EE certificate -BEGIN CERTIFICATE- ... base64 data ... -END CERTIFICATE- # Any issuer(s) of above issuer ... [ The lines starting with "#" are optional and can contain "comments" in various other formats, so long as they don't start with five "-" characters, they're ignored. ]
Re: Doing something wrong.
On Wed, Jan 19, 2022 at 04:40:29PM -0500, Wayne Spivak wrote: > I am creating the file by using cat file1 file2 file3 > ws.pem (which > is my test combo file) Does the last "line" of each of the files end in a newline character? A missing newline at the end of file1 or file2 will corrupt the concatenated result. In that case, you'll get more useful results with: perl -lne print file1 file2 file3 rather than : cat file1 file2 file3 Also with "cat ... > ws.pem", if ws.pem does not already exist it may be created world-readable. Be sure to set a sensible umask (077), or: # rm -f combo.pem # openssl pkey -in keyfile.pem -out combo.pem # perl -lne print certfile.pem ... >> combo.pem which sets sensible permissions when creating a new private key file. -- Viktor.
Re: Doing something wrong.
On Wed, Jan 19, 2022 at 04:47:55PM -0500, Wayne Spivak wrote: > >My file looks like > > -BEGIN PRIVATE KEY- > ... base64 data ... > -END PRIVATE KEY- > -BEGIN CERTIFICATE- > ... base64 data ... > -END CERTIFICATE--BEGIN CERTIFICATE- (THIS IS HOW IT > LOOKS) > ... base64 data ... > -END CERTIFICATE- Missing newline as expected... -- Viktor.
Re: Routing Gmail/Workspace mail through postfix first
Hi, > > I'm using postfix-3.5.10 and would like to use it to front-end a > > domain currently being managed by Google Workspace to be able to send > > mail through our filters first. > > I take it this means *inbound* mail sent from outside users to your > users, whose mailboxes are ultimately hosted by Gmail, but you want > to process the mail on your MX hosts first. Yes, that's it exactly, and I've also thought about the points you've raised about spam/SPF/DKIM/forwarding. I was hoping there was an interface for managing this within Google Workspace. I was envisioning some type of API being involved that provides that layer of authentication?
Re: Doing something wrong.
On 1/19/22 16:46, Viktor Dukhovni wrote: Only "-l dane" can produce a "Verified" result with no explicit trust ... the default is to not trust any CAs. ah. thx! o/ posttls-finger -cC -lsecure -F /etc/ssl/certs/ca-bundle.trust.crt '[mx.example.com]' posttls-finger: mx.example.com[XX.XX.XX.X3]:25: matched peername: mx.example.com posttls-finger: mx.example.com[XX.XX.XX.X3]:25: subject_CN=mx.example.com, issuer_CN=R3, fingerprint=..., pkey_fingerprint=... posttls-finger: Verified TLS connection established to mx.example.com[XX.XX.XX.X3]:25: TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X448 server-signature ECDSA (P-384) server-digest SHA384
RE: Doing something wrong.
That was the solution for TLS failing when I start postfix: perl -lne print file1 file2 file3 I then tested with: [root@mcq postfix]# posttls-finger -cC -lsecure '[mcq.sbanetweb.com]' posttls-finger: warning: DNSSEC validation may be unavailable posttls-finger: warning: reason: dnssec_probe 'ns:.' received a response that is not DNSSEC validated posttls-finger: certificate verification failed for mcq.sbanetweb.com[96.224.250.24]:25: untrusted issuer /C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2009 Entrust, Inc. - for authorized use only/CN=Entrust Root Certification Authority - G2 posttls-finger: mcq.sbanetweb.com[96.224.250.24]:25: subject_CN=mcq.sbanetweb.com, issuer_CN=Entrust Certification Authority - L1K, fingerprint=1E:69:25:44:74:52:B4:C5:AA:C4:9F:7C:E8:F7:0B:96:A7:35:A9:F6:60:1 F:D4:07:30:CD:B3:6B:99:69:88:EC, pkey_fingerprint=89:F7:3F:9B:2F:6F:F1:51:7B:4E:4C:CD:D5:5D:CB:C7:CE:CA:75:C9 :CF:D8:73:EB:08:D2:71:1A:48:8E:FC:CD posttls-finger: Untrusted TLS connection established to mcq.sbanetweb.com[96.224.250.24]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 And as you see it still is failing. I'm also getting an error on submission in the log, Error is no such file/directory. Ideas? -Original Message- From: owner-postfix-us...@postfix.org On Behalf Of Viktor Dukhovni Sent: Wednesday, January 19, 2022 4:54 PM To: postfix-users@postfix.org Subject: Re: Doing something wrong. On Wed, Jan 19, 2022 at 04:40:29PM -0500, Wayne Spivak wrote: > I am creating the file by using cat file1 file2 file3 > ws.pem (which > is my test combo file) Does the last "line" of each of the files end in a newline character? A missing newline at the end of file1 or file2 will corrupt the concatenated result. In that case, you'll get more useful results with: perl -lne print file1 file2 file3 rather than : cat file1 file2 file3 Also with "cat ... > ws.pem", if ws.pem does not already exist it may be created world-readable. Be sure to set a sensible umask (077), or: # rm -f combo.pem # openssl pkey -in keyfile.pem -out combo.pem # perl -lne print certfile.pem ... >> combo.pem which sets sensible permissions when creating a new private key file. -- Viktor.
Re: Routing Gmail/Workspace mail through postfix first
On 2022-01-19 at 17:04:37 UTC-0500 (Wed, 19 Jan 2022 17:04:37 -0500) Alex is rumored to have said: Hi, I'm using postfix-3.5.10 and would like to use it to front-end a domain currently being managed by Google Workspace to be able to send mail through our filters first. I take it this means *inbound* mail sent from outside users to your users, whose mailboxes are ultimately hosted by Gmail, but you want to process the mail on your MX hosts first. Yes, that's it exactly, and I've also thought about the points you've raised about spam/SPF/DKIM/forwarding. I was hoping there was an interface for managing this within Google Workspace. I was envisioning some type of API being involved that provides that layer of authentication? If you're paying Google for service, shouldn't you be able to ask them about what their service includes??? -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Doing something wrong.
On Wed, Jan 19, 2022 at 05:07:38PM -0500, Wayne Spivak wrote:
> That was the solution for TLS failing when I start postfix:
>
> perl -lne print file1 file2 file3
And now your server has the intermediate issuer in its chain, and
verification works:
posttls-finger: mcq.sbanetweb.com[96.224.250.24]:25: matched peername:
mcq.sbanetweb.com
posttls-finger: mcq.sbanetweb.com[96.224.250.24]:25:
subject_CN=mcq.sbanetweb.com, issuer_CN=Entrust Certification Authority - L1K,
fingerprint=1E:69:25:44:74:52:B4:C5:AA:C4:9F:7C:E8:F7:0B:96:A7:35:A9:F6:60:1F:D4:07:30:CD:B3:6B:99:69:88:EC,
pkey_fingerprint=89:F7:3F:9B:2F:6F:F1:51:7B:4E:4C:CD:D5:5D:CB:C7:CE:CA:75:C9:CF:D8:73:EB:08:D2:71:1A:48:8E:FC:CD
posttls-finger: Verified TLS connection established to
mcq.sbanetweb.com[96.224.250.24]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384
(256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)
server-digest SHA256
> [root@mcq postfix]# posttls-finger -cC -lsecure '[mcq.sbanetweb.com]'
This does not use any trust-anchor certs, so verification is sure to
fail when the intermediate issuer can't be verified. This is expected
and normal. You'd need to specify a CAfile ("-F CAfile" option), but
that's not necessary, it works.
> posttls-finger: warning: DNSSEC validation may be unavailable
> posttls-finger: warning: reason: dnssec_probe 'ns:.' received a response that
> is not DNSSEC validated
Your resolver is not a validating resolver. This is harmless if you're
not using DANE.
> posttls-finger: certificate verification failed for
> mcq.sbanetweb.com[96.224.250.24]:25: untrusted issuer /C=US/O=Entrust,
> Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2009 Entrust, Inc. - for
> authorized use only/CN=Entrust Root Certification Authority - G2
As expected. You're all set.
> I'm also getting an error on submission in the log, Error is no such
> file/directory.
Start a new thread and post all relevant logs and configuration details.
--
Viktor.
Re: Doing something wrong.
Thank you. It’s appreciated.
I’ll work on the other issue and see if I can solve it.
Regards,
Wayne
Wayne Spivak
SBA.NET.WEB
A div of SBA * Consulting LTD
Tel LI: +1 (516) 221-3306
NY Tel: +1 (212) 487-5085
Tel CT: +1-860-760-0250
Fax: +1 (516) 387-1184
mailto:wspi...@sbaconsulting.com
http://www.sbaconsulting.com
LinkedIn: http://LinkedIn.com/in/WayneSpivak
Twitter: @SBAConsult Skype: SBAConsult
Sent from my iPhone; typos expected and endorsed by Apple
> On Jan 19, 2022, at 5:32 PM, Viktor Dukhovni
> wrote:
>
> On Wed, Jan 19, 2022 at 05:07:38PM -0500, Wayne Spivak wrote:
>
>> That was the solution for TLS failing when I start postfix:
>>
>> perl -lne print file1 file2 file3
>
> And now your server has the intermediate issuer in its chain, and
> verification works:
>
>posttls-finger: mcq.sbanetweb.com[96.224.250.24]:25: matched peername:
> mcq.sbanetweb.com
>posttls-finger: mcq.sbanetweb.com[96.224.250.24]:25:
> subject_CN=mcq.sbanetweb.com, issuer_CN=Entrust Certification Authority -
> L1K,
> fingerprint=1E:69:25:44:74:52:B4:C5:AA:C4:9F:7C:E8:F7:0B:96:A7:35:A9:F6:60:1F:D4:07:30:CD:B3:6B:99:69:88:EC,
>
> pkey_fingerprint=89:F7:3F:9B:2F:6F:F1:51:7B:4E:4C:CD:D5:5D:CB:C7:CE:CA:75:C9:CF:D8:73:EB:08:D2:71:1A:48:8E:FC:CD
>posttls-finger: Verified TLS connection established to
> mcq.sbanetweb.com[96.224.250.24]:25: TLSv1.3 with cipher
> TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature
> RSA-PSS (2048 bits) server-digest SHA256
>
>> [root@mcq postfix]# posttls-finger -cC -lsecure '[mcq.sbanetweb.com]'
>
> This does not use any trust-anchor certs, so verification is sure to
> fail when the intermediate issuer can't be verified. This is expected
> and normal. You'd need to specify a CAfile ("-F CAfile" option), but
> that's not necessary, it works.
>
>> posttls-finger: warning: DNSSEC validation may be unavailable
>> posttls-finger: warning: reason: dnssec_probe 'ns:.' received a response
>> that is not DNSSEC validated
>
> Your resolver is not a validating resolver. This is harmless if you're
> not using DANE.
>
>> posttls-finger: certificate verification failed for
>> mcq.sbanetweb.com[96.224.250.24]:25: untrusted issuer /C=US/O=Entrust,
>> Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2009 Entrust, Inc. - for
>> authorized use only/CN=Entrust Root Certification Authority - G2
>
> As expected. You're all set.
>
>> I'm also getting an error on submission in the log, Error is no such
>> file/directory.
>
> Start a new thread and post all relevant logs and configuration details.
>
> --
>Viktor.
Re: SASL questions
On Tue, Jan 18, 2022 at 07:22:40PM -0500, Joe Acquisto-j4 wrote: > . . . > > I would imagine that Postfix can only authenticate to > > servers that have entries in /etc/postfix/sasl_passwd. > > > > smtp_sasl_password_maps (default: empty) > > > > Optional Postfix SMTP client lookup tables with one > > username:password entry per sender, remote hostname > > or next-hop domain. Per-sender lookup is done only > > when sender-dependent authentication is enabled. If > > no username:password entry is found, then the > > Postfix SMTP client will not attempt to > > authenticate to the remote host. > > > > But it seems unlikely that you'd have put an entry there > > for a server of yours that doesn't authenticate. > > > > Perhaps you need to add that server to debug_peer_list > > and see what the extra logs say. > > > > cheers, > > raf > > I believe I have that correct, per examples (and it is working mostly as > expected) > /etc/postfixsasl_passwd takes this form: > > j...@aaa.comjoea@AAA:ADADAD > j...@aaad.comj...@aaad.com:ADADAD2 > > As said, this appears to work and does not interfer with incoming > email that goes to a local host, unauthenticated, in all but one case. Yes, it has nothing to do with incoming connections. It's used by the Postfix SMTP client when making outgoing connections. Does this mean that the problem you are seeing is with incoming connections? Sorry, but I was under the impression that your problem was that Postfix's SMTP client was trying to authenticate itself to a remote server when delivering mail somewhere (presumably because that remote server required it). If the problem is that an incoming SMTP connection is coming from a remote client, and your Postfix is insisting on that connection authenticating itself, then that's a very different thing. > joe a cheers, raf
Re: Adding Additional domains and outgoing email
On Wed, Jan 19, 2022 at 08:38:07AM -0500, Ruben Safir wrote: > On Tue, Jan 18, 2022 at 11:14:58AM -0500, Ruben Safir wrote: > > On Tue, Jan 18, 2022 at 04:50:11PM +0100, Matus UHLAR - fantomas wrote: > > > On 18.01.22 10:32, Ruben Safir wrote: > > > >I am sorry, that is wrong. I am getting main and master confused. > > > [...] > > > How do I know that dovecot is being querried for authentication via sasl If your /etc/postfix/main.cf contains: smtpd_sasl_type = dovecot smtpd_sasl_path = private/auth and your /etc/postfix/master.cf contains (for submission/smtps): -o smtpd_sasl_auth_enable=yes then Postfix will be querying Dovecot for SASL authentication. And if Dovecot is up and running and configured to create the /var/spool/postfix/private/auth socket that is referred to above, and that socket exists, and has correct permissions, then those queries should work. > and how would I debug that? > I think it is not being seen. When I see an incoming smtps connection with SASL, my logs look like: postfix/smtps/smtpd[52213]: connect from unknown[IP6addr] postfix/smtps/smtpd[52213]: Anonymous TLS connection established from unknown[IP6addr]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 dovecot: auth-worker(52194): conn unix:auth-worker (pid=52193,uid=109): auth-worker<11>: pam(u...@example.org,IP6addr): pam_authenticate() failed: Authentication failure (Password mismatch?) postfix/smtps/smtpd[52213]: 0C5125E340: client=unknown[IP6addr], sasl_method=PLAIN, sasl_username=u...@example.org postfix/cleanup[52217]: 0C5125E340: message-id= postfix/qmgr[3563496]: 0C5125E340: from=, size=729, nrcpt=2 (queue active) postfix/smtps/smtpd[52213]: disconnect from unknown[IP6addr] ehlo=1 auth=1 mail=1 rcpt=2 data=1 quit=1 commands=7 The dovecot log there might be unrelated (because this connection's authentication did succeed) but the username is correct (wierd, never mind). The following line contains: sasl_method=PLAIN, sasl_username=u...@example.org which shows that SASL happened.s And the last line shows: auth=1 which shows that the incoming SMTP client did issue an authentication command. If it had gone wrong, there would be log messages to indicate the failure. You can probably increase debugging levels in Dovecot and/or Postfix to see more detail. I don't think Dovecot itself logs authentication failures by default (probably because there are usually so many of them from POP/IMAP connection attempts). cheers, raf
