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: 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
Appricate some help in understanding a connection refused situation.
3wrt.326.1642610579514; regular_text: Wed, 19 Jan 2022 08:42:59 -0800 (PST) regular_text: MIME-Version: 1.0 regular_text: References: regular_text: regular_text: In-Reply-To: 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-- pointer_record: 0 *** HEADER EXTRACTED deferred/1/14FDA745F9 *** named_attribute: encoding=8bit pointer_record: 0 *** MESSAGE FILE END deferred/1/14FDA745F9 *** -- *** 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: Postgrey - whitelisting subdomains
On Fri, November 26, 2021 14:40, Dino Edwards wrote: > Did you try using > > .dhs.gov > No. As the man page does not indicate that this is correct syntax. I have made that change however and will see it it makes a difference. -- *** 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
Postgrey - whitelisting subdomains
I looked for a postgrey list to ask this, but the one that I found does not seem to have any archives after 2019 so I came here instead. If there is somewhere else to ask this please let me know. We use postfix with postgrey. We have a whitelist /usr/local/etc/postfix/postgrey_whitelist_clients.local According to the man page: Whitelists Whitelists allow you to specify client addresses or recipient address, for which no greylisting should be done. Per default postgrey will read the following files: /usr/local/etc/postfix/postgrey_whitelist_clients /usr/local/etc/postfix/postgrey_whitelist_clients.local /usr/local/etc/postfix/postgrey_whitelist_recipients In /usr/local/etc/postfix/postgrey_whitelist_clients.local we have dhs.gov: [root@mx31 ~]# grep dhs.gov /usr/local/etc/postfix/postgrey_whitelist_clients.local dhs.gov The problem is that postgrey grey-listed this email: Nov 26 13:43:36 mx31 postgrey[27438]: action=greylist, reason=new, client_name=mx0f-00376703.gpphosted.com, client_address=67.231.155.98, sender=aceuserserv...@cbp.dhs.gov, recipient= After a delay the send/receive pair was auto whitelisted. However, I was given to understand that domain entries in the whitelist also applied to subdomains. Also from the postgrey man page: The following can be specified for client addresses: domain.addr "domain.addr" domain and subdomains. Why was email from dhs.gov grey-listed? Have I misconfigured something? -- *** 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: Javamail connection
On Fri, December 25, 2020 12:43, John Stoffel wrote: > > Why don't you setup a local only postfix instance on the same host as > the application, which only listed on 127.0.0.1:25, which the dumb > Java app can then send email through *without encryption*, then let > the local postfix instance do all the hard work of sending the email > to other servers using encryption? > > It seems like the simpler setup to get working right, and gets most of > the pain in the Java app out of the way. > > John > That is reasonable suggestion and is a possibility which I have considered several times. However, in this case the application is being evaluated for its suitability to replace and existing one. Bypassing this particular problem with Postfix only exposes the next arising from the application's unwillingness to accept our certificates. It is established to my satisfaction that this is not a Postfix issue. Therefore,this has to be a configuration issue within the application itself. If I do not solve it now then at some point it is going to cause another problem, likely when we do not have the luxury of time to figure it out. Regards, -- *** 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
Java mail submission through Postfix
I would like to understand exactly what these postfix log messages tell me about starttls, if anything: Dec 24 13:09:32 mx32 postfix-p25/smtpd[25786]: SSL_accept:SSLv3/TLS write session ticket Dec 24 13:09:32 mx32 postfix-p25/smtpd[25786]: Anonymous TLS connection established from accounting-2.internal.harte-lyne.ca[192.168.216.88]: TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 Dec 24 13:09:32 mx32 postfix-p25/smtpd[25786]: NOQUEUE: client=accounting-2.internal.harte-lyne.ca[192.168.216.88], sasl_method=LOGIN, sasl_username=byrnejb_hll Dec 24 13:09:33 mx32 postfix/smtpd[36248]: initializing the server-side TLS engine Dec 24 13:09:33 mx32 postfix/smtpd[36248]: connect from localhost[127.0.32.1] Dec 24 13:09:33 mx32 postfix/smtpd[36248]: 52DEC3DC1C: client=localhost[127.0.32.1] Dec 24 13:09:33 mx32 postfix/cleanup[27823]: 52DEC3DC1C: message-id=<1366581056.0.1608833361...@accounting-2.internal.harte-lyne.ca> Dec 24 13:09:33 mx32 postfix/smtpd[36248]: disconnect from localhost[127.0.32.1] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5 Dec 24 13:09:33 mx32 postfix/qmgr[23987]: 52DEC3DC1C: from=, size=1549, nrcpt=1 (queue active) Dec 24 13:09:33 mx32 postfix-p25/smtpd[25786]: proxy-accept: END-OF-MESSAGE: 250 2.0.0 from MTA(smtp:[localhost]:10025): 250 2.0.0 Ok: queued as 52DEC3DC1C; from= to= proto=ESMTP helo= sasl_username= Dec 24 13:09:33 mx32 postfix/smtp[28101]: 52DEC3DC1C: to=, relay=imap.hamilton.harte-lyne.ca[216.185.71.57]:25, delay=0.15, delays=0.02/0/0.11/0.02, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 72A511C0F8C) Dec 24 13:09:33 mx32 postfix/qmgr[23987]: 52DEC3DC1C: removed Dec 24 13:09:37 mx32 postfix-p25/smtpd[25786]: disconnect from accounting-2.internal.harte-lyne.ca[192.168.216.88] ehlo=2 starttls=1 auth=1 mail=1 rcpt=1 data=1 quit=1 commands=8 -- *** 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: Javamail connection
On Tue, December 22, 2020 13:27, Viktor Dukhovni wrote: > > Your suspicions are unfounded. The client is rejecting the server's > certificate chain with a fatal certificate unknown alert. That's the > issue to fix. All else is distraction. > After reviewing Postix logs with smtpd_tls_logging turned up to 3 I arrived at the same conclusion a little while ago. I am just bereft of ideas as to how to proceed at the moment. -- *** 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: Javamail connection
On Tue, December 22, 2020 12:46, Viktor Dukhovni wrote: > On Tue, Dec 22, 2020 at 09:24:27AM -0500, James B. Byrne wrote: > >> > It clearly supports STARTTLS, since it is actually performing the TLS >> > handshake, and abandons it after receiving certificates it is not happy >> > with. >> >> Which confuses me, because I can use java to successfully negotiate a >> certificate exchange with Postfix using the same keystore that the >> application >> is using. > > Perhaps you're confusing the Java keystore with the Java trust store, > they are separate entities. Java is a programming language, not a > single application. Each Java program gets to do its own thing. > Yes, they often share some common libraries and file formats, ... In this case, from what I can see in the application configuration files, the keystore and the truststore are the same file: . . . / . . . / . . . > > Well, you're running tests with completely different Java client > applications and likely in fact different configuration settings. All > that's in common is that both are Java, which is something, but not > much... Granted, but short of writing my own mail agent in Java, a language that I have next to no experience with, I have to use the tools that I can find and which are simple enough for me to use. SSLPoke is just using the Java SSL libraaries to exercise connectivity, and for a very long time that was the issue. I am now past that stage. > > Note that certificates don't pass "keystore" validation, they pass > "trust store" validation. Java keystores are for your own private > key and cert (akin to PKCS12 containers, or a PEM with key + cert > chain), while trust stores are akin to a cert bundle with lots of > CA certs. As shown above, in this case the application configured to use the same file as both keystore and truststore. In fact, in the SSLPoke tests I was only passing the truststore arguments. But if I do use both key and truststore arguments then I get the same result: JAVA_VERSION="12" java \ -Djavax.net.ssl.trustStore=/opt/idempiere/idempiere-server/jettyhome/etc/keystore \ -Djavax.net.ssl.keyStore=/opt/idempiere/idempiere-server/jettyhome/etc/keystore \ -Djavax.net.ssl.trustStorePassword=testing \ -Djavax.net.ssl.keyStorePassword=testing \ SSLPoke 192.168.216.32 465 Successfully connected > >> I know that the service is different on both ports, but the >> certificate acceptability should be the same. And it is the client >> that is causing the problem. > > You could hypothetically have different certificate settings for > the different ports in master.cf, but if you don't then indeed > the server side TLS behaviour is likely the same across the board. > I do not. And, I believe we are past the phase where the truststore verification is the issue. I may be wrong but the evidence from SSLPoke and KeyStore Explorer tells against verification failing. I am suspicious of the SSLv3 / TLSv1.3 contratemps shown in the Postfix log files. But I have no idea how that would make a certificate unacceptable to the client. Unless it could not read it? -- *** 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: Javamail connection
I have been looking at the Postfix logs and wonder if this is significant: Dec 22 10:10:08 mx32 postfix-p25/smtpd[12694]: SSL_accept:SSLv3/TLS read client hello Dec 22 10:10:08 mx32 postfix-p25/smtpd[12694]: SSL_accept:SSLv3/TLS write server hello Dec 22 10:10:08 mx32 postfix-p25/smtpd[12694]: SSL_accept:SSLv3/TLS write change cipher spec Dec 22 10:10:08 mx32 postfix-p25/smtpd[12694]: SSL_accept:TLSv1.3 write encrypted extensions Dec 22 10:10:08 mx32 postfix-p25/smtpd[12694]: SSL_accept:SSLv3/TLS write certificate Dec 22 10:10:08 mx32 postfix-p25/smtpd[12694]: SSL_accept:TLSv1.3 write server certificate verify Dec 22 10:10:08 mx32 postfix-p25/smtpd[12694]: SSL_accept:SSLv3/TLS write finished Dec 22 10:10:08 mx32 postfix-p25/smtpd[12694]: SSL_accept:TLSv1.3 early data Dec 22 10:10:08 mx32 postfix-p25/smtpd[12694]: SSL3 alert read:fatal:certificate unknown Dec 22 10:10:08 mx32 postfix-p25/smtpd[12694]: SSL_accept:error in error Dec 22 10:10:08 mx32 postfix-p25/smtpd[12694]: SSL_accept error from accounting-2.internal.harte-lyne.ca[192.168.216.88]: -1 Dec 22 10:10:08 mx32 postfix-p25/smtpd[12694]: warning: TLS library problem: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown:/usr/src/crypto/openssl/ssl/record/rec_layer_s3.c:1544:SSL alert number 46: It appears to me that the client is insisting on SSLv3 but that Postfix is looking for or replying with TLSv1.3. Would that cause a problem with the certificate being recognised by the client? -- *** 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: Javamail connection
On Mon, December 21, 2020 20:07, Viktor Dukhovni wrote: > It clearly supports STARTTLS, since it is actually performing the TLS > handshake, and abandons it after receiving certificates it is not happy > with. > Which confuses me, because I can use java to successfully negotiate a certificate exchange with Postfix using the same keystore that the application is using. I cannot see Postfix sending a different server certificate on port 465 from that it presents on ports 25 or 465. And if the certificate on 465 passes the keystore validation on the client then what would prevent it from passing on post 25? I know that the service is different on both ports, but the certificate acceptability should be the same. And it is the client that is causing the problem. -- *** 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: Javamail connection
On Mon, December 21, 2020 20:00, Jaroslaw Rafa wrote: > > If you are able to connect via 465, then maybe the application just isn't > designed to use "inline" TLS, but rather uses only SMTP-over-TLS? The latter > is supported on port 465, while submission via port 587 requires first > plaintext connection and then dynamic in-session switchover to TLS, using > STARTTLS command. Maybe your application just does not support that? That is a possibility. However, having looked at the example configurations and discussions on the application support groups, it appears to me that connecting to port 25 with STARTTLS is the accepted practice. The problem I had with the certificate negotiation is not uncommon with this application, due to Java's rather idiosyncratic PKI certificate handling. I had reason to believe that when I finally solved that problem then everything else would just work. The SSLv3 problem was a surprise, but was easily compensated for. But, I still cannot get this application to send email so there must be something else that I have done, or not done, which is preventing this from working. And it seems that I am past the SSL problems and into SMTP, I hope. -- *** 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: Javamail connection
On Mon, December 21, 2020 16:12, Wietse Venema wrote: > > This test connects to a DIFFERENT Postfix service than the Javamail client. > This proves NOTHING about the service that the Javamail client connects to. > We are discussing this at cross-purposes. I understand that the service at 465 is not the STARTTLS postfix service. The software I am using to test the SSL connection does not do SMTP in any case. The initial problem was simply getting javamail to recognize the validity of the PKI certificate presented by Postfix. A successful connection to 465 with the certificate chain proves that the certificate Postfix presents is accepted and nothing else. However, up to yesterday, that was the problem. Now I can move on to the next, which is why the application cannot negotiate a STARTTLS with Postfix. The next problem uncovered was that the application insists on using SSLv3 and Postfix was configured with that disabled. Now with SSLv3 enabled on Postfix, albeit temporarily, I need to discover what else is preventing a successful STARTTLS connection. It is like peeling an onion, every problem solved reveals another difficulty. But, eventually one runs out of layers and obtains the desired result. The application is in widespread use so the difficulty has to be local to my set up. I just have to discover what that is. -- *** 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: Javamail connection
On Mon, December 21, 2020 15:42, Viktor Dukhovni wrote: > > This is largely a non-Postfix issue. You're struggling to configure and > use some Java software, and this is not the forum for support with that. I understand that. Java support is not what I am asking for. I am trying to understand what the error messages are telling me. > > It is, however, fair to ask here for clarification of Postfix error > messages, and any issues with configuring the certificates/keys for > a Postfix SMTP server or client. > > The particular error is unequivocally the client not liking the server > certificate chain. If the server certificate chain (which you can > test with: > > posttls-finger -cC -F /some/CAfile -l secure "[server-name]:25" > > is as expected, then debugging the client's unhappiness is a proper > topic for a different forum. > I have used openssl s_client to effect that same test. It has always passed. The problem being that openssl, as postfix, does not use a java keystore to verify certificates. I have finally gotten to the point that the certificate errors are not the Java issue, or at least they should not be, since I can use Java and the keystore to successfully connect to Postfix, albeit on port 465. So, the error is somewhere in the application. But, I did not write it. So I need to pin down what is happening and understand it. Otherwise I will not be able to get anything done with fixing it. If indeed it is is a programing error and not some obscure configuration setting. The help I receive here is invaluable. Thank you. -- *** 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: Javamail connection
On Mon, December 21, 2020 15:22, Wietse Venema wrote: > James B. Byrne: > [ Charset ISO-8859-1 converted... ] >> >> >> On Mon, December 21, 2020 13:46, Wietse Venema wrote: >> > James B. Byrne: >> >> > Dec 21 12:25:21 mx32 postfix-p25/smtpd[62565]: warning: TLS library >> >> problem: >> >> > error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate >> >> > unknown:/usr/src/crypto/openssl/ssl/record/rec_layer_s3.c:1544:SSL alert >> >> number >> >> > 46: >> >> > Dec 21 12:25:21 mx32 postfix-p25/smtpd[62565]: lost connection after >> >> STARTTLS >> >> > from accounting-2.internal.harte-lyne.ca[192.168.216.88] >> > >> > Results from A web search suggest that this may be a certificate >> > verification problem. >> >> That is what I have been trying to confirm. And after a lot of poking around >> with Java's keystore/cacrets implementation I think that I have ruled that >> out: >> >> JAVA_VERSION="12" java >> -Djavax.net.ssl.trustStore=/opt/idempiere/idempiere-server/jettyhome/etc/keystore >> -Djavax.net.ssl.trustStorePassword=idempiere-2020-ksadmin SSLPoke >> 192.168.216.32 465 >> Successfully connected > > That proves nothing. This test uses port 465, but your Javamail is > connecting to port 25. > I disagree. What it shows is that Java, using the keystore belonging to the application, can connect and verify an SSL connection to postfix on the target host. The port is immaterial as that does not affect whether or not the client/server certificates are acceptable to the Trust Store. I have just spent two weeks getting to this point. Up until this morning I could not get SSLPoke to successfully connect to the mail service at all. And the error was always to do with the certificate chain. SSLPoke cannot do STARTTLS and thus it will always fail on ports 25 and 587 whether or not the certificate chain was acceptable because it gets an unexpected SSL message. openssl s_client -starttls smtp from the application host has always been able to successfully connect to TCP25 on the target, but openssl does not use the keystore file. -- *** 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: Javamail connection
On Mon, December 21, 2020 14:20, Viktor Dukhovni wrote: > > - The Postfix SMTP server is reporting an error from the underlying > OpenSSL library. > - That error is receipt of a fatal "SSL alert", i.e. a courtesy message > from the *client* that it cannot complete the handshake, and is giving up. > - Instead of just disconnecting, the client indicates the reason why it > can't go on. > - The specific reason is that the clien is unhappy with the server's > certificate. I agree. And for the past ten days that is what I have been trying to resolve. I finally did that this morning and successfully connected to the mx service host using the exact keystore file that the application uses. JAVA_VERSION="12" java -Djavax.net.ssl.trustStore=/opt/idempiere/idempiere-server/jettyhome/etc/keystore -Djavax.net.ssl.trustStorePassword=testing SSLPoke 192.168.216.32 465 So, there has to be something in the application that is causing this to break. But I am not a Java programmer. I am simply trying to get this messaging feature to work so that we can proceed with our evaluation of idempiere. > > SSLv3 is a red herring, the TLS protocol (1.0 through 1.2) evolved from > of SSLv3 and shares much code with the original (now deprecated) SSLv3. > While TLS 1.3 is a significant departure, it too still shares some of > the underpinnings, so you'll see "sslv3" in error messages for all > protocol versions from SSLv3 through TLS 1.3. > In this case, the connection from the client could not get past the protocol handshake until after SSLv3 was re-enabled. But the advice about misleading error messages is duly noted. -- *** 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: Javamail connection
On Mon, December 21, 2020 13:46, Wietse Venema wrote:
> James B. Byrne:
>> > Dec 21 12:25:21 mx32 postfix-p25/smtpd[62565]: warning: TLS library
>> problem:
>> > error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate
>> > unknown:/usr/src/crypto/openssl/ssl/record/rec_layer_s3.c:1544:SSL alert
>> number
>> > 46:
>> > Dec 21 12:25:21 mx32 postfix-p25/smtpd[62565]: lost connection after
>> STARTTLS
>> > from accounting-2.internal.harte-lyne.ca[192.168.216.88]
>
> Results from A web search suggest that this may be a certificate
> verification problem.
That is what I have been trying to confirm. And after a lot of poking around
with Java's keystore/cacrets implementation I think that I have ruled that out:
JAVA_VERSION="12" java
-Djavax.net.ssl.trustStore=/opt/idempiere/idempiere-server/jettyhome/etc/keystore
-Djavax.net.ssl.trustStorePassword=idempiere-2020-ksadmin SSLPoke
192.168.216.32 465
Successfully connected
The file /opt/idempiere/idempiere-server/jettyhome/etc/keystore is the java
keystore used by the Jetty application. 192.168.216.32 is the host that the
application is trying to send email through. I cannot connect to TCP25 with
SSLPoke because SSLPoke does not do STARTTLS. Likewise for TCP587. But TCP465
does not do STARTTLS and so the certificate handshake gets initiated and
accepted by the client:
Dec 21 14:19:45 mx32 postfix-p465/smtpd[38338]: SSL_accept:before SSL
initialization
Dec 21 14:19:45 mx32 syslogd: last message repeated 1 times
Dec 21 14:19:45 mx32 postfix-p465/smtpd[38338]: SSL_accept:SSLv3/TLS read
client hello
Dec 21 14:19:45 mx32 postfix-p465/smtpd[38338]: SSL_accept:SSLv3/TLS write
server hello
. . .
Dec 21 14:19:45 mx32 syslogd: last message repeated 1 times
Dec 21 14:19:45 mx32 postfix-p465/smtpd[38338]: SSL_accept:SSLv3/TLS read
finished
Dec 21 14:19:45 mx32 postfix-p465/smtpd[38338]:
accounting-2.internal.harte-lyne.ca[192.168.216.88]: Issuing session ticket,
key expiration: 1608578588
Dec 21 14:19:45 mx32 postfix-p465/smtpd[38338]:
accounting-2.internal.harte-lyne.ca[192.168.216.88]: save session
7E720D7E3D4A5307C7CB9D260FCD393FA066ED895E350B36F67322E61C0F0C32=smtps=269488207
to smtpd cache
Dec 21 14:19:45 mx32 postfix-p465/smtpd[38338]: send attr request = update
Dec 21 14:19:45 mx32 postfix-p465/smtpd[38338]: send attr cache_type = smtpd
Dec 21 14:19:45 mx32 postfix-p465/smtpd[38338]: send attr cache_id =
7E720D7E3D4A5307C7CB9D260FCD393FA066ED895E350B36F67322E61C0F0C32=smtps=269488207
Dec 21 14:19:45 mx32 postfix-p465/smtpd[38338]: send attr session = [data 119
bytes]
Dec 21 14:19:45 mx32 postfix/tlsmgr[93660]: put smtpd session
id=7E720D7E3D4A5307C7CB9D260FCD393FA066ED895E350B36F67322E61C0F0C32=smtps=269488207
[data 119 bytes]
Dec 21 14:19:45 mx32 postfix/tlsmgr[93660]: write smtpd TLS cache entry
7E720D7E3D4A5307C7CB9D260FCD393FA066ED895E350B36F67322E61C0F0C32=smtps=269488207:
time=1608578385 [data 119 bytes]
. . .
Dec 21 14:19:45 mx32 postfix-p465/smtpd[38338]: SSL_accept:SSLv3/TLS write
session ticket
>
> What is the output from these commands:
>
> postconf -n |grep 'smtpd.*tls'
smtpd_starttls_timeout = ${stress?10}${stress:120}s
smtpd_tls_CAfile = /usr/local/etc/pki/tls/certs/ca-bundle.crt
smtpd_tls_ask_ccert = no
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /usr/local/etc/pki/tls/certs/ca.harte-lyne.mx32.crt
smtpd_tls_ciphers = high
smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
smtpd_tls_exclude_ciphers = MD5, aDSS, kECDH, kDH, 3DES, RC4, SEED, IDEA, RC2,
RC5
smtpd_tls_fingerprint_digest = sha256
smtpd_tls_key_file = /usr/local/etc/pki/tls/private/ca.harte-lyne.mx32.key
smtpd_tls_loglevel = 2
smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_protocols = TLSv1.3, TLSv1.2, TLSv1.1, TLSv1, SSLv3, !SSLv2
smtpd_tls_protocols = TLSv1.3, TLSv1.2, TLSv1.1, TLSv1, SSLv3, !SSLv2
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:/var/db/postfix/smtpd_scache
smtpd_tls_session_cache_timeout = 3
Note that SSLv3 has only been enabled to carry out these tests. Ihe
application would not successfully connect otherwise.
> postconf -P |grep 'smtpd.*tls'
smtp/inet/smtpd_tls_security_level = may
submission/inet/smtpd_recipient_restrictions =
permit_sasl_authenticated,permit_tls_clientcerts,reject_unauth_destination
submission/inet/smtpd_sender_restrictions =
permit_sasl_authenticated,permit_tls_clientcerts,reject
submission/inet/smtpd_tls_security_level = encrypt
smtps/inet/smtpd_recipient_restrictions =
permit_sasl_authenticated,permit_tls_clientcerts,reject_unauth_destination
smtps/inet/smtpd_sender_restrictions =
permit_sasl_authenticated,permit_tls_clientcerts,reject_unauth_destination
smtps/inet/smtpd_tls_wrappermode = yes
localhost:2626/inet/smtpd_tls_security_level = none
>
> Which of your three smtpd services is the client connecting t
Re: Javamail connection
On Mon, December 21, 2020 12:30, James B. Byrne wrote: > I have gotten to the point that the keystore used by the jetty application is > properly configured: > > JAVA_VERSION="12" java > -Djavax.net.ssl.trustStore=/opt/idempiere/idempiere-server/jettyhome/etc/keystore > -Djavax.net.ssl.trustStorePassword=testing SSLPoke mx32.harte-lyne.ca 465 > Successfully connected > > This means that the server's certificate is properly recognized by the client > host. > > However, we nonetheless get this error from Postfix when we send a test email > through the application: > > Dec 21 12:25:21 mx32 postfix-p25/smtpd[62565]: warning: TLS library problem: > error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate > unknown:/usr/src/crypto/openssl/ssl/record/rec_layer_s3.c:1544:SSL alert > number > 46: > Dec 21 12:25:21 mx32 postfix-p25/smtpd[62565]: lost connection after STARTTLS > from accounting-2.internal.harte-lyne.ca[192.168.216.88] > > I believe that this is telling me that the application is attempting to > establish an SSL connection using STARTTLS. However, the error referencing > the > certificate is mystifying to me. > > Can someone explain to me what this error means? > Let me guess. We do not allow SSLv3. The application uses SSLv3. Our settings: smtpd_tls_protocols = TLSv1.3, TLSv1.2, TLSv1.1, TLSv1, !SSLv3, !SSLv2 smtpd_tls_mandatory_protocols = TLSv1.3, TLSv1.2, TLSv1.1, TLSv1, !SSLv3, !SSLv2 And submission requires encryption: smtpd_tls_security_level = may smtpd_tls_auth_only = yes So no fallback is possible. If this is the problem. -- *** 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: Javamail connection
I have gotten to the point that the keystore used by the jetty application is properly configured: JAVA_VERSION="12" java -Djavax.net.ssl.trustStore=/opt/idempiere/idempiere-server/jettyhome/etc/keystore -Djavax.net.ssl.trustStorePassword=testing SSLPoke mx32.harte-lyne.ca 465 Successfully connected This means that the server's certificate is properly recognized by the client host. However, we nonetheless get this error from Postfix when we send a test email through the application: Dec 21 12:25:21 mx32 postfix-p25/smtpd[62565]: warning: TLS library problem: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown:/usr/src/crypto/openssl/ssl/record/rec_layer_s3.c:1544:SSL alert number 46: Dec 21 12:25:21 mx32 postfix-p25/smtpd[62565]: lost connection after STARTTLS from accounting-2.internal.harte-lyne.ca[192.168.216.88] I believe that this is telling me that the application is attempting to establish an SSL connection using STARTTLS. However, the error referencing the certificate is mystifying to me. Can someone explain to me what this error means? -- *** 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: Javamail connection
On Thu, December 17, 2020 14:28, Wietse Venema wrote: > Wietse Venema: > > Very likely, tls_wrappermode is turned on as it should be on port > 465, which requires the client to speak first (no server greewting, > no client EHLO and STARTTLS). > > Apparently, the client is configured to expect "port 578" server > where a server speaks first and sends a greeting before the client > sends EHLO and STARTTLS. > > Wietse Did you mean port 587? -- *** 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
Javamail connection
ames 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: should we use plaintext for message?
Has anyone considered the absolute want of utility that image data presents for the blind? The advantage of plain text is that there are any number of automated assists that can process it into audio. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: how to reroute messages in queue
On Mon, March 16, 2020 13:37, Wietse Venema wrote: > > Is that a content filter setting? You may be able to work around > that with "postsuper -r AD79220201". That command moves the message > to the maildrop queue. From there on, Postfix ignores the content > filter record, and handles the message as if it is submnitted with > /usr/sbin/sendmail. If you have enabled content inspection for the > pickup daemon, then the message will get a new content_filter record > with the correct IP address. > > Wietse > Thank you very much. That worked perfectly for Q in $(mailq | grep Mar | cut -f1 -d" "); do postsuper -r $Q; done -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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
how to reroute messages in queue
postfix v-3.4.9 on FreeBSD-12. We run our postfix mail exchangers in FreeBSD jails. Following the conversion of one of these from ezjail to iocage we encountered a problem with amavisd and opendkim resulting from the different manner in which iocage handles the loopback address. These issues have been resolved. However, there are 20 messages stuck in the delivery queue all having the same reason: AD79220201 1501819 Mon Mar 16 08:34:42 byrn...@harte-lyne.ca (delivery temporarily suspended: connect to 127.0.0.1[127.0.0.1]:10024: Connection refused) Is there any way to change the queued messages target address from 127.0.0.1 to the one assigned by iocage, in this case 127.0.32.1? Sincerely, -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: STARTTLS and PCI requirements
On Thu, January 2, 2020 13:16, Viktor Dukhovni wrote: > > What protocol versions do you have enabled? More likely the issue is > that you've disabled TLS 1.0. > You are correct. Disabling TLSv1 as we were instructed to do by the PCI DSS audit, is the root cause of the problem. This has been corrected, or broken depending upon ones point of view. The haphazard exclude list has been rendered more sane. Now I need to see if the PCI people will consider TLSv1 a false positive or exception. Thank you all for the help. Sincerely, -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: STARTTLS and PCI requirements (postfix-3.3.4)
The following are the settings in main.cf that have been changed
followed by the commented (#) default values:
postconf mail_version
mail_version = 3.3.4
postconf -n | grep smtp | grep tls
smtp_tls_CAfile = /usr/local/etc/pki/tls/certs/ca-bundle.crt
#smtp_tls_CAfile =
smtp_tls_cert_file =
/usr/local/etc/pki/tls/certs/ca.harte-lyne.mx31.crt
#smtp_tls_cert_file =
smtp_tls_ciphers = high
#smtp_tls_ciphers = medium
smtp_tls_exclude_ciphers = MD5, aDSS, SRP, PSK, aECDH, aDH, SEED,
IDEA, RC2,\ RC4, RC5, DES, 3DES #smtp_tls_exclude_ciphers =
smtp_tls_key_file = /usr/local/etc/pki/tls/private/ca.harte-lyne.mx31.key
#smtp_tls_key_file = $smtp_tls_cert_file
smtp_tls_mandatory_ciphers = high
#smtp_tls_mandatory_ciphers = medium
smtp_tls_mandatory_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1,
!SSLv3, !SSLv2
#smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
smtp_tls_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv3,
!SSLv2#smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_security_level = dane
#smtp_tls_security_level =
smtp_tls_session_cache_database = btree:/var/db/postfix/smtp_scache
#smtp_tls_session_cache_database =
smtp_tls_session_cache_timeout = 3600s
#smtp_tls_session_cache_timeout = 3600s
smtpd_starttls_timeout = ${stress?10}${stress:120}s
#smtpd_starttls_timeout = ${stress?{10}:{300}}s
smtpd_tls_CAfile = /usr/local/etc/pki/tls/certs/ca-bundle.crt
#smtpd_tls_CAfile =
smtpd_tls_ask_ccert = no
#smtpd_tls_ask_ccert = no
smtpd_tls_auth_only = yes
#smtpd_tls_auth_only = no
smtpd_tls_cert_file = /usr/local/etc/pki/tls/certs/ca.harte-lyne.mx31.crt
#smtpd_tls_cert_file =
smtpd_tls_ciphers = high
#smtpd_tls_ciphers = medium
smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
#smtpd_tls_dh1024_param_file =
smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK,
aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, KRB5-DES, CBC3-SHA
#smtpd_tls_exclude_ciphers =
smtpd_tls_fingerprint_digest = sha256
#smtpd_tls_fingerprint_digest = md5
smtpd_tls_key_file =
/usr/local/etc/pki/tls/private/ca.harte-lyne.mx31.key
#smtpd_tls_key_file = $smtpd_tls_cert_file
smtpd_tls_mandatory_ciphers = high
#smtpd_tls_mandatory_ciphers = medium
smtpd_tls_mandatory_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1,
!SSLv3, !SSLv2
#smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv3, !SSLv2
#smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_received_header = yes
#smtpd_tls_received_header = no
smtpd_tls_security_level = may
#smtpd_tls_security_level =
smtpd_tls_session_cache_database = btree:/var/db/postfix/smtpd_scache
#smtpd_tls_session_cache_database =
smtpd_tls_session_cache_timeout = 3600s
#smtpd_tls_session_cache_timeout = 3600s
--
*** e-Mail is NOT a SECURE channel ***
Do NOT transmit sensitive data via e-Mail
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: STARTTLS and PCI requirements
On Thu, January 2, 2020 12:35, Bastian Blank wrote: > On Thu, Jan 02, 2020 at 12:16:33PM -0500, James B. Byrne wrote: >> We recently were forced by our PCI compliance audit to change our >> permissible ciphers. I speculate that this is the source of our >> problem. Our revised cipher list is: > > Don't, as long as you don't enforce encryption as well. > >> I would appreciate any guidance as to how to correct this issue >> without running afoul of the PCI DSS. > > Don't use mail to transport payment data, so PCI is not applicable. This advice is not helpful. It is not what we are sending but rather what we are receiving. We have no control over the information that our clients send us. PCI DSS exists to deal with this sort of thing. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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
STARTTLS and PCI requirements
-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: Question respecting the headers?
On Wed, July 24, 2019 13:21, Bill Cole wrote: > On 24 Jul 2019, at 12:56, James B. Byrne wrote: > >> I am sure that the message associated with the header extract >> reproduced below is fraudulent. But, I would like to know how this >> particular header line was constructed at the source: >> >> Received: from theguardian.com (regtreis.viverindia.com.br >> [31.172.134.4]) >> >> How did they get 'from theguardian.com' into the Received header >> generated by our mx? > > The token immediately following the "from" in a Received header > generated by Postfix is the name offered in the EHLO or HELO command > from the SMTP client. > I am not asking this question correctly. theguardian.com is not the domain that is sending this traffic. The people who are sending it connect from an array of IP addresses but they always use theguardian.com as the server name. I had believed up until this moment that we were checking that the remote server name matched the server domain but perhaps we are just checking that the server name exists in DNS. Can we configure Postfix to prevent fraudulent use of a valid DNS host? -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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
address with illegal extension
FreeBSD-11.2 Postfix-3.3.1 cyrus-imapd-3.0.7 We have discovered that our maillog file has numerous occurrences of this sort of error report: postfix/local[92211]: warning: A7F5413745E: address with illegal extension: sysadmin+root/cron/transfers/imanet This error does not prevent the correct delivery of messages into subfolders. The proximate cause of this are entries in virtual_domains similar to: ima...@host.harte-lyne.ca sysadmin+root/cron/transfers/imanet Where we use '/' to delineate the folder hierarchy. If we change the RHS in virtual_domains to use '.' then the error messages in maillog disappear. However, if we use '.' instead of '/' then the local delivery agent dumps the messages into the user's top level mailbox instead of the desired folder. Using '/' is dictated by cyrus-imap. Formerly cyrus-imap used '.' but with the upgrade to v3 the use of '.' was deprecated and '/' recommended in its place. Which we did. My question is: what rfc makes the '/' illegal in a local delivery address? -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: Name Service error but resolver is working
I appreciate your help on this. I have visited http://dnsviz.net, rerun the analysis, and followed the DNS tree from root to leaf. I see this: DNSKEYalg=8, id=203262048 bit DNSKEYalg=8, id=21342048 bits (secure) DSdigest alg=2 (secure) DNSKEYalg=8, id=21342048 bits (secure) DNSKEYalg=8, id=354331024 bits (secure) DNSKEYalg=8, id=378522048 bits (secure) DNSKEYalg=8, id=206491280 bits (secure) mx31.harte-lyne.ca/A (secure) Responses for mx31.harte-lyne.ca/MX NameTTL TypeDataStatus Returned by dns01 dns02 dns03 dns04 RR count (Answer/Authority/Additional) OK 0/4/1 0/4/1 Response size (bytes) OK 606 606 Response time (ms) OK 22 37 To me it seems that DNSSEC is working for us. What is it in the report that tells you it is not? We are changing our nameserver IP addresses at our remote location (DNS02 [216.185.71.133] and DNS04 [216.185.71.134]). We are at the same time reconfiguring the services themselves. I do not know if this is having any impact on these problems but if it is then it is not likely that this will be resolved today. Thank you for your assistance. I am clearly missing something that is obvious to you and I would appreciate it very much to find out what that is. On Thu, November 8, 2018 10:17, Viktor Dukhovni wrote: > >> On Nov 8, 2018, at 10:01 AM, Viktor Dukhovni >> wrote: >> >> My analysis is that some of upstream providers have broken DNSSEC >> implementations that don't handle NSEC3 properly or at all, and >> therefore "authenticated denial of existence" is not working for >> your domain. >> >> If the problem is still unresolved your choices are: >> >> * Try switching to NSEC. Delete "NSEC3PARAM" and re-sign >>the zone. >> >> * Find a more competent DNS provider >> >> * Temporarily disable DNSSEC (remove the DS records at .CA) >>until the problems with denial of existence are resolved. >> >> If DNSSEC is desired, but not critical, I'd do the last first, >> then try either or both of the first two, until the nameservers >> respond correctly with appropriately signed NSEC or NSEC3 >> records for queries that return NoData and NXDdomain. > > And the problem does appear unresolved (link is to analysis at a > specific time, so won't change when the issue is actually resolved): > > http://dnsviz.net/d/mx31.harte-lyne.ca/W-RStQ/dnssec/?rr=15=all=all=on=.= > -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: Name Service error but resolver is working
> > People are telling you the answer, and you're refusing to listen, I > find this puzzling, unless you're no longer getting email from the > list (which seems plausible). I am afraid that my comprehension of what has been written is limited. I regret the defect but there it is. > Every MTA will perform *MX* lookups on the envelope > sender domain, before it looks for any *A* records. When the *MX* > lookups fail, your domain is down, and your mail will tempfail. Thank you. Now I understand what is happening and how my previous beliefs were misinformed. > > $ dig -t mx SAMBA-01.BROCKLEY-2016.HARTE-LYNE.CA > > ; <<>> DiG 9.11.2 <<>> -t mx SAMBA-01.BROCKLEY-2016.HARTE-LYNE.CA > ;; global options: +cmd > ;; connection timed out; no servers could be reached > > Your DNS is broken. Fix it! At the .CA level you have: > > Below that things look rather grim, your nameservers need attention. > We have been experiencing an prolonged outage at our off-site dns location. The two NS in question are located there. The establishment of NS at multiple location was intended to handle this sort of situation. We are dealing with the matter but it involves two separate upstream providers and is somewhat complicated thereby. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: Name Service error but resolver is working
I do not know what is going on here: This is found in the maillog on inet17 Nov 7 16:40:21 inet17 postfix/smtpd[79991]: NOQUEUE: reject: RCPT from unknown[216.185.71.31]: 450 4.1.2 : Recipient address rejected: Domain not found; from=<> to= proto=ESMTP helo= But this is what I get when I run dig on the same host a moment later: [root@inet17 /var/spool/imap]# dig SAMBA-01.BROCKLEY-2016.HARTE-LYNE.CA ; <<>> DiG 9.12.1-P2 <<>> SAMBA-01.BROCKLEY-2016.HARTE-LYNE.CA ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 706 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;SAMBA-01.BROCKLEY-2016.HARTE-LYNE.CA. IN A ;; ANSWER SECTION: SAMBA-01.BROCKLEY-2016.HARTE-LYNE.CA. 60 IN A 192.168.8.65 ;; AUTHORITY SECTION: BROCKLEY-2016.HARTE-LYNE.CA. 172800 IN NS samba-02.BROCKLEY-2016.HARTE-LYNE.CA. BROCKLEY-2016.HARTE-LYNE.CA. 172800 IN NS samba-03.BROCKLEY-2016.HARTE-LYNE.CA. BROCKLEY-2016.HARTE-LYNE.CA. 172800 IN NS samba-04.BROCKLEY-2016.HARTE-LYNE.CA. BROCKLEY-2016.HARTE-LYNE.CA. 172800 IN NS samba-05.BROCKLEY-2016.HARTE-LYNE.CA. BROCKLEY-2016.HARTE-LYNE.CA. 172800 IN NS SAMBA-01.BROCKLEY-2016.HARTE-LYNE.CA. ;; Query time: 1 msec ;; SERVER: 216.185.71.33#53(216.185.71.33) ;; WHEN: Wed Nov 07 16:41:16 EST 2018 ;; MSG SIZE rcvd: 187 Why does dig find the domain while Postfix does not? I am guessing that I have a misconfiguration somewhere but I cannot think of where. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: Name Service error but resolver is working
On Wed, November 7, 2018 12:22, Paul wrote: > Hi > > Maybe related to some of your NS not responding certainly from the UK > that is > > dig -t a mx31.harte-lyne.ca @dns01.harte-lyne.ca OK > > dig -t a mx31.harte-lyne.ca @dns02.harte-lyne.ca    No > response > > dig -t a mx31.harte-lyne.ca @dns03.harte-lyne.ca  several > seconds to > respond > > dig -t a mx31.harte-lyne.ca @dns04.harte-lyne.ca  No response > Neither dns02 nor dns04 are listed in the /etc/resolv.conf file on the affected services. With respect to Viktor's answer. My understanding is that: in the absence of a specified MX record then the A RR is supposed to be used. In this case MX31 is one of the MX for the entire domain. Why is the failure to lookup an MX record fatal? Why is not the A record value used in its absence? -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: Name Service error but resolver is working
>> 50DFB12B2F7 7501 Tue Nov 6 17:22:42 MAILER-DAEMON >> (delivery temporarily suspended: Host or domain name not found. >> Name service error for name=mx31.harte-lyne.ca type=MX: Host not >> found, try again) On Wed, November 7, 2018 11:30, Wietse Venema wrote: >> I do not understand what the DNS issue is, but I cannot flush >> messages with this error. > > Are your services chrooted? > > $ postconf -F '*/unix/chroot' | grep '\= y' > > Those will not use the name server configured in /etc/resolv.conf, > but rather, the one configured in $queue_directory/etc/resolv.conf. > > Wietse No. We do not use chrooted services: # postconf -F '*/unix/chroot' anvil/unix/chroot = n bounce/unix/chroot = n cleanup/unix/chroot = n defer/unix/chroot = n discard/unix/chroot = n error/unix/chroot = n flush/unix/chroot = n lmtp/unix/chroot = n local/unix/chroot = n proxymap/unix/chroot = n proxywrite/unix/chroot = n relay/unix/chroot = n retry/unix/chroot = n rewrite/unix/chroot = n scache/unix/chroot = n showq/unix/chroot = n smtp/unix/chroot = n tlsmgr/unix/chroot = n trace/unix/chroot = n verify/unix/chroot = n virtual/unix/chroot = n retry/unix/chroot = n -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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
Name Service error but resolver is working
On our IMAP service host I am seeing messages in the mailq similar to the following: 50DFB12B2F7 7501 Tue Nov 6 17:22:42 MAILER-DAEMON (delivery temporarily suspended: Host or domain name not found. Name service error for name=mx31.harte-lyne.ca type=MX: Host not found, try again) Postfix on the IMAP host is configured to route outgoing mail through MX31. And mail is flowing in and out of the IMAP system. Most things are being delivered. But a few messages are stuck in the mail queue with this error and I cannot figure out what the problem with them is. I have confirmed that the DNS resolver on both the IMAP host and MX31 are working. I can ping from the IMAP host to MX31. On the IMAP host I can use swaks to successfully send mail via the localhost. On the IMAP host I can also use swaks to successfully send mail via MX31. The test messages both arrived in the destination mailbox on the IMAP host. I do not understand what the DNS issue is, but I cannot flush messages with this error. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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
What is Postfix telling me?
Starting shortly after midnight 20180906 our maillog file began to record this sort of message pair every six minutes or so. Sep 6 12:36:42 mx31 postgrey[85107]: action=pass, reason=client AWL, client_name=malton22-1176258451.sdsl.bell.ca, client_address=70.28.71.147, sender=c...@airportcargo.ca, recipient=impo...@harte-lyne.ca Sep 6 12:36:48 mx31 postfix-p25/smtpd[66636]: proxy-reject: END-OF-MESSAGE: 451 4.5.0 Error in processing, id=29937-07, quar+notif FAILED: mail_dispatch: no recognized protocol name: -2 at /usr/local/sbin/amavisd line 9638.; from= to= proto=ESMTP helo= We are not getting the error message for any other domain and we do not get it for every message from airportcargo.ca. For example: Sep 6 15:06:21 mx31 postgrey[85107]: action=pass, reason=client AWL, client_name=toroondcmxzomta01.bellnexxia.net, client_address=67.69.168.80, sender=c...@airportcargo.ca, recipient=impo...@harte-lyne.ca Sep 6 15:06:21 mx31 policyd-spf[68870]: prepend X-Comment: SPF skipped for whitelisted relay domain - client-ip=67.69.168.80; helo=toroondcmxzomta01-srv.bellnexxia.net; envelope-from=c...@airportcargo.ca; receiver= Sep 6 15:06:22 mx31 postfix/qmgr[79845]: E64931EBF7: from=, size=3786, nrcpt=1 (queue active) Sep 6 15:06:22 mx31 postfix-p25/smtpd[64693]: proxy-accept: END-OF-MESSAGE: 250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as E64931EBF7; from= to= proto=ESMTP helo= Since SPF appears to figure in the successful receipt I checked the DNS RR: drill airportcargo.ca txt ;; ANSWER SECTION: airportcargo.ca.11072 IN TXT "v=spf1 a mx include:mail.airportcargo.ca include:airportcargo.ca include:home.zetwork.ca ~all" drill airportcargo.ca mx ;; ANSWER SECTION: airportcargo.ca.4552 IN MX 30 lastmx.spamexperts.net. airportcargo.ca.4552 IN MX 20 fallbackmx.spamexperts.eu. airportcargo.ca.4552 IN MX 10 mx.spamexperts.com. But this only tells me that any SPF failure for airportcargo.ca messages should be treated as a softfail. Our policyd-spf.conf has these options set: HELO_reject = Fail - Reject on HELO Fail Mail_From_reject = Fail Domain_Whitelist = bellnexxia.net,lcbo.com Which, to me, indicates that mail arriving via bellnexxia.net is not checked for SPF compliance or at least messages delivered by that route do not fail regardless of the SPF settings for the sender's domain. If someone could clue me in as to what is happening then I would be most grateful. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: SPF + outside backup MX relay = redelivery failures: Help requested
On Tue, July 24, 2018 10:27, Phil Stracchino wrote: > On 07/24/18 09:59, Phil Stracchino wrote: >> On 07/24/18 08:42, Viktor Dukhovni wrote: >>>> On Jul 24, 2018, at 8:36 AM, Phil Stracchino >>>> wrote: >>>> >>>> EXCEPT when mail is being queued through my secondary MX >>>> because I'm >>>> offline. Then it's a problem, which I'm now trying to figure out >>>> how to >>>> fix. >>> >>> You MUST NOT filter inbound traffic via your secondary MX. >>> If that MX host is too liberal in what it accepts, find another, >>> or live without a secondary MX. >> >> I'm not TRYING to filter traffic from my secondary MX. I'm just not >> sure of the best way to set things up such that it does NOT get >> filtered. > > Also, for clarification, all of this was working — i.e. mail queued > through my backup MX was correctly delivered — *UNTIL* I added SPF > filtering a year or two ago. I only recently discovered that this > created a problem when the MX backup flushed queued mail. The single > thing that I am specifically trying to figure out is how to set things > up to *NOT* SPF-filter mail coming in through my MX relay, without > turning off SPF checking altogether. Theory says that adding the MX > relay to HELO_whitelist should have accomplished this, but it appears > it > didn't. > > Do I need a smarter SPF filter than pypolicyd-spf? > *IS* there a different SPF filter? > Or am I just missing something in my configuration that *should* be > obvious? > > From: policyd-spf.conf # Whitelist: CIDR Notation list of IP addresses not to check SPF for. # Example (default is no whitelist): # Whitelist = 192.168.0.0/31,192.168.1.12 # Domain_Whitelist: List of domains whose sending IPs # (defined by passing # their SPF check should be whitelisted from SPF. # Example (default is no domain whitelist): # Domain_Whitelist = pobox.com,trustedforwarder.org Domain_Whitelist = bellnexxia.net,lcbo.com # Domain_Whitelist_PTR: List of domains to whitelist against SPF checks base # on PTR match. # Example (default is no PTR whitelist) # Domain_Whitelist_PTR = yahoo.com . . . -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: Network difficulties with some senders
On Thu, July 19, 2018 22:23, Viktor Dukhovni wrote: > On Thu, Jul 19, 2018 at 02:30:52PM -0400, James B. Byrne wrote: > >> > You really need to show more of the (non-verbose) logging for this >> > session and the below. You're cutting out critical context. >> >> Jul 19 13:40:39 mx31 postfix-p25/smtpd[96635]: NOQUEUE: >> client=mail.rosedale.ca[66.135.118.147] >> Jul 19 13:40:39 mx31 postfix-p25/smtpd[96635]: lost connection after >> DATA (0 bytes) from mail.rosedale.ca[66.135.118.147] >> Jul 19 13:40:39 mx31 postfix-p25/smtpd[96635]: disconnect from >> mail.rosedale.ca[66.135.118.147] ehlo=1 mail=1 rcpt=1 data=0/1 >> commands=3/4 > > The sending client is encountering networking issues. Unrelated > to Postfix or TLS. Your new systems may have enabled TCP window > scaling or ECN, or other TCP features that are giving the sending > system indigestion. Or just a vanilla MTU issue. You could try > to disable window scaling, which makes data transfer slower for > senders with a high bandwidth delay product, but email is generally > tolerant of a few seconds to minutes of extra delay. > > Stating carefully at PCAP files might help. > >> Jul 19 13:40:39 mx31 postfix-p25/smtpd[40715]: disconnect from >> mail.rosedale.ca[66.135.118.147] ehlo=1 mail=1 rcpt=1 data=0/1 >> commands=3/4 > > Much the same, no TLS in sight. > We have resolved this issue. But the fix is not what one would describe as intuitive. The local cacheing DNS service on the MX host is local_unbound with a reference to 127.0.0.1 in resolv.conf. I set resolv.conf to check only our forwarding DNS hosts and removed the reference to 127.0.0.1. And the 'lost connection after DATA (0 bytes)' problem immediately disappeared and did not return. The clue which unlocked this puzzle I discovered when I attempted to ssh into the MX host directly rather than to the underlying host and use a local console connection. There was a noticeable delay logging on via ssh. Turning off UseDNS in sshd_config allowed immediate ssh logons. That told me that the issue was with the resolver. The MX host in question is running in a FreeBSD jail. FreeBSD ships with a default DNS service named local_unbound. This was set up in accordance with previous experience and appeared to be working, from the command line. A feature of FreeBSD jails is that each requires a dedicated cloned loopback interface each with its own unique IP address, usually 127.0.0.[cloned index number]. Jails are supposed to automatically map references to 127.0.0.1 to whatever IP-ADDR is assigned to that Jail's lo interface. I had previously discovered that this was not the case with Postfix's inet_interfaces setting. It turns out that the same thing happens with the resolver (or rather what is expected does not happen) when 127.0.0.1 is placed in /etc/resolv.conf. I replaced 127.0.0.1 with the address actually assigned to the cloned lo interface used by that jail and problem did not resurface. If I return it to 127.0.0.1 then we get the problem behaviour. Evidently the issue is caused by DNS timeouts. Why it affected only a few senders I cannot explain but we have had no further disconnects attributable to this cause since the changes were made to resolv.conf. We changed nothing else so this is either the remedy or we have a massively improbable coincidence. Not impossible but very unlikely. Having written that no doubt I have called upon the fates to disabuse me of my hubris. Thanks for all the help. It was greatly appreciated. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: STARTTLS / DANE difficulties?
On Thu, July 19, 2018 10:19, Viktor Dukhovni wrote: > > This does not look *at all* similar to me. The client sent: > > EHLO > STARTTLS + TLS complete handshake > EHLO(inside TLS encrypted stream) > MAIL FROM: (inside TLS encrypted stream) > RCPT TO:(inside TLS encrypted stream) > RCPT TO:(inside TLS encrypted stream) > DATA: (inside TLS encrypted stream) > > Then connection was lost after "DATA". This is *not* a TLS handshake > failure. Looks rather more like an ordinary message transmission > failure, or perhaps data-stage greylisting, ... > > You really need to show more of the (non-verbose) logging for this > session and the below. You're cutting out critical context. > Jul 19 13:40:35 mx31 postfix-p25/smtpd[31356]: disconnect from unknown[93.186.253.159] commands=0/0 Jul 19 13:40:39 mx31 postgrey[85107]: action=pass, reason=triplet found, client_name=mail.rosedale.ca, client_address=66.135.118.147, sender=jtho...@connectrans.com, recipient=x...@harte-lyne.ca Jul 19 13:40:39 mx31 policyd-spf[5684]: prepend Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=66.135.118.147; helo=mail.rosedale.ca; envelope-from=x...@connectrans.com; receiver= Jul 19 13:40:39 mx31 postfix-p25/smtpd[96635]: NOQUEUE: client=mail.rosedale.ca[66.135.118.147] Jul 19 13:40:39 mx31 postfix-p25/smtpd[96635]: lost connection after DATA (0 bytes) from mail.rosedale.ca[66.135.118.147] Jul 19 13:40:39 mx31 postfix-p25/smtpd[96635]: disconnect from mail.rosedale.ca[66.135.118.147] ehlo=1 mail=1 rcpt=1 data=0/1 commands=3/4 Jul 19 13:40:39 mx31 postgrey[85107]: action=pass, reason=triplet found, client_name=mail.rosedale.ca, client_address=66.135.118.147, sender=jtho...@connectrans.com, recipient=x...@harte-lyne.ca Jul 19 13:40:39 mx31 policyd-spf[34171]: prepend Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=66.135.118.147; helo=mail.rosedale.ca; envelope-from=x...@connectrans.com; receiver= Jul 19 13:40:39 mx31 postfix-p25/smtpd[40715]: NOQUEUE: client=mail.rosedale.ca[66.135.118.147] Jul 19 13:40:39 mx31 postfix-p25/smtpd[40715]: lost connection after DATA (0 bytes) from mail.rosedale.ca[66.135.118.147] Jul 19 13:40:39 mx31 postfix-p25/smtpd[40715]: disconnect from mail.rosedale.ca[66.135.118.147] ehlo=1 mail=1 rcpt=1 data=0/1 commands=3/4 Jul 19 13:40:46 mx31 postfix-p25/smtpd[96548]: warning: hostname host159-253-186-93.serverdedicati.aruba.it does not resolve to address 93.186.253.159: hostname nor servname provided, or not known -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: SMTP client timeout issues - was: STARTTLS / DANE difficulties?
On Thu, July 19, 2018 10:42, Viktor Dukhovni wrote: > On Thu, Jul 19, 2018 at 10:22:38AM -0400, James B. Byrne wrote: > >> After changing the client certificate request to 'no' we get a >> little further in the negotiation but it still fails: > > No, you get 100% of the way through the TLS handshake, the problem > is with SMTP inside the now encrypted channel. Perhaps MTU issues > in the client->server direction. > >> Jul 19 09:31:37 mx32 postfix-p25/smtpd[44981]: NOQUEUE: >> client=mail.rosedale.ca[66.135.118.147] >> Jul 19 09:31:37 mx32 postfix-p25/smtpd[44981]: >> lost connection after DATA (0 bytes) >> from mail.rosedale.ca[66.135.118.147] >> Jul 19 09:31:37 mx32 postfix-p25/smtpd[44981]: >> disconnect from mail.rosedale.ca[66.135.118.147] >> ehlo=1 mail=1 rcpt=1 data=0/1 commands=3/4 > > This delivery attempt did not even do TLS at all. > > The connection is lost, at the beginning of what would be the data > transfer phase. Perhaps a path MTU issue in the client -> server > direction. > >> They are reporting a timeout error when trying to transmit to our >> Postfix-3.3.1 MX. > > What I find a bit surprising is the combination of "NOQUEUE" and > "rcpt=1", which would normally mean an accepted recipient and the > assignment of a queue-id. Do you have a pre-queue proxy-filter? > In that case the queue id is assigned only after the full message > body is received. Yes we do: smtp inet n - n - - smtpd -o smtpd_tls_security_level=may -o smtpd_proxy_filter=127.0.0.1:10024 -o smtpd_client_connection_count_limit=10 -o smtpd_proxy_options=speed_adjust -o syslog_name=postfix-p25 Which is for amavisd. /usr/local/etc/amavisd.conf:$inet_socket_port = 10024; Our system load averages are not excessive: MX host: 12:18PM up 8 days, 19 mins, 1 users, load averages: 0.39, 0.34, 0.29 Stand-alone Desktop workstation: 2:19PM up 13 days, 16:39, 1 users, load averages: 0.35, 0.29, 0.26 Both systems running FreeBSD-11.1 > >> Their DSN says: >> >> . . . conversation with mx32.harte-lyne.ca[216.185.71.32]:25 timed >> out while sending MAIL FROM . . . > > That's odd, they actually sent "MAIL FROM", "RCPT TO" and "DATA" > pipelined together. But somehow never saw the replies? Perhaps > buggy pipelining support? In the particular case under consideration I discovered this reference to the Barracuda firewall: What are potential causes of "Sender Timeout" on the Barracuda Spam Firewall? https://campus.barracuda.com/product/emailsecuritygateway/knowledgebase/5016000GTxtAAG/what-are-potential-causes-of-sender-timeout-on-the-barracuda-spam-firewall/ Which contains the following notes: . . . Sender timeouts can be caused by any the following: Firewall with proxying or some type of packet filtering enabled for port 25 (sender or receiver's firewall) . . . Any type of relay device between the firewall and Barracuda not configured properly or with additional scanning enabled (receiver's side) . . . Here are some references for additional information: ESMTP TLS Configuration Note: If you use Transport Layer Security (TLS) encryption for e-mail communication then the ESMTP inspection feature (enabled by default) in the PIX drops the packets. In order to allow the e-mails with TLS enabled, disable the ESMTP inspection feature as this output shows. Refer to Cisco bug ID CSCtn08326 (registered customers only) for more information. pix(config)#policy-map global_policy pix(config-pmap)#class inspection_default pix(config-pmap-c)#no inspect esmtp pix(config-pmap-c)#exit pix(config-pmap)#exit . . . -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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
SMTP client timeout issues - was: STARTTLS / DANE difficulties?
After changing the client certificate request to 'no' we get a little further in the negotiation but it still fails: . . . Jul 19 09:31:37 mx32 postgrey[29869]: action=pass, reason=triplet found, client_name=mail.rosedale.ca, client_address=66.135.118.147, sender=jtho...@connectrans.com, recipient=expo...@harte-lyne.ca Jul 19 09:31:37 mx32 policyd-spf[15740]: prepend Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=66.135.118.147; helo=mail.rosedale.ca; envelope-from=jtho...@connectrans.com; receiver= Jul 19 09:31:37 mx32 postfix-p25/smtpd[44981]: NOQUEUE: client=mail.rosedale.ca[66.135.118.147] Jul 19 09:31:37 mx32 postfix-p25/smtpd[44981]: lost connection after DATA (0 bytes) from mail.rosedale.ca[66.135.118.147] Jul 19 09:31:37 mx32 postfix-p25/smtpd[44981]: disconnect from mail.rosedale.ca[66.135.118.147] ehlo=1 mail=1 rcpt=1 data=0/1 commands=3/4 . . . The internal mail server for this organisation is MX Exchange. However, the MTA relay is a Barracuda firewall appliance: PORT STATE SERVICE VERSION 25/tcp open smtpBarracuda Networks Spam Firewall smtpd Service Info: CPE: cpe:/h:barracudanetworks:spam_%26_virus_firewall_600:- They are reporting a timeout error when trying to transmit to our Postfix-3.3.1 MX. All we see is the above in our maillog. Their DSN says: . . . conversation with mx32.harte-lyne.ca[216.185.71.32]:25 timed out while sending MAIL FROM . . . We have only seen this type of problem (client disconnect with 0 data transferred) with a very few of our correspondents. As it coincides with moving from Postfix-2.11 to 3.3 we are concerned that we have introduced some sort of compatibility issue. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: STARTTLS / DANE difficulties?
On Wed, July 11, 2018 14:13, James B. Byrne wrote:
> On Wed, July 11, 2018 11:12, Viktor Dukhovni wrote:
>> On Wed, Jul 11, 2018 at 10:13:48AM -0400, James B. Byrne wrote:
>>
>>> > The connecting client did not like one of the certificates in the
>>> > chain. Perhaps it expected to find a working WebPKI certificate
>>> > from one of the usual suspects ("browser bundle" public root
>>> CAs).
>>> >
>
> My concern in this is to assure myself that our services are running
> correctly. If they are and the difficulties all lie with samba.org
> then can live without the mailing list digest for now.
>
We are encountering errors with several domains similar to the one
reported by samba.org:
. . .
Jul 18 22:36:38 mx31 postgrey[85107]: action=pass, reason=triplet
found, client_name=mailroot5.namespro.ca, client_address=158.85.87.68,
sender=d...@everydayfreight.com, recipient=expo...@harte-lyne.ca
Jul 18 22:36:38 mx31 postfix-p25/smtpd[17802]: lost connection after
DATA (0 bytes) from mailroot5.namespro.ca[158.85.87.68]
Jul 18 22:36:38 mx31 postfix-p25/smtpd[17802]: disconnect from
mailroot5.namespro.ca[158.85.87.68] ehlo=2 starttls=1 mail=1 rcpt=2
data=0/1 commands=6/7
. . .
Jul 18 23:41:45 mx31 policyd-spf[81903]: prepend Received-SPF: Pass
(mailfrom) identity=mailfrom; client-ip=66.135.118.147;
helo=mail.rosedale.ca; envelope-from=jtho...@connectrans.com;
receiver=
Jul 18 23:41:45 mx31 postfix-p25/smtpd[97338]: NOQUEUE:
client=mail.rosedale.ca[66.135.118.147]
Jul 18 23:41:45 mx31 postfix-p25/smtpd[97338]: lost connection after
DATA (0 bytes) from mail.rosedale.ca[66.135.118.147]
. . .
This is causing us problems in our operational departments. Based on
the message traffic surrounding this issue I have changed the client
certificate request setting to 'no' to see if that improves delivery.
smtpd_tls_ask_ccert = no.
Any insightful comments on this situation are welcomed.
--
*** e-Mail is NOT a SECURE channel ***
Do NOT transmit sensitive data via e-Mail
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: STARTTLS / DANE difficulties?
On Wed, July 11, 2018 11:12, Viktor Dukhovni wrote:
> On Wed, Jul 11, 2018 at 10:13:48AM -0400, James B. Byrne wrote:
>
>> > The connecting client did not like one of the certificates in the
>> > chain. Perhaps it expected to find a working WebPKI certificate
>> > from one of the usual suspects ("browser bundle" public root CAs).
>> >
>> > You should ask the postmaster of the sending domain?
>> > Is the problem ongoing? Or a transient glitch?
>>
>> It is an ongoing problem with delivery to us of the samba-users
>> mailing list digest, of which I am a subscriber.
>
> Any logs they're willing to share would likely be enlightening.
>
I will ask.
>> I am in communication with the person directly responsible for
>> implementing DANE at that site. They have just implemented DANE
>> which is when the problems first started.
>
> Do you know which MTA they're using?
>
NMAP reports: Exim smtpd 4.91
>
>> and as they are missing a number of TLSA RRs
>
> What does that mean???
>
When I run a DANE test against the domain that is failing to connect
this is among the results:
Test # HostIP Status Test Description (§ Section)
103 hr1.samba.org FAILED Service hostname must have matching TLSA record
Resolving TLSA records for hostname '_25._tcp.hr1.samba.org'
403 hr1.samba.org FAILED All IP addresses for a host that is TLSA
protected must TLSA verify
Validating TLSA records for 0 out of 1 IP addresses found for host
hr1.samba.org
>> their problem with us may be an incomplete implementation.
>
> Do they support certificate usage DANE-TA(2)? Perhaps their MTA
> only supports DANE-EE(3) and chokes on DANE-TA(2). You could publish
> both "3 1 1" and "2 1 1" TLSA records for each MX host, and see if
> that resolves the issue.
I will attempt that as soon as I finish the movement of our MX
services off their current hosts and onto the new.
>
> If it does, the Samba list should disable DANE support until their
> implementation is less crippled. It needs to either not enforce
> DANE for MX hosts with just DANE-TA(2) records, or properly support
> DANE-TA(2) records.
>
Ah. Well, I know how welcome the news that 'one is doing something so
wrong that one should just stop doing it' can be. I would rather
avoid the natural antagonism such advice is likely to engender.
Instead I have provided them a few clues as to where some obvious
problems lie and left it to their judgement as to how to proceed.
Eventually they will either sort out their troubles or arrive at the
same conclusion.
My concern in this is to assure myself that our services are running
correctly. If they are and the difficulties all lie with samba.org
then can live without the mailing list digest for now.
--
*** e-Mail is NOT a SECURE channel ***
Do NOT transmit sensitive data via e-Mail
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: STARTTLS / DANE difficulties?
On Tue, July 10, 2018 20:35, Viktor Dukhovni wrote:
>
> The connecting client did not like one of the certificates in the
> chain. Perhaps it expected to find working a WebPKI certificate
> from one of the usual suspects ("browser bundle" public root CAs).
>
> You should ask the postmaster of the sending domain? Is the problem
> ongoing? Or a transient glitch?
>
It is an ongoing problem with delivery to us of the samba-users
mailing list digest, of which I am a subscriber.
I am in communication with the person directly responsible for
implementing DANE at that site. They have just implemented DANE which
is when the problems first started.
As we use 'smtp_tls_security_level = dane' and as they are missing a
number of TLSA RRs their problem with us may be an incomplete
implementation. I have referred them to:
https://dane-test.had.dnsops.gov/server/dane_check.cgi?host=hr1.samba.org.
We will see if any changes result.
Thank you for your help, as always.
Regards,
--
*** e-Mail is NOT a SECURE channel ***
Do NOT transmit sensitive data via e-Mail
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: STARTTLS / DANE difficulties?
d Data Systems/O=Harte & Lyne Limited/L=Hamilton/ST=Ontario/C=CA/DC=hamilton/DC=harte-lyne/DC=ca i:/CN=CA_HLL_ISSUER_2016/OU=Networked Data Services/O=Harte & Lyne Limited/L=Hamilton/ST=Ontario/C=CA/DC=harte-lyne/DC=ca 1 s:/CN=CA_HLL_ISSUER_2016/OU=Networked Data Services/O=Harte & Lyne Limited/L=Hamilton/ST=Ontario/C=CA/DC=harte-lyne/DC=ca i:/CN=CA_HLL_ROOT_2016/ST=Ontario/O=Harte & Lyne Limited/OU=Networked Data Services/C=CA/DC=harte-lyne/DC=ca/L=Hamilton 2 s:/CN=CA_HLL_ROOT_2016/ST=Ontario/O=Harte & Lyne Limited/OU=Networked Data Services/C=CA/DC=harte-lyne/DC=ca/L=Hamilton i:/CN=CA_HLL_ROOT_2016/ST=Ontario/O=Harte & Lyne Limited/OU=Networked Data Services/C=CA/DC=harte-lyne/DC=ca/L=Hamilton --- Server certificate -BEGIN CERTIFICATE- . . . Start Time: 1531246902 Timeout : 300 (sec) Verify return code: 0 (ok) --- 250 SMTPUTF8 QUIT DONE -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: STARTTLS / DANE difficulties?
On Tue, July 10, 2018 13:30, Viktor Dukhovni wrote: > On Tue, Jul 10, 2018 at 12:55:38PM -0400, James B. Byrne wrote: > >> We are migrating our Postfix MX services and in the process have >> disrupted a setup which has been very stable for the past couple of >> years. One of the remaining items is this sort of message which >> only started very recently: > > What is the MX hostname associated with this Postfix instance? What > domains does it serve? That has bearing on the TLSA records seen > by the connecting SMTP client. mx31.harte-lyne.ca - harte-lyne.ca / .harte-lyne.ca > >> Jul 10 11:55:30 mx31 postfix-p25/smtpd[70030]: warning: TLS library >> problem: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert >> bad >> certificate:/usr/src/crypto/openssl/ssl/s3_pkt.c:1493:SSL alert >> number > 42: > > The client rejected the server's certificate chain. The details > are known only to the client. > >> I thought that these errors were the result of a misconfigured >> certificate or private key for the postfix service. However, I have >> examined these and they appear to be correct: > > "Correct" is in the eye of the beholder. Did the certificate chain > match the associated DANE TLSA records? Might samba.org have reason > to expect to authenticate your server via WebPKI? You're using a > private CA... > >> CN=mx31.harte-lyne.ca https://dane-test.had.dnsops.gov/server/dane_check.cgi?host=harte-lyne.ca ere[prts that all declared servers, other than those currently off-line, are error free. > > Its current cert chain seems to match the TLSA records for the above > name, though two of the three TLSA records seem redundant: > > mx31.harte-lyne.ca. IN A 216.185.71.31 ; AD=1 NoError > mx31.harte-lyne.ca. IN ? ; AD=1 NODATA > _25._tcp.mx31.harte-lyne.ca. IN CNAME > _tlsa._dane.trust.harte-lyne.ca. ; AD=1 NoError > _tlsa._dane.trust.harte-lyne.ca. IN TLSA 2 0 2 > 67274b355428905895c6b581950e0ed4f7d043f31f7e7020b716b7faa06776b6aadd33e127624b6e8c75c520a01d9cad3bd29f18fa7dcb3d5fd3917510e6722a > ; AD=1 NoError > _tlsa._dane.trust.harte-lyne.ca. IN TLSA 2 1 2 > 380259229e21a1946b38cfc594cbc993b61bc93762b7b6c6637b3eef9c5a2bb70c589b91beb73bd1304eac11b3917e33819e2b47d25d4966435a2a3e83c1f80f > ; AD=1 NoError > _tlsa._dane.trust.harte-lyne.ca. IN TLSA 2 1 2 > c26e0ec16a46a97386e8f31f8ecc971f2d73136aa377dfdaac2b2b00f7cab4bb29b17d913c82093b41fd0d9e40b66a68361c126f1f4017f9ce60eabc5adba90e > ; AD=1 NoError > mx31.harte-lyne.ca[216.185.71.31]: pass: TLSA match: depth = 1, > name = mx31.harte-lyne.ca > TLS = TLS12 with ECDHE-RSA-AES256GCM-SHA384 > name = mx31.harte-lyne.ca > name = mx31 > name = mx31.hamilton > name = mx31.hamilton.harte-lyne.ca > depth = 0 > Issuer CommonName = CA_HLL_ISSUER_2016 > Issuer Organization = Harte & Lyne Limited > notBefore = 2018-06-01T00:00:00Z > notAfter = 2023-06-30T23:59:59Z > Subject CommonName = mx31.harte-lyne.ca > Subject Organization = Harte & Lyne Limited > pkey sha256 [nomatch] <- 3 1 1 > 3fa3dae08e2fecff0611a75767ee0995a115e308a181ad79a6d163315742b270 > cert sha512 [nomatch] <- 3 0 2 > cc5bd085ba7e1c136539083bf32ad6512b6c0fe5a31a8f2f775b627ab1c6525d7464c751191a4e1747072f5bd63d364713e48a4636ca25e31532ca0657444c7f > pkey sha512 [nomatch] <- 3 1 2 > 39248e9342c4fc8fb67dac3f51e7a2d9e77d7a37df6fac0272006cc7d757e5346c9e11f93f7f8c34cacf95cd0e60d1ab5b3fc2b9881551fa9bc9a6fb6e3300a8 > depth = 1 > Issuer CommonName = CA_HLL_ROOT_2016 > Issuer Organization = Harte & Lyne Limited > notBefore = 2016-11-01T00:00:00Z > notAfter = 2035-11-01T23:59:59Z > Subject CommonName = CA_HLL_ISSUER_2016 > Subject Organization = Harte & Lyne Limited > pkey sha256 [nomatch] <- 2 1 1 > 9c19d0fed453f6c49cd9f569af9b5da75ef6d8baabd26308eee88adb2d06a3b5 > cert sha512 [nomatch] <- 2 0 2 > ab23a715c42f6cf8a2502b725969adedf1f6c6bedbb483fb49badc5470232297b34a3a7716b2dd7eb086bd6e462599db95f9af3415209eadea71450c72af942a > pkey sha512 [matched] <- 2 1 2 > 380259229e21a1946b38cfc594cbc993b61bc93762b7b6c6637b3eef9c5a2bb70c589b91beb73bd1304eac11b3917e33819e2b47d25d4966435a2a3e83c1f80f > depth = 2 > Issuer CommonName = CA_HLL_ROOT_2016 > Issuer Organization = Harte & Lyne Limited > notBefore = 2016-11-01T00:00:00Z > notAfter = 2036-10-31T23:59:59Z > Subject CommonName = CA_HLL_ROOT_2016 > Subject Organ
STARTTLS / DANE difficulties?
We are migrating our Postfix MX services and in the process have
disrupted a setup which has been very stable for the past couple of
years. One of the remaining items is this sort of message which only
started very recently:
Jul 10 11:55:29 mx31 postfix-p25/smtpd[70030]: connect from
hr1.samba.org[144.76.82.147]
Jul 10 11:55:30 mx31 postfix-p25/smtpd[70030]: warning: TLS library
problem: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad
certificate:/usr/src/crypto/openssl/ssl/s3_pkt.c:1493:SSL alert number
42:
Jul 10 11:55:30 mx31 postfix-p25/smtpd[70030]: lost connection after
STARTTLS from hr1.samba.org[144.76.82.147]
Jul 10 11:55:30 mx31 postfix-p25/smtpd[70030]: disconnect from
hr1.samba.org[144.76.82.147] ehlo=1 starttls=1 commands=2
I thought that these errors were the result of a misconfigured
certificate or private key for the postfix service. However, I have
examined these and they appear to be correct:
postconf -n | grep -i tls
smtp_tls_CAfile = /usr/local/etc/pki/tls/certs/ca-bundle.crt
smtp_tls_cert_file = /usr/local/etc/pki/tls/certs/ca.harte-lyne.mx31.crt
smtp_tls_ciphers = medium
smtp_tls_exclude_ciphers = MD5, aDSS, SRP, PSK, aECDH, aDH, SEED,
IDEA, RC2, RC5
smtp_tls_key_file = /usr/local/etc/pki/tls/private/ca.harte-lyne.mx31.key
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_security_level = dane
smtp_tls_session_cache_database = btree:/var/db/postfix/smtp_scache
smtp_tls_session_cache_timeout = 3600s
smtpd_starttls_timeout = ${stress?10}${stress:120}s
smtpd_tls_CAfile = /usr/local/etc/pki/tls/certs/ca-bundle.crt
smtpd_tls_ask_ccert = yes
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /usr/local/etc/pki/tls/certs/ca.harte-lyne.mx31.crt
smtpd_tls_ciphers = medium
smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
smtpd_tls_fingerprint_digest = sha256
smtpd_tls_key_file =
/usr/local/etc/pki/tls/private/ca.harte-lyne.mx31.key
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:/var/db/postfix/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
# ll /usr/local/etc/pki/tls/private/
total 18
-rw--- 1 root wheel 3243 Jun 7 15:37 2016003E.key
lrwxr-xr-x 1 root wheel12 Jul 10 12:19 ca.harte-lyne.mx31.key ->
2016003E.key
ll /usr/local/etc/pki/tls/certs
total 565
-rw-r--r-- 1 root wheel 10164 Jun 7 15:37 2016003E.pem
-rw-r--r-- 1 root wheel 822512 Jul 10 12:05 ca-bundle.crt
lrwxr-xr-x 1 root wheel 22 Jul 10 12:07 ca.harte-lyne.mx31.crt
-> ca.harte-lyne.mx31.pem
lrwxr-xr-x 1 root wheel 12 Jul 10 12:06 ca.harte-lyne.mx31.pem
-> 2016003E.pem
# openssl x509 -noout -text -in
/usr/local/etc/pki/tls/certs/ca.harte-lyne.mx31.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 538312766 (0x2016003e)
Signature Algorithm: sha512WithRSAEncryption
Issuer: CN=CA_HLL_ISSUER_2016, OU=Networked Data Services,
O=Harte & Lyne Limited, L=Hamilton, ST=Ontario, C=CA,
DC=harte-lyne, DC=ca
Validity
Not Before: Jun 1 00:00:00 2018 GMT
Not After : Jun 30 23:59:59 2023 GMT
Subject: CN=mx31.harte-lyne.ca, OU=Networked Data Services,
O=Harte & Lyne Limited, L=Hamilton, ST=Ontario, C=CA,
DC=hamilton, DC=harte-lyne, DC=ca
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
. . .
Can someone interpret for me what these messages are telling me? Is
samba.org misconfigured or me?
--
*** e-Mail is NOT a SECURE channel ***
Do NOT transmit sensitive data via e-Mail
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
FreeBSD-11 (Jail) Saslauthd rimap authentication fails
,
reject_unknown_helo_hostname, permit
smtpd_milters = inet:127.0.0.1:8891
smtpd_proxy_timeout = 300s
smtpd_recipient_restrictions = reject_non_fqdn_recipient
reject_unknown_recipient_domain permit_mynetworks
permit_sasl_authenticated
reject_unauth_destination reject_unauth_pipelining
check_policy_service
inet:10023 check_policy_service unix:private/policyd-spf permit
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated,
defer_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = smtpd
smtpd_sender_restrictions = permit_mynetworks, check_sender_access
hash:/usr/local/etc/postfix/sender_access, check_sender_mx_access
hash:/usr/local/etc/postfix/sender_mx_access, check_sender_ns_access
hash:/usr/local/etc/postfix/sender_ns_access,
permit_sasl_authenticated,
reject_non_fqdn_sender, reject_unknown_sender_domain, permit
smtpd_starttls_timeout = ${stress?10}${stress:120}s
smtpd_timeout = ${stress?10}${stress:120}s
smtpd_tls_CAfile = /usr/local/etc/pki/tls/certs/ca-bundle.crt
smtpd_tls_ask_ccert = yes
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /usr/local/etc/pki/tls/certs/ca.harte-lyne.mx32.crt
smtpd_tls_ciphers = medium
smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
smtpd_tls_fingerprint_digest = sha256
smtpd_tls_key_file =
/usr/local/etc/pki/tls/private/ca.harte-lyne.mx32.key
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:/var/db/postfix/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
strict_rfc821_envelopes = yes
tls_random_source = dev:/dev/urandom
transport_maps = hash:/usr/local/etc/postfix/transport
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/usr/local/etc/postfix/virtual,
regexp:/usr/local/etc/postfix/virtual.regexp
--
*** e-Mail is NOT a SECURE channel ***
Do NOT transmit sensitive data via e-Mail
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: What is postfix telling me to do?
On Wed, June 27, 2018 17:02, James B. Byrne wrote: > > On Wed, June 27, 2018 15:55, Viktor Dukhovni wrote: . . . >> And you should still try to find the real cause of the >> "queue file write error" issue. The DANE bounce backlog >> was a related symptom not a cause. >> > > I believe that I have uncovered that as well. > . . . > I infer from this that I have some sort of misconfiguration in > amavisd.conf. . . The issue was that amavisd's default inet_acl values only allow connections from 127.0.0.1 and [::1]. Adding an explicit setting in amavisd.conf of: @inet_acl = qw( 127.0.0.1 [::1] 127.0.32.1 [::32]); resolved this issue. It all works within a FreeBSD jail as it should, at the moment. Thanks for the list's advice and help. It is always greatly appreciated. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: What is postfix telling me to do?
On Wed, June 27, 2018 15:55, Viktor Dukhovni wrote: Thank you for your assistance. > > And you should still try to find the real cause of the > "queue file write error" issue. The DANE bounce backlog > was a related symptom not a cause. > I believe that I have uncovered that as well. [root@mx32 ~]# tail /var/log/maillog . . . Jun 27 15:52:03 mx32 postfix-p25/smtpd[50050]: connect from mx32.hll.ca[A.B.C.32] Jun 27 15:52:03 mx32 postfix-p25/smtpd[50050]: NOQUEUE: client=mx32.hll.ca[A.B.C.32] Jun 27 15:52:03 mx32 amavis[6850]: (!)DENIED ACCESS from IP 127.0.32.1, policy bank '' Jun 27 15:52:03 mx32 postfix-p25/smtpd[50050]: warning: lost connection with proxy 127.0.32.1:10024 Jun 27 15:52:03 mx32 postfix-p25/smtpd[50050]: proxy-reject: END-OF-MESSAGE: 451 4.3.0 Error: queue file write error; from= to= proto=ESMTP helo= Jun 27 15:52:03 mx32 postfix/cleanup[40298]: 9E70612C76: message-id=<20180627195203.9e70612...@mx32.hll.ca> . . . I infer from this that I have some sort of misconfiguration in amavisd.conf. I am not sure what but it may be an uninitialised variable used to name one of the policy arrays. I will be looking into this tomorrow. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: What is postfix telling me to do?
On Wed, June 27, 2018 13:49, Wietse Venema wrote: > James B. Byrne: >> This still does not clarify for me why the double-bounce address was >> being reported given that the postconf reported values for notify >> did >> not include bounces. > > Asl someone else on the list noted, this was triggered by the > 'queue file write error' condition. Postfix is quote verbose > about such errors, so I am surrised that you came up > empty-handed when examining the logs. > > Wietse > That was not Postfix's fault. I am transitioning between two server OS. MX32 runs FreeBSD and on that OS maillog files are bz compressed and rolled over every night. I was oblivious to that when I searched and so obviously I found nothing outside of the current maillog file. The log entries were there but, by the time I found them, I had moved past the need to see them. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: What is postfix telling me to do?
On Tue, Jun 26, 2018 at 02:34:19PM -0400, James B. Byrne wrote: > When we do we frequently (always?) get messages like this in > the mail queue: Well, I may not have solved the problem, but I have identified what it is and provided a work-around for now. The issue is this: smtp_tls_security_level=dane Last week Viktor Dukhovni reported to me that our domain had a problem with our DNSSEC. I investigated that and discovered on our master DNS host the named daemon was reporting errors similar to the following. Jun 9 00:37:40 dns03 named[3729]: malformed transaction: . . . These errors did not have any obvious cause and inquires on the OS users list did not elicit any diagnosis. So for want of any clear remediation I simply restarted the named service and the problem with DNSSEC went away. However, the problem returned. And, in combination with the dane security level setting in Postfix, apparently caused Postfix to report: (delivery temporarily suspended: Server certificate not verified) Switching smtp_tls_security_level from 'dane' to 'may' allowed the mail to be delivered without further problem. [root@mx32 ~]# mailq Mail queue is empty This still does not clarify for me why the double-bounce address was being reported given that the postconf reported values for notify did not include bounces. Now, the problem with DANE and our DNS master service turns out to be rather odd. Somehow we ended up with two named processes running simultaneously on that host. How one can have two processes bind to the same port escapes me but evidently it happened. Or it did not happen and the June 8 process somehow failed to terminate in consequence. [root@dns03 ~ (master #)]# service named restart Stopping named:[ OK ] Starting named:[ OK ] [root@dns03 ~ (master #)]# ps -ef | grep named named 3729 1 0 Jun08 ?00:00:59 /usr/sbin/named -u named named24749 1 0 10:04 ?00:00:00 /usr/sbin/named -u named root 24859 22025 0 10:06 pts/100:00:00 grep named June 8 corresponds to when the dynamic update errors commenced: /var/log/messages-20180610:Jun 8 13:37:38 dns03 named[3729]: malformed transaction: . . . How this problem impacted DNSSEC I do not understand but the evidence is that it did. The solution to the twinned named service problem was to first kill the named process from June 8 and then restart the remaining named service. We will see if the DNS problem reoccurs. But, the only change required to get the mail delivered was switching the security level from 'dane' to 'may'. Which will have to go back to dane once I am convinced that our underlying problems with DNSSEC has been resolved. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: What is postfix telling me to do?
On Tue, June 26, 2018 16:47, Wietse Venema wrote: > James B. Byrne: >> I am configuring a new Postfix-3.3.0 service to act as one of our >> public MX providers. The address of this new MX service has been >> published in our DNS but with a lower precedence (higher priority >> number) than our active MX service. >> >> Naturally enough there are countless spam bots regularly hitting the >> low priority MX services and so when I activate Postfix for testing >> we >> get numerous opportunistic connections. When we do we frequently >> (always?) get messages like this in the mail queue: >> >> Received by mx32.hll.ca (Postfix) id 002F8E7E3; Mon, 25 Jun 2018 >> 22:13:17 -0400 (EDT) >> Date Mon, 25 Jun 2018 22:13:17 -0400 (EDT) >> >Frommailer-dae...@mx32.hll.ca (Mail Delivery System) >> To postmas...@mx32.hll.ca (Postmaster) >> Subject Postfix SMTP server: errors from >> smtp1.e2mailb2b.info[208.234.16.120] >> Message-Id <20180626021317.002f8e...@mx32.harte-lyne.ca> >> Message text >> >> Transcript of session follows. >> >> Out: 220 mx32.hll.ca ESMTP Postfix >> In: EHLO smtp1.e2mailb2b.info >> Out: 250-mx32.hll.ca >> Out: 250-PIPELINING >> Out: 250-SIZE 2048 >> Out: 250-ETRN >> Out: 250-STARTTLS >> Out: 250-ENHANCEDSTATUSCODES >> Out: 250-8BITMIME >> Out: 250-DSN >> Out: 250 SMTPUTF8 >> In: MAIL FROM: BODY=8BITMIME >> Out: 250 2.1.0 Ok >> In: RCPT TO: >> Out: 250 2.1.5 Ok >> In: DATA >> Out: 354 End data with . >> Out: 451 4.3.0 Error: queue file write error >> In: QUIT >> Out: 221 2.0.0 Bye >> >> Note that 'In: RCPT TO:' refers to a >> non-existent mailbox address. >> >> For other details, see the local mail logfile > > And, what is in the local mail logfile around the time that this > message was received on Mon, 25 Jun 2018 22:13:17 -0400 (EDT)? > >> # postconf -f | grep notify >> notify_classes = resource, software >> Since I do not set notify_classes in main.cf these are the defaults. > > You have "notify_classes = ... bounce ..." somewhere, otherwise > you would not receive the above SMTP session recording. > > Try: postconf -P | grep notify_classes > > Wietse > [root@mx32 ~]# postconf | grep notify notify_classes = resource, software [root@mx32 ~]# [root@mx32 ~]# postconf -P | grep notify [root@mx32 ~]# I looked for that before I called upon the list for help. This is what I found in the maillog file on mx32, which appears to me passing strange for what is not there: [root@mx32 ~]# grep 'Jun 25' /var/log/maillog* /var/log/maillog:Jun 26 00:03:35 mx32 postfix/anvil[85166]: statistics: max connection rate 1/60s for (smtpd:189.52.165.134) at Jun 25 23:58:34 /var/log/maillog:Jun 26 00:03:35 mx32 postfix/anvil[85166]: statistics: max connection count 1 for (smtpd:189.52.165.134) at Jun 25 23:58:34 /var/log/maillog:Jun 26 00:03:35 mx32 postfix/anvil[85166]: statistics: max cache size 1 at Jun 25 23:58:34 On our IMAP server this is what is in its maillog: [root@inet07 ~ (master #)]# grep 'Jun 25 22:13' /var/log/maillog Jun 25 22:13:16 inet07 postfix/smtpd[18442]: connect from mx32.harte-lyne.ca[216.185.71.32] Jun 25 22:13:16 inet07 postfix/smtpd[18442]: disconnect from mx32.harte-lyne.ca[216.185.71.32] Jun 25 22:13:16 inet07 postfix/smtpd[18442]: connect from mx32.harte-lyne.ca[216.185.71.32] Jun 25 22:13:16 inet07 postfix/smtpd[18442]: disconnect from mx32.harte-lyne.ca[216.185.71.32] Jun 25 22:13:16 inet07 postfix/smtpd[18442]: connect from mx32.harte-lyne.ca[216.185.71.32] Jun 25 22:13:16 inet07 postfix/smtpd[18442]: disconnect from mx32.harte-lyne.ca[216.185.71.32] Jun 25 22:13:16 inet07 postfix/smtpd[18442]: connect from mx32.harte-lyne.ca[216.185.71.32] Jun 25 22:13:16 inet07 postfix/smtpd[18442]: disconnect from mx32.harte-lyne.ca[216.185.71.32] Jun 25 22:13:16 inet07 postfix/smtpd[18442]: connect from mx32.harte-lyne.ca[216.185.71.32] Jun 25 22:13:16 inet07 postfix/smtpd[18442]: disconnect from mx32.harte-lyne.ca[216.185.71.32] It seemed that the new server simply connects and disconnects without ever trying establish a session. Today on the IMAP service host I set the debug level to 2 and the debug host to mx32 and this is what I see now: Jun 26 18:11:00 inet07 postfix/smtpd[26275]: connect from mx32.harte-lyne.ca[216.185.71.32] Jun 26 18:11:00 inet07 postfix/smtpd[26275]: match_hostname: mx32.harte-lyne.ca ~? 127.0.0.0/8 Jun 26 18:11:00 inet07 postfix/smtpd[26275]: match_hostaddr: 216.185.71.32 ~? 127.0.0.0/8 Jun 26 18:11:00 inet07 postfix/smtpd[26275]: match_hostname: mx32.harte-lyne.ca ~? 209.47.176.17 Jun 26 18:11:00 inet07 postfix/smtpd[26275]: match_hostad
What is postfix telling me to do?
I am configuring a new Postfix-3.3.0 service to act as one of our public MX providers. The address of this new MX service has been published in our DNS but with a lower precedence (higher priority number) than our active MX service. Naturally enough there are countless spam bots regularly hitting the low priority MX services and so when I activate Postfix for testing we get numerous opportunistic connections. When we do we frequently (always?) get messages like this in the mail queue: Receivedby mx32.hll.ca (Postfix) id 002F8E7E3; Mon, 25 Jun 2018 22:13:17 -0400 (EDT) DateMon, 25 Jun 2018 22:13:17 -0400 (EDT) >From mailer-dae...@mx32.hll.ca (Mail Delivery System) To postmas...@mx32.hll.ca (Postmaster) Subject Postfix SMTP server: errors from smtp1.e2mailb2b.info[208.234.16.120] Message-Id <20180626021317.002f8e...@mx32.harte-lyne.ca> Message text Transcript of session follows. Out: 220 mx32.hll.ca ESMTP Postfix In: EHLO smtp1.e2mailb2b.info Out: 250-mx32.hll.ca Out: 250-PIPELINING Out: 250-SIZE 2048 Out: 250-ETRN Out: 250-STARTTLS Out: 250-ENHANCEDSTATUSCODES Out: 250-8BITMIME Out: 250-DSN Out: 250 SMTPUTF8 In: MAIL FROM: BODY=8BITMIME Out: 250 2.1.0 Ok In: RCPT TO: Out: 250 2.1.5 Ok In: DATA Out: 354 End data with . Out: 451 4.3.0 Error: queue file write error In: QUIT Out: 221 2.0.0 Bye Note that 'In: RCPT TO:' refers to a non-existent mailbox address. For other details, see the local mail logfile Mailq displays this: 002F8E7E3 1063 Mon Jun 25 22:13:17 double-bou...@mx32.hll.ca (delivery temporarily suspended: Server certificate not verified) postmas...@mx32.hll.ca I checked postconf and got this result: # postconf -f | grep notify notify_classes = resource, software Since I do not set notify_classes in main.cf these are the defaults. The address for postmas...@mx32.hll.ca is aliased to root and root is aliased to sysadmin.root.m...@hll.ca. All traffic on mx32 destined to hll.ca. is routed via the transport map to: harte-lyne.carelay:[mx07.hamilton.hll.ca] .harte-lyne.ca relay:[mx07.hamilton.hll.ca] On mx07.hamilton.hll.ca the address sysadmin.root.m...@hll.ca. delivers to byrn...@hll.ca via the virtual map. SO my questions are: The double-bounce address is that used by Postfix for sender verification probes. Why are they still in the queue? Are they not supposed to be discarded? To which server does the message '(delivery temporarily suspended: Server certificate not verified)' apply? What settings or other configuration changes must I make to get rid of these things and to prevent reoccurrence? Thanks. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: Postfix-3.3.0_1 Can't assign requested address
On Fri, June 15, 2018 15:40, Ralf Hildebrandt wrote: >> 84A19B389 1256 Wed Jun 13 16:03:45 byrn...@harte-lyne.ca >> (delivery temporarily suspended: connect to >> inet07.hamilton.harte-lyne.ca[216.185.71.27]:25: Can't assign >> requested address) > > ... > >> smtp_bind_address = 127.0.31.1 > > That's why. I think. > Thank you. That was the problem. Regards, -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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
Postfix-3.3.0_1 Can't assign requested address
pickup -o content_filter= -o receive_override_options=no_header_body_checks cleanupunix n - n - 0 cleanup qmgr fifo n - n 300 1 qmgr tlsmgr unix - - n 1000? 1 tlsmgr rewriteunix - - n - - trivial-rewrite bounce unix - - n - 0 bounce defer unix - - n - 0 bounce trace unix - - n - 0 bounce verify unix - - n - 1 verify flush unix n - n 1000? 0 flush proxymap unix - - n - - proxymap proxywrite unix - - n - 1 proxymap smtp unix - - n - - smtp relay unix - - n - - smtp -o smtp_fallback_relay= showq unix n - n - - showq error unix - - n - - error retry unix - - n - - error discardunix - - n - - discard local unix - n n - - local virtualunix - n n - - virtual lmtp unix - - n - - lmtp anvil unix - - n - 1 anvil scache unix - - n - 1 scache 127.0.31.1:2626 inet n - n - - smtpd -o smtpd_tls_security_level=none -o smtpd_sasl_auth_enable=no -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions= -o milter_macro_daemon_name=ORIGINATING -o syslog_name=postfix-p2626 policyd-spf unix y n n - - spawn user=nobody argv=/usr/local/bin/policyd-spf smtp-amavis unix - - n - 6 smtp -o smtp_data_done_timeout=1200 -o smtp_send_xforward_command=yes -o disable_dns_lookups=yes -o max_use=20 127.0.31.1:10025 inet n - n - - smtpd -o content_filter= -o local_header_rewrite_clients= -o local_recipient_maps= -o mynetworks=127.0.0.0/8 -o relay_recipient_maps= -o smtpd_client_restrictions=permit_mynetworks,reject -o smtpd_delay_reject=no -o smtpd_milters= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=reject_unauth_pipelining -o smtpd_end_of_data_restrictions= -o smtpd_restriction_classes= -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters,no_address_mappings smtp inet n - n - 1 postscreen dnsblogunix - - n - 0 dnsblog tlsproxy unix - - n - 0 tlsproxy -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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
SENDEr-ACCESS exceptions
The constantcontact.com domain was added to our sender_access file: constantcontact.com REJECT .constantcontact.com REJECT I must have done this but at some distant time in the past as I have no recollection of doing so. The situation is that now one of the professional organisations our firm belongs to sends its newsletter via constantcontact.com. I can of course simply remove constantcontact.com from the block list. However, given that it is one of only two such entries I must have had considerable provocation to add it to begin with. My researches into the reputation of constantcontact.com does not inspire confidence and tends to support the original decision. However, i may be compelled to allow their servers to connect to deliver this particular organisation's monthly newsletter. At the moment this is what happens: This is what we see in our logs respecting constantcontact.com smtpd[14594]: NOQUEUE: reject: RCPT from ccm168.constantcontact.com[208.75.123.168]: 554 5.7.1 <AMUVf+m56QtmyuiScINpnzw==_1115946392118_8o8akGcxEeOfSdSuUpLCrA==@in.constantcontact.com>: Sender address rejected: Access denied; from=<AMUVf+m56QtmyuiScINpnzw==_1115946392118_8o8akGcxEeOfSdSuUpLCrA==@in.constantcontact.com> to=<quinter...@harte-lyne.ca> proto=ESMTP helo= This indicates that we obtain a recipient address from the connection before it is rejected. Is their a method available to me to permit one recipient address for this sender and block all the rest? Is there a better way to block all traffic from constantcontact.com except for a specific recipent? -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: TLS warning
On Thu, May 25, 2017 05:23, li...@lazygranch.com wrote: > > > This paper is a good read on email security. It goes into the various > means that a man in the middle can reduce security, one of which is > enabled by selecting opportunistic encryption. (Of which in all > practicality you don't have a choice if you want maximum > compatibility. I'm amazed at the lack of encryption in first world > countries like Canada or the UK.) > Yes, I cannot image why members of the so called 'five-eyes' consortium would not actively promote signal security among their populations. Must be an oversight. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: Problems with aliases
On Wed, May 10, 2017 00:48, Doug Hardie wrote: > I have a situation that is most likely a problem with my understanding > of postfix and not a code problem. I am getting ready to take over a > domain name for mail service. A number of new addresses in that > domain need to be forwarded to other mail servers. I setup postfix to > do that and it worked fine. However, there is still some time before > I actually take over the domain. In the meantime I was entering some > of the addresses and forwarding addresses into the vmail alias file. > Each entry was preceded by "# ". My understanding was that lines > starting with a # would be ignored. I did not bother to run postmap > as it would do nothing useful. > > Several hours later I noticed that no outgoing mail was going out. > Everything was receiving an error in maillog: > If the source file has an mtime later than the resulting map file then postfix will treat this as an error condition. At least this is my experience so far. If you check your maillog file you will find entries if this is the case. Further, if you rebuild a mapfile then you must reload postfix for it to recognize the changes contained therein. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: Server certificate not verified
On Mon, April 17, 2017 11:30, Viktor Dukhovni wrote: > Thank you for bringing this to my attention. > > Your host has DANE TLSA records, but lacks a matching certificate. I am mystified as to what I have done wrong in this respect. The certificate in question has this value as its common name: Subject: CN=inet18.mississauga.harte-lyne.ca The DNS entries match as far as I can see: ;; ANSWER SECTION: inet18.mississauga.harte-lyne.ca. 102897 IN A 209.47.176.18 ;; ANSWER SECTION: 18.176.47.209.in-addr.arpa. 140860 IN PTR inet18.mississauga.harte-lyne.ca. And yet as you write, the TLSA verification chain fails: TLSA records found: 3 TLSA: 2 1 2 380259229e21a1946b38cfc594cbc993b61bc93762b7b6c6637b3eef9c5a2bb70c589b91beb73bd1304eac11b3917e33819e2b47d25d4966435a2a3e83c1f80f TLSA: 2 0 2 67274b355428905895c6b581950e0ed4f7d043f31f7e7020b716b7faa06776b6aadd33e127624b6e8c75c520a01d9cad3bd29f18fa7dcb3d5fd3917510e6722a TLSA: 2 1 2 c26e0ec16a46a97386e8f31f8ecc971f2d73136aa377dfdaac2b2b00f7cab4bb29b17d913c82093b41fd0d9e40b66a68361c126f1f4017f9ce60eabc5adba90e Connecting to IPv4 address: 209.47.176.18 port 25 recv: 220 inet18.mississauga.harte-lyne.ca ESMTP Postfix send: EHLO cheetara.huque.com recv: 250-inet18.mississauga.harte-lyne.ca recv: 250-PIPELINING recv: 250-SIZE 2048 recv: 250-ETRN recv: 250-STARTTLS recv: 250-ENHANCEDSTATUSCODES recv: 250-8BITMIME recv: 250-DSN recv: 250 SMTPUTF8 send: STARTTLS recv: 220 2.0.0 Ready to start TLS TLSv1.2 handshake succeeded. Cipher: TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 Peer Certificate chain: 0 Subject CN: inet18.mississauga.harte-lyne.ca Issuer CN: CA_HLL_ISSUER_2016 1 Subject CN: CA_HLL_ISSUER_2016 Issuer CN: CA_HLL_ROOT_2016 2 Subject CN: CA_HLL_ROOT_2016 Issuer CN: CA_HLL_ROOT_2016 SAN dNSName: inet18.mississauga.harte-lyne.ca SAN dNSName: inet18 SAN dNSName: inet18.hamilton SAN dNSName: inet18.hamilton.harte-lyne.ca SAN dNSName: inet18.mississagua SAN dNSName: inet18.mississagua.harte-lyne.ca Error: peer authentication failed. rc=62 (Hostname mismatch) [2] Authentication failed for all (1) peers. What may be an obvious error to other I cannot see myself. What is wrong with the certificate? Is one no longer permitted to have SubAlternativeNames? > > It looks like you're trying to arrive at working configuration > without thinking about the key questions: > > * What domains do you accept mail for? These are listed in the relay_domains map. > * Where is mail delivered? At our main IMAP service which is not directly accessible to this particular host. This host is a backup MX and should forward mail to the primary MX host when that becomes available. > * What domain should appear in headers and envelopes of > locally generated mail? The FQDN of this host is required as any originating mail is internal mail. This I believe is the default. > * What notices should be sent to the postmaster (often > "none" is the right answer, provided logs, queues, ... > are monitored). > >> However, the source of this problem appears to me to be an invalid >> sender > > No, the source is postmaster notices (possibly unwanted) that > loop back to the local machine, and fail DANE authentication. > -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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
Server certificate not verified
aps= -o smtpd_client_restrictions=permit_mynetworks,reject -o smtpd_delay_reject=no -o smtpd_milters= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=reject_unauth_pipelining -o smtpd_end_of_data_restrictions= -o smtpd_restriction_classes= -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters,no_address_mappings -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: How to implement something close to, but not quite an "announcement-only" mailing list?
On Sat, April 15, 2017 08:01, Kevin A. McGrail wrote: > On 4/14/2017 10:19 PM, Ramon F Herrera wrote: >> On 4/14/2017 8:41 PM, Kevin A. McGrail wrote: >>> On 4/14/2017 9:35 PM, Ramon F Herrera wrote: >>>> >>>> I guess this would be more descriptive and succinct: >>>> >>>> A "members-only PLUS disguising of all e-mail addresses >>>> contained in the headers" mailing list. >>> I didn't follow all your logic in the previous email but overall >>> you'll likely need something like *mailman or majordomo* plus >>> something like MIMEDefang in front of it to achieve your needs. >> >> This begs the question, to all the readers: Given those 2 >> requirements, and my lack of time to learn/compare Majordomo vs. >> mailman, which one would you use? . . . > I use Mailman and it works. Of course, I'm an advisor to Virtru along > with John Viega, Mailman's original author. So in solidarity with him, > I'm going to completely malign majordomo and say that it's horrible! > :-) More seriously, both are great, both work well and I use lists > every day using both. Lot comparing a Honda Civic to a Toyota Camry. > They both just work and get you from point A to B with little grief or > comfort. > > Regards, > KAM > >From wikipedia: The current version of Majordomo is 1.94.5, released 19 January 2000.[4] The official website warns that it will not work with Perl versions 5.001 and 5.005_01 specifically. It recommends to use Perl 4.036 or the latest version available. Support for Perl 4.036 may not be kept for the future.[5] >From me: We ran many mailing lists from the mid 1990's to the mid 2000's with Majordomo. It worked well then and I infer from its continued employment here that it still does. However, it has not been worked on in a considerable time and the world for which it was constructed no longer exists. Shortly before we switched to Mailman a Majordomo 2 project started up and this is still active. You can find the source for MJ2 at http://ftp.mj2.org/pub/mj2/snapshots/ For the few mailing lists that we still host we switched to Mailman around 2005. This was mainly due to the fact that at the time it shipped with RHEL and RHEL was what we were using. RHEL still includes Mailman as far as I know. Mailman is still under active development. It was updated to accommodate the 2015 DMARC fiasco. It also has a web based management interface and built-in archiving tool. These features make Mailman somewhat more convenient for list managers who may not themselves be sysadmins. Regards, -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: Postfix error message to Postmaster
On Mon, April 10, 2017 11:29, Wietse Venema wrote: > James B. Byrne: >> 66 Apr 8 10:50:27 inet08 postfix-p25/smtpd[18374]: warning: >> timeout talking to proxy 127.0.0.1:10024 >> 67 Apr 8 10:50:27 inet08 postfix-p25/smtpd[18374]: >> proxy-reject: >> END-OF-MESSAGE: 451 4.3.0 Error: queue file write error; from= >> to= proto=ESMTP helo= > > The spam proxy is taking a long time to do something. To find out what > that is, see the spam proxy's log. > > Wietse > This is all that I see in /var/log/spamd for the relevant time period. # cat /var/log/spamd.log-20170409 . . . Sat Apr 8 00:06:25 2017 [3845] info: spamd: server started on port 783/tcp (running version 3.3.1) Sat Apr 8 00:06:25 2017 [3845] info: spamd: server pid: 3845 Sat Apr 8 00:06:25 2017 [3845] info: spamd: server successfully spawned child process, pid 3851 Sat Apr 8 00:06:25 2017 [3845] info: spamd: server successfully spawned child process, pid 3852 Sat Apr 8 00:06:25 2017 [3845] info: prefork: child states: IS Sat Apr 8 00:06:25 2017 [3845] info: prefork: child states: II Sun Apr 9 03:29:27 2017 [3845] info: spamd: server killed by SIGTERM, shutting down There are no entries at all between midnight on the 8th and a maintenance reboot on the 9th. Or have I misunderstood your reference? -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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
Postfix error message to Postmaster
We continue to receive messages addressed to Postmaster from our MX host. All appear to be related to a single original transmission. The issue seems to be some sort of time-out with the Amavis proxy. Is there some way of determining exactly what is wrong with this specific sender's message? The Postmaster receives this messages: Transcript of session follows. Out: 220 inet08.hamilton.harte-lyne.ca ESMTP Postfix In: EHLO mail-it0-f47.google.com Out: 250-inet08.hamilton.harte-lyne.ca Out: 250-PIPELINING Out: 250-SIZE 2048 Out: 250-ETRN Out: 250-STARTTLS Out: 250-ENHANCEDSTATUSCODES Out: 250-8BITMIME Out: 250 DSN In: STARTTLS Out: 220 2.0.0 Ready to start TLS In: EHLO mail-it0-f47.google.com Out: 250-inet08.hamilton.harte-lyne.ca Out: 250-PIPELINING Out: 250-SIZE 2048 Out: 250-ETRN Out: 250-AUTH LOGIN PLAIN Out: 250-AUTH=LOGIN PLAIN Out: 250-ENHANCEDSTATUSCODES Out: 250-8BITMIME Out: 250 DSN In: MAIL FROM: SIZE=1701895 Out: 250 2.1.0 Ok In: RCPT TO: Out: 250 2.1.5 Ok In: DATA Out: 354 End data with . Out: 451 4.3.0 Error: queue file write error Session aborted, reason: lost connection For other details, see the local mail logfile The maillog contains these types of entries: 66 Apr 8 10:50:27 inet08 postfix-p25/smtpd[18374]: warning: timeout talking to proxy 127.0.0.1:10024 67 Apr 8 10:50:27 inet08 postfix-p25/smtpd[18374]: proxy-reject: END-OF-MESSAGE: 451 4.3.0 Error: queue file write error; from= to= proto=ESMTP helo= 68 Apr 8 10:50:27 inet08 postfix/cleanup[18523]: AE20261ED8: message-id=<20170408145027.ae20261...@inet08.hamilton.harte-lyne.ca> 69 Apr 8 10:50:27 inet08 postfix-p25/smtpd[18374]: disconnect from mail-it0-f49.google.com[209.85.214.49] 70 Apr 8 10:50:27 inet08 postfix/qmgr[17396]: AE20261ED8: from=<double-bou...@inet08.hamilton.harte-lyne.ca>, size=1429, nrcpt=1 (queue active) 71 Apr 8 10:50:28 inet08 postfix/smtp[18524]: AE20261ED8: to=<postmas...@inet08.hamilton.harte-lyne.ca>, orig_to=, relay=inet07.hamilton.harte-lyne.ca[216.185.71.27]:25, delay=0.56, delays=0.07/0.05/0.32/0.12, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 2FA418A69E) 72 Apr 8 10:50:28 inet08 postfix/qmgr[17396]: AE20261ED8: removed -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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
postfix-policyd-sf vs. policy-spf + postgrey
I am re-provisioning the host system that lost its HDD last week and am taking the opportunity to install FreeBSD. This system will host our off-site MX and DNS services. In the process of installing postfix-3.1.4 I have run across a package named postfix-policyd-sf. On cursory inspection this appears to be a drop in replacement for both postgrey and policyd-spf. As policyd-spf does not appear to be provided via the FreeBSD ports collection I am contemplating using postfix-policyd-sf instead as this is provided as a binary package. Since postfix-policyd-sf reputedly handles the postgrey service its use would eliminate postgrey as a separate maintenance item as well. postfix-policyd-sf has a dependency on libmysqlclient.so.18 and so I infer that there is a mySQL/MariaDB database somewhere as the back-end. However, there is no information provided as to how this is to be set up, configured or maintained if such a requirement exists. Before I do anything rash I would like to receive any comments anyone may have respecting replacing postgrey and policyd-spf with postfix-policyd-sf. Are there configuration issues? Is postfix-policyd-sf less flexible in handling white-listing senders? Is mySQL a requirement? Thanks, P.S. The problems last week that we had with policyd-spf were tied to the loss of one of our DNS services. The resolver on the MX host was slightly misconfigured which exacerbated the delay in reaching a responding server. However, the local host (127.0.0.1) was at the top of the list in resolv.conf and it was providing DNS service without any appreciable delay so I cannot fathom why policyd-spf was looking elsewhere. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: policyd-spf and temperrors
On Fri, March 17, 2017 12:57, Thomas Leuxner wrote:
> * James B. Byrne <byrn...@harte-lyne.ca> 2017.03.17 17:44:
>
>> Mar 17 12:31:22 inet08 postfix/spawn[14598]: warning: command
>> /usr/libexec/postfix/policyd-spf exit status 1
>
> It is spawned per mail in my configuration:
>
> $ postconf -nf | grep -A1 private/policyd
> check_policy_service { unix:private/policyd-spf, timeout=10s,
> default_action=DUNNO }
>
> $ postconf -Mf | grep policyd
> policyd-spf unix - n n - 0 spawn
> user=policyd-spf
> argv=/usr/bin/policyd-spf
>
> As its written in Python it depends on a working environment. Any
> chance this recently has been updated on this machine?
>
> Regards
> Thomas
>
The host system runs under CentOS-6. Other than Postfix itself all
the packages on this system are either from CentOS or EPEL. Python
was last updated in September 2016. pypolicd-spf was last updated
January 2017. These problems only evidenced themselves very recently:
[root@inet08 ~]# ll /var/log/maillog*
-rw---. 1 root root 53522676 Mar 17 17:27 /var/log/maillog
-rw---. 1 root root 40029710 Feb 19 03:10 /var/log/maillog-20170219
-rw---. 1 root root 53658030 Feb 26 03:45 /var/log/maillog-20170226
-rw---. 1 root root 53710015 Mar 5 03:32 /var/log/maillog-20170305
-rw---. 1 root root 48568993 Mar 12 03:39 /var/log/maillog-20170312
[root@inet08 ~]# grep Temperror /var/log/maillog-20170219 | wc -l
187
[root@inet08 ~]# grep Temperror /var/log/maillog-20170226 | wc -l
72
[root@inet08 ~]# grep Temperror /var/log/maillog-20170305 | wc -l
107
[root@inet08 ~]# grep Temperror /var/log/maillog-20170312 | wc -l
134
[root@inet08 ~]# grep Temperror /var/log/maillog | wc -l
11615
The issue was first noticed yesterday. but appears to have started on
the 15th.
[root@inet08 ~]# grep Temperror /var/log/maillog | grep 'Mar 12' | wc -l
2
[root@inet08 ~]# grep Temperror /var/log/maillog | grep 'Mar 13' | wc -l
3
[root@inet08 ~]# grep Temperror /var/log/maillog | grep 'Mar 14' | wc -l
4
[root@inet08 ~]# grep Temperror /var/log/maillog | grep 'Mar 15' | wc -l
1516
[root@inet08 ~]# grep Temperror /var/log/maillog | grep 'Mar 16' | wc -l
3696
[root@inet08 ~]# grep Temperror /var/log/maillog | grep 'Mar 17' | wc -l
6394
Moving to the most recent version of pypolicyd-spf requires upgrading
python. Since the YUM package manager on CentOS-6 requires python 2.6
this is a non-starter.
We are in the process of moving off Linux to FreeBSD in any case. I
will spin up a BHyve FreeBSD instance for Postfix and migrate our MX
address to the new server. So much for the weekend.
--
*** e-Mail is NOT a SECURE channel ***
Do NOT transmit sensitive data via e-Mail
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: policyd-spf and temperrors
On Fri, March 17, 2017 16:49, Scott Kitterman wrote: > > > On March 17, 2017 12:20:11 PM EDT, "James B. Byrne" > <byrn...@harte-lyne.ca> wrote: >>I have just noticed this error. I suspect this points to the root of >>our problems. What does it mean? >> >> >>Mar 17 12:16:58 inet08 postfix-p25/smtpd[14495]: connect from >>russian-caravan.cloud9.net[168.100.1.4] >>Mar 17 12:16:59 inet08 postfix-p25/smtpd[14529]: warning: problem >>talking to server private/policyd-spf: Connection timed out > > You didn't say what version of the policy server you are running. > There was a design issue that caused it to make multiple, sequential > lookups of the same domain. Depending on how fast your DNS is and the > configuration, it could cause these kinds of problems. > > I reworked all that in version 2.0. If you are running an earlier > version, upgrading will likely help. > > You also didn't mention if there's a caching resolver on the server. > That would also help since the redundant lookups would at least hit > the local cache. > > You can ask questions or file bugs specific to this policy server at > https://launchpad.net/pypolicyd-spf > > Scott K > Installed Packages Name: pypolicyd-spf Arch: noarch Version : 1.3.2 Release : 1.el6 Size: 106 k Repo: installed >From repo : epel Summary : SPF Policy Server for Postfix (Python implementation) URL : https://launchpad.net/pypolicyd-spf License : ASL 2.0 We currently run a DNS service on that host. It is operating correctly as far as I can see. In the meantime I have had to disable SPF checking entirely as it was preventing the delivery of any mail whatsoever. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: policyd-spf and temperrors
I have also seen this: Mar 17 12:31:22 inet08 postfix/spawn[14598]: warning: command /usr/libexec/postfix/policyd-spf exit status 1 However, these message only began to appear yesterday evening. This is the first occurrence found in logs going back to February 12: var/log/maillog:Mar 16 17:15:09 inet08 postfix-p25/smtpd[17270]: warning: problem talking to server private/policyd-spf: Connection timed out Temperrors have apparently being going on forever. Often related to outbound.protection.outlook.com. So it is possible that there really is no problem. But there are lots of regular correspondents that are suddenly having this problem delivering their mail to us so I remain suspicious that we have a problem somewhere in our setup. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: policyd-spf and temperrors
I have just noticed this error. I suspect this points to the root of our problems. What does it mean? Mar 17 12:16:58 inet08 postfix-p25/smtpd[14495]: connect from russian-caravan.cloud9.net[168.100.1.4] Mar 17 12:16:59 inet08 postfix-p25/smtpd[14529]: warning: problem talking to server private/policyd-spf: Connection timed out -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: policyd-spf and temperrors
On Fri, March 17, 2017 11:41, Viktor Dukhovni wrote: > >> On Mar 17, 2017, at 11:31 AM, James B. Byrne <byrn...@harte-lyne.ca> >> wrote: >> >> mohawkglobalta.com. 1476IN TXT "v=spf1 >> include:spf.protection.outlook.com ip4:208.33.203.70/31 -all" > > Don't forget the lookups needed to process the "include:" clause, and > the fact that DNS observations vary with time. > > $ dig +short -t txt spf.protection.outlook.com > "v=spf1 ip4:207.46.101.128/26 ip4:207.46.100.0/24 ip4:207.46.163.0/24 > ip4:65.55.169.0/24 ip4:157.56.110.0/23 ip4:157.55.234.0/24 > ip4:213.199.154.0/24 ip4:213.199.180.0/24 > include:spfa.protection.outlook.com -all" > > $ dig +short -t txt spfa.protection.outlook.com > "v=spf1 ip4:157.56.112.0/24 ip4:207.46.51.64/26 ip4:157.55.158.0/23 > ip4:64.4.22.64/26 ip4:40.92.0.0/14 ip4:40.107.0.0/17 > ip4:40.107.128.0/18 ip4:134.170.140.0/24 > include:spfb.protection.outlook.com -all" > > $ dig +short -t txt spfb.protection.outlook.com > "v=spf1 ip6:2a01:111:f400::/48 ip4:23.103.128.0/19 ip4:23.103.198.0/23 > ip4:65.55.88.0/24 ip4:104.47.0.0/17 ip4:23.103.200.0/21 > ip4:23.103.208.0/21 ip4:23.103.191.0/24 ip4:216.32.180.0/23 > ip4:94.245.120.64/26 -all" > > [ These have a 10 minute TTL ] > However, dig lookups performed on these exact domains return virtually instantaneously on our MX server running spf. I can set the spf timeout higher than 20 seconds but I suspect that something else is at work here. This Temperror is also affecting these sites and many more: Mar 17 11:39:47 inet08 policyd-spf[13505]: Temperror; identity=helo; client-ip=69.89.30.42; helo=gproxy3-pub.mail.unifiedlayer.com; envelope-from=p...@thecargosolutionscanada.com; receiver=b...@harte-lyne.ca . . . Mar 17 11:42:52 inet08 policyd-spf[13032]: Temperror; identity=helo; client-ip=168.100.1.4; helo=russian-caravan.cloud9.net; envelope-from=owner-postfix-us...@postfix.org; receiver=b...@harte-lyne.ca . . . Mar 17 11:51:36 inet08 policyd-spf[13709]: Temperror; identity=helo; client-ip=66.135.215.173; helo=mxslcpool71.ebay.com; envelope-from=e...@ebay.com; receiver=b...@harte-lyne.ca They cannot all be suddenly affected by a DNS outage? (P.S. thecargosolutionscanada.com would fail anyway due to too many DNS lookups, but it does not get that far in the process.) -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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
policyd-spf and temperrors
n - - local
virtualunix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - n - 1 anvil
scache unix - - n - 1 scache
mailmanunix - n n - - pipe flags=FR
user=mailman:mailman
argv=/usr/lib/mailman/postfix/postfix-to-mailman.py
${nexthop} ${user}
127.0.0.1:2626 inet n- n - - smtpd
-o smtpd_tls_security_level=none
-o smtpd_sasl_auth_enable=no
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=
-o milter_macro_daemon_name=ORIGINATING
-o syslog_name=postfix-p2626
policyd-spf unix y n n - - spawn
user=nobody
argv=/usr/libexec/postfix/policyd-spf
smtp-amavis unix - - n - 6 smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
-o disable_dns_lookups=yes
-o max_use=20
127.0.0.1:10025 inet n - n - - smtpd
-o content_filter=
-o local_header_rewrite_clients=
-o local_recipient_maps=
-o mynetworks=127.0.0.0/8
-o relay_recipient_maps=
-o smtpd_client_restrictions=permit_mynetworks,reject
-o smtpd_delay_reject=no
-o smtpd_milters=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=reject_unauth_pipelining
-o smtpd_end_of_data_restrictions=
-o smtpd_restriction_classes=
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o
receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters,no_address_mappings
--
*** e-Mail is NOT a SECURE channel ***
Do NOT transmit sensitive data via e-Mail
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: postfix virtual domain walking
On Mon, June 13, 2016 16:42, Wietse Venema wrote: > James B. Byrne: >> These delivery names are only found in /etc/postfix/virtual. > > What about an email "address book" on a user machine? > > Wietse > It is certainly a possibility. However, my difficulty with that explanation is that: 1. Our users employ webmail (squirrelmail) so their address books are maintained on a sealed server. There are no user accounts on it. And we run aide on it. And we have fail2ban running. And ssh is blocked at the firewall. 2. Some of these addresses like .bugzilla and .redhat are only used for bug reporting. They would be found on the respective sites but it seems to me doubtful that they would end up in a user address book. 3. If there is nothing that involves Postfix then something like what you propose must be the case. Or someone has gone to some lengths to scan for these addresses using our domain name as a search term. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: postfix virtual domain walking
On Mon, June 13, 2016 14:25, Wietse Venema wrote:
> James B. Byrne:
>> However, the question arises as to how these local delivery
>> addresses
>> are being harvested? Some of these are used very infrequently and
>> some of them have not been active for years. It seems remarkable
>> that
>> addresses that are known to only be used for one purpose, say
>> bugzilla
>> or readhat network, are found in these attacks.
>
> The names may have been harvested from a compromised user machine.
>
>> Is there some way for remote unauthenticated users to query postfix
>> in
>> such a fashion as to effectively walk the virtual domain list for
>> local delivery addresses? If so then what is it and how can it be
>> prevented. Or should it?
>
> As far as I know, there is no SMTP command to 'list' a local database.
> That is, unless there is some kind of LDAP or SQL injection bug.
>
> Wietse
>
These delivery names are only found in /etc/postfix/virtual. There is
no LDAP service or RDBMS involved whatsoever. As far as I can tell
there would be no reason for any user machine to have them listed as
they exist solely to map incoming mail to specific imap subfolders.
It may very well be that these people attempting to break in have gone
to the internet hunting for every revealed variant address. But that
in itself seems even more worrying.
--
*** e-Mail is NOT a SECURE channel ***
Do NOT transmit sensitive data via e-Mail
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
postfix virtual domain walking
We are currently subjected to a persistent penetration attempt that apparently is directed against our smtp authentication. The user names employed at the present time are all local address portions of a single user's virtual domain which have no means of authentication. So the attack is futile in that sense. However, the question arises as to how these local delivery addresses are being harvested? Some of these are used very infrequently and some of them have not been active for years. It seems remarkable that addresses that are known to only be used for one purpose, say bugzilla or readhat network, are found in these attacks. Is there some way for remote unauthenticated users to query postfix in such a fashion as to effectively walk the virtual domain list for local delivery addresses? If so then what is it and how can it be prevented. Or should it? -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: remapping return-path ?
On Fri, May 20, 2016 16:06, Tanstaafl wrote: > On 5/19/2016 1:50 PM, James B. Byrne <byrn...@harte-lyne.ca> wrote: >> We have a situation where some party is harvesting our employees' >> mailbox names and using them for a directed brute force attack >> against >> our SMTP servers. In order dodge this we have undertaken to rename >> of >> user mailboxes. > > Trying for the life of me to figure out how or why you think this is a > good way to mitigate such an attack... > > Failing miserably. > The issue is moot. I discovered the cause of the return path setting was the user themselves and had them reconfigure their MUA to remove that setting. The mailbox renaming exercise has to do do with single logon. Our email addresses have had the same form since 1995 and from that time user logon accounts were used as their mailbox and email local address as well. Since this information is already known we are simply moving all of our user ids to something that does not show up in the email headers and leaving the email addresses as they are. It is most disconcerting to see an sasl attack on our relays which only uses actual userids for our company employees, albeit they have a lot of defunct userids in that list. If these names are no longer anywhere in use as actual user ids then that is at least one attack avenue that is forestalled. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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
remapping return-path ?
We have a situation where some party is harvesting our employees' mailbox names and using them for a directed brute force attack against our SMTP servers. In order dodge this we have undertaken to rename of user mailboxes. However, we use the imap service to authenticate for SMTP delivery and so the actual mailbox name must be used when sending. What happens then is that the newly renamed mailbox identity ends up in the RETURN-PATH of the sender's message. We would like to remap that value back to the sender's original mailbox name since that is what is set up to receive mail for that user. A diagram may help, or not depending on whether the reader uses fixed space fonts. oldmailboxn...@harte-lyne.ca <--- the original email address in /etc/postfix/virtual oldmailboxn...@harte-lyne.ca oldmailboxname On the IMAP service host oldmailboxname <--- the original imap mailbox newmailboxname <--- the renamed imap mailbox in /etc/postfix/virtual oldmailboxn...@harte-lyne.ca newmailboxname When sending from newmailboxname the Return-Path value is newmailboxname@harte-lyne. newmailboxname is deliberately set up so as to not receive mail. We want the Return-path value to say oldmailboxn...@harte-lyne.ca instead, which does receive mail. I tried this in the outgoing MTA: sender_canonical_maps = hash:/etc/postfix/canonical with this in /etc/postfix/canonical: newmailboxnameoldmailboxname Rebuilding the hash db and restarting postfix thereafter did not change the results shown in the Return-PAth. Is there a way to accomplish this? -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: I wonder if I get this email...
On Fri, May 13, 2016 01:49, lejeczek wrote: > hi everybody. > > I'm a subscriber to a few mailing lists, for a good number > of years now, but recently something very annoying happened > and I'm hoping postfix list here there is someone could > suggest some troubleshooting that may resolve this problem. > > I use Yahoo free of charge mail service, about two weeks ago > I stopped getting my own messages I send to any list. > > I see they go through for people reply and I get the replies. > > I checked all the filters, both server and local side, > nothing, but I did not change anything there around when it > happened anyway. > > To eliminate third parties I tried directly with Yahoo > webmail, sending from there, but to no avail, my emails I > would not get, they are not in the inbox nor in "bulk mail" > as Yahoo call it. > > It is a sticky wicket I understand, but maybe someone has > experienced something so weird as this and knows what to do > - apart from ditching Yahoo away of course. > > many thanks. > > L > > > Your Yahoo account deliveries are being blocked by Yahoo because cloud9.net is delivering your message claiming it to be sent from yahoo.co.uk. Yahoo blocks these as forgeries. The problem with this policy and its effect on many, if not most, MLMs is well known. A fix has been made to MailMan but I do not know about Majordomo. In any case I was once told that nobody much wants to tinker with the current postfix-users MLM setup so I doubt that any upgrade is contemplated even if one is available. BTW. None of your messages to this list are being delivered to any Yahoo subscribers for exactly the same reasons. I believe that AOL accounts may be in the same boat and that Google mail accounts flag these messages as spammish. But these are just dim recollections from when I had to deal with this issue at its start. . . . Received: from inet08.hamilton.harte-lyne.ca ([127.0.0.1]) by localhost (inet08.hamilton.harte-lyne.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMDvliMzfdAN for <byrn...@harte-lyne.ca>; Fri, 13 May 2016 01:50:00 -0400 (EDT) Received-SPF: None (no SPF record) identity=mailfrom; client-ip=168.100.1.4; helo=russian-caravan.cloud9.net; envelope-from=owner-postfix-us...@postfix.org; receiver=byrn...@harte-lyne.ca Received: from russian-caravan.cloud9.net (russian-caravan.cloud9.net [168.100.1.4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.cloud9.net", Issuer "GeoTrust DV SSL CA - G3" (verified OK)) by inet08.hamilton.harte-lyne.ca (Postfix) with ESMTPS for <byrn...@harte-lyne.ca>; Fri, 13 May 2016 01:49:58 -0400 (EDT) . . . From: lejeczek <pelj...@yahoo.co.uk> -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: Mail is not being rejected with check_policy_server when SPF fails?
On Wed, May 11, 2016 19:18, Alice Wonder wrote: > > I've found that legitimate mail fails SPF too often to reject. Problem > is system administrators don't keep the policy up to date as the > network changes, or they don't understand SPF. > > I think SPF is good for spam score but shouldn't reject based on it > alone. > > We take the position that any domain that implements SPF with the -all tag is telling us to reject anything purporting to come from them that fails spf, which we do. Likewise, any domain that has enabled spf has committed to maintain a valid spf configuration in their zone file or we will reject their mail per the spf rules. SPF is essentially a performance contract which the sender domain has voluntarily entered into with their correspondents. If poor spf configuration causes problems for them they can either fix the problem or disable spf altogether. There is no point in us enabling a crippled spf configuration to persist without repair. We are not doing them or their other correspondents any favour should we do so. Depending on the site we will often send a message to both the sender and to the postmaster address detailing the issue that they are having. Although empirically we see that many, many sites have no way of receiving email addressed to postmas...@domain.tld. The humorous thing is that often the non-delivery notice is sent from, you guessed it, postmas...@domain.tld. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: Postfix error 450 4.7.1 Sender address rejected: Access denied
On Thu, May 5, 2016 12:37, Christian Kivalo wrote: > > There it is: lymanworldwide.com uses nameservices provided by > name-services.com > Thanks, that is it. I suppose we will just have to explicitly permit them in. Not that I approve of their choice of registrars (enom). Thanks for the help. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: Postfix error 450 4.7.1 Sender address rejected: Access denied
On Thu, May 5, 2016 12:11, Christian Kivalo wrote: > > > Am 5. Mai 2016 17:34:36 MESZ, schrieb "James B. Byrne" > <byrn...@harte-lyne.ca>: >>Can anyone clue me in on what configuration issue might be causing >>this and whose configuration it is, mine or theirs? >> >>postfix-p25/smtpd[18149]: NOQUEUE: reject: RCPT from >>smout-245174.nsmailserv.com[202.162.245.174]: 450 4.7.1 >><impo...@lymanworldwide.com>: Sender address rejected: Access denied; >>from=<impo...@lymanworldwide.com> to=<expo...@harte-lyne.ca> >>proto=ESMTP helo= >> >> >># postconf -n . . . >>smtpd_sender_restrictions = permit_mynetworks, check_sender_access >>hash:/etc/postfix/sender_access, check_sender_mx_access >>hash:/etc/postfix/sender_mx_access, check_sender_ns_access >>hash:/etc/postfix/sender_ns_access, permit_sasl_authenticated, >>reject_non_fqdn_sender, reject_unknown_sender_domain, permit > > Whats in these files? > # cat /etc/postfix/sender_access . . . # ACCESS(5) ::1 OK 127.0.0.1 OK 216.185.71.9 OK 216.185.71.10 OK 216.185.71.11 OK 216.185.71.12 OK 216.185.71.13 OK 216.185.71.14 OK 216.185.71.15 OK 216.185.71.16 OK 216.185.71.17 OK 216.185.71.18 OK 216.185.71.19 OK 216.185.71.20 OK 216.185.71.21 OK 216.185.71.22 OK 216.185.71.23 OK 216.185.71.24 OK 216.185.71.25 OK 216.185.71.26 OK 216.185.71.27 OK 216.185.71.28 OK 216.185.71.29 OK forex.cont...@harte-lyne.ca OK mailman.halisp.netOK upsdocs.com OK .upsdocs.com OK verticalresponse.com REJECT # cat /etc/postfix/sender_mx_access . . . # Cannot use OK result in this map, use DUNNO instead. # cat /etc/postfix/sender_ns_access . . . # Cannot use OK result in this map, use DUNNO instead. # colocrossings.com DEFER name-services.com DEFER name-services.net DEFER leaseweb.be DEFER leaseweb.ca DEFER leaseweb.ch DEFER leaseweb.comDEFER leaseweb.de DEFER leaseweb.fr DEFER leaseweb.netDEFER leaseweb.nl DEFER leaseweb.orgDEFER leaseweb.us DEFER -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: Postfix error 450 4.7.1 Sender address rejected: Access denied
On Thu, May 5, 2016 12:01, Gao wrote: > try use "~all" instead of "-all" in your SPF txt record. > We are not the sender. We are the recipient. Our SPF record does not bear on this issue insofar as I can see. In any case, our SPF TXT RR already includes ~all, not -all. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: Postfix error 450 4.7.1 Sender address rejected: Access denied
On Thu, May 5, 2016 11:34, James B. Byrne wrote: > Can anyone clue me in on what configuration issue might be causing > this and whose configuration it is, mine or theirs? > > postfix-p25/smtpd[18149]: NOQUEUE: reject: RCPT from > smout-245174.nsmailserv.com[202.162.245.174]: 450 4.7.1 > <impo...@lymanworldwide.com>: Sender address rejected: Access denied; > from=<impo...@lymanworldwide.com> to=<expo...@harte-lyne.ca> > proto=ESMTP helo= > > I discovered this issue in their DNS with respect to SPF: ;; ANSWER SECTION: lymanworldwide.com. 1800IN TXT "v=spf1 include:netcore.co.in -all" lymanworldwide.com. 1800IN TXT "v=spf1 include:spf.protection.outlook.com -all" But it does not appear to me that the connection is getting to the point where SPF is considered. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: Postfix error 450 4.7.1 Sender address rejected: Access denied
Can anyone clue me in on what configuration issue might be causing
this and whose configuration it is, mine or theirs?
postfix-p25/smtpd[18149]: NOQUEUE: reject: RCPT from
smout-245174.nsmailserv.com[202.162.245.174]: 450 4.7.1
<impo...@lymanworldwide.com>: Sender address rejected: Access denied;
from=<impo...@lymanworldwide.com> to=<expo...@harte-lyne.ca>
proto=ESMTP helo=
# postconf -n
alias_maps = hash:/etc/aliases
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
ddd $daemon_directory/$process_name $process_id & sleep 5
delay_warning_time = 30m
disable_vrfy_command = yes
header_checks = regexp:/etc/postfix/header_checks.regexp
home_mailbox = Maildir/
html_directory = no
ignore_mx_lookup_error = no
inet_interfaces = localhost, inet08.hamilton.harte-lyne.ca
inet_protocols = all
local_transport = smtp
mail_spool_directory = /var/spool/mail
mailman_destination_recipient_limit = 1
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 2048
milter_default_action = accept
milter_protocol = 2
mydestination =
mynetworks = 216.185.71.0/26, 127.0.0.0/8
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = $smtpd_milters
policyd-spf_time_limit = 3600
queue_minfree = 4096
rbl_reply_maps = hash:/etc/postfix/rbl_reply
readme_directory = /usr/share/doc/postfix-2.11.1/README_FILES
recipient_delimiter = +
relay_clientcerts = hash:/etc/postfix/relay_clientcerts
relay_domains = hash:/etc/postfix/relay_domains
sample_directory = /usr/share/doc/postfix-2.11.1/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_dns_support_level = dnssec
smtp_host_lookup = dns
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtp_tls_cert_file = /etc/pki/tls/certs/ca.harte-lyne.smtp.crt
smtp_tls_ciphers = medium
smtp_tls_exclude_ciphers = MD5, aDSS, SRP, PSK, aECDH, aDH, SEED,
IDEA, RC2, RC5
smtp_tls_key_file = /etc/pki/tls/private/ca.harte-lyne.smtp.key
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_security_level = dane
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtp_tls_session_cache_timeout = 3600s
smtpd_client_restrictions = permit
smtpd_data_restrictions = permit_mynetworks,
reject_multi_recipient_bounce, reject_unauth_pipelining, permit
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, check_helo_access
pcre:/etc/postfix/helo_checks.pcre, reject_non_fqdn_helo_hostname,
reject_unknown_helo_hostname, permit
smtpd_milters = inet:127.0.0.1:8891
smtpd_proxy_timeout = 300s
smtpd_recipient_restrictions = reject_non_fqdn_recipient,
reject_unknown_recipient_domain, permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination,
reject_unauth_pipelining, check_policy_service
unix:/var/spool/postfix/postgrey/socket, check_policy_service
unix:private/policyd-spf, permit
smtpd_relay_restrictions = permit_mynetworks,
permit_sasl_authenticated, defer_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = smtpd
smtpd_sender_restrictions = permit_mynetworks, check_sender_access
hash:/etc/postfix/sender_access, check_sender_mx_access
hash:/etc/postfix/sender_mx_access, check_sender_ns_access
hash:/etc/postfix/sender_ns_access, permit_sasl_authenticated,
reject_non_fqdn_sender, reject_unknown_sender_domain, permit
smtpd_starttls_timeout = ${stress?10}${stress:120}s
smtpd_timeout = ${stress?10}${stress:120}s
smtpd_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtpd_tls_ask_ccert = yes
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/pki/tls/certs/ca.harte-lyne.smtpd.crt
smtpd_tls_ciphers = medium
smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
smtpd_tls_fingerprint_digest = sha1
smtpd_tls_key_file = /etc/pki/tls/private/ca.harte-lyne.smtpd.key
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
soft_bounce = no
strict_rfc821_envelopes = yes
tls_random_source = dev:/dev/urandom
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/virtual,
regexp:/etc/postfix/virtual.regexp
--
*** e-Mail is NOT a SECURE channel ***
Do NOT transmit sensitive data via e-Mail
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
Interpreting unauthorised relaying
r/lib/postfix/smtpd_scache smtpd_tls_session_cache_timeout = 3600s soft_bounce = no strict_rfc821_envelopes = yes tls_random_source = dev:/dev/urandom transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/etc/postfix/virtual, regexp:/etc/postfix/virtual.regexp -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via 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
Autoresponders
As much as I hate these things it seems that we do have a use case for one at the present. Ideally this would run as entry in an aliased :include: mailing list. I suppose I could just put a simple bash script together and call that but I rather suspect this approach would in the end prove more time consuming than using some sort of package; the simpler the better. Does anyone have any recommendations? Postfix 2.6 (MDA) - as distributed with RHEL6.6 Cyrus-IMAP 2.3 (LDA) - ditto -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via 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: [SOLVED] Re: SMTPD Configuration error
On Tue, June 23, 2015 17:32, Viktor Dukhovni wrote: On Tue, Jun 23, 2015 at 03:19:04PM -0400, James B. Byrne wrote: smtp_tls_security_level = dane Not useful without: smtp_dns_support_level = dnssec and 127.0.0.1 as the only nameserver entry in /etc/resolv.conf and a validating resolver running on 127.0.0.1. Otherwise, use may, not dane. All MX and delivery hosts have a named instance running on them. Only our internal DNS servers are listed in /etc/resolv.conf on any host. 127.0.0.1 is the first entry in resolv.conf for hosts running a named instance. I do not understand why that should be the only entry however. DANE is supposed to protect against man-in-the-middle (MiTM) attacks. If your DNS queries are over an insecure channel (go off host), then the security status of the replies cannot be trusted, and there's not much point in doing DANE (unless you expect all the attackers to be remote, beyond the nameservers you use, and never between the host and its iterative nameserver. That's a rather risky assumption. We run our own name-servers for our domains. In other words we have the delegation for harte-lyne.ca, harte-lyne.com, and so forth. We also have the delegation for our cat C netblocks and provide the DNS reverse lookups form our own name-servers. Our name-servers reside on the same network segments as our mail servers. All our host resolvers, not just the mail server hosts, are configured to only use our internal name-servers by ip address. Those hosts that have an instance of named running also have 127.0.0.1 listed first. Given these conditions it is difficult for me to imagine a circumstance where a mitm attack would be possible. If you can formulate a scenario then I am most eager to learn it since I am obviously not aware of every possibility. I regret if I seem obtuse but this is an area of which I have but little experience. Sincerely, -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via 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
[SOLVED] Re: SMTPD Configuration error
On Mon, June 22, 2015 10:09, Viktor Dukhovni wrote:
On Mon, Jun 22, 2015 at 09:40:58AM -0400, James B. Byrne wrote:
However, postfix had already been
under git control as a separate repository when etckeeper was
installed and, unbeknownst to me git considered that a submodule so
when etckeeper did its update commits the postfix directory was not
updated with the rest.
Have you considered using git to go back to the previous
configuration?
Start with:
git log
The sad case of unwanted and unrecognised git submodules was
previously explained. And this has been fixed.
INET07 = local delivery
[root@inet07 etc]# postconf -n
...
relay_clientcerts = hash:/etc/postfix/relay_clientcerts
Does the .db file exist (did you postmap the file)?
relay_domains = hash:/etc/postfix/relay_domains
Ditto.
Both these were missing, along with another map. That was indeed the
problem with getting the server to accept connections.
relayhost = smtp.hamilton.harte-lyne.ca
Typically, you'd want that in []:
relayhost = [smtp.hamilton.harte-lyne.ca]
unless that really is intended to be an MX RRset and not a hostname.
I understand that the brackets mean do not lookup the MX records. I
can see why that would be preferred if email was meant to be forwarded
on to a specific host not listed in DNS as an MX. But this particular
host is the final destination of all mail destined to domains under
our control and it does not accept mail for retransmission onward. I
do not see the point in this case. I suppose I should just delete the
entry.
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
Generally this is left empty.
smtp_tls_cert_file = /etc/pki/tls/certs/ca.harte-lyne.$TLSHOST.crt
smtp_tls_key_file = /etc/pki/tls/private/ca.harte-lyne.$TLSHOST.key
What is this $TLSHOST? I notice it is set in the INET07 main.cf
file but not in this one.
An oversight on my part. I made some changes that I did not entirely
back out before running postconf.
smtp_tls_ciphers = medium
smtp_tls_exclude_ciphers = MD5, aDSS, SRP, PSK, aECDH, aDH, SEED,
IDEA, RC2, RC5
smtp_tls_protocols = !SSLv2, !SSLv3
Exchange 2003 interoperability mode, that's fine.
smtp_tls_security_level = dane
Not useful without:
smtp_dns_support_level = dnssec
and 127.0.0.1 as the only nameserver entry in /etc/resolv.conf
and a validating resolver running on 127.0.0.1. Otherwise, use
may, not dane.
All MX and delivery hosts have a named instance running on them. Only
our internal DNS servers are listed in /etc/resolv.conf on any host.
127.0.0.1 is the first entry in resolv.conf for hosts running a named
instance. I do not understand why that should be the only entry
however.
smtp_use_tls = yes
Obsolete.
Removed.
smtpd_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
Often can be left empty instead. Why load a pile of certificates
you don't use. If you must a pile of certificates, use CApath,
not CAfile.
Why is this so? What is the effect of leaving it empty? I presume
this has to do with TRUST and since we really do not trust anybody
sending email being whom they claim to be it is redundant.
smtpd_tls_cert_file = /etc/pki/tls/certs/ca.harte-lyne.smtpd.crt
smtpd_tls_key_file = /etc/pki/tls/private/ca.harte-lyne.smtpd.key
This is more reasonable (no $TLSHOST), do the key and certificate
match? Any signs of trouble in the logs:
Nothing respecting the keys or certs. Which is to say there were other
problems reported.
http://www.postfix.org/DEBUG_README.html#logging
smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
Did you generate that parameter file?
Yes, automatically performed weekly by a cron job. It does not seem
necessary to do so more frequently than that but if so then a schedule
change is trivial.
INET08 - MX host unable to connect to INET07 (timeout)
# postconf -n
TLSHOST = smtp
What's the point of this TLSHOST business.
At one point we were sharing main.cf between two hosts, the vary
backup host from which I recovered a working config file. This was an
attempt to minimize the number of places customization edits needed to
be performed. It has been removed and the file naming rationalized
instead.
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
Why?
We run our own private CA. Our root certificate is required for the
validation chain as far as I am aware. This is a custom bundle with
our root and issuer CA certificates added.
smtp_tls_cert_file = /etc/pki/tls/certs/ca.harte-lyne.$TLSHOST.crt
smtp_tls_key_file = /etc/pki/tls/private/ca.harte-lyne.$TLSHOST.key
Why not just use the exact file name without a $TLSHOST variable?
Fixed.
smtp_use_tls = yes
Obsolete.
Removed
smtpd_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
Empty is better.
Why?
smtpd_tls_ask_ccert = yes
Do you plan to support client certs? For submission? Or
on port 25?
Yes, on 25 only. There are no submissions on this particular server
Re: SMTPD Configuration error
I considered and tried most of the suggestions surrounding git without success. The archived version in the unused git repo in /etfc/postfix was just too old (2012). However, in my distraction with the problem at hand I had forgotten that I had previously set up and maintained at our off-site facility entire ghost systems for each our primary internet services. Once recalled that fact I simply pulled the configuration file from that host and restarted. So, I can now read this mail. Another product of haste and distraction. How can one read messages on how to fix ones email system when the problem is that ones email system will not deliver incoming mail? I was about to resend my original request via my gmail account, which only exists for this reason, when I recalled the backup. I have also reinitialised the etckeeper setup on INET07 and verified that the postfix directory is being backed up. I have also checked the one on INET08 and confirmed that there was no problem there. I will go through the rest of the diagnosis provided and apply the recommend fixes or explain our reasons for the variances. Which may or may not be supportable. In which case we will alter them. Thank you for the prompt response. I appreciate the help very much. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via 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
SMTPD Configuration error
local_transport = smtp
mail_spool_directory = /var/spool/mail
mailman_destination_recipient_limit = 1
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 2048
milter_default_action = accept
milter_protocol = 2
mydestination =
mynetworks = 216.185.71.0/26, 209.47.176.0/26, 127.0.0.0/8
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = $smtpd_milters
policyd-spf_time_limit = 3600
queue_minfree = 4096
rbl_reply_maps = hash:/etc/postfix/rbl_reply
readme_directory = /usr/share/doc/postfix-2.11.1/README_FILES
recipient_delimiter = +
relay_clientcerts = hash:/etc/postfix/relay_clientcerts
relay_domains = hash:/etc/postfix/relay_domains
sample_directory = /usr/share/doc/postfix-2.11.1/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_dns_support_level = dnssec
smtp_host_lookup = dns
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtp_tls_cert_file = /etc/pki/tls/certs/ca.harte-lyne.$TLSHOST.crt
smtp_tls_ciphers = medium
smtp_tls_exclude_ciphers = MD5, aDSS, SRP, PSK, aECDH, aDH, SEED,
IDEA, RC2, RC5
smtp_tls_key_file = /etc/pki/tls/private/ca.harte-lyne.$TLSHOST.key
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_security_level = dane
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtp_tls_session_cache_timeout = 3600s
smtp_use_tls = yes
smtpd_client_restrictions = permit
smtpd_data_restrictions = permit_mynetworks,
reject_multi_recipient_bounce, reject_unauth_pipelining, permit
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, check_helo_access
pcre:/etc/postfix/helo_checks.pcre, reject_non_fqdn_helo_hostname,
reject_unknown_helo_hostname, permit
smtpd_milters = inet:127.0.0.1:8891
smtpd_proxy_timeout = 300s
smtpd_recipient_restrictions = reject_non_fqdn_recipient,
reject_unknown_recipient_domain, permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination,
reject_unauth_pipelining, check_policy_service
unix:/var/spool/postfix/postgrey/socket, check_policy_service
unix:private/policyd-spf, permit
smtpd_relay_restrictions = permit_mynetworks,
permit_sasl_authenticated, defer_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = smtpd
smtpd_sender_restrictions = permit_mynetworks, check_sender_access
hash:/etc/postfix/sender_access, check_sender_mx_access
hash:/etc/postfix/sender_mx_access, check_sender_ns_access
hash:/etc/postfix/sender_ns_access, permit_sasl_authenticated,
reject_non_fqdn_sender, reject_unknown_sender_domain, permit
smtpd_starttls_timeout = ${stress?10}${stress:120}s
smtpd_timeout = ${stress?10}${stress:120}s
smtpd_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtpd_tls_ask_ccert = yes
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/pki/tls/certs/ca.harte-lyne.smtpd.crt
smtpd_tls_ciphers = medium
smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
smtpd_tls_fingerprint_digest = sha1
smtpd_tls_key_file = /etc/pki/tls/private/ca.harte-lyne.smtpd.key
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
soft_bounce = no
strict_rfc821_envelopes = yes
tls_random_source = dev:/dev/urandom
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/virtual,
regexp:/etc/postfix/virtual.regexp
--
*** e-Mail is NOT a SECURE channel ***
Do NOT transmit sensitive data via 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: how to refuse un-encrypted email
On Wed, June 3, 2015 10:41, Bill Cole wrote: Note that if you want maximal protection for both message metadata (headers and SMTP envelope) and content both in transit and after delivery, you have a very large problem space that has ultimately frustrated some very smart people, including Phil Zimmermann (the original author of PGP) who recently started to try to create a fully secure email service and gave up on it as impossible. I had not read that the Dark Mail project was dead or that Zimmermann had left it. Where can this information be found? -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via 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: how to refuse un-encrypted email
On Wed, June 3, 2015 09:15, John Allen wrote: Is there any way of testing for and refusing un-encrypted email? secondary, would it be possible to do this based upon the recipient. default would be encrypted, but email directed at some recipients may be in plain text. What level of encryption are you contextualizing? STARTTLS between SMTP peers; or the message itself using S/MIME or PGP/GPG; or something else? -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via 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: Receiving emails from my own spoofed domain
On Sat, May 9, 2015 19:19, Jonathan Bees wrote: Hi, This might be a stupid question, but I recently received a email spam from one of my users u...@mydomain.com, which was spam. After asking her about it and afterwards checking logs, it turns out it came from some random Brazilian server (and she was not hacked *sigh of relief*). But the spam email from seemingly our own user got me to wondering how to prevent such situations happening in the future. I am aware of SPF, but is there a Postfix-way of stopping spammer sending emails with my own spoofed domain? Making Postfix aware not to accept emails from (supposedly) u...@example.com when not originating from a host listed in mynetworks ? Jonathan We use this: #/etc/postfix/main.cf . . . check_helo_access pcre:/etc/postfix/helo_checks.pcre #/etc/postfix/helo_checks.prce . . . # Dopplegangers /^(.*\.)?(hamilton\.)?halisp\.net$/ 550 Do not use this domain/hostname /^(.*\.)?(hamilton\.)?harte-lyne\.ca$/ 550 Do not use this domain/hostname /^(.*\.)?(hamilton\.)?harte-lyne\.com$/ 550 Do not use this domain/hostname /^\[?216\.185\.76\.28\]?$/ 550 Spammer comes to me \ Greets me with my own IP \ His mail I shall not see. . . . -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via 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: postfix-policyd-spf-perl and troubles with Amazon?
On Wed, May 6, 2015 09:45, Tobi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi list I know it's technically not a postfix issue :-) But maybe someone else here on this list has the same problem. I'm using Postfix with postfix-policyd-spf-perl About 4 or 5 days ago I started to get error messages from postfix for mails from Amazon. The log shows May 6 15:33:12 mail1 postfix/policy-spf[10692]: Policy action=DEFER_IF_PERMIT SPF-Result=marketplace.amazon.de ... spf1.amazon.com: Unknown error on DNS 'TXT' lookup of 'spf1.amazon.com' May 6 15:33:12 mail1 postfix/smtpd[10069]: NOQUEUE: reject: RCPT from a0-3.smtp-out.eu-west-1.amazonses.com[54.240.0.3]: 450 4.7.1 tobs...@brain-force.ch: Recipient address rejected: SPF-Result=marketplace.amazon.de ... spf1.amazon.com: Unknown error on DNS 'TXT' lookup of 'spf1.amazon.com'; from=comm-bounces+bbc-message-a370530b4pb...@marketplace.amazon.de to=tobs...@brain-force.ch proto=ESMTP helo=a0-3.smtp-out.eu-west-1.amazonses.com May 6 15:33:37 mail1 postfix/smtpd[10069]: disconnect from a0-3.smtp-out.eu-west-1.amazonses.com[54.240.0.3] I did not change anything on the server side. I tried to verify the SPF records from Amazon with http://www.kitterman.com/spf/validate.html but the tests were always successfull. Does anyone have this problem too with Amazon? Or does anyone have an idea how to solve it? Thanks dig spf1.amazon.com TXT ;; ANSWER SECTION: spf1.amazon.com.900 IN TXT spf2.0/pra ip4:207.171.160.0/19 ip4:87.238.80.0/21 ip4:72.21.192.0/19 ip4:194.154.193.192/27 ip4:194.7.41.152/28 ip4:212.123.28.40/32 ip4:203.81.17.0/24 ip4:72.21.212.0/25 ip4:178.236.10.128/26 -all spf1.amazon.com.900 IN TXT v=spf1 ip4:207.171.160.0/19 ip4:87.238.80.0/21 ip4:72.21.192.0/19 ip4:194.154.193.192/27 ip4:194.7.41.152/28 ip4:212.123.28.40/32 ip4:203.81.17.0/24 ip4:72.21.212.0/25 ip4:178.236.10.128/26 -all Amazon has screwed up their spf records. A DNS host can have only ONE spf TXT RR and that must not contain or recursively resolve to more than TEN tags. You will have to contact the DNS maintainer for the amazon.com zone ;; AUTHORITY SECTION: amazon.com. 60 IN SOA dns-external-master.amazon.com. root.amazon.com. 2010112764 180 60 3024000 60 Who evidently is reached via r...@amazon.com. Good luck with that. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via 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: postfix-policyd-spf-perl and troubles with Amazon?
On Wed, May 6, 2015 10:11, Scott Kitterman wrote: On Wednesday, May 06, 2015 09:58:57 AM James B. Byrne wrote: Amazon has screwed up their spf records. A DNS host can have only ONE spf TXT RR and that must not contain or recursively resolve to more than TEN tags. No. That's not it. One of those is a v=spf1 SPF record and the other is a spf2.0 Sender ID record. Much more likely the issue is the use of EDNS0. In the part of the dig output you didn't include, you probably got: ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 and ;; MSG SIZE rcvd: 611 Actually, no. I got this: ;; ANSWER SECTION: spf1.amazon.com.900 IN TXT spf2.0/pra ip4:207.171.160.0/19 ip4:87.238.80.0/21 ip4:72.21.192.0/19 ip4:194.154.193.192/27 ip4:194.7.41.152/28 ip4:212.123.28.40/32 ip4:203.81.17.0/24 ip4:72.21.212.0/25 ip4:178.236.10.128/26 -all spf1.amazon.com.900 IN TXT v=spf1 ip4:207.171.160.0/19 ip4:87.238.80.0/21 ip4:72.21.192.0/19 ip4:194.154.193.192/27 ip4:194.7.41.152/28 ip4:212.123.28.40/32 ip4:203.81.17.0/24 ip4:72.21.212.0/25 ip4:178.236.10.128/26 -all ;; AUTHORITY SECTION: amazon.com. 2751IN NS ns3.p31.dynect.net. amazon.com. 2751IN NS ns1.p31.dynect.net. amazon.com. 2751IN NS ns4.p31.dynect.net. amazon.com. 2751IN NS ns2.p31.dynect.net. amazon.com. 2751IN NS pdns6.ultradns.co.uk. amazon.com. 2751IN NS pdns1.ultradns.net. ;; Query time: 1 msec ;; SERVER: 216.185.71.33#53(216.185.71.33) ;; WHEN: Wed May 6 09:54:00 2015 ;; MSG SIZE rcvd: 600 And thanks for the correction. I had never run into MS's Sender ID in the wild before and had no recollection of its existence until you reminded me. One more thing to look for. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via 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: Is this a result of reject_unknown_sender_domain ?
On Wed, April 29, 2015 22:26, Viktor Dukhovni wrote:
The fact that the same name fails HELO checks (which don't use the
default suffixes) is not unexpected.
Actually, my suspicion was that this was a case of cause and effect.
The reject due to the host name lookup failure was the result of the
process that was generating the additional dns queries. I just want
to find out if the behaviour is expected or abnormal.
I presume that there is some setting in Postfix that governs this
behaviour and I would like to discover what that is, if indeed one
exists.
I discovered:
smtp_dns_resolver_options (default: empty)
and these
smtp_dns_support_level = dnssec
smtp_host_lookup = dns
But none of these seem to control the appending of our local search
domains to incoming smtp traffic from external network addresses. I
am perplexed as to why this behaviour occurs at all for that
circumstance.
postconf -n
alias_maps = hash:/etc/aliases
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
ddd $daemon_directory/$process_name $process_id sleep 5
delay_warning_time = 30m
disable_vrfy_command = yes
header_checks = regexp:/etc/postfix/header_checks.regexp
home_mailbox = Maildir/
html_directory = no
ignore_mx_lookup_error = no
inet_interfaces = localhost, inet08.hamilton.harte-lyne.ca
inet_protocols = all
local_transport = smtp
mail_spool_directory = /var/spool/mail
mailman_destination_recipient_limit = 1
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 2048
milter_default_action = accept
milter_protocol = 2
mydestination =
mynetworks = 216.185.71.0/26, 209.47.176.0/26, 127.0.0.0/8
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = $smtpd_milters
policyd-spf_time_limit = 3600
queue_minfree = 4096
rbl_reply_maps = hash:/etc/postfix/rbl_reply
readme_directory = /usr/share/doc/postfix-2.11.1/README_FILES
recipient_delimiter = +
relay_clientcerts = hash:/etc/postfix/relay_clientcerts
relay_domains = hash:/etc/postfix/relay_domains
sample_directory = /usr/share/doc/postfix-2.11.1/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_dns_support_level = dnssec
smtp_host_lookup = dns
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtp_tls_cert_file = /etc/pki/tls/certs/ca.harte-lyne.hamilton.smtp.crt
smtp_tls_key_file = /etc/pki/tls/private/ca.harte-lyne.hamilton.smtp.key
smtp_tls_security_level = dane
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtp_tls_session_cache_timeout = 3600s
smtp_use_tls = yes
smtpd_client_restrictions = permit
smtpd_data_restrictions = permit_mynetworks,
reject_multi_recipient_bounce, reject_unauth_pipelining, permit
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, check_helo_access
pcre:/etc/postfix/helo_checks.pcre, reject_non_fqdn_helo_hostname,
reject_unknown_helo_hostname, permit
smtpd_milters = inet:127.0.0.1:8891
smtpd_proxy_timeout = 300s
smtpd_recipient_restrictions = reject_non_fqdn_recipient,
reject_unknown_recipient_domain, permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination,
reject_unauth_pipelining, check_policy_service
unix:/var/spool/postfix/postgrey/socket, check_policy_service
unix:private/policyd-spf, permit
smtpd_relay_restrictions = permit_mynetworks,
permit_sasl_authenticated, defer_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = smtpd
smtpd_sender_restrictions = permit_mynetworks, check_sender_access
hash:/etc/postfix/sender_access, check_sender_mx_access
hash:/etc/postfix/sender_mx_access, check_sender_ns_access
hash:/etc/postfix/sender_ns_access, permit_sasl_authenticated,
reject_non_fqdn_sender, reject_unknown_sender_domain, permit
smtpd_starttls_timeout = ${stress?10}${stress:120}s
smtpd_timeout = ${stress?10}${stress:120}s
smtpd_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtpd_tls_ask_ccert = yes
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/pki/tls/certs/ca.harte-lyne.hamilton.smtp.crt
smtpd_tls_fingerprint_digest = sha1
smtpd_tls_key_file = /etc/pki/tls/private/ca.harte-lyne.hamilton.smtp.key
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
soft_bounce = no
strict_rfc821_envelopes = yes
tls_random_source = dev:/dev/urandom
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/virtual,
regexp:/etc/postfix/virtual.regexp
--
*** e-Mail is NOT a SECURE channel ***
Do NOT transmit sensitive data via e-Mail
James B. Byrnemailto:byrn...@harte-lyne.ca
Harte Lyne Limited http://www.harte
Re: Is this a result of reject_unknown_sender_domain ?
Further on this. Doing the forward and reverse lookups reveals this: ;; QUESTION SECTION: ;133.201.62.95.in-addr.arpa.IN PTR ;; ANSWER SECTION: 133.201.62.95.in-addr.arpa. 106382 IN PTR static-133-201-62-95.ipcom.comunitel.net. ;; AUTHORITY SECTION: 62.95.in-addr.arpa. 106382 IN NS ns.ripe.net. But no A record exists: ;; QUESTION SECTION: ;static-133-201-62-95.ipcom.comunitel.net. IN A ;; AUTHORITY SECTION: ipcom.comunitel.net.10800 IN SOA ns1.comunitel.net. hostmaster.comunitel.net. 2015010200 86400 7200 2592000 172800 It seems to me the return value used by Postfix should be static-133-201-62-95.ipcom.comunitel.net. But instead Postfix appears to use: static-133-201-62-95.ipcom.comunitel.net Where the trailing root (dot) domain returned on the PRT RR is ignored. I believe that it is this omission that leads to the appending of the locally specified resolver search paths. Is this the intended behaviour? If so then why? -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via 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: Is this a result of reject_unknown_sender_domain ?
On Thu, April 30, 2015 11:14, Viktor Dukhovni wrote: Separately, various restrictions like reject_unknown_helo_hostname and reject_unknown_sender_domain, ... use explicit DNS lookups that do disable the search list. Nothing to see here, the DNS queries are not unexpected. I follow that. My point is that in the circumstance that a host identifies itself solely with an IP address then the only manner in which Postfix can obtain the associated domain name is via the PTR RR. Since that must be, by definition, a FQDN then why is the search path in the local resolver involved at all? The issue to me seems to be the trailing dot on the FQDN returned from the PRT RR which then is seemingly ignored. If the dot was retained then the resolver, presumably, would know not to append the local search paths, and thereby eliminate a number of pointless DNS queries and useless log entries. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via 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: Is this a result of reject_unknown_sender_domain ?
On Thu, April 30, 2015 11:28, Viktor Dukhovni wrote: There is no trailing dot. Postfix gets a name from getnameinfo() which it passes for forward checking to getaddrinfo(). Whether the C-library is doing any DNS under the covers is up to the C- library. The name returned by getnameinfo() could have come from /etc/hosts, NIS, LDAP, ... Thank you. I now understand, somewhat. I think. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via 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
Is this a result of reject_unknown_sender_domain ?
I am seeing these in my maillog: /var/log/maillog Apr 29 15:17:15 inet08 postfix-p25/smtpd[18108]: NOQUEUE: reject: RCPT from unknown[95.62.201.133]: 450 4.7.1 static-133-201-62-95.ipcom.comunitel.net: Helo command rejected: Host not found; from= to=owner-pac...@halisp.net proto=SMTP helo=static-133-201-62-95.ipcom.comunitel.net And these in my dns query log: /var/log/dnsquery.log static-133-201-62-95.ipcom.comunitel.net static-133-201-62-95.ipcom.comunitel.net.hamilton.harte-lyne.ca static-133-201-62-95.ipcom.comunitel.net.harte-lyne.ca static-133-201-62-95.ipcom.comunitel.net.mississauga.harte-lyne.ca I would like to confirm that the last three oddball dns lookups are somehow related to postfix's sender restrictions that I have configured, reproduced herein: smtpd_sender_restrictions = permit_mynetworks, check_sender_access hash:/etc/postfix/sender_access, check_sender_mx_access hash:/etc/postfix/sender_mx_access, check_sender_ns_access hash:/etc/postfix/sender_ns_access, permit_sasl_authenticated, reject_non_fqdn_sender, reject_unknown_sender_domain, permit And if so then I would appreciate having the exact process explained to me as well. I can guess at what is going on but I would prefer certain knowledge if available. /etc/resolv.conf . . . search harte-lyne.ca hamilton.harte-lyne.ca mississauga.harte-lyne.ca And if not then can anyone suggest to what is happening? Have I misconfigured something? -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via 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
