On 2017-06-22 23:46, Jeremy Harris wrote:
> > I had some major changes to my setup due to the stack whale.
>
> The what?
Do I really have to use the (TM) name ? :-)
Anyway, had to upgrade from jessie to stretch, and accept more SMTP calls
directly instead of through a gateway whose bugs I was at least familiar
with.
> > 2017-06-21 22:23:56 SMTP connection from [66.163.186.85]:34461 (TCP/IP connection count = 1)
> > 2017-06-21 22:23:59 TLS error on connection from
> > sonic318-23.consmr.mail.ne1.yahoo.com [66.163.186.85]:34461 (gnutls_handshake):\
> > A TLS fatal alert has been received.
> We can't tell from that info why the first connection had a problem
> except tat it was TLS-related. Consider cipher-list mismatches,
The cipher config on my side is:
tls_require_ciphers = NORMAL:!VERS-SSL3.0
any known problems with that?
Can I (at least potentially) get more infomation about cipher mismatches
in exim logs? My logging filter is:
log_selector = +smtp_connection +incoming_port -acl_warn_skipped
(I see from the Spec, 52.15, that tls_cipher is already on by default.)
> > 2017-06-21 22:23:59 Connection from [66.163.186.85]:33111 refused: too many connections from that IP address
> > 2017-06-21 22:24:00 SMTP connection from sonic318-23.consmr.mail.ne1.yahoo.com [66.163.186.85]:34461 closed by EOF
> >
> > There is always the 2nd simultaneous connection from the same host. I have
> >
> > smtp_accept_max_per_host = 1
> >
> > I _think_ that is not relevant, but just in case.
>
> It's relevant to the second connection you logged being refused (note
> the port number difference).
Of course. I slipped into my normal terse mode there :-(. I really
meant:
Is it possible that the fact I prevent the second connection from being
made is what stops the mail from getting through at all? For example,
is it possible that some stupid homebaked yahoo code, seeing that its
first choice of cipher is unavailable, immediately makes a 2nd
connection hoping for better luck with another cipher?
> or certificate-verification issues.
This is a possibility, as the CN of my certificate didn't match my
domain. I have corrected that now. But, I thought that didn't matter
for SMTP? After all the certificate is self-signed, so I could make it
whatever I wanted.
> Run in debug mode and see if you can get more detailed info (problem
> is, it's the peer cancelling the TLS connection; it may be we don't
> have any reason at our end). Try using cmdline tools to investigate.
Difficulty in coordinating with the sending party. But I'll keep that
in mind.
--
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign:
http://primate.net/~itz/blog/the-problem-with-gpg-signatures.html
