Hello all,
I've seen this error in my maillog:
Oct 11 21:49:02 baobab postfix/smtpd[21916]: connect from
r164.europe-news.chanel.com[172.82.238.164]
Oct 11 21:49:02 baobab postfix/smtpd[21916]: SSL_accept error from
r164.europe-news.chanel.com[172.82.238.164]: -1
Oct 11 21:49:02 baobab postfi
On Tue, Oct 11, 2022 at 09:57:02PM +0200, Luciano Mannucci wrote:
> I've seen this error in my maillog:
>
> Oct 11 21:49:02 baobab postfix/smtpd[21916]: connect from
> r164.europe-news.chanel.com[172.82.238.164]
> Oct 11 21:49:02 baobab postfix/smtpd[21916]: SSL_accept error from
> r164.europe-
On Tue, Oct 11, 2022 at 04:37:44PM -0400, Viktor Dukhovni wrote:
> > Do I have to worry?
>
> If Android clients aren't a concern for your MTA, you should perhaps
> configure your ACME client (e.g. certbot) to build a chain file without
> the cross certificate. Details on the letsencrypt.org webs
On Tue, 11 Oct 2022 16:37:44 -0400
Viktor Dukhovni wrote:
> > Do I have to worry?
>
> If Android clients aren't a concern for your MTA, you should perhaps
> configure your ACME client (e.g. certbot) to build a chain file without
> the cross certificate. Details on the letsencrypt.org website:
Hi,
I have enabled tls in 2 postfix servers(MTA1, MTA2). when i try to send
mail from simple java client to server it is working fine. TLS negotiation
happened properly. But when MTA1 try to send mail to other MTA, mail is
getting deferred by writing following log
" Aug 2 11:21:34 AHQ postfix/
Hi,
I have enabled tls in 2 postfix servers(MTA1, MTA2). when i try to send
mail from simple java client to server it is working fine. TLS negotiation
happened properly. But when MTA1 try to send mail to other MTA, TLS is
failing by giving following error.
"certificate verification failed for x
Hello,
i've just setted up a postfix server, and i constantly have such error
in my logs :
Sep 13 21:31:34 effraie01 postfix/smtpd[12650]: SSL_accept error from
ng17.bullet.mail.bf1.yahoo.com
(ever from yahoo servers)
i can't figure out wher my mistake come from.
here is my postconf -n :
On Wed, Aug 02, 2017 at 12:10:31PM +0530, hyndavirap...@bel.co.in wrote:
> " Aug 2 11:21:34 AHQ postfix/smtp[6372]: BEC5D67928BD:
> to=, orig_to=,
> relay=201.123.1.4[201.123.1.4]:25, delay=0.06, delays=0.04/0.01/0.01/0,
> dsn=4.7.5, status=deferred (Server certificate not verified) "
That's nic
> On Wed, Aug 02, 2017 at 12:10:31PM +0530, hyndavirap...@bel.co.in wrote:
>> " Aug 2 11:21:34 AHQ postfix/smtp[6372]: BEC5D67928BD:
>> to=, orig_to=,
relay=201.123.1.4[201.123.1.4]:25, delay=0.06, delays=0.04/0.01/0.01/0,
dsn=4.7.5, status=deferred (Server certificate not verified) "
> That's nic
> On Wed, Aug 02, 2017 at 12:10:31PM +0530, hyndavirap...@bel.co.in wrote:
>> " Aug 2 11:21:34 AHQ postfix/smtp[6372]: BEC5D67928BD:
>> to=, orig_to=,
relay=201.123.1.4[201.123.1.4]:25, delay=0.06, delays=0.04/0.01/0.01/0,
dsn=4.7.5, status=deferred (Server certificate not verified) "
> That's nic
On 8/2/2017 2:19 AM, Viktor Dukhovni wrote:
> On Wed, Aug 02, 2017 at 12:10:31PM +0530, hyndavirap...@bel.co.in wrote:
>
>> " Aug 2 11:21:34 AHQ postfix/smtp[6372]: BEC5D67928BD:
>> to=, orig_to=,
>> relay=201.123.1.4[201.123.1.4]:25, delay=0.06, delays=0.04/0.01/0.01/0,
>> dsn=4.7.5, status=defe
On Wed, Aug 02, 2017 at 10:00:58AM -0500, Noel Jones wrote:
> >> smtpd_tls_loglevel = 2
> >
> > Change that to 1, and also set:
> >
> > smtp_tls_security_level = 1
>
>
> Oops, that should be
>
>smtp_tls_loglevel = 1
Indeed a typo, thanks for the corection, ... and then the OP must
*P
> On Wed, Aug 02, 2017 at 10:00:58AM -0500, Noel Jones wrote:
>
>> >> smtpd_tls_loglevel = 2
>> >
>> > Change that to 1, and also set:
>> >
>> > smtp_tls_security_level = 1
>>
>>
>> Oops, that should be
>>
>>smtp_tls_loglevel = 1
>
> Indeed a typo, thanks for the corection, ... and then th
On Thu, Aug 03, 2017 at 12:19:55PM +0530, hyndavirap...@bel.co.in wrote:
> > He's not posted the configuration of the sending system or
> > its logs. This is a waste of everyone's time.
The relevant logging is the TLS-related logging from the sending
postfix/smtp client process that happens *bef
> On Thu, Aug 03, 2017 at 12:19:55PM +0530, hyndavirap...@bel.co.in wrote:
>
>> > He's not posted the configuration of the sending system or
>> > its logs. This is a waste of everyone's time.
>
> The relevant logging is the TLS-related logging from the sending
> postfix/smtp client process that h
On Fri, Aug 04, 2017 at 12:31:53PM +0530, hyndavirap...@bel.co.in wrote:
> >> Can you help me to solve this problem
> >
> > Not without the requested logging, and copy of the server and CA
> > certificates.
> TLS logging is as below,
> Aug 4 11:52:29 AHQ postfix/smtp[11652]: 201.123.1.4[201.123
hyndavirap...@bel.co.in:
>
> Hi,
>
> I have enabled tls in 2 postfix servers(MTA1, MTA2). when i try to send
> mail from simple java client to server it is working fine. TLS negotiation
> happened properly. But when MTA1 try to send mail to other MTA, TLS is
> failing by giving following error.
> On 2015-10-29 10:11, hyndavirap...@bel.co.in wrote:
>
> Every 3000 Sheets of paper costs us a tree.. Save trees... Conserve
> Trees. Don't print this email or any Files unless you really need to
this list might be the least appropriate place to spread such agenda.
After all, a MTA is alrea
hyndavirap...@bel.co.example:
> 1. error log before adding "smtp_tls_CAfile" param is as follows
>
I replaced the top-level domain name for privacy reasons.
> postfix/smtp[3525]: certificate verification failed for
> 201.123.80.173[201.123.80.173]:25: untrusted issuer
> /C=EXAMPLE/ST=karnataka/L
On Fri, Oct 30, 2015 at 09:20:05AM -0400, Wietse Venema wrote:
> > postfix/smtp[6891]: 17A3F232B1: to=,
> > relay=201.123.80.173[201.123.80.173]:25, delay=337, delays=327/0.02/10/0,
> > dsn=4.7.5, status=deferred (Server certificate not verified)
>
> Now it knows the issuer, but the name in the c
> hyndavirap...@bel.co.example:
>> 1. error log before adding "smtp_tls_CAfile" param is as follows
>>
>
> I replaced the top-level domain name for privacy reasons.
>
>> postfix/smtp[3525]: certificate verification failed for
>> 201.123.80.173[201.123.80.173]:25: untrusted issuer
>> /C=EXAMPLE/ST=k
On Sat, Oct 31, 2015 at 04:10:33PM +0530, hyndavirap...@bel.co.in wrote:
> tls_policy file contains:
>
> [201.123.80.173]:25 encrypt match=AHQserver
Is the name in the certificate really not fully-qualified? The
"encrypt" policy does not entail certificate verification.
Try:
[201.123.80
hyndavirap...@bel.co.in:
> AHQ.tcs.mil.example relay:[201.123.80.173]:25
...
> [201.123.80.173]:25 encrypt match=AHQserver
...
> CN=AHQserver/emailAddress=ahqserver_smtp_ad...@tcs.mil.example
The match= requires a complete match (case-insensitive). You specify
only a substring of the
On Sat, Oct 31, 2015 at 10:16:37AM -0400, Wietse Venema wrote:
> hyndavirap...@bel.co.in:
> > AHQ.tcs.mil.example relay:[201.123.80.173]:25
> ...
> > [201.123.80.173]:25 encrypt match=AHQserver
> ...
> > CN=AHQserver/emailAddress=ahqserver_smtp_ad...@tcs.mil.example
>
> The match= requir
> On Sat, Oct 31, 2015 at 04:10:33PM +0530, hyndavirap...@bel.co.in wrote:
>
>> tls_policy file contains:
>>
>> [201.123.80.173]:25 encrypt match=AHQserver
>
> Is the name in the certificate really not fully-qualified? The
> "encrypt" policy does not entail certificate verification.
> Try:
>
>
On Fri, Sep 13, 2013 at 09:44:38PM +0200, Mathieu R. wrote:
> Sep 13 21:31:34 effraie01 postfix/smtpd[12650]: SSL_accept error
> from ng17.bullet.mail.bf1.yahoo.com
There is generally more information in the log than this when the
TLS handshake fails. DO NOT over-summarize the logs.
> (ever fro
Le 13/09/2013 22:29, Viktor Dukhovni a écrit :
On Fri, Sep 13, 2013 at 09:44:38PM +0200, Mathieu R. wrote:
Sep 13 21:31:34 effraie01 postfix/smtpd[12650]: SSL_accept error
from ng17.bullet.mail.bf1.yahoo.com
There is generally more information in the log than this when the
TLS handshake fails
On Fri, Sep 13, 2013 at 11:03:22PM +0200, Mathieu R. wrote:
> >There is generally more information in the log than this when the
> >TLS handshake fails. DO NOT over-summarize the logs.
>
> Sep 13 22:58:40 effraie01 postfix/smtpd[22230]: SSL_accept error
> from ng4.bullet.mail.bf1.yahoo.com[98.13
Le 13/09/2013 23:26, Viktor Dukhovni a écrit :
On Fri, Sep 13, 2013 at 11:03:22PM +0200, Mathieu R. wrote:
>There is generally more information in the log than this when the
>TLS handshake fails. DO NOT over-summarize the logs.
Sep 13 22:58:40 effraie01 postfix/smtpd[22230]: SSL_accept error
On Sep 13, 2013, at 23:51, Mathieu R. wrote:
> Le 13/09/2013 23:26, Viktor Dukhovni a écrit :
>> If your traffic volume is not too heavy, you can temporarily raise
>> the Postfix SMTP server TLS log level to "2":
>>
>> smtpd_tls_loglevel = 2
>>
>> this will show more details of the TLS han
On Fri, Sep 13, 2013 at 11:51:39PM +0200, Mathieu R. wrote:
> not very much more :
>
> Sep 13 23:33:09 effraie01 postfix/smtpd[25221]: connect from
> ng4.bullet.mail.bf1.yahoo.com[98.139.164.99]
> Sep 13 23:33:44 effraie01 postfix/smtpd[25221]: SSL_accept error
> from ng4.bullet.mail.bf1.yahoo.co
Le 14/09/2013 03:23, Viktor Dukhovni a écrit :
On Fri, Sep 13, 2013 at 11:51:39PM +0200, Mathieu R. wrote:
not very much more :
Sep 13 23:33:09 effraie01 postfix/smtpd[25221]: connect from
ng4.bullet.mail.bf1.yahoo.com[98.139.164.99]
Sep 13 23:33:44 effraie01 postfix/smtpd[25221]: SSL_accept e
> So, there is nothing i can do ?
If you don't need TLS for yahoo you can disable it for that server. Take
a look at
http://www.postfix.org/postconf.5.html#smtpd_discard_ehlo_keyword_address_maps
On Sat, Sep 14, 2013 at 08:45:05AM +0200, Mathieu R. wrote:
> >Yahoo sends "STARTTLS", Postfix says "go ahead" and Yahoo
> >disconnects.
> >There's is nothing more to it. Some strange problem on the Yahoo
> >side, unless your firewall is blocking the handshake.
>
> My firewall is not doing such
The mx lookup on effraie.org returns mx.effraie.org. The cert
mx.effraie.org sends has a number of dnsnames, but not mx.effraie.org.
I bet that is why the session failed.
The mx for 400iso.net, mx.400iso.net, sends the same cert and also
likely will fail tls negotiation with some senders.
In ge
On Sun, Sep 15, 2013 at 03:31:38PM -0400, James Cloos wrote:
> The mx lookup on effraie.org returns mx.effraie.org. The cert
> mx.effraie.org sends has a number of dnsnames, but not mx.effraie.org.
>
> I bet that is why the session failed.
I noticed this, but I thought it unlikely that a sender
James Cloos a écrit :
>The mx lookup on effraie.org returns mx.effraie.org. The cert
>mx.effraie.org sends has a number of dnsnames, but not mx.effraie.org.
>
>I bet that is why the session failed.
>
>The mx for 400iso.net, mx.400iso.net, sends the same cert and also
>likely will fail tls negoti
Mathieu R.:
> As it seem to be a good advice, I did change my dns entries for
> mx to mail.effraie.org, wich is covered by the (new) cacert
> certificat of the mail server.
>
> I still have the same error in logs
It does not matter what the server certificate says, because it is
never sent. The
I ran into a problem that seems to have some of the same attributes. In
my case Google was rejecting my email, however they may have been a
little more polite about doing so.
Have you checked your DNS and reverse DNS entries. Is your server a
dedicated system with a single IP address.
In my
I have a problem and I am not really sure what it is. I use the utility
program "sendEmail" to relay mail in several different scripts I created. When
I send to "Yahoo", everything goes fine. If I try and send through Postfix on
my server, with the same configuration except for user name and passwo
Trying to send mail results in this error from Thunderbird client:
Sending of message failed.
An error occurred sending mail: Unable to establish a secure link
with SMTP server mail.bsdbox.co using STARTTLS since it doesn't
advertise that feature. Switch off STARTTLS for that server o
On Wed, Mar 18, 2015 at 05:46:45PM -0400, Postfix User wrote:
> The is the output from the "sendEmail" program:
>
> Mar 18 16:57:29 scorpio sendEmail[29407]: SUCCESS => Received: 220 2.0.0
> Ready to start TLS
> Mar 18 16:57:29 scorpio sendEmail[29407]: ERROR => TLS setup failed: SSL
> connect
Hello,
I'm running a FreeBSD 10.2 system, postfix 2.11.6, Openssl 1.0.1P. I'm
working on setting up a webmail client to my existing
Postfix/Dovecot/Mysql setup. I've tried two webmail clients both are
giving me the below errors when the webmail client (postfix dovecot
mysql the web server are all
On Tue, Dec 10, 2013 at 11:57:56PM +1100, Mark Jamsek wrote:
>|Dec 10 11:36:03 mail postfix/smtpd[57120]: warning:
>[highlight]cannot get RSA certificate from file
>
> /etc/ssl/cert/dovecot.pem:
>
>disabling TLS support
New spectacle prescription recommended: :-)
>s
On 11/12/2013 5:50 AM, Viktor Dukhovni wrote:
On Tue, Dec 10, 2013 at 11:57:56PM +1100, Mark Jamsek wrote:
|Dec 10 11:36:03 mail postfix/smtpd[57120]: warning:
[highlight]cannot get RSA certificate from file
/etc/ssl/cert/dovecot.pem:
disabling TLS support
New spectacle p
Mac Mini, 10.13 High Sierra running Mac Server 5.4. From a Mac client,
specifying "Use TLS/SSL" in SMTP settings works just fine when sending out
mail. However, from Windows 10 Mail running on a PC in the same network, I
cannot keep "Require SSL for outgoing email" checked in the Win10 Mail
setting
On Sat, Oct 31, 2015 at 12:05:29PM -0400, David Mehler wrote:
> I am using self-signed certificates via my own CA if that matters.
A certificate is either self-signed, or issued by a CA. Which is it?
> Oct 30 12:12:01 ohio postfix/submission/smtpd[4795]: SSL_accept error from
> localhost[::1]:
Hello,
Thank you. I apologize, let me clarify my statement. I have created my
own CA on an offline machine which I use to sign all of my
certificates.
When you say the client doesn't trust the server certificate, that's
not the webmail, that's the submission service not trusting the
postfix Serve
On Sat, Oct 31, 2015 at 03:35:14PM -0400, David Mehler wrote:
> Thank you. I apologize, let me clarify my statement. I have created my
> own CA on an offline machine which I use to sign all of my
> certificates.
Good, that removes ambiguity.
> When you say the client doesn't trust the server cer
Hello,
Still stuck. I've got the below not sure if it helps, it does show
that on 143 and 587 client wise no peer is being sent or verified.
openssl s_client -starttls smtp -connect localhost:587
CONNECTED(0003)
34379270664:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown
protocol:/
On Sun, Nov 01, 2015 at 02:49:20PM -0500, David Mehler wrote:
> Still stuck. I've got the below not sure if it helps, it does show
> that on 143 and 587 client wise no peer is being sent or verified.
>
> openssl s_client -starttls smtp -connect localhost:587
> CONNECTED(0003)
> 34379270664:er
Hi,
Thanks. The only thing I have in the maillog is a connection made, tls
established, then the connection is dropped.
Thanks.
Dave.
On 11/1/15, Viktor Dukhovni wrote:
> On Sun, Nov 01, 2015 at 02:49:20PM -0500, David Mehler wrote:
>
>> Still stuck. I've got the below not sure if it helps, it
On Sun, Nov 01, 2015 at 07:06:42PM -0500, David Mehler wrote:
> Thanks. The only thing I have in the maillog is a connection made, tls
> established, then the connection is dropped.
Not possible. Those logs don't match the report of a failed SSL
connection on the client side.
--
Viktor
Hello,
Thanks. Don't ask me how, but flipping the tls protocols from the list
I had to high and now the 587 works. Imap on 143 still won't, but
that's not for this list. The point is for the moment it is working.
Thanks for all your help.
Thanks.
Dave.
On 11/1/15, Viktor Dukhovni wrote:
> On S
On Sun, Nov 01, 2015 at 08:08:46PM -0500, David Mehler wrote:
> Thanks. Don't ask me how, but flipping the tls protocols from the list
> I had to high and now the 587 works.
No idea what that means, but so long as you're satisfied...
--
Viktor.
> On Nov 10, 2017, at 1:18 PM, avignonais wrote:
>
>
> 2017-11-10 12:38:28.755534-0500 0x39f75Default 0x0
> 13873 smtpd: warning: TLS library problem: error:1408A10B:SSL
> routines:SSL3_GET_CLIENT_HELLO:wrong version
> number:/BuildRoot/Library/Caches/com.apple.xbs/Sou
Thanks! From what I think you're saying, it sounds like this wouldn't be
particularly fixable, at least not by me, LOL. That's ok, we can still send
mail from the Win 10 PC if we uncheck "Require SSL for outgoing."
Awhile back, possibly with Mac Server 5.3 or maybe even earlier, mail logs
stopped
> On Nov 10, 2017, at 2:02 PM, avignonais wrote:
>
> Thanks! From what I think you're saying, it sounds like this wouldn't be
> particularly fixable, at least not by me, LOL. That's ok, we can still send
> mail from the Win 10 PC if we uncheck "Require SSL for outgoing."
No, I am saying that m
Understood. Not sure I'd be able to install the debugger or sniffer utilities
you link to, but FWIW here's the entire relevant logfile captured by that
Terminal command I mentioned in my earlier reply. It's everthing that was
recorded pertaining to a failed test email sent from our Windows 10 PC, w
> On Nov 10, 2017, at 2:19 PM, avignonais wrote:
>
> Understood. Not sure I'd be able to install the debugger or sniffer utilities
> you link to,
The "tcpdump" utility is a standard feature of MacOS:
$ uname -srv
Darwin 17.2.0 Darwin Kernel Version 17.2.0: Fri Sep 29 18:27:05 PDT 2017;
root:
OK.. I'm far from proficient in this, but checking for instructions online I
*think* I was able to capture a pcap file that should include the failed
email attempt sent from one of our Windows 10 PCs specifying "Require SSL
for outgoing email." I looked thru the pcap file using Mac Terminal but hav
Did you get my PCAP file that I uploaded (see reply above). I sent it as you
asked...
--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Ah, ok, so this involves our certificate instead of a postfix
mis-configuration of some sort. Yes, our (only) certificate is self-signed,
we don't s u b s c r i b e to any SSL Certificate service. On the Mac we
can specify "Always trust" when the Mail client first asks about the
self-signed ce
AES256-SHA (256/256 bits)
Feb 11 16:23:42 mail postfix/smtp[22382]: BDCC11C35E9: host
nashfinch.com.s5a1.psmtp.com[64.18.4.10] said: 451 Remote TLS ERROR -
Connection closed by peer (state:SSLv2/v3 read server hello A)
(host:[63.85.29.124]) - psmtp (in reply to RCPT TO command)
on all of their 4
ted TLS connection
> established to nashfinch.com.s5a1.psmtp.com[64.18.4.10]:25: TLSv1 with
> cipher AES256-SHA (256/256 bits)
The nashfinch.com email service is proxied by Postini.
> Feb 11 16:23:42 mail postfix/smtp[22382]: BDCC11C35E9: host
> nashfinch.com.s5a1.psmtp.com[64.18.4.
hello all
We have a RHEL 7 based server running monitoring software consisting of
Groundwork Monitoring Software, which includes Nagios , Nedi, and other
tools. This server is set up with TLS enabled and it uses a script to send
email to any SMTP server that we choose. I have an SMTP server set u
> On Dec 10, 2018, at 6:41 PM, Sean Son
> wrote:
>
> 330462 Dec 7 20:39:21 mailer postfix/smtpd[12242]: SSL3 alert
> read:fatal:unknown CA
> 330463 Dec 7 20:39:21 mailer postfix/smtpd[12242]: SSL_accept:failed in
> SSLv3 read client key exchange A
> 330464 Dec 7 20:39:21 mailer postfix/sm
On Mon, Dec 10, 2018 at 6:57 PM Viktor Dukhovni
wrote:
> > On Dec 10, 2018, at 6:41 PM, Sean Son
> wrote:
> >
> > 330462 Dec 7 20:39:21 mailer postfix/smtpd[12242]: SSL3 alert
> read:fatal:unknown CA
> > 330463 Dec 7 20:39:21 mailer postfix/smtpd[12242]: SSL_accept:failed
> in SSLv3 read clie
> On Dec 10, 2018, at 8:00 PM, Sean Son
> wrote:
>
> Thank you for the reply. Can the client be configured to trust more than one
> SSL cert?
You've told us nothing about the client, so it would be a miracle
if someone on the list could give an answer to that question.
Is the client running
On Mon, Dec 10, 2018 at 9:40 PM Viktor Dukhovni
wrote:
> > On Dec 10, 2018, at 8:00 PM, Sean Son
> wrote:
> >
> > Thank you for the reply. Can the client be configured to trust more
> than one SSL cert?
>
> You've told us nothing about the client, so it would be a miracle
> if someone on the li
> On Dec 10, 2018, at 8:00 PM, Sean Son
> wrote:
>
> Thank you for the reply. Can the client be configured to trust more
> than one SSL cert?
most of clients support more than one certificate authority.
On Mon, Dec 10, 2018 at 9:40 PM Viktor Dukhovni
wrote:
You've told us nothing about the
71 matches
Mail list logo
