Re: SSL_accept error from unknown[10.5.2.1]: lost connection

2023-02-08 Thread Wolfgang Paul Rauchholz 
Thank you for the insight.

It helped solving the issue.

Un cordial saludo,
Wolfgang Rauchholz
+34 627 994 977
https://www.linkedin.com/in/wolfgangrauchholz/



On Tue, Feb 7, 2023 at 6:51 PM Wietse Venema  wrote:

> Wolfgang Paul Rauchholz:
> > Hello I run postfix (postfix-3.5.8-4.el8.x86_64) on my Rocky Linux 8.7
> home
> > server
> > I setup postfix and dovecot as a firs step and it seems to be working;
> > meaning I can send and receive mails (I send/returned mail from a gmail
> > account).
> > But I find these error messages in  /var/log/maillog and after
> researching
> > and making changes cannot fix them.
> > I searched on the web and there are many different cases discussed,
> but...
> >
> > Feb  5 03:50:12 home postfix/smtps/smtpd[402300]: SSL_accept error from
> > unknown[10.5.2.1]: lost connection
> > Feb  5 03:50:12 home postfix/smtps/smtpd[402300]: lost connection after
> > CONNECT from unknown[10.5.2.1]
> > Feb  5 03:50:12 home postfix/smtps/smtpd[402300]: disconnect from
> > unknown[10.5.2.1] commands=0/0
>
> This could be a TLS wrappermode mismatch.
>
> Port 587 (submission) should not use TLS wrappermode.
>
> Port 465 (smtps) should use TLS wrappermode.
>
> Port 25 (smtp) should not use TLS wrappermode.
>
> Either the client or the server got this wrong.
>
> Wietse
>

Re: SSL_accept error from unknown[10.5.2.1]: lost connection

2023-02-07 Thread Wietse Venema 
Wolfgang Paul Rauchholz:
> Hello I run postfix (postfix-3.5.8-4.el8.x86_64) on my Rocky Linux 8.7 home
> server
> I setup postfix and dovecot as a firs step and it seems to be working;
> meaning I can send and receive mails (I send/returned mail from a gmail
> account).
> But I find these error messages in  /var/log/maillog and after researching
> and making changes cannot fix them.
> I searched on the web and there are many different cases discussed, but...
> 
> Feb  5 03:50:12 home postfix/smtps/smtpd[402300]: SSL_accept error from
> unknown[10.5.2.1]: lost connection
> Feb  5 03:50:12 home postfix/smtps/smtpd[402300]: lost connection after
> CONNECT from unknown[10.5.2.1]
> Feb  5 03:50:12 home postfix/smtps/smtpd[402300]: disconnect from
> unknown[10.5.2.1] commands=0/0

This could be a TLS wrappermode mismatch.

Port 587 (submission) should not use TLS wrappermode.

Port 465 (smtps) should use TLS wrappermode.

Port 25 (smtp) should not use TLS wrappermode.

Either the client or the server got this wrong.

Wietse

Re: SSL_accept error from unknown[10.5.2.1]: lost connection

2023-02-07 Thread Viktor Dukhovni 
On Tue, Feb 07, 2023 at 05:59:52PM +0100, Wolfgang Paul Rauchholz wrote:

> Feb  5 03:50:12 home postfix/smtps/smtpd[402300]:
>   SSL_accept error from unknown[10.5.2.1]: lost connection
> Feb  5 03:50:12 home postfix/smtps/smtpd[402300]:
>   lost connection after CONNECT from unknown[10.5.2.1]
> Feb  5 03:50:12 home postfix/smtps/smtpd[402300]:
>   disconnect from unknown[10.5.2.1] commands=0/0

Something (was the address actually 10.5.2.1, or did you replace it for
"privacy") connected to the port 465 implicit TLS submission service.
And probably disconnected without even initiating an SSL handshake.

Are any of your authorised devices or users having problems sending
email?  If not, you don't have a problem, except perhaps that the
connection is coming from a private IP address 10.0.0.0/8, which may a
configuration issue on your firewall, external IPs should not be changed
in transit.  Of course this could also be a source that is internal to
your network.

> I do have letsencrypt certificates that seem to be ok (domain
> wo-lar.com) I added this to the /main.cf config file.

These are likely irrelevant.

> Where do I need to start looking?  Thanks for your insights.

Is there an actual problem?  Unless you're concerned about unexpected
connection attempts from a seemingly internal IP, there's nothing to
worry about, port scans and TLS scans are a fact of life on the
internet.  Some (like my DANE survey[1]) are even for the public good,
rather than malicious.

-- 
Viktor.

[1] https://stats.dnssec-tools.org/

Re: SSL_accept error from unknown

2021-10-18 Thread Dominic Raferd 

On 19/10/2021 05:59, Maurizio Caloro wrote:

see today logs "SSL_accept Error", please its this a known issue?
installed Postfix 3.4.14, Openssl 1.1.1d, Debian 10.11.

Oct 19 05:59:18 nmail postfix/smtps/smtpd[32720]: SSL_accept error 
from 232.115.xx.xx.static.ip.windstream.net[40.138.xx.xx]: lost 
connection
Oct 19 06:45:31 nmail postfix/smtps/smtpd[688]: SSL_accept error from 
unknown[192.x.x.x]: -1
Oct 19 06:45:31 nmail postfix/smtps/smtpd[688]: warning: TLS library 
problem: error:1408F10B:SSL routines:ssl3_get_record:wrong version 
number:../ssl/record/ssl3_record.c:332
Yes these are common on our mailservers too, I think they are caused by 
bad SSL/TLS on the sending host (most likely a spammer or hunting for 
SSL/TLS vulnerabilities).

Re: SSL_accept error from other MTA

2017-01-15 Thread Admin Beckspaced 


On 15.01.2017 07:39, Noel Jones wrote:

On 1/14/2017 2:40 AM, Admin Beckspaced wrote:

All other MTA's don't seem to have any problems with TLS / STARTTLS.

What can I do to fix this problem? Let the other MTA know that they
got an issue with their TLS setup?

Thanks & greetings
Becki


If your goal is to get the mail flowing, you can disable STARTTLS
for this particular client by using
http://www.postfix.org/postconf.5.html#smtpd_discard_ehlo_keyword_address_maps

Use a cidr: type map with an entry like:
10.10.10.10  starttls



   -- Noel Jones




I decided to go with this option to keep mail flowing for the moment
being ... also aware that this is just a temporary workaround.

will contact the admin, in the hope that they still use an ancient
exchange server version and are going to update that?

or is there any other option on my site to fix things with this specific
client?

thanks & greetings
Becki

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

Re: SSL_accept error from other MTA

2017-01-14 Thread Noel Jones 
On 1/14/2017 2:40 AM, Admin Beckspaced wrote:
> All other MTA's don't seem to have any problems with TLS / STARTTLS.
> 
> What can I do to fix this problem? Let the other MTA know that they
> got an issue with their TLS setup?
> 
> Thanks & greetings
> Becki


If your goal is to get the mail flowing, you can disable STARTTLS
for this particular client by using
http://www.postfix.org/postconf.5.html#smtpd_discard_ehlo_keyword_address_maps

Use a cidr: type map with an entry like:
10.10.10.10  starttls



  -- Noel Jones

Re: SSL_accept error from other MTA

2017-01-14 Thread Viktor Dukhovni 

> On Jan 14, 2017, at 8:51 AM, Admin Beckspaced  wrote:
> 
> 2017-01-14T14:41:43.183704+01:00 cx20 postfix/smtpd[25337]: initializing the 
> server-side TLS engine
> 2017-01-14T14:41:43.195287+01:00 cx20 postfix/smtpd[25337]: connect from 
> mail.kommunalunternehmen.de[217.6.53.146]
> 2017-01-14T14:41:43.254888+01:00 cx20 postfix/smtpd[25337]: setting up TLS 
> connection from mail.kommunalunternehmen.de[217.6.53.146]
> 2017-01-14T14:41:43.255444+01:00 cx20 postfix/smtpd[25337]: 
> mail.kommunalunternehmen.de[217.6.53.146]: TLS cipher list 
> "aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH"
> 2017-01-14T14:41:43.257024+01:00 cx20 postfix/smtpd[25337]: 
> SSL_accept:before/accept initialization
> 2017-01-14T14:41:43.277843+01:00 cx20 postfix/smtpd[25337]: SSL_accept:SSLv3 
> read client hello A
> 2017-01-14T14:41:43.278453+01:00 cx20 postfix/smtpd[25337]: SSL_accept:SSLv3 
> write server hello A
> 2017-01-14T14:41:43.278829+01:00 cx20 postfix/smtpd[25337]: SSL_accept:SSLv3 
> write certificate A
> 2017-01-14T14:41:43.296343+01:00 cx20 postfix/smtpd[25337]: SSL_accept:SSLv3 
> write key exchange A
> 2017-01-14T14:41:43.297537+01:00 cx20 postfix/smtpd[25337]: SSL_accept:SSLv3 
> write server done A
> 2017-01-14T14:41:43.298112+01:00 cx20 postfix/smtpd[25337]: SSL_accept:SSLv3 
> flush data
> 2017-01-14T14:41:43.313040+01:00 cx20 postfix/smtpd[25337]: SSL_accept:error 
> in SSLv3 read client certificate A
> 2017-01-14T14:41:43.313611+01:00 cx20 postfix/smtpd[25337]: SSL_accept error 
> from mail.kommunalunternehmen.de[217.6.53.146]: Connection reset by peer
> 2017-01-14T14:41:43.313970+01:00 cx20 postfix/smtpd[25337]: lost connection 
> after STARTTLS from mail.kommunalunternehmen.de[217.6.53.146]
> 2017-01-14T14:41:43.314315+01:00 cx20 postfix/smtpd[25337]: disconnect from 
> mail.kommunalunternehmen.de[217.6.53.146]
> 
> I see: SSL_accept:error in SSLv3 read client certificate A
> 
> so does this mean that the other exchange server has a problem with their 
> certificate?

No, if your reported "postconf -n" output matches reality, then your server 
does not
solicit client certificates.  The "read client certificate A" state is 
misleading,
the server actually expects a client key exchange at that point.  A complete 
handshake
log without any client certs looks like:

Jan 14 19:21:48 mournblade postfix/smtpd[12682]: SSL_accept:before/accept 
initialization
Jan 14 19:21:48 mournblade postfix/smtpd[12682]: SSL_accept:SSLv3 read client 
hello A
Jan 14 19:21:48 mournblade postfix/smtpd[12682]: SSL_accept:SSLv3 write server 
hello A
Jan 14 19:21:48 mournblade postfix/smtpd[12682]: SSL_accept:SSLv3 write 
certificate A
Jan 14 19:21:48 mournblade postfix/smtpd[12682]: SSL_accept:SSLv3 write key 
exchange A
Jan 14 19:21:48 mournblade postfix/smtpd[12682]: SSL_accept:SSLv3 write server 
done A
Jan 14 19:21:48 mournblade postfix/smtpd[12682]: SSL_accept:SSLv3 flush data
Jan 14 19:21:48 mournblade postfix/smtpd[12682]: SSL_accept:SSLv3 read client 
certificate A
Jan 14 19:21:48 mournblade postfix/smtpd[12682]: SSL_accept:SSLv3 read client 
key exchange A
Jan 14 19:21:48 mournblade postfix/smtpd[12682]: SSL_accept:SSLv3 read 
certificate verify A
Jan 14 19:21:48 mournblade postfix/smtpd[12682]: SSL_accept:SSLv3 read finished 
A
Jan 14 19:21:48 mournblade postfix/smtpd[12682]: SSL_accept:SSLv3 write session 
ticket A
Jan 14 19:21:48 mournblade postfix/smtpd[12682]: SSL_accept:SSLv3 write change 
cipher spec A
Jan 14 19:21:48 mournblade postfix/smtpd[12682]: SSL_accept:SSLv3 write 
finished A
Jan 14 19:21:48 mournblade postfix/smtpd[12682]: SSL_accept:SSLv3 flush data

> Is the problem on the exchange server site? or is it my postfix server?

Perhaps your 4096-bit RSA certificate signed with SHA2-256 is too modern
for the client software in question.  With a PCAP file of a session, we
could see more data from the TLS server HELLO, perhaps that could yield
a clue, but logs from the sending client would be much more useful, since
it is the one deciding to not continue.

-- 
Viktor.

Re: SSL_accept error from other MTA

2017-01-14 Thread Admin Beckspaced 


On 14.01.2017 14:03, Christian Kivalo wrote:

You could set smtpd_tls_loglevel = 1 and get some more information on the next 
connection attempt.

Without knowing more details i'd say you have no cipher in common, that could 
be when you're dealing with an ancient version of exchange or some crappy 
middlebox.


Thanks for your reply ;)

pushing the tls loglevel to 2 revealed the following in the logs:

2017-01-14T14:41:43.183704+01:00 cx20 postfix/smtpd[25337]: initializing
the server-side TLS engine
2017-01-14T14:41:43.195287+01:00 cx20 postfix/smtpd[25337]: connect from
mail.kommunalunternehmen.de[217.6.53.146]
2017-01-14T14:41:43.254888+01:00 cx20 postfix/smtpd[25337]: setting up
TLS connection from mail.kommunalunternehmen.de[217.6.53.146]
2017-01-14T14:41:43.255444+01:00 cx20 postfix/smtpd[25337]:
mail.kommunalunternehmen.de[217.6.53.146]: TLS cipher list
"aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH"
2017-01-14T14:41:43.257024+01:00 cx20 postfix/smtpd[25337]:
SSL_accept:before/accept initialization
2017-01-14T14:41:43.277843+01:00 cx20 postfix/smtpd[25337]:
SSL_accept:SSLv3 read client hello A
2017-01-14T14:41:43.278453+01:00 cx20 postfix/smtpd[25337]:
SSL_accept:SSLv3 write server hello A
2017-01-14T14:41:43.278829+01:00 cx20 postfix/smtpd[25337]:
SSL_accept:SSLv3 write certificate A
2017-01-14T14:41:43.296343+01:00 cx20 postfix/smtpd[25337]:
SSL_accept:SSLv3 write key exchange A
2017-01-14T14:41:43.297537+01:00 cx20 postfix/smtpd[25337]:
SSL_accept:SSLv3 write server done A
2017-01-14T14:41:43.298112+01:00 cx20 postfix/smtpd[25337]:
SSL_accept:SSLv3 flush data
2017-01-14T14:41:43.313040+01:00 cx20 postfix/smtpd[25337]:
SSL_accept:error in SSLv3 read client certificate A
2017-01-14T14:41:43.313611+01:00 cx20 postfix/smtpd[25337]: SSL_accept
error from mail.kommunalunternehmen.de[217.6.53.146]: Connection reset
by peer
2017-01-14T14:41:43.313970+01:00 cx20 postfix/smtpd[25337]: lost
connection after STARTTLS from mail.kommunalunternehmen.de[217.6.53.146]
2017-01-14T14:41:43.314315+01:00 cx20 postfix/smtpd[25337]: disconnect
from mail.kommunalunternehmen.de[217.6.53.146]

I see: SSL_accept:error in SSLv3 read client certificate A

so does this mean that the other exchange server has a problem with
their certificate?
Is the problem on the exchange server site? or is it my postfix server?

thanks & greetings
Becki


---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

Re: SSL_accept error from other MTA

2017-01-14 Thread Christian Kivalo 


Am 14. Jänner 2017 09:40:22 MEZ schrieb Admin Beckspaced :
>Dear postfix users,
>
>I'm running Postfix version 2.11.6 on an OpenSUSE 42.1 box and all is
>running sweet & fine ;)
>Except a customer calls me that he can't receive emails from one of his
>partners.
>
>After looking for the partner email I found those log entries:
>
>2017-01-14T00:31:28.312121+01:00 cx20 postfix/smtpd[12579]: connect
>from
>mail.kommunalunternehmen.de[217.6.53.146]
>2017-01-14T00:31:28.419190+01:00 cx20 postfix/smtpd[12579]: SSL_accept
>error from mail.kommunalunternehmen.de[217.6.53.146]: Connection reset
>by peer
>2017-01-14T00:31:28.420304+01:00 cx20 postfix/smtpd[12579]: lost
>connection after STARTTLS from
>mail.kommunalunternehmen.de[217.6.53.146]
>2017-01-14T00:31:28.420870+01:00 cx20 postfix/smtpd[12579]: disconnect
>from mail.kommunalunternehmen.de[217.6.53.146]
>
>and those log entries repeat and repeat. From what I can also see in
>the
>logs it seems to be an exchange mail server:
>
>2017-01-13T14:17:55.649227+01:00 cx20 postfix/cleanup[3703]:
>960DA1A198A:
>message-id=<96C90C91ED31E24D8985DCEF2658CA0923EFD130@ku-exchange-02.kommunalunternehmen.local>
>
>is this a buggy or wrong configured MTA which has problems with TLS on
>port 25?
>
>All other MTA's don't seem to have any problems with TLS / STARTTLS.
>
>What can I do to fix this problem? Let the other MTA know that they got
>an issue with their TLS setup?
>
>Thanks & greetings
>Becki
>
>Here's my postconf, using a valid certificate from letsencrypt
>
>linux:~ # postconf -n | grep tls
>smtp_enforce_tls = no
>smtp_tls_CAfile =
>smtp_tls_CApath =
>smtp_tls_cert_file = /fullchain.pem
>smtp_tls_key_file = /privkey.pem
>smtp_tls_loglevel = 0
>smtp_tls_session_cache_database =
>smtp_use_tls = yes
>smtpd_tls_CAfile =
>smtpd_tls_CApath =
>smtpd_tls_ask_ccert = no
>smtpd_tls_cert_file = /fullchain.pem
>smtpd_tls_key_file = /privkey.pem
>smtpd_tls_loglevel = 0
>smtpd_tls_received_header = no
>smtpd_use_tls = yes
>tls_random_source = dev:/dev/urandom

You could set smtpd_tls_loglevel = 1 and get some more information on the next 
connection attempt.

Without knowing more details i'd say you have no cipher in common, that could 
be when you're dealing with an ancient version of exchange or some crappy 
middlebox.

-- 
 Christian Kivalo

Re: SSL_accept error from ...outbound.protection.outlook.com

2016-11-07 Thread Viktor Dukhovni 
On Mon, Nov 07, 2016 at 10:30:06AM -0500, Bill Cole wrote:

> >Nov  7 15:03:29 blueberry postfix/smtpd[18091]:
> >mail-ve1eur01hn032d.outbound.protection.outlook.com[2a01:111:f400:fe1f::32d]:
> >TLS cipher list "aNULL:-aNULL:HIGH:@STRENGTH:!aNULL"
> 
> This is probably your problem. The austere cipher list is the result of this
> setting, shown in your postconf output:
> 
> smtpd_tls_ciphers = high

Let's not speculate, ...  It is almost certain that the problem
lies elsewhere, and even with the OP's SSL library half-broken
("unknown state") that's also likely not the problem, but just in
case:

http://dilbert.com/strip/1995-06-24

The outlook.com email servers are fully able to support modern TLS
ciphersuites, and do not object to my self-signed cert.

Nov  7 16:34:41 amnesiac postfix/smtpd[6205]: connect from
mail-by2nam01on0058.outbound.protection.outlook.com[104.47.34.58]
Nov  7 16:34:42 amnesiac postfix/smtpd[6205]: Anonymous TLS connection
established from
mail-by2nam01on0058.outbound.protection.outlook.com[104.47.34.58]:
TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)
Nov  7 16:34:42 amnesiac postfix/smtpd[6205]: A59CF284B0A:
client=mail-by2nam01on0058.outbound.protection.outlook.com[104.47.34.58]
Nov  7 16:34:42 amnesiac postfix/cleanup[26419]: A59CF284B0A: ...
Nov  7 16:34:43 amnesiac postfix/qmgr[16255]: A59CF284B0A: from=<...>,
size=130131, nrcpt=1 (queue active)
Nov  7 16:34:43 amnesiac postfix/virtual[29503]: A59CF284B0A:
to=<...>, orig_to=<...>, relay=virtual, delay=1.1, delays=1/0/0/0.03,
dsn=2.0.0, status=sent (delivered to maildir)
Nov  7 16:34:43 amnesiac postfix/qmgr[16255]: A59CF284B0A: removed

The real issue, mentioned on this list previously IIRC, is the
over-aggressive way in which Microsoft deprecated MD5.  They
needlessly (and unfortunately) apply the MD5 restriction to the
self-signatures of root CAs, and even in the context of STARTTLS,
where they happily deliver in cleartext or to self-signed certs,
so failing with weak signatures is noticeably lame.

The OP just happens one of the unlucky ones who goes way overboard
with 4096-bit RSA keys and SHA512 signatures (don't do that it's
futile), but uses a root CA whose self-signature is with MD5:

$ posttls-finger -cC floppy.org |
openssl crl2pkcs7 -nocrl -certfile /dev/stdin |
openssl pkcs7 -noout -print_certs -text |
perl -lne '
print "" if /^Cert/;
print $1 if m{(?:Signature Algorithm|Subject|Issuer):\s*(.*)}
'

sha512WithRSAEncryption
O=Root CA, OU=http://www.cacert.org, CN=CA Cert Signing 
Authority/emailAddress=supp...@cacert.org
CN=blueberry.post-peine.de
sha512WithRSAEncryption

md5WithRSAEncryption
O=Root CA, OU=http://www.cacert.org, CN=CA Cert Signing 
Authority/emailAddress=supp...@cacert.org
O=Root CA, OU=http://www.cacert.org, CN=CA Cert Signing 
Authority/emailAddress=supp...@cacert.org
md5WithRSAEncryption

A suitable 2048-bit self-signed certificate will work much better.

-- 
Viktor.

Re: SSL_accept error from ...outbound.protection.outlook.com

2016-11-07 Thread Bill Cole 

On 7 Nov 2016, at 9:26, Florian Piekert wrote:


Hello everybody,

another issue around TLS/SSL from me.

I see tons of
==> mail/mail.log <==

[...]

Nov  7 15:03:29 blueberry postfix/smtpd[18091]:
mail-ve1eur01hn032d.outbound.protection.outlook.com[2a01:111:f400:fe1f::32d]:
TLS cipher list "aNULL:-aNULL:HIGH:@STRENGTH:!aNULL"


This is probably your problem. The austere cipher list is the result of 
this setting, shown in your postconf output:


smtpd_tls_ciphers = high

This has the perverse effect of causing some senders to fallback to no 
encryption and others to fail because they are configured to never do 
that when a server claims to support TLS or are simply broken.

Re: SSL_accept error from ...

2011-08-19 Thread Wietse Venema 
Victor Duchovni:
 On Fri, Jul 22, 2011 at 09:32:29AM -0400, Wietse Venema wrote:
 
   So what are those?
  
  Postfix prints all information that is available on the OpenSSL
  error stack. The absence of such logging suggests that the error
  stack is empty (perhaps the client hung up), or that your grep(1)
  command eliminated them.
 
 These are typically just lost connections. A problem client in my
 logs shows:
 
   8 plaintext deliveries
   6 plaintext DATA timeouts
  24 TLS deliveries
 109 TLS DATA timeouts
   7 TLS SSL accept error: 0

I've cleaned up the Postfix TLS I/O error handling, and as a result
Postfix error messages are more informative. For example: 

SSL accept error from host[addr]:port: lost connection
SSL connect error to host[addr]:port: connection timed out

None of these changes affect existing functionality, they just make
the logging more understandable.

Wietse

20110817

Cleanup: to avoid misleading error messages, the tls_bio_ops(3)
module now sets errno to zero after a TLS operation fails
due to a non-system-call error. File: tls/tls_bio_ops.c.

Cleanup: TLS handshake error reporting. The SMTP client and
server now report STARTTLS network errors as connection
lost, connection timed out etc.  instead of error number
0.  Files: tls/tls_bio_ops.c, tls/tls_server.c, tls/tls_client.c.

20110818

Cleanup: normalization of vstream(3) error handling. For
consistency with the plaintext read/write routines, the
tls_stream(3) read/write routines now return -1 instead of
random OpenSSL error values.  File: tls/tls_stream.c.

Re: SSL_accept error from ...

2011-07-22 Thread Wietse Venema 
Ralf Hildebrandt:
 I'm seeing sporadic SSL_accept error messages and would like to know
 their significance. Sometimes I'm seeing : 0, sometime : -1
 
 A few examples:
 
 Jul  3 17:44:00 mail postfix/smtpd[1210]: SSL_accept error from 
 post.blossin.de[217.92.177.100]: -1
 Jul  3 17:53:22 mail postfix/smtpd[1174]: SSL_accept error from 
 post.blossin.de[217.92.177.100]: -1
 Jul  3 18:31:12 mail postfix/smtpd[8533]: SSL_accept error from 
 post.blossin.de[217.92.177.100]: -1
 Jul  4 15:13:25 mail postfix/smtpd[9088]: SSL_accept error from 
 post.blossin.de[217.92.177.100]: -1
 
 ...
 
 Jul  5 11:38:38 mail postfix/smtpd[17412]: SSL_accept error from 
 www.neuro.med.tu-dresden.de[141.76.248.20]: 0
 Jul  6 02:32:25 mail postfix/smtpd[1491]: SSL_accept error from 
 server.detodos.com.br[189.90.142.30]: 0
 
 So what are those?

Postfix prints all information that is available on the OpenSSL
error stack. The absence of such logging suggests that the error
stack is empty (perhaps the client hung up), or that your grep(1)
command eliminated them.

Wietse

Re: SSL_accept error from ...

2011-07-22 Thread Ralf Hildebrandt 
* Wietse Venema wie...@porcupine.org:

  Jul  3 17:44:00 mail postfix/smtpd[1210]: SSL_accept error from 
  post.blossin.de[217.92.177.100]: -1
  Jul  3 17:53:22 mail postfix/smtpd[1174]: SSL_accept error from 
  post.blossin.de[217.92.177.100]: -1
  Jul  3 18:31:12 mail postfix/smtpd[8533]: SSL_accept error from 
  post.blossin.de[217.92.177.100]: -1
  Jul  4 15:13:25 mail postfix/smtpd[9088]: SSL_accept error from 
  post.blossin.de[217.92.177.100]: -1
  
  ...
  
  Jul  5 11:38:38 mail postfix/smtpd[17412]: SSL_accept error from 
  www.neuro.med.tu-dresden.de[141.76.248.20]: 0
  Jul  6 02:32:25 mail postfix/smtpd[1491]: SSL_accept error from 
  server.detodos.com.br[189.90.142.30]: 0
  
  So what are those?
 
 Postfix prints all information that is available on the OpenSSL
 error stack. The absence of such logging suggests that the error
 stack is empty (perhaps the client hung up), 

I guess so then

 or that your grep(1) command eliminated them.

That's all there was. OK, I'll just ignore those then.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: SSL_accept error from ...

2011-07-22 Thread Wietse Venema 
Ralf Hildebrandt:
 * Wietse Venema wie...@porcupine.org:
 
   Jul  3 17:44:00 mail postfix/smtpd[1210]: SSL_accept error from 
   post.blossin.de[217.92.177.100]: -1
   Jul  3 17:53:22 mail postfix/smtpd[1174]: SSL_accept error from 
   post.blossin.de[217.92.177.100]: -1
   Jul  3 18:31:12 mail postfix/smtpd[8533]: SSL_accept error from 
   post.blossin.de[217.92.177.100]: -1
   Jul  4 15:13:25 mail postfix/smtpd[9088]: SSL_accept error from 
   post.blossin.de[217.92.177.100]: -1
   
   ...
   
   Jul  5 11:38:38 mail postfix/smtpd[17412]: SSL_accept error from 
   www.neuro.med.tu-dresden.de[141.76.248.20]: 0
   Jul  6 02:32:25 mail postfix/smtpd[1491]: SSL_accept error from 
   server.detodos.com.br[189.90.142.30]: 0
   
   So what are those?
  
  Postfix prints all information that is available on the OpenSSL
  error stack. The absence of such logging suggests that the error
  stack is empty (perhaps the client hung up), 
 
 I guess so then
 
  or that your grep(1) command eliminated them.
 
 That's all there was. OK, I'll just ignore those then.

I would not deny that this user interface can be improved.  One
minor improvement would be to log lost connection when the OpenSSL
error stack is empty (i.e. when ERR_peek_error() returns an end-of-data
indication instead of an OpenSSL error number).

Wietse

Re: SSL_accept error from ...

2011-07-22 Thread Ralf Hildebrandt 
* Wietse Venema wie...@porcupine.org:

  That's all there was. OK, I'll just ignore those then.
 
 I would not deny that this user interface can be improved.  One
 minor improvement would be to log lost connection when the OpenSSL
 error stack is empty (i.e. when ERR_peek_error() returns an end-of-data
 indication instead of an OpenSSL error number).

That would definitely raise less suspicion!

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: SSL_accept error from ...

2011-07-22 Thread Victor Duchovni 
On Fri, Jul 22, 2011 at 09:32:29AM -0400, Wietse Venema wrote:

  So what are those?
 
 Postfix prints all information that is available on the OpenSSL
 error stack. The absence of such logging suggests that the error
 stack is empty (perhaps the client hung up), or that your grep(1)
 command eliminated them.

These are typically just lost connections. A problem client in my
logs shows:

  8 plaintext deliveries
  6 plaintext DATA timeouts
 24 TLS deliveries
109 TLS DATA timeouts
  7 TLS SSL accept error: 0

There is nothing on the TLS error stack. Anonymised log samples:

TLS delivery:

2011-07-22T05:51:11-04:00 amnesiac postfix/smtpd[9446]: connect from 
unknown[192.0.2.1]
2011-07-22T05:51:12-04:00 amnesiac postfix/smtpd[9446]: Anonymous TLS 
connection established from unknown[192.0.2.1]: TLSv1 with cipher 
DHE-RSA-AES256-SHA (256/256 bits)
2011-07-22T05:51:12-04:00 amnesiac postfix/smtpd[9446]: 755A11AC8003: 
client=unknown[192.0.2.1]
2011-07-22T05:51:12-04:00 amnesiac postfix/cleanup[9603]: 755A11AC8003: 
message-id=id1
2011-07-22T05:51:12-04:00 amnesiac postfix/qmgr[11097]: 755A11AC8003: 
from=sender1, size=19041, nrcpt=1 (queue active)
2011-07-22T05:51:12-04:00 amnesiac postfix/smtp[9512]: 755A11AC8003: 
to=rcpt1, relay=127.0.0.1[127.0.0.1]:27, delay=0.2, delays=0.16/0/0/0.03, 
dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 9C384EF8003)
2011-07-22T05:51:12-04:00 amnesiac postfix/qmgr[11097]: 755A11AC8003: removed
2011-07-22T05:51:12-04:00 amnesiac postfix/smtpd[9446]: disconnect from 
unknown[192.0.2.1]

TLS DATA timeout:

2011-07-22T05:51:30-04:00 amnesiac postfix/smtpd[9390]: connect from 
unknown[192.0.2.1]
2011-07-22T05:51:30-04:00 amnesiac postfix/smtpd[9390]: Anonymous TLS 
connection established from unknown[192.0.2.1]: TLSv1 with cipher 
DHE-RSA-AES256-SHA (256/256 bits)
2011-07-22T05:51:30-04:00 amnesiac postfix/smtpd[9390]: 921D21AC8009: 
client=unknown[192.0.2.1]
2011-07-22T05:52:16-04:00 amnesiac postfix/smtpd[9390]: timeout after DATA 
(57269 bytes) from unknown[192.0.2.1]
2011-07-22T05:52:26-04:00 amnesiac postfix/smtpd[9390]: disconnect from 
unknown[192.0.2.1]

plaintext delivery

2011-07-22T05:53:22-04:00 amnesiac postfix/smtpd[9443]: C62C71748001: 
client=unknown[192.0.2.1]
2011-07-22T05:53:22-04:00 amnesiac postfix/cleanup[9278]: C62C71748001: 
message-id=id2
2011-07-22T05:53:57-04:00 amnesiac postfix/qmgr[11097]: C62C71748001: 
from=sender1, size=161047, nrcpt=1 (queue active)
2011-07-22T05:53:57-04:00 amnesiac postfix/smtp[9509]: C62C71748001: 
to=rcpt1, relay=127.0.0.1[127.0.0.1]:27, delay=35, delays=35/0/0/0.12, 
dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 717B5EF8001)
2011-07-22T05:53:57-04:00 amnesiac postfix/qmgr[11097]: C62C71748001: removed

TLS SSL_accept error 0

2011-07-22T05:53:33-04:00 amnesiac postfix/smtpd[9446]: connect from 
unknown[192.0.2.1]
2011-07-22T05:53:33-04:00 amnesiac postfix/smtpd[9446]: SSL_accept error from 
unknown[192.0.2.1]: 0
2011-07-22T05:53:33-04:00 amnesiac postfix/smtpd[9446]: lost connection after 
STARTTLS from unknown[192.0.2.1]
2011-07-22T05:53:33-04:00 amnesiac postfix/smtpd[9446]: disconnect from 
unknown[192.0.2.1]

plaintext DATA timeout

2011-07-22T05:54:22-04:00 amnesiac postfix/smtpd[9389]: connect from 
unknown[192.0.2.1]
2011-07-22T05:54:22-04:00 amnesiac postfix/smtpd[9389]: D4AF21748001: 
client=unknown[192.0.2.1]
2011-07-22T05:55:08-04:00 amnesiac postfix/smtpd[9389]: timeout after DATA 
(65624 bytes) from unknown[192.0.2.1]
2011-07-22T05:55:08-04:00 amnesiac postfix/smtpd[9389]: disconnect from 
unknown[192.0.2.1]

-- 
Viktor.

Re: SSL_accept error from unknown[x.x.x.]: -1

2009-11-27 Thread Noel Jones 

On 11/26/2009 9:43 PM, sosogh wrote:

Hi list
I am running two postfix on two servers.One acts as smtp tls client,
the other one acts as smtpd tls server.
I tried to send mails from smtp tls client to smtpd tls server

---

IP are:
smtp tls client:1.1.1.1  (postfix version  2.3.8 OpenSSL 0.9.8c 05 Sep 2006)
smtpd tls server:2.2.2.2  (postfix version  2.5.5 OpenSSL 0.9.8g 19 Oct 2007)

configuration are:
(1)smtp tls client:
In main.cf:
default_transport = smtp-tls:[2.2.2.2]:465


The postfix smtp client doesn't support the long deprecated 
smtps wrappermode.


You should abandon wrappermode and configure postfix to use 
STARTTLS on port 587 or port 25.

http://www.postfix.org/TLS_README.html#server_tls

If you feel you must use smtps, please see
http://www.postfix.org/TLS_README.html#client_smtps


  -- Noel Jones

Re: SSL_accept error from - somebody that could tell me what to do

2009-06-15 Thread Wietse Venema 
Jelle de Jong:
 Jun 15 13:57:46 emily postfix/smtpd[23401]: input attribute name: seed
 Jun 15 13:57:46 emily postfix/smtpd[23401]: input attribute value: 
 YuvlIV0a1sMFU6JK6BcvsKr6WJm8YP7zsFNJz/XEv+w=
 Jun 15 13:57:46 emily postfix/smtpd[23401]: private/tlsmgr: wanted attribute: 
 (list terminator)
 Jun 15 13:57:46 emily postfix/smtpd[23401]: input attribute name: (end)
 Jun 15 13:57:46 emily postfix/smtpd[23401]: SSL_accept error from 
 sepaip2.webish.nl[77.243.228.161]: -1
 Jun 15 13:57:46 emily postfix/smtpd[23401]: match_hostname: sepaip2.webish.nl 
 ~? 127.0.0.0/8

Code fragment:
sts = tls_bio_accept(vstream_fileno(props-stream), props-timeout,
 TLScontext);
if (sts = 0) {
msg_info(SSL_accept error from %s: %d, props-namaddr, sts);
tls_print_errors();
tls_free_context(TLScontext);
return (0);

This means that the OpenSSL library error stack did not contain 
any additional information about the problem.

Maybe the client-side logging is more informative.

Wietse

Re: SSL_accept error from - somebody that could tell me what to do

2009-06-15 Thread Jelle de Jong 
Wietse Venema wrote:
 Jelle de Jong:
 Jun 15 13:57:46 emily postfix/smtpd[23401]: input attribute name: seed
 Jun 15 13:57:46 emily postfix/smtpd[23401]: input attribute value: 
 YuvlIV0a1sMFU6JK6BcvsKr6WJm8YP7zsFNJz/XEv+w=
 Jun 15 13:57:46 emily postfix/smtpd[23401]: private/tlsmgr: wanted 
 attribute: (list terminator)
 Jun 15 13:57:46 emily postfix/smtpd[23401]: input attribute name: (end)
 Jun 15 13:57:46 emily postfix/smtpd[23401]: SSL_accept error from 
 sepaip2.webish.nl[77.243.228.161]: -1
 Jun 15 13:57:46 emily postfix/smtpd[23401]: match_hostname: 
 sepaip2.webish.nl ~? 127.0.0.0/8
 
 Code fragment:
 sts = tls_bio_accept(vstream_fileno(props-stream), props-timeout,
  TLScontext);
 if (sts = 0) {
 msg_info(SSL_accept error from %s: %d, props-namaddr, sts);
 tls_print_errors();
 tls_free_context(TLScontext);
 return (0);
 
 This means that the OpenSSL library error stack did not contain 
 any additional information about the problem.
 
 Maybe the client-side logging is more informative.
 
   Wietse


Thank you Wietse, I have asked the other server party to see if they can
sent me the logs, I hope they will sent them, they say the problem is on
my end, but I have no diffidence for that so far.

I will also sent the debug info to the openssl mailinglist and see if
they know what to do.

If somebody has any more ideas please share them.

Best regards,

Jelle de Jong

Re: SSL_accept error from - somebody that could tell me what to do

2009-06-15 Thread Victor Duchovni 
On Mon, Jun 15, 2009 at 04:48:26PM +0200, Jelle de Jong wrote:

 Thank you Wietse, I have asked the other server party to see if they can
 sent me the logs, I hope they will sent them, they say the problem is on
 my end, but I have no diffidence for that so far.
 
 I will also sent the debug info to the openssl mailinglist and see if
 they know what to do.

Obtain ssldump (has not been updated for a while, but is still quite
usable).  Apply ssldump (or wireshark to a full (no trucation
of packets) packet capture of the session. Then post the ssldump
output.

The OpenSSL-users list is only appropriate once you have reasons to
suspect that you actually have an OpenSSL related issue and not a
network issue, ...

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
mailto:majord...@postfix.org?body=unsubscribe%20postfix-users

If my response solves your problem, the best way to thank me is to not
send an it worked, thanks follow-up. If you must respond, please put
It worked, thanks in the Subject so I can delete these quickly.