Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
TLS error entries in my sendmail logs
123 views
Skip to first unread message
Clark Smith
Aug 31, 2018, 2:24:20 PM8/31/18
to
I recently started running a sendmail with TLS. In order to do
that, I generated an installed a self-signed certificate. This is working
fine, in that I can send and receive emails all right. Email clients that
use my instance of sendmail as their MTA do detect that they are dealing
with a self-signed certificate, but after enabling the corresponding
exception, everything proceeds smoothly afterwards.
Now I keep getting entries in my mail.log file from a remote MTA
that does not seem to be playing well with mine:
Aug 29 12:39:20 mybox sm-mta[26195]: STARTTLS=server, error: accept
failed=0, SSL_error=5, errno=0, retry=-1, relay=xxx.com [xx.xx.xx.xx]
Is this a tell-tale sign of a problem in my sendmail (my ecertificate?),
or is something wrong with the remote MTA?
It's always from the same IP address, and I have noticed that,
after a while, emails from that IP address are delivered to my MTA all
right. That is, it does not seem to be somebody just pinging my MTA - I
have entries from other IP addresses to that effect, but this is
different.
Finally, log entries corresponding to successful connections look
like the following:
Aug 31 11:11:39 mybox sm-mta[11977]: STARTTLS=server, relay=xxx.com
[xx.xx.xx.xx], version=TLSv1/SSLv3, verify=NOT, cipher=AES128-SHA,
bits=128/128
I am guessing that 'verify=NOT' means that my self-signed
certificate could not be verified, but that is not a problem for me.
that, I generated an installed a self-signed certificate. This is working
fine, in that I can send and receive emails all right. Email clients that
use my instance of sendmail as their MTA do detect that they are dealing
with a self-signed certificate, but after enabling the corresponding
exception, everything proceeds smoothly afterwards.
Now I keep getting entries in my mail.log file from a remote MTA
that does not seem to be playing well with mine:
Aug 29 12:39:20 mybox sm-mta[26195]: STARTTLS=server, error: accept
failed=0, SSL_error=5, errno=0, retry=-1, relay=xxx.com [xx.xx.xx.xx]
Is this a tell-tale sign of a problem in my sendmail (my ecertificate?),
or is something wrong with the remote MTA?
It's always from the same IP address, and I have noticed that,
after a while, emails from that IP address are delivered to my MTA all
right. That is, it does not seem to be somebody just pinging my MTA - I
have entries from other IP addresses to that effect, but this is
different.
Finally, log entries corresponding to successful connections look
like the following:
Aug 31 11:11:39 mybox sm-mta[11977]: STARTTLS=server, relay=xxx.com
[xx.xx.xx.xx], version=TLSv1/SSLv3, verify=NOT, cipher=AES128-SHA,
bits=128/128
I am guessing that 'verify=NOT' means that my self-signed
certificate could not be verified, but that is not a problem for me.
Alexander Bochmann
Sep 1, 2018, 6:32:10 AM9/1/18
to
Hi,
...on Fri, 31 Aug 2018 20:24:18, noad...@nowhere.net wrote:
> Aug 29 12:39:20 mybox sm-mta[26195]: STARTTLS=server, error: accept
> failed=0, SSL_error=5, errno=0, retry=-1, relay=xxx.com [xx.xx.xx.xx]
There's several mail services out there (notably Hotmail / outlook.com) that
seem to expect certain configuration details (key size, dh parameters, ???)
from a TLS peer, and drop the link otherwise.
I don't think I ever managed to work out all the specifics, and gave up on
communication with outlook.com (there's a "Srv_Features:outlook.com S" in
my access db, though I don't assume that really does whatever I thought at
the time).
Alex.
...on Fri, 31 Aug 2018 20:24:18, noad...@nowhere.net wrote:
> Aug 29 12:39:20 mybox sm-mta[26195]: STARTTLS=server, error: accept
> failed=0, SSL_error=5, errno=0, retry=-1, relay=xxx.com [xx.xx.xx.xx]
seem to expect certain configuration details (key size, dh parameters, ???)
from a TLS peer, and drop the link otherwise.
I don't think I ever managed to work out all the specifics, and gave up on
communication with outlook.com (there's a "Srv_Features:outlook.com S" in
my access db, though I don't assume that really does whatever I thought at
the time).
Alex.
Claus Aßmann
Sep 1, 2018, 9:07:16 AM9/1/18
to
Clark Smith wrote:
> I am guessing that 'verify=NOT' means that my self-signed
> certificate could not be verified, but that is not a problem for me.
Maybe reading the documentation would be better than "guessing"?
> I am guessing that 'verify=NOT' means that my self-signed
> certificate could not be verified, but that is not a problem for me.
${verify}
The result of the verification of the presented
cert; only defined after STARTTLS has been used
(or attempted). Possible values are:
....
NOT no cert requested.
--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.
Clark Smith
Sep 1, 2018, 9:48:56 AM9/1/18
to
On Sat, 01 Sep 2018 13:07:15 +0000, Claus Aßmann wrote:
> Clark Smith wrote:
>
>> I am guessing that 'verify=NOT' means that my self-signed
>> certificate could not be verified, but that is not a problem for me.
>
> Maybe reading the documentation would be better than "guessing"?
>
> ${verify}
> The result of the verification of the presented cert; only
> defined after STARTTLS has been used (or attempted).
> Possible values are:
> ....
> NOT no cert requested.
Thanks. Any ideas on how to debug the log entries that I pointed
> Clark Smith wrote:
>
>> I am guessing that 'verify=NOT' means that my self-signed
>> certificate could not be verified, but that is not a problem for me.
>
> Maybe reading the documentation would be better than "guessing"?
>
> ${verify}
> The result of the verification of the presented cert; only
> defined after STARTTLS has been used (or attempted).
> Possible values are:
> ....
> NOT no cert requested.
out? Since I posted I noticed that other MTAs are eliciting similar
entries. I am trying to ascertain whether it is me, doing something
wrong, or the remote MTA. For example, is it the case that some MTAs will
refuse to do business with MTAs that present self-signed certificates?
Claus Aßmann
Sep 2, 2018, 11:02:28 PM9/2/18
to
Clark Smith wrote:
> I recently started running a sendmail with TLS. In order to do
Which version?
> I recently started running a sendmail with TLS. In order to do
> Aug 29 12:39:20 mybox sm-mta[26195]: STARTTLS=server, error: accept
> failed=0, SSL_error=5, errno=0, retry=-1, relay=xxx.com [xx.xx.xx.xx]
Either upgrade to a new version or increase the LogLevel to
get some more info.
Some crappy services (like Yahoo, Mailgun) do not "like" unknown CAs
and prefer to send mail in the clear instead... rather stupid, but...
Clark Smith
Sep 3, 2018, 9:55:35 AM9/3/18
to
On Mon, 03 Sep 2018 03:02:27 +0000, Claus Aßmann wrote:
> Clark Smith wrote:
>> I recently started running a sendmail with TLS. In order to do
>
> Which version?
8.14.4.
> Clark Smith wrote:
>> I recently started running a sendmail with TLS. In order to do
>
> Which version?
>> Aug 29 12:39:20 mybox sm-mta[26195]: STARTTLS=server, error: accept
>> failed=0, SSL_error=5, errno=0, retry=-1, relay=xxx.com [xx.xx.xx.xx]
>
> SSL_ERROR_SYSCALL 5 /* look at error stack/return value/errno */
>
> Either upgrade to a new version or increase the LogLevel to get some
> more info.
it, but I don't seem to be getting anything that was not getting before
after that.
What level should I use?
> Some crappy services (like Yahoo, Mailgun) do not "like" unknown CAs and
> prefer to send mail in the clear instead... rather stupid, but...
triggering this.
Claus Aßmann
Sep 3, 2018, 10:09:40 AM9/3/18
to
Clark Smith wrote:
> On Mon, 03 Sep 2018 03:02:27 +0000, Claus Aßmann wrote:
> > Either upgrade to a new version or increase the LogLevel to get some
> > more info.
> I launched it as -d0.14. It gave me some extra info when starting
That's debug info, not LogLevel.
> On Mon, 03 Sep 2018 03:02:27 +0000, Claus Aßmann wrote:
> > Either upgrade to a new version or increase the LogLevel to get some
> > more info.
> I launched it as -d0.14. It gave me some extra info when starting
> What level should I use?
anyway, with Yahoo etc you probably get something like
certificate unknown
so you should ask them to fix their #$%@^, or
- you can give in and get a free certificate from ..., or
- turn off STARTTLS for those $^&@# as suggested by someone.
Clark Smith
Sep 3, 2018, 11:45:49 AM9/3/18
to
On Mon, 03 Sep 2018 14:09:39 +0000, Claus Aßmann wrote:
> Clark Smith wrote:
> Clark Smith wrote:
>> On Mon, 03 Sep 2018 03:02:27 +0000, Claus Aßmann wrote:
>
>> > Either upgrade to a new version or increase the LogLevel to get some
>> > more info.
>
>> I launched it as -d0.14. It gave me some extra info when starting
>
> That's debug info, not LogLevel.
I was going by the description of -d in the man pages, but
>
>> > Either upgrade to a new version or increase the LogLevel to get some
>> > more info.
>
>> I launched it as -d0.14. It gave me some extra info when starting
>
> That's debug info, not LogLevel.
looking further down I understand what you mean.
>
>> What level should I use?
>
> Try 10 (at least).
Clark Smith
Sep 5, 2018, 5:07:34 PM9/5/18
to
On Mon, 03 Sep 2018 14:09:39 +0000, Claus Aßmann wrote:
> Clark Smith wrote:
>> On Mon, 03 Sep 2018 03:02:27 +0000, Claus Aßmann wrote:
>
>> > Either upgrade to a new version or increase the LogLevel to get some
>> > more info.
>
>> I launched it as -d0.14. It gave me some extra info when starting
>
> That's debug info, not LogLevel.
>
>> What level should I use?
>
> Try 10 (at least).
>
> anyway, with Yahoo etc you probably get something like certificate
> unknown so you should ask them to fix their #$%@^, or - you can give in
> and get a free certificate from ..., or - turn off STARTTLS for those
> $^&@# as suggested by someone.
Well, I did not get anything much of interest with LogLevel 10.
>
>> > Either upgrade to a new version or increase the LogLevel to get some
>> > more info.
>
>> I launched it as -d0.14. It gave me some extra info when starting
>
> That's debug info, not LogLevel.
>
>> What level should I use?
>
> Try 10 (at least).
>
> anyway, with Yahoo etc you probably get something like certificate
> unknown so you should ask them to fix their #$%@^, or - you can give in
> and get a free certificate from ..., or - turn off STARTTLS for those
> $^&@# as suggested by someone.
However, since turning off STARTTLS for those that are choking on my
certificate works fine, and the stuff they are sending me is not all that
sensitive, I'll tentatively declare this closed.
0 new messages