View previous topic :: View next topic |
Author |
Message |
jankom Guru
Joined: 30 Aug 2021 Posts: 364 Location: USA
|
Posted: Wed Mar 13, 2024 8:24 pm Post subject: postfix cannot receive emai [SOLVED] |
|
|
wrong version number:../openssl-3.0.12/ssl/record/ssl3_record.c:354
My postfix mailserver has been working fine but recently did an eix-sync and now I cannot receive email from the outside world. Sending mail with claws, sendmail or telnet works, but even if I do a telnet - STARTTLS session test email sent to myself the email is not delivered. Here is a relevant section of /var/log/mail.log: Code: | Mar 13 15:26:45 localhost postfix/smtpd[5007]: disconnect from localhost[127.0.0.1] ehlo=1 starttls=1 mail=1/2 rcpt=2/3 data=1 quit=1 commands=7/9
Mar 13 15:26:56 localhost postfix/smtpd[4989]: SSL_accept error from unknown[10.100.0.1]: -1
Mar 13 15:26:56 localhost postfix/smtpd[4989]: warning: TLS library problem: error:0A00010B:SSL routines::wrong version number:../openssl-3.0.12/ssl/record/ssl3_record.c:354:
Mar 13 15:26:56 localhost postfix/smtpd[4989]: lost connection after STARTTLS from unknown[10.100.0.1]
Mar 13 15:26:56 localhost postfix/smtpd[4989]: disconnect from unknown[10.100.0.1] ehlo=1/2 starttls=0/1 commands=1/3
| Note: 10.100.0.1 is the vpn connected remote machine having public IP with some ports forwarded to the local machine for operation of the mailserver on the local machine.
I have been working on debugging this for two days now and finally turned to this community for help.
jankom
Last edited by jankom on Sat Apr 06, 2024 10:25 pm; edited 3 times in total |
|
Back to top |
|
|
grknight Retired Dev
Joined: 20 Feb 2015 Posts: 1921
|
Posted: Wed Mar 13, 2024 8:42 pm Post subject: |
|
|
This looks like a client is trying to connect with something less than TLS1.2 which will fail with OpenSSL-3 by default.
Telnet cannot do TLS (unless there's something new I don't know about), but openssl s_client can. |
|
Back to top |
|
|
jankom Guru
Joined: 30 Aug 2021 Posts: 364 Location: USA
|
Posted: Wed Mar 13, 2024 9:26 pm Post subject: |
|
|
Quote: | Telnet cannot do TLS | Yes. I did STARTTLS in telnet then continued telnet session in another terminal with openssl s_client. Sending message to the outside world is OK. But when responding back from the outside fails because of the "wrong version" and message is not accepted. |
|
Back to top |
|
|
grknight Retired Dev
Joined: 20 Feb 2015 Posts: 1921
|
Posted: Wed Mar 13, 2024 9:59 pm Post subject: |
|
|
jankom wrote: | Quote: | Telnet cannot do TLS | Yes. I did STARTTLS in telnet then continued telnet session in another terminal with openssl s_client. |
This is very strange to me. s_client replaces telnet for a TLS connection. I don't see how it would be possible to attach to an existing STARTTLS when s_client will send it all over again.
If I was testing, then I would use: openssl s_client -connect <mail server>:587 -starttls smtp or similar (filling in the server address as well)
There is no need for a second terminal.
Also, check your postfix config so that no TLS settings are set too low. |
|
Back to top |
|
|
freke Veteran
Joined: 23 Jan 2003 Posts: 1029 Location: Somewhere in Denmark
|
Posted: Thu Mar 14, 2024 9:33 am Post subject: |
|
|
I see that a few times a month on my server - for me it's mostly scanners it seems (stretchoid.com)
(And I disable anything below TLSv1.2 in main.cf)
I usually use https://www.checktls.com/TestReceiver to test my setup when changing configs/setup etc. |
|
Back to top |
|
|
jankom Guru
Joined: 30 Aug 2021 Posts: 364 Location: USA
|
Posted: Thu Mar 14, 2024 2:08 pm Post subject: Thank you both |
|
|
@ grknight: Quote: | s_client replaces telnet for a TLS connection | Yes. Sorry about that. I have no experience with telnet. Internet search suggested to test my email server with telnet session. However, it would only connect with STARTTLS. The internet search then suggested to use the openssl s_client method to continue. This is part of my learning curve.
@freke: the "checktls" test showed only Code: | [005.469] STARTTLS command works on this server
[005.620] Connection converted to SSL
SSLVersion in use: TLSv1_3
Cipher in use: TLS_AES_256_GCM_SHA384
Perfect Forward Secrecy: yes
Session Algorithm in use: Curve X25519 DHE(253 bits)
Certificate #1 of 1 (sent by MX):
Cert VALIDATION ERROR(S): unable to get local issuer certificate
This may help: What Is An Intermediate Certificate
So email is encrypted but the recipient domain is not verified
Cert Hostname VERIFIED (andraslinux.jgklinux.jankom.net = andraslinux.jgklinux.jankom.net | DNS:andraslinux.jgklinux.jankom.net)
Not Valid Before: Jan 29 00:00:00 2024 GMT
Not Valid After: Apr 28 23:59:59 2024 GMT
subject: /CN=andraslinux.jgklinux.jankom.net
issuer: /C=AT/O=ZeroSSL/CN=ZeroSSL RSA Domain Secure Site CA |
As far as my main.cf is concerned there is no line about "TLSv". main.cf.default has several lines showing ">=TLSv1". Shall I include all thes in my main.cf with modification to "TLSv1.2"? Specifically, with lines smtp and smtpd? smtpd is running on my machine, therefore smtpd lines would be sufficient to include in main.cf?
jankom |
|
Back to top |
|
|
freke Veteran
Joined: 23 Jan 2003 Posts: 1029 Location: Somewhere in Denmark
|
Posted: Thu Mar 14, 2024 3:13 pm Post subject: |
|
|
Could it be the 10.100.0.1 machine have openssl-issues? did you update that, too?
It seems CheckTLS connected fine - but unable to verify ssl-cert.
Can also try to add varbose output to smtpd in /etc/postfix/master.cf Code: | # ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (no) (never) (100)
# ==========================================================================
smtp inet n - n - - smtpd -v |
EDIT: Well - the verbose output doesn't seem to give much SSL/TLS info really - at least not with my test just now.
Last edited by freke on Thu Mar 14, 2024 3:26 pm; edited 1 time in total |
|
Back to top |
|
|
grknight Retired Dev
Joined: 20 Feb 2015 Posts: 1921
|
Posted: Thu Mar 14, 2024 3:22 pm Post subject: |
|
|
freke wrote: | It seems CheckTLS connected fine - but unable to verify ssl-cert. |
Not being able to verify the certificate for mail is fine. Transfer of mail is still done encrypted.
Verified certs are only required if your policies dictate that clients are known and must be trusted with a matching certificate. |
|
Back to top |
|
|
freke Veteran
Joined: 23 Jan 2003 Posts: 1029 Location: Somewhere in Denmark
|
Posted: Thu Mar 14, 2024 3:27 pm Post subject: |
|
|
grknight wrote: | freke wrote: | It seems CheckTLS connected fine - but unable to verify ssl-cert. |
Not being able to verify the certificate for mail is fine. Transfer of mail is still done encrypted.
Verified certs are only required if your policies dictate that clients are known and must be trusted with a matching certificate. |
Indeed - forgot to add that this wasn't really an error |
|
Back to top |
|
|
freke Veteran
Joined: 23 Jan 2003 Posts: 1029 Location: Somewhere in Denmark
|
Posted: Thu Mar 14, 2024 3:36 pm Post subject: |
|
|
You can also try to change the output-format on the CheckTLS-site to SSLDetail or Debug to see if that reveals more.
A standard Detail-output on my hosts just gives this Code: | seconds lookup result
[000.000] DNS LOOKUPS
[000.001] SEARCHLIST 168.63.129.16,1.1.1.1,8.8.8.8
[000.598] MX-->vlh.dk (10) mail.vlh.dk
[000.976] MX:A-->mail.vlh.dk 212.237.179.56
seconds test stage and result
[000.000] Trying TLS on mail.vlh.dk[212.237.179.56:25] (10)
[000.126] Server answered
[000.418] <‑‑ 220 mail.vlh.dk ESMTP NO UCE
[000.419] We are allowed to connect
[000.419] ‑‑> EHLO www12-azure.checktls.com
[000.544] <‑‑ 250-mail.vlh.dk
250-PIPELINING
250-SIZE 41943040
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING
[000.545] We can use this server
[000.545] TLS is an option on this server
[000.545] ‑‑> STARTTLS
[000.747] <‑‑ 220 2.0.0 Ready to start TLS
[000.748] STARTTLS command works on this server
[001.216] Connection converted to SSL
SSLVersion in use: TLSv1_3
Cipher in use: TLS_AES_256_GCM_SHA384
Perfect Forward Secrecy: yes
Session Algorithm in use: Curve X25519 DHE(253 bits)
Certificate #1 of 3 (sent by MX):
Cert VALIDATED: ok
Cert Hostname VERIFIED (mail.vlh.dk = *.vlh.dk | DNS:*.vlh.dk | DNS:vlh.dk)
Not Valid Before: Jun 26 15:50:32 2023 GMT
Not Valid After: Jul 27 15:50:31 2024 GMT
subject: /CN=*.vlh.dk
issuer: /C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G4
Certificate #2 of 3 (sent by MX):
Cert VALIDATED: ok
Not Valid Before: Oct 12 03:49:43 2022 GMT
Not Valid After: Oct 12 00:00:00 2027 GMT
subject: /C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G4
issuer: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
Certificate #3 of 3 (sent by MX, also in CA Root Store):
Cert VALIDATED: ok
Not Valid Before: Sep 1 12:00:00 1998 GMT
Not Valid After: Jan 28 12:00:00 2028 GMT
subject: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
issuer: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
[002.335] ~~> EHLO www12-azure.checktls.com
[002.461] <~~ 250-mail.vlh.dk
250-PIPELINING
250-SIZE 41943040
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING
[002.462] TLS successfully started on this server
[002.462] ~~> MAIL FROM:<test@checktls.com>
[002.622] <~~ 250 2.1.0 Ok
[002.622] Sender is OK
[002.622] ~~> QUIT
[002.748] <~~ 221 2.0.0 Bye | versus a SSLDetail run that gives 'a bit' more info on the SSL/TLS steps Code: | [000.508] ‑‑> EHLO www12-azure.checktls.com
[000.633] <‑‑ 250-mail.vlh.dk
250-PIPELINING
250-SIZE 41943040
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING
[000.634] We can use this server
[000.634] TLS is an option on this server
[000.634] ‑‑> STARTTLS
[000.759] <‑‑ 220 2.0.0 Ready to start TLS
[000.759] STARTTLS command works on this server
ssl : new ctx 94325344095216
: don't start handshake: IO::Socket::SSL=GLOB(0x55c9d4bcdc60)
: ssl handshake not started
: using SNI with hostname mail.vlh.dk
: set socket to non-blocking to enforce timeout=30
: call Net::SSLeay::connect
: done Net::SSLeay::connect -> -1
: ssl handshake in progress
: waiting for fd to become ready: SSL wants a read first
: socket ready, retrying connect
: call Net::SSLeay::connect
: done Net::SSLeay::connect -> -1
: ssl handshake in progress
: waiting for fd to become ready: SSL wants a read first
: socket ready, retrying connect
: call Net::SSLeay::connect
: done Net::SSLeay::connect -> -1
: ssl handshake in progress
: waiting for fd to become ready: SSL wants a read first
: socket ready, retrying connect
: call Net::SSLeay::connect
: done Net::SSLeay::connect -> -1
: ssl handshake in progress
: waiting for fd to become ready: SSL wants a read first
: socket ready, retrying connect
: call Net::SSLeay::connect
: ok=1 [2] /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
: ok=1 [1] /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G4
: ok=1 [0] /C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G4/CN=*.vlh.dk
: done Net::SSLeay::connect -> 1
: ssl handshake done
[001.078] Connection converted to SSL
SSLVersion in use: TLSv1_3
Cipher in use: TLS_AES_256_GCM_SHA384
Perfect Forward Secrecy: yes
Session Algorithm in use: Curve X25519 DHE(253 bits)
Certificate #1 of 3 (sent by MX):
Cert VALIDATED: ok
ssl : scheme=smtp cert=94325347943392
: identity=mail.vlh.dk cn=*.vlh.dk alt=2 *.vlh.dk 2 vlh.dk
Cert Hostname VERIFIED (mail.vlh.dk = *.vlh.dk | DNS:*.vlh.dk | DNS:vlh.dk)
cert not revoked by OCSP
Data:
Version: 3 (0x2)
Serial Number: 5e:84:a1:42:75:4f:f4:8f:6b:fb:c1:e4
Validity:
Not Before: Jun 26 15:50:32 2023 GMT
Not After: Jul 27 15:50:31 2024 GMT
Subject:
commonName = *.vlh.dk
Issuer:
countryName = BE
organizationName = GlobalSign nv-sa
commonName = AlphaSSL CA - SHA256 - G4
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public Key Bits: (4096 bit)
Modulus:
... |
|
|
Back to top |
|
|
jankom Guru
Joined: 30 Aug 2021 Posts: 364 Location: USA
|
Posted: Thu Mar 14, 2024 4:01 pm Post subject: |
|
|
Yes, 10.100.0.1 has the same openssl-3.0.12 as my home mailserver.
Added Code: | # line 787 chenged from TLSv1
smtpd_tls_protocols = >=TLSv1.2
| to main.cf but still unable to receive from outside world.
I can send email with openssls_client using email my email account in the outside world as "mail from" command, and the mail is being delivered. However message sent from that outside account is not belivered. Code: | Mar 14 11:42:58 localhost postfix/smtpd[2910]: 3E27B4013F: client=unknown[10.100.0.1]
Mar 14 11:43:49 localhost postfix/smtpd[2885]: timeout after EHLO from unknown[10.100.0.1]
Mar 14 11:43:49 localhost postfix/smtpd[2885]: disconnect from unknown[10.100.0.1] ehlo=2 starttls=1 commands=3
Mar 14 11:45:32 localhost postfix/smtpd[2907]: timeout after EHLO from unknown[10.100.0.1]
Mar 14 11:45:32 localhost postfix/smtpd[2907]: disconnect from unknown[10.100.0.1] ehlo=2 starttls=1 commands=3
Mar 14 11:46:26 localhost postfix/smtpd[2907]: connect from unknown[10.100.0.1]
Mar 14 11:46:46 localhost postfix/smtpd[2942]: connect from unknown[10.100.0.1]
Mar 14 11:46:47 localhost postfix/smtpd[2942]: A8B4C401D4: client=unknown[10.100.0.1]
Mar 14 11:47:58 localhost postfix/smtpd[2910]: timeout after RCPT from unknown[10.100.0.1]
Mar 14 11:47:58 localhost postfix/smtpd[2910]: disconnect from unknown[10.100.0.1] ehlo=2 starttls=1 mail=1 rcpt=1 commands=5
| It looks like a "timeout" issue is preventing from receiving messages from the outside world. The "11:46:47" line refers to a message sent from a gmail account.
OK, I'll increase smtpd verbosity and report back later.
Thanks again for your interest in helping to solve this problem.
jankom |
|
Back to top |
|
|
freke Veteran
Joined: 23 Jan 2003 Posts: 1029 Location: Somewhere in Denmark
|
Posted: Thu Mar 14, 2024 6:16 pm Post subject: |
|
|
IIRC multiple -v can be added for increased verbosity if needed.
(and remember to reload with postfix reload ) |
|
Back to top |
|
|
jankom Guru
Joined: 30 Aug 2021 Posts: 364 Location: USA
|
Posted: Thu Mar 14, 2024 6:20 pm Post subject: New direction - getting closer? |
|
|
Verbose mail.log indicates some troubling signs (excerpt): Code: | Mar 14 13:20:54 localhost postfix/smtpd[2340]: connect from unknown[10.100.0.1]
Mar 14 13:20:54 localhost postfix/smtpd[2340]: match_list_match: unknown: no match
Mar 14 13:20:54 localhost postfix/smtpd[2340]: match_list_match: 10.100.0.1: no match
Mar 14 13:20:54 localhost postfix/smtpd[2340]: match_list_match: unknown: no match
Mar 14 13:20:54 localhost postfix/smtpd[2340]: match_list_match: 10.100.0.1: no match
Mar 14 13:20:54 localhost postfix/smtpd[2340]: match_hostname: smtpd_forbid_bare_newline_exclusions: unknown ~? 127.0.0.0/8
Mar 14 13:20:54 localhost postfix/smtpd[2340]: match_hostaddr: smtpd_forbid_bare_newline_exclusions: 10.100.0.1 ~? 127.0.0.0/8
| while route-n of the remote machine (that has the public ip and ovpn tunneled into): Code: | Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 198.74.55.1 0.0.0.0 UG 2 0 0 eth0
10.100.0.0 10.100.0.2 255.255.255.0 UG 0 0 0 tun0
10.100.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
198.74.55.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
| and output of ovpn connect message: Code: | 2024-03-14 13:16:09 net_iface_up: set tun0 up
2024-03-14 13:16:09 net_addr_ptp_v4_add: 10.100.0.6 peer 10.100.0.5 dev tun0
2024-03-14 13:16:09 /etc/openvpn/up.sh tun0 1500 0 10.100.0.6 10.100.0.5 init
2024-03-14 13:16:09 Initialization Sequence Completed
| What is confusing to me is 10.100.0.1 vs. 10.100.0.2 vs. 10.100.0.5.
ovpn and openssl were updated on both the remote and local machine with eix-sync.
Could it be that the update confused my network settings thus preventing mailserver receiving messages? Sinc I'm just a retired linux enthusiast I'm not that knowledgeable in network dynamics, just searching around for clues.
jankom |
|
Back to top |
|
|
jankom Guru
Joined: 30 Aug 2021 Posts: 364 Location: USA
|
Posted: Mon Mar 18, 2024 9:08 pm Post subject: I'm not giving up |
|
|
(1) openssl verify <my email server> fails because of no intermediate certificate, but could not fix it even after re-issuing acme certificates. Howver:
(2) I can receive emails sent from an openssl -s_clien session started from an outside computer. I think my email server acts as a relay here and delivers the DATA to my own account on the mailserver.
(3) Sending mail from an email account on an outside mailserver (gmail ,etc) is not delivered. After resetting back master.cf of postfix no non-verbose smtp logging I get this log from a mail sent on 15:52:30 Code: | Mar 18 15:52:47 localhost postfix/smtpd[2647]: connect from unknown[10.100.0.1]
Mar 18 15:56:10 localhost postfix/smtpd[2738]: connect from unknown[10.100.0.1]
Mar 18 15:56:10 localhost postfix/smtpd[2738]: improper command pipelining after CONNECT from unknown[10.100.0.1]: EHLO apzg-0721-a-021\r\n
Mar 18 15:56:14 localhost postfix/smtpd[2738]: lost connection after EHLO from unknown[10.100.0.1]
Mar 18 15:56:14 localhost postfix/smtpd[2738]: disconnect from unknown[10.100.0.1] ehlo=1 commands=1
Mar 18 15:57:49 localhost postfix/smtpd[2647]: timeout after EHLO from unknown[10.100.0.1]
Mar 18 15:57:49 localhost postfix/smtpd[2647]: disconnect from unknown[10.100.0.1] ehlo=2 starttls=1 commands=3
| Apparently the foreign mailserver contacted my postfix/dovecot 17 seconds later, but interrupted delivery of the message after about 5 minutes. My interpretation
(3-a) TLS connection was made
(3-b) "improper command pipelining..." - what is that?
10.100.0.1 is the server on the other end of the vpn and having a public IP.
So what is EHLO apzg-071...? Is that some kind of an encrypted name of the foreign mailserver. Sending out mail works, no problem, just receiving from a foreign mailserver is dead.
Everything seemed to work for years and months until recently when I did eix-sync on both ends of the pvn.
Just FYI if it sparks some ideas - thanks
jankom |
|
Back to top |
|
|
freke Veteran
Joined: 23 Jan 2003 Posts: 1029 Location: Somewhere in Denmark
|
Posted: Tue Mar 19, 2024 6:16 pm Post subject: Re: I'm not giving up |
|
|
jankom wrote: | (3-b) "improper command pipelining..." - what is that? |
Postfix was recently updated to prevent pipelining some data to prevent injecting ie. smtp-commands.
Code: | [A longer and updated version of this text may be found at https://www.postfix.org/smtp-smuggling.html]
SUMMARY
As part of a non-responsible disclosure process, SEC Consult has published an email spoofing attack that involves a composition of email services with specific differences in the way they handle line endings other than <CR><LF>.
DETAILS AND IMPACT
See https://www.postfix.org/smtp-smuggling.html
SHORT-TERM WORKAROUNDS
A short-term workaround can be deployed now, before the upcoming long holiday and associated production change freeze.
NOTE: This will stop only the published form of the attack. Other forms exist that will not be stopped in this manner.
* With all Postfix versions, "smtpd_data_restrictions =
reject_unauth_pipelining" will stop the published exploit.
* Postfix 3.9 (stable release expected early 2024), rejects unauthorised
pipelining by default: "smtpd_forbid_unauth_pipelining = yes".
* Postfix 3.8.1, 3.7.6, 3.6.10 and 3.5.20 include the same feature,
but the "smtpd_forbid_unauth_pipelining" parameter defaults to "no".
Compatibility: the setting "smtpd_forbid_unauth_pipelining = yes" or "smtpd_data_restrictions = reject_unauth_pipelining" may break legitimate SMTP clients that mis-implement SMTP, but such clients are exceedingly rare, especially when email is sent across the Internet.
LONG-TERM FIX
A long-term fix is being validated. This stops all forms of the smuggling attacks. For many sites, this will be ready too late for deployment before a long holiday break, when typically production changes are not allowed until January.
TIMELINE
* Dec 18 SEC Consult publishes an attack that involves the composition
of two different email service behaviors.
* Dec 19 Research and implement a fix for Postfix, start testing
and Q/A.
* Dec 20 Draft this response document at
https://www.postfix.org/smtp-smuggling.html.
* TBD: Publish updated source code releases for stable Postfix versions
3.8.4, 3.7.9, 3.6.13, 3.5.23.
* TBD: OSS distributions publish updated packages for Postfix versions
3.8.4, 3.7.9, 3.6.13, 3.5.23.
* Dec 22: last day before a 10+ day holiday break, start of production
change freezes until early January.
REFERENCES
https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-leave@postfix.org |
Quote: | 10.100.0.1 is the server on the other end of the vpn and having a public IP.
So what is EHLO apzg-071...? Is that some kind of an encrypted name of the foreign mailserver. Sending out mail works, no problem, just receiving from a foreign mailserver is dead.jankom |
Code: | EHLO apzg-0721-a-021\r\n | would be what the host (10.100.0.1) sends as it's hostname, the \r\n part seems wrong and might be what is triggering the pipelining prevention/disconnection? |
|
Back to top |
|
|
jankom Guru
Joined: 30 Aug 2021 Posts: 364 Location: USA
|
Posted: Wed Mar 20, 2024 5:07 pm Post subject: |
|
|
Thanks, freke.
Quote: | the \r\n part seems wrong | is probably a red herring, a misleading output of the verbose logging. The \r\n part reminds me of the AINSI-C quoting method . The outside mail server succeede TLS connection and starts the "telnet" session with ehlo <server name> <RETURN> as I do in a successful openssl s-client... session. I'm posting outputs of the "telnet" session sending email from my laptop to my mailserver and receiving it correctly. The server name and email accounts redacted. Code: | Start Time: 1710883375
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
ehlo acerlinux
250-<my postfix mailserver>
250-PIPELINING
250-SIZE 30720000
250-VRFY
250-ETRN
250-AUTH PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING
mail from: foo@gmail.com
250 2.1.0 Ok
rcpt to: foo@<my postfix mailserver>
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
testing from laptop
.
250 2.0.0 Ok: queued as 733D2813A8
quit
221 2.0.0 Bye
closed
janos@acerlinux:~/Desktop$
Mar 19 17:22:54 andraslinux postfix/smtpd[2258]: connect from unknown[10.100.0.1]
Mar 19 17:25:41 andraslinux postfix/smtpd[2258]: 733D2813A8: client=unknown[10.100.0.1]
Mar 19 17:25:55 andraslinux postfix/cleanup[2265]: 733D2813A8: message-id=<>
Mar 19 17:25:55 andraslinux postfix/qmgr[1877]: 733D2813A8: from=<foo@gmail.com>, size=230, nrcpt=1 (queue active)
Mar 19 17:25:55 andraslinux postfix/local[2266]: 733D2813A8: to=<foo@<my postfix mailserver>>, relay=local, delay=91, delays=91/0.02/0/0, dsn=2.0.0, status=sent (delivered to mailbox)
Mar 19 17:25:55 andraslinux postfix/qmgr[1877]: 733D2813A8: removed
Mar 19 17:26:03 andraslinux postfix/smtpd[2258]: disconnect from unknown[10.100.0.1] ehlo=2 starttls=1 mail=1/2 rcpt=1 data=1 quit=1 unknown=0/1 commands=7/9
Received: from acerlinux (unknown [10.100.0.1])
by <my postfix mailserver> (Postfix) with ESMTPS id 733D2813A8
for <foo@<my postfix mailserver>>; Tue, 19 Mar 2024 17:24:24 -0400 (EDT)
testing from laptop
| I studied your post and the update notes and modified my settings, but it is still not working. Here is the log file (not verbose) Code: | Mar 20 11:45:31 andraslinux dovecot: master: Dovecot v2.3.20 (80a5ac675d) starting up for imap, pop3, lmtp (core dumps disabled)
Mar 20 11:45:31 andraslinux postfix[1797]: Postfix is using backwards-compatible default settings
Mar 20 11:45:31 andraslinux postfix[1797]: See http://www.postfix.org/COMPATIBILITY_README.html for details
Mar 20 11:45:31 andraslinux postfix[1797]: To disable backwards compatibility use "postconf compatibility_level=3.6" and "postfix reload"
Mar 20 11:45:32 andraslinux postfix/postfix-script[1876]: starting the Postfix mail system
Mar 20 11:45:32 andraslinux postfix/master[1878]: daemon started -- version 3.8.4, configuration /etc/postfix
Mar 20 11:47:42 andraslinux postfix/smtpd[2263]: connect from unknown[10.100.0.1]
Mar 20 11:47:43 andraslinux postfix/smtpd[2263]: 71E7F813A8: client=unknown[10.100.0.1]
Mar 20 11:51:36 andraslinux postfix/smtpd[2439]: connect from unknown[10.100.0.1]
Mar 20 11:51:52 andraslinux postfix/smtpd[2439]: warning: unknown[10.100.0.1]: SASL PLAIN authentication failed: (reason unavailable), sasl_username=mail@synovacarpets.com
Mar 20 11:51:53 andraslinux postfix/smtpd[2439]: lost connection after AUTH from unknown[10.100.0.1]
Mar 20 11:51:53 andraslinux postfix/smtpd[2439]: disconnect from unknown[10.100.0.1] ehlo=2 starttls=1 auth=0/1 commands=3/4
Mar 20 11:52:00 andraslinux postfix/smtpd[2439]: connect from unknown[10.100.0.1]
Mar 20 11:52:16 andraslinux postfix/smtpd[2439]: warning: unknown[10.100.0.1]: SASL PLAIN authentication failed: (reason unavailable), sasl_username=mail
Mar 20 11:52:17 andraslinux postfix/smtpd[2439]: lost connection after AUTH from unknown[10.100.0.1]
Mar 20 11:52:17 andraslinux postfix/smtpd[2439]: disconnect from unknown[10.100.0.1] ehlo=2 starttls=1 auth=0/1 commands=3/4
Mar 20 11:52:43 andraslinux postfix/smtpd[2263]: timeout after DATA (0 bytes) from unknown[10.100.0.1]
Mar 20 11:52:43 andraslinux postfix/smtpd[2263]: disconnect from unknown[10.100.0.1] ehlo=2 starttls=1 mail=1 rcpt=1 data=0/1 commands=5/6
Mar 20 11:57:16 andraslinux dovecot: imap-login: Disconnected: Connection closed (no auth attempts in 1 secs): user=<>, rip=10.100.0.1, lip=10.100.0.6, TLS, session=<k6sUpRkUfk4KZAAB>
Mar 20 12:00:05 andraslinux postfix/smtpd[2460]: connect from unknown[10.100.0.1]
Mar 20 12:00:06 andraslinux postfix/smtpd[2460]: 83AA9813A8: client=unknown[10.100.0.1]
Mar 20 12:05:06 andraslinux postfix/smtpd[2460]: timeout after DATA (0 bytes) from unknown[10.100.0.1]
Mar 20 12:05:06 andraslinux postfix/smtpd[2460]: disconnect from unknown[10.100.0.1] ehlo=2 starttls=1 mail=1 rcpt=1 data=0/1 commands=5/6
Mar 20 12:05:50 andraslinux postfix/smtpd[2460]: connect from unknown[10.100.0.1]
Mar 20 12:06:19 andraslinux postfix/smtpd[2460]: lost connection after EHLO from unknown[10.100.0.1]
Mar 20 12:06:19 andraslinux postfix/smtpd[2460]: disconnect from unknown[10.100.0.1] ehlo=1/2 starttls=1 commands=2/3 |
Theis what I observe/conclude:
(1) SASL PLAIN connections refused, as it should be from spam (mail@synovacarpets.com) or (mail)
(2) Test mail attempting to deliver from outside mail server (foo@fmail.com) connects successfully. at 12:00:05
but
(3) transmits nothing after the DATA command in "telnet" session.
(4) Disconnets after 5 minutes of waiting.
I tested that with openssl s_client... session: after issuing DATA and doing nothing - the "telnet" session disconnects after 5 minuts.
So I think my mail server does not want to receive DATA stream from the foreign mailserver.
This is where I'm at, for now.
jankom |
|
Back to top |
|
|
jankom Guru
Joined: 30 Aug 2021 Posts: 364 Location: USA
|
Posted: Sat Apr 06, 2024 10:24 pm Post subject: solved |
|
|
Finally my pstfix/dovecot mailserver works again, receiving emails from foreign mailservers. "foreign" means any other mailserver on the Internet.
Lessons learned, what was the problem? Unfortunately, not exactly sure. Nvertheless, created backups of configuration files for future reference in similar situations.
My best guess is that the root cause was eix-sync on February 26. This created some ._...* configuration file changes that I duely executed. However, part of the system update was an updated version of postfix. The updated version requires TLSv1.2 or newer. This was already a requirement in dovecot, but not in postfix. Also, dovecot documentation indicates that mbox mailbox format is deprecated. This, and confusion about configuration files lead me to frustrating trial and error debugging steps. A frustrating lesson learned was that even an invisable space character put in a wrong place can wrac havoc in the mailserver operation.
1) Configuration confusion: syntax of how the comment (#) character is used.
"#" without "space" character following it implies that it is a default setting, no need to uncomment it. However sometimes there are choices. In that case it is not clear which is the default setting: the first choice, or a choice has to be made explicitely by uncommenting one of those. I don't know who creates these distribution configuration files: gentoo or the source developer. My suggestion is that in such cases put a space character after the comment character, thus indicating that one of the choices need to be uncommented.
2) Confusion - postfix main and master:
main.cf vs main.cf.default vs main.cf.proto
looks like main.cf is similar to main.proto, but main.cf.default has more items. Main .cf.default is a list of all configurable parameters, some having definitions for default, some blank, tut some of the blank items do need entries.
mmaster.cf vs master.cf.proto
different story: master.cf is identical to master.cf.proto and there is no .default version.
3) Confusion Postfix - Gentoo wiki states that main,conf should have "mynetworks_style = host". This does not work in my case. Yes, the same wiki says that "There are means and ways, like SMTP Authentication, that allow to secure access to a mail server even further".
I have also hardened my mailserver because of recommendations of Gentoo Complete Virtual Mailserver web page. Just as an aside: what does it mean "virtual" here?
Yet another question: why are there two submission stanzas in master.cf: one as "submission", he other with "submissions" (plural)? Just curious.
Help and comments in this forum guided me for a better understanding of the mailserver system, thank you grknight and freke for staying with me.
Finally, I show here my configuration settings where they differ from default. I attempted to use default settings as much as possible and logical. Comments are welcome.
Postfix main.cf
Code: | mynetworks_style = class
alias_maps = hash:/etc/mail/aliases
smtpd_banner = $myhostname ESMTP NO UCE
message_size_limit = 30720000
smtpd_sasl_path = private/auth
smtpd_tls_cert_file = /etc/ssl/dovecot/server.pem
smtpd_tls_key_file = /etc/ssl/dovecot/server.key
smtpd_tls_protocols = >=TLSv1.2
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_discard_ehlo_keywords = chunking, silent-discard
smtpd_helo_required = yes
disable_vrfy_command = yes |
Postfix master.cf
Code: | -o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_tls_auth_only=yes
-o smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject |
Dovecot 10-master.conf
Code: | user = postfix
group = postfix
unix_listener /var/spool/postfix/private/auth {
mode = 0666
} |
jankom |
|
Back to top |
|
|
figueroa Advocate
Joined: 14 Aug 2005 Posts: 3005 Location: Edge of marsh USA
|
Posted: Sun Apr 07, 2024 4:01 am Post subject: |
|
|
In my experience, often enough (too often) a postfix update brings with it suggested changes to postfix configuration files, mainly main.cf, that will effectively destroy the user's local mailserver configuration and set many things back to default. This requires careful reading and often tedious editing to keep things working properly. Many times I've just discarded the new configurations without adverse effect. I attend to post-update configuration changes with dispatch-conf. Your mileage may vary.
Glad you have been able to set things back to working. _________________ Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
Back to top |
|
|
|