Re: Postfix is wrongly marking CA certificate expired
Just updated Logs -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Re: Postfix is wrongly marking CA certificate expired
> On Jan 21, 2019, at 2:40 AM, phoenixsagar wrote:
>
> Logs are like :
> postfix/backend/smtp[95117]: CA certificate verification failed for
> abc-abc.mail.abc.outlook.com[111.111.111.111]:25: certificate has expired
The key context here is "CA certificate verification". The expired certificate
is an issuer CA certificate, not the leaf server certificate. This could be
either sent by the remote server, or found in the local trust store. Not
infrequently, the problem is a stale certificate in the local trust store,
which does need to be kept up to date. Make sure you don't have stale
intermediate CA certs in your trust store. Also post the certificates
sent on the wire, which you can capture with:
$ posttls-finger -cC -Lsummary example.com
FWIW, the relevant source code is below. Perhaps the "depth" should
also have been logged to give a more complete context.
tls_verify.c:
/* tls_log_verify_error - Report final verification error status */
voidtls_log_verify_error(TLS_SESS_STATE *TLScontext)
{
...
int depth = TLScontext->errordepth;
#define PURPOSE ((depth>0) ? "CA": TLScontext->am_server ? "client": "server")
...
case X509_V_ERR_CERT_HAS_EXPIRED:
case X509_V_ERR_ERROR_IN_CERT_NOT_AFTER_FIELD:
msg_info("%s certificate verification failed for %s: certificate has"
" expired", PURPOSE, TLScontext->namaddr);
break;
...
}
--
Viktor.
Re: Postfix is wrongly marking CA certificate expired
Thanks viktor. All Certificates are valid for these certificates Im getting above logs. Is there any issue due to missing root CA certificate as client has not received any root CA certificate(Subject and issuer different in all certificates) in capture ? Correct me If am wrong I can only see End entity and intermediate certificate. Wireshark Capture : Frame 13: 736 bytes on wire (5888 bits), 736 bytes captured (5888 bits) Ethernet II, Src: Cisco_3d:10:7f (18:8b:9d:3d:10:7f), Dst: Vmware_b8:33:4f (00:50:56:b8:33:4f) Internet Protocol Version 4, Src: 23.103.198.42, Dst: 10.64.102.22 Transmission Control Protocol, Src Port: 25, Dst Port: 63024, Seq: 3255, Ack: 340, Len: 670 [3 Reassembled TCP Segments (3566 bytes): #10(1448), #11(1448), #13(670)] Secure Sockets Layer TLSv1.2 Record Layer: Handshake Protocol: Multiple Handshake Messages Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 3561 Handshake Protocol: Server Hello Handshake Protocol: Certificate Handshake Type: Certificate (11) Length: 3077 Certificates Length: 3074 Certificates (3074 bytes) Certificate Length: 1901 Certificate: 3082076930820651a003020102020c5760c0769d1714309d... (id-at-commonName=mail.protection.outlook.com,id-at-organizationName=Microsoft Corporation,id-at-localityName=Redmond,id-at-stateOrProvinceName=Washington,id-at-countryName=U signedCertificate version: v3 (2) serialNumber: 0x5760c0769d1714309d2d95de signature (sha256WithRSAEncryption) issuer: rdnSequence (0) rdnSequence: 3 items (id-at-commonName=GlobalSign Organization Validation CA - SHA256,id-at-organizationName=GlobalSign nv-sa,id-at-countryName=BE) validity notBefore: utcTime (0) utcTime: 18-05-18 22:06:55 (UTC) notAfter: utcTime (0) utcTime: 20-05-18 22:06:55 (UTC) subject: rdnSequence (0) rdnSequence: 5 items (id-at-commonName=mail.protection.outlook.com,id-at-organizationName=Microsoft Corporation,id-at-localityName=Redmond,id-at-stateOrProvinceName=Washington,id-at-countryName=US) subjectPublicKeyInfo extensions: 10 items algorithmIdentifier (sha256WithRSAEncryption) Padding: 0 encrypted: aba7b1085de90b0d145f7aa5b0962188a096d3f1e8416b09... Certificate Length: 1167 Certificate: 3082048b30820373a003020102020e4707b1019a0c57ad39... (id-at-commonName=GlobalSign Organization Validation CA - SHA256,id-at-organizationName=GlobalSign nv-sa,id-at-countryName=BE) signedCertificate version: v3 (2) serialNumber: 0x4707b1019a0c57ad39b3e17da9f9 signature (sha256WithRSAEncryption) issuer: rdnSequence (0) rdnSequence: 4 items (id-at-commonName=GlobalSign Root CA,id-at-organizationalUnitName=Root CA,id-at-organizationName=GlobalSign nv-sa,id-at-countryName=BE) validity notBefore: utcTime (0) utcTime: 15-09-04 00:00:00 (UTC) notAfter: utcTime (0) utcTime: 25-09-04 00:00:00 (UTC) subject: rdnSequence (0) rdnSequence: 3 items (id-at-commonName=GlobalSign Organization Validation CA - SHA256,id-at-organizationName=GlobalSign nv-sa,id-at-countryName=BE) subjectPublicKeyInfo extensions: 8 items algorithmIdentifier (sha256WithRSAEncryption) Padding: 0 encrypted: 9ab9821cdd83838b92c0c4ed01ad84fc4eee6d9c1d01fa52... Handshake Protocol: Server Key Exchange Handshake Protocol: Certificate Request Handshake Protocol: Server Hello Done -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Re: Forwarding received mail through AWS SES
On 2019-01-20 14:40, John Stoffel wrote: The only problem with Digital Ocean right now is that Charter/Spectrum in the US has blocked all (most? At least the one I'm using...) blocks assigned to DO for some insane reason. Why insane? Having been a DO customer for more than five years, I am not surprised. *bad neighborhood*. DO is not doing enough to prevent spam and viruses emanating from its network. This affects me both as a sender and as a recipient of emails. I have received too much spam emanating from DO's network, including traditional email spam and text messages with links to droplets on the DO network that were spreading malware. When I tried to get DO's abuse team to take action, they were slow, dismissive, useless. Despite evidence to a level that would withstand in a court of justice, they closed the cases with no action taken simply because the offending droplet has gone. It does not seem to have occurred to them that the spammer has probably gone to another IP address on their network. My conclusion was to jump ship at the next opportunity. I am currently testing an alternative provider and will possibly say goodbye to DO in a few weeks.
Re: Forwarding received mail through AWS SES
> "Yuval" == Yuval Levy writes: Yuval> On 2019-01-20 14:40, John Stoffel wrote: >> The only problem with Digital Ocean right now is that Charter/Spectrum >> in the US has blocked all (most? At least the one I'm using...) blocks >> assigned to DO for some insane reason. Yuval> Why insane? Having been a DO customer for more than five Yuval> years, I am not surprised. *bad neighborhood*. DO is not Yuval> doing enough to prevent spam and viruses emanating from its Yuval> network. This affects me both as a sender and as a recipient Yuval> of emails. I'm not sure you'll ever find *any* good neighborhood, since it's too easy for anyone to spin up a system next to yours IP wise, and then someone just takes the hammer and nukes the entire block. Even if you are a good netizen. Yuval> I have received too much spam emanating from DO's network, Yuval> including traditional email spam and text messages with links Yuval> to droplets on the DO network that were spreading malware. Yuval> When I tried to get DO's abuse team to take action, they were Yuval> slow, dismissive, useless. Despite evidence to a level that Yuval> would withstand in a court of justice, they closed the cases Yuval> with no action taken simply because the offending droplet has Yuval> gone. It does not seem to have occurred to them that the Yuval> spammer has probably gone to another IP address on their Yuval> network. I don't bother too much with tracking it for my own personal domain, I just postgrey, spamassassin, and then try to black hole those that make it through. It's not ideal, but I don't have a beter answer and I don't think *anyone* does. Yuval> My conclusion was to jump ship at the next opportunity. I am Yuval> currently testing an alternative provider and will possibly say Yuval> goodbye to DO in a few weeks. Share the results please. John
Re: Forwarding received mail through AWS SES
On 2019-01-20 14:40, John Stoffel wrote: > The only problem with Digital Ocean right now is that Charter/Spectrum > in the US has blocked all (most? At least the one I'm using...) blocks > assigned to DO for some insane reason. The insane reason is phishing spam, and DO ignoring abuse notices. And this is not an appropriate subject for the Postfix mailing list.
Trying to debug postfix 'unknown mail transport error'
FreeBSD 11.2, Postfix 3.3.2, Dovecot 2.3.4
Random user verification failures are occurring and I am not sure why.
Here's an example -
>From /var/log/maillog:
Failure:
Jan 21 12:20:41 ns postfix/smtpd[31736]: NOQUEUE: reject: RCPT from
mta2.email.famousfootwear.com[136.147.183.86]: 450 4.1.1 :
Recipient address rejected: unverified address: unknown mail transport
error; from=<
bounce-299_html-404541337-2436561-7222883-9...@bounce.email.famousfootwear.com>
to= proto=ESMTP helo=
Jan 21 12:20:41 ns dovecot: lmtp(31763): Connect from local
Jan 21 12:20:41 ns dovecot: lmtp(31763): Disconnect from local: Client has
quit the connection (state=READY)
Success:
Jan 21 12:20:41 ns postfix/lmtp[31778]: 189C1A2DFB1: to=,
relay=ns.mahan.org[private/dovecot-lmtp], delay=0, delays=0/0/0/0,
dsn=2.1.5, status=deliverable (250 2.1.5 OK)
I am not sure why it sometimes fails. Any help is appreciated.
My config (that I think are related)
Postfix mail transport:
root@ns:/usr/local/etc/dovecot # postconf -n | grep transport
mailbox_transport = lmtp:unix:private/dovecot-lmtp
Dovecot auth config
auth_cache_size = 10 M
auth_username_format = %Ln
service auth-worker {
user = postfix
}
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0666
user = postfix
}
}
Dovecot lmtp config:
protocols = imap lmtp sieve
service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
group = postfix
mode = 0666
user = postfix
}
}
protocol lmtp {
mail_fsync = optimized
mail_plugins = " sieve"
}
Changing the imaps port-number
I am trying to change the imaps port-number to a non-standard port ()
since it seems that buisness.comcast.net is intercepting the standard imaps
port number and repeated emails requesting that they stop have been ignored.
This is only an issue when I am trying to access my personal mail server
when I am away from home.
I currently have the following configured in 10-master.conf -
service imap-login {
inet_listener imap {
address = 127.0.0.1, ::1
port = 143
}
inet_listener imaps {
port =
}
process_min_avail = 3
service_count = 0
vsz_limit = 1 G
}
But I do not see any listeners for port . Prior to this, I was using a
stunnel + dovecot where stunnel received on port and forwarded it to
port 143 (imap). I want to use the secure imap features in dovecot moving
forward.
Thanks,
Patrick
Re: Trying to debug postfix 'unknown mail transport error'
> On Jan 21, 2019, at 3:44 PM, Patrick Mahan wrote: > > Jan 21 12:20:41 ns postfix/smtpd[31736]: NOQUEUE: reject: RCPT from > mta2.email.famousfootwear.com[136.147.183.86]: 450 4.1.1 : > Recipient address rejected: unverified address: unknown mail transport error; > from= > to= proto=ESMTP helo= > > Jan 21 12:20:41 ns dovecot: lmtp(31763): Connect from local > Jan 21 12:20:41 ns dovecot: lmtp(31763): Disconnect from local: Client has > quit the connection (state=READY) You have left out earlier logging by the Postfix lmtp(8) delivery agent that details the "unknown mail transport error" in question. The Dovecot LMTP server logs are not especially informative in this case. -- Viktor.
Re: Changing the imaps port-number
Patrick Mahan:
> service imap-login {
> inet_listener imap {
Wrong mailing list.
Wietse
Re: Trying to debug postfix 'unknown mail transport error'
Patrick Mahan: > FreeBSD 11.2, Postfix 3.3.2, Dovecot 2.3.4 > > Random user verification failures are occurring and I am not sure why. > > Here's an example - > > >From /var/log/maillog: > > Failure: > > Jan 21 12:20:41 ns postfix/smtpd[31736]: NOQUEUE: reject: RCPT from > mta2.email.famousfootwear.com[136.147.183.86]: 450 4.1.1 : > Recipient address rejected: unverified address: unknown mail transport http://www.postfix.org/DEBUG_README.html#logging Look for obvious signs of trouble Postfix logs all failed and successful deliveries to a logfile. The file is usually called /var/log/maillog or /var/log/mail; the exact pathname is defined in the /etc/syslog.conf file. When Postfix does not receive or deliver mail, the first order of business is to look for errors that prevent Postfix from working properly: % egrep '(warning|error|fatal|panic):' /some/log/file | more Note: the most important message is near the BEGINNING of the output. Error messages that come later are less useful.
Postfix logging without syslogd
postfix-3.4-20190121-nonprod-logger has lightly-tested code for logging to file without using syslogd. This solves a usability problem in MacOS, may help to work around a logging bottleneck with systemd, and solves 99% of the problem for logging to stdout in a container (hopefully we have 100% soon). Available from ftp://ftp.porcupine.org/mirrors/postfix-release/experimental postfix-3.4-20190121-nonprod-logger.HISTORY postfix-3.4-20190121-nonprod-logger.RELEASE_NOTES postfix-3.4-20190121-nonprod-logger.tar.gz postfix-3.4-20190121-nonprod-logger.tar.gz.gpg1 postfix-3.4-20190121-nonprod-logger.tar.gz.gpg2 postfix-3.4-20190121-nonprod-logger.tar.gz.sig See the RELEASE_NOTES file for instructions and limitations. Wietse
Re: Postfix logging without syslogd
On Mon, Jan 21, 2019 at 07:04:56PM -0500, Wietse Venema wrote: > postfix-3.4-20190121-nonprod-logger has lightly-tested code for > logging to file without using syslogd. I see that the postlogd(8) service correctly uses a unix-dgram service to avoid message reordering, so the usual attention to detail has not deserted you. :-) Thanks! For log rotation instructions, I would add that the old file should not be modified, compressed or otherwise assumed complete, until a new file is observed to have been written by postlogd(8) after processing the "reload" command. If one is not sure whether Postfix is running, one could use postlog(1) (as root) to cause a new file to be written, one way or the other. The only other nit that comes to mind, is that some syslog servers needlessly delete and re-create their unix-dgram sockets on reload, which leads to needless opportunities for brief loss of messages written to the previous incarnation of the socket. I've not looked to see what master(8) does with the unix-dgram socket on reload... I expect it is left as-is, I can't think of a good reason to rebind it. -- Viktor.
Re: Changing the imaps port-number
Whoops! You are correct, too many mailing lists, my apologies.
Patrick
On Mon, Jan 21, 2019 at 1:23 PM Wietse Venema wrote:
> Patrick Mahan:
> > service imap-login {
> > inet_listener imap {
>
> Wrong mailing list.
>
> Wietse
>
Re: Trying to debug postfix 'unknown mail transport error'
Viktor, I didn't include it because I could not find it. Which is, yes, confusing to me. I looked for other failures from lmtp, but did not seen anything. Thanks, Patrick On Mon, Jan 21, 2019 at 1:23 PM Viktor Dukhovni wrote: > > On Jan 21, 2019, at 3:44 PM, Patrick Mahan wrote: > > > > Jan 21 12:20:41 ns postfix/smtpd[31736]: NOQUEUE: reject: RCPT from > mta2.email.famousfootwear.com[136.147.183.86]: 450 4.1.1 : > Recipient address rejected: unverified address: unknown mail transport > error; from=< > bounce-299_html-404541337-2436561-7222883-9...@bounce.email.famousfootwear.com> > to= proto=ESMTP helo= > > > > Jan 21 12:20:41 ns dovecot: lmtp(31763): Connect from local > > Jan 21 12:20:41 ns dovecot: lmtp(31763): Disconnect from local: Client > has quit the connection (state=READY) > > You have left out earlier logging by the Postfix lmtp(8) delivery agent > that > details the "unknown mail transport error" in question. The Dovecot LMTP > server logs are not especially informative in this case. > > -- > Viktor. > >
Re: Postfix logging without syslogd
On 22 Jan 2019, at 11:04 am, Wietse Venema mailto:wie...@porcupine.org>> wrote: > > postfix-3.4-20190121-nonprod-logger has lightly-tested code for > logging to file without using syslogd. > > This solves a usability problem in MacOS, may help to work around > a logging bottleneck with systemd, and solves 99% of the problem > for logging to stdout in a container (hopefully we have 100% soon). > > Available from ftp://ftp.porcupine.org/mirrors/postfix-release/experimental > <ftp://ftp.porcupine.org/mirrors/postfix-release/experimental> > >postfix-3.4-20190121-nonprod-logger.HISTORY >postfix-3.4-20190121-nonprod-logger.RELEASE_NOTES >postfix-3.4-20190121-nonprod-logger.tar.gz >postfix-3.4-20190121-nonprod-logger.tar.gz.gpg1 >postfix-3.4-20190121-nonprod-logger.tar.gz.gpg2 >postfix-3.4-20190121-nonprod-logger.tar.gz.sig > > See the RELEASE_NOTES file for instructions and limitations. > > Wietse Thanks so much for doing this Wietse. Just tried it on MacOS Mojave machine. Sudo make install ends with: cc -I. -I../../include -DUSE_TLS -DUSE_SASL_AUTH -DDEF_SERVER_SASL_TYPE=\"dovecot\" -DDEF_COMMAND_DIR=\"/usr/local/sbin\" -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\" -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\" -DHAS_PCRE -I/usr/local/opt//include -DHAS_SSL -I/usr/local/opt/openssl@1.1/1.1.1a/include -DHAS_MYSQL -I/usr/local/opt/mysql@5.7/include/mysql -DBIND_8_COMPAT -DNO_NETINFO -DRESOLVE_H_NEEDS_ARPA_NAMESER_COMPAT_H -DNO_EAI -DDEF_SMTPUTF8_ENABLE=\"no\" -DHAS_DEV_URANDOM -DSNAPSHOT -DNONPROD -DDEF_MAILQ_PATH=\"/usr/local/bin/mailq\" -DDEF_NEWALIAS_PATH=\"/usr/local/bin/newaliases\" -DDEF_SENDMAIL_PATH=\"/usr/local/sbin/sendmail\" -UUSE_DYNAMIC_LIBS -DDEF_SHLIB_DIR=\"no\" -UUSE_DYNAMIC_MAPS -Wmissing-prototypes -Wformat -Wno-comment -g -O -I. -DMACOSX -c dict_cidr.c cc -I. -I../../include -DUSE_TLS -DUSE_SASL_AUTH -DDEF_SERVER_SASL_TYPE=\"dovecot\" -DDEF_COMMAND_DIR=\"/usr/local/sbin\" -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\" -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\" -DHAS_PCRE -I/usr/local/opt//include -DHAS_SSL -I/usr/local/opt/openssl@1.1/1.1.1a/include -DHAS_MYSQL -I/usr/local/opt/mysql@5.7/include/mysql -DBIND_8_COMPAT -DNO_NETINFO -DRESOLVE_H_NEEDS_ARPA_NAMESER_COMPAT_H -DNO_EAI -DDEF_SMTPUTF8_ENABLE=\"no\" -DHAS_DEV_URANDOM -DSNAPSHOT -DNONPROD -DDEF_MAILQ_PATH=\"/usr/local/bin/mailq\" -DDEF_NEWALIAS_PATH=\"/usr/local/bin/newaliases\" -DDEF_SENDMAIL_PATH=\"/usr/local/sbin/sendmail\" -UUSE_DYNAMIC_LIBS -DDEF_SHLIB_DIR=\"no\" -UUSE_DYNAMIC_MAPS -Wmissing-prototypes -Wformat -Wno-comment -g -O -I. -DMACOSX -c dict_db.c dict_db.c:768:2: error: "Unsupported Berkeley DB version" #error "Unsupported Berkeley DB version" ^ 1 error generated. make: *** [dict_db.o] Error 1 make: *** [update] Error 1 I used: make -f Makefile.init makefiles CCARGS='-DUSE_TLS -DUSE_SASL_AUTH \ -DDEF_SERVER_SASL_TYPE=\"dovecot\" \ -DDEF_COMMAND_DIR=\"/usr/local/sbin\" \ -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\" \ -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\" \ -DHAS_PCRE -I/usr/local/opt//include \ -DHAS_SSL -I/usr/local/opt/openssl@1.1/1.1.1a/include \ -DHAS_MYSQL -I/usr/local/opt/mysql@5.7/include/mysql' AUXLIBS='-L/usr/local/lib -lpcre -L/usr/local/Cellar/openssl@1.1/1.1.1a/lib -lssl -lcrypto -L/usr/local/opt/mysql@5.7/lib \ -lmysqlclient -lz -lm' sendmail_path=/usr/local/sbin/sendmail newaliases_path=/usr/local/bin/newaliases mailq_path=/usr/local/bin/mail I tried adding ‘-lda’ to the AUXLIBS string but got the same result. I have berkeley-db version 18.1.25 installed via Homebrew. Don’t think I had this issue with the previous version of Postfix. Thanks, James.
Re: Postfix logging without syslogd
> On Jan 21, 2019, at 11:41 PM, James Brown wrote: > > Just tried it on MacOS Mojave machine. Sudo make install ends with: > > dict_db.c:768:2: error: "Unsupported Berkeley DB version" > #error "Unsupported Berkeley DB version" > ^ > > I used: > > I tried adding ‘-lda’ to the AUXLIBS string but got the same result. > > I have berkeley-db version 18.1.25 installed via Homebrew. > > Don’t think I had this issue with the previous version of Postfix. You mean previous version of Berkeley DB. While many projects are moving to semantic versioning, Berkeley DB has no intention of going with the crowd: https://download.oracle.com/otndocs/products/berkeleydb/html/changelog_18_1.html#idm140164927133552 12. The version numbering scheme for Berkeley DB changed from a five-part number to a three-part number of the form ... This release is numbered 18.1.x, indicating that it is the first release of the year 2018. 18.1.x is the successor to the 6.2.x (also known as 12.2.6.2.x) releases. The third and fourth parameters of db_full_version() are no longer meaningful and are now deprecated; if present, they are are set to zero. [#26743] There's no longer any reason to expect a given version number to convey anything about the API, or for the numbers to not go to infinity and beyond. :-) There's apparently now also an SQLite interface with Berkeley DB as the storage backend. https://www.oracle.com/technetwork/database/database-technologies/berkeleydb/overview/sql-160887.html though presumably in that case one no longer has a simple key-value datastore. -- Viktor.
Re: Postfix is wrongly marking CA certificate expired
Hi viktor, See the posted certificates from wire. I am not getting why this is random behaviour. At some time only certificate marked as expired and after some time same certificate gets marked as valid. -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Re: Postfix logging without syslogd
On Jan 21, 2019, at 6:04 PM, Wietse Venema wrote: > > postfix-3.4-20190121-nonprod-logger has lightly-tested code for > logging to file without using syslogd. > I just successfully built it on a Mojave system and so far, all looks good. One test email sent out (my Postfix is outgoing only) was properly logged. Have not tested anything yet involving log rotation. Unlike James Brown and his Unsupported Berkeley DB version, I do not have Berkeley DB on my system (unless a version comes with MacOS), do not use mySQL, and do not have anything from Homebrew on the system. -- Larry Stone lston...@stonejongleux.com
Fixing open relay problem
I've been running Postfix for many years now (so thanks to Wietse and all the others who have put in hard work to make it such a great mail system) and recently I built a new mail server and copied most of the config files from the old one. After a couple of months, I began to notice that it appeared to be getting used (infrequently) as an open relay, despite my attempts to lock it down so that couldn't happen. Then, the problem got worse. The one pattern I noticed was that all the messages had forged senders that were from my domain (e.g., bogussen...@mydomain.com). I've poured through the documentation, and a couple of times thought I found the answer, only to make a change and have it not work. My band-aid (while researching the real solution) has been to firewall off access from IP address ranges that were the sources of the email. But to be clear, that's only a band-aid until a real solution is in place. The two config parameters that seem most relevant to the problem are listed below: (from postconf -n) *smtpd*_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, permit_auth_destination, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_destination, reject_unlisted_recipient, reject_unauth_destination check_recipient_access regexp:/etc/postfix/recipient_checks.regexp, check_recipient_access hash:/etc/postfix/recipient_checks, reject_unauth_pipelining, reject_invalid_hostname, reject_non_fqdn_hostname, reject_rbl_client domain-name, permit (and from postconf -d) *smtpd*_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination What's really confounding me is that it seems to be (properly) rejecting all relay email except those that have mydomain.com in their from address. Adding to that confusion is that this same set of config parameters used to work fine on the old system, so I've also been looking at relevant defaults that changed. Unfortunately, I'm coming up dry at this point. Any help or pointers would be greatly appreciated. Thanks. -- Stephen Stephen McHenry
Re: Postfix logging without syslogd
On 22 Jan 2019, at 5:18 pm, Larry Stone wrote: > > On Jan 21, 2019, at 6:04 PM, Wietse Venema wrote: >> >> postfix-3.4-20190121-nonprod-logger has lightly-tested code for >> logging to file without using syslogd. >> > > I just successfully built it on a Mojave system and so far, all looks good. > One test email sent out (my Postfix is outgoing only) was properly logged. > Have not tested anything yet involving log rotation. Unlike James Brown and > his Unsupported Berkeley DB version, I do not have Berkeley DB on my system > (unless a version comes with MacOS), do not use mySQL, and do not have > anything from Homebrew on the system. > > -- > Larry Stone > lston...@stonejongleux.com I’ll try removing Berkeley DB and give it another go. Thanks Larry. James.
Re: Postfix logging without syslogd
On 21 Jan 2019, at 22:13, Viktor Dukhovni wrote: > 12. The version numbering scheme for Berkeley DB changed from a > five-part number to a three-part number of the form > ... This release is numbered 18.1.x, Do you know why the current version in FreeBSD ports is 6.2.32_1? (or the older db5 is still current as well) -- Can I borrow your underpants for 10 minutes?
Re: Postfix logging without syslogd
On 22 Jan 2019, at 5:22 pm, James Brown mailto:jlbr...@bordo.com.au>> wrote: > > On 22 Jan 2019, at 5:18 pm, Larry Stone <mailto:lston...@stonejongleux.com>> wrote: >> >> On Jan 21, 2019, at 6:04 PM, Wietse Venema > <mailto:wie...@porcupine.org>> wrote: >>> >>> postfix-3.4-20190121-nonprod-logger has lightly-tested code for >>> logging to file without using syslogd. >>> >> >> I just successfully built it on a Mojave system and so far, all looks good. >> One test email sent out (my Postfix is outgoing only) was properly logged. >> Have not tested anything yet involving log rotation. Unlike James Brown and >> his Unsupported Berkeley DB version, I do not have Berkeley DB on my system >> (unless a version comes with MacOS), do not use mySQL, and do not have >> anything from Homebrew on the system. >> >> -- >> Larry Stone >> lston...@stonejongleux.com <mailto:lston...@stonejongleux.com> > > I’ll try removing Berkeley DB and give it another go. Thanks Larry. > > James. I removed Berkeley DB (via Homebrew uninstall) and it gets much further. Now stops on: In file included from abounce.c:187: ./mail_params.h:20:10: fatal error: 'openssl/opensslv.h' file not found #include/* OPENSSL_VERSION_NUMBER */ ^~~~ 1 error generated. Shouldn’t this line in my make command find it? -DHAS_SSL -I/usr/local/opt/openssl@1.1/1.1.1a/include $locate openssl/opensslv.h /usr/local/Cellar/openssl/1.0.2p/include/openssl/opensslv.h /usr/local/Cellar/openssl/1.0.2q/include/openssl/opensslv.h /usr/local/Cellar/openssl@1.1/1.1.1/include/openssl/opensslv.h /usr/local/Cellar/openssl@1.1/1.1.1a/include/openssl/opensslv.h
Re: Fixing open relay problem
On Tue, 22 Jan 2019 at 06:22, Stephen McHenry wrote: > I've been running Postfix for many years now (so thanks to Wietse and all > the others who have put in hard work to make it such a great mail system) > and recently I built a new mail server and copied most of the config files > from the old one. > > After a couple of months, I began to notice that it appeared to be getting > used (infrequently) as an open relay, despite my attempts to lock it down > so that couldn't happen. Then, the problem got worse. The one pattern I > noticed was that all the messages had forged senders that were from my > domain (e.g., bogussen...@mydomain.com). > > I've poured through the documentation, and a couple of times thought I > found the answer, only to make a change and have it not work. My band-aid > (while researching the real solution) has been to firewall off access from > IP address ranges that were the sources of the email. But to be clear, > that's only a band-aid until a real solution is in place. > > The two config parameters that seem most relevant to the problem are > listed below: > (from postconf -n) > > *smtpd*_recipient_restrictions = permit_mynetworks, > permit_sasl_authenticated, permit_auth_destination, reject_non_fqdn_sender, > reject_non_fqdn_recipient, reject_unknown_sender_domain, > reject_unknown_recipient_domain, reject_unauth_destination, > reject_unlisted_recipient, reject_unauth_destination check_recipient_access > regexp:/etc/postfix/recipient_checks.regexp, check_recipient_access > hash:/etc/postfix/recipient_checks, reject_unauth_pipelining, > reject_invalid_hostname, reject_non_fqdn_hostname, reject_rbl_client > domain-name, permit > > > (and from postconf -d) > > *smtpd*_relay_restrictions = permit_mynetworks, > permit_sasl_authenticated, defer_unauth_destination > > What's really confounding me is that it seems to be (properly) rejecting > all relay email except those that have mydomain.com in their from > address. Adding to that confusion is that this same set of config > parameters used to work fine on the old system, so I've also been looking > at relevant defaults that changed. Unfortunately, I'm coming up dry at this > point. > > Any help or pointers would be greatly appreciated. > I think you are just lucky that this didn't happen till now. Note that postconf -d just shows the defaults, not what you are using. My approach (a typical one I think) is to block all emails with envelope sender @mydomain.com unless the client has authenticated via port 465 or 587: master.cf: #note - smtps is port 465 465 inet n - y - - smtpd -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=$smtpd_recipient_restrictions_authenticated #submission=port 587 587inet n - y - - smtpd -o smtpd_tls_security_level=encrypt -o syslog_name=postfix/submission -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=$smtpd_recipient_restrictions_authenticated main.cf: ... # for authenticated senders only smtpd_recipient_restrictions_authenticated = # make the implicit permit explicit permit # for all others smtpd_recipient_restrictions = ... check_sender_access hash:/etc/postfix/sender_access ... ... sender_access: ... mydomain.com REJECT privileged domain without authentication ... Note: this stops fake envelope sender using domain.com, but does not stop fake 'From:' header using domain.com; for the latter I use DMARC. I also use header_checks to detect fakes such as From: domi...@mydomain.com < fakesen...@fakedomain.com>.
