> The advice to use the MX record to 'redirect' email for client-domain.net to
> mail.server.com (for example) will work happily.
>
> However (referring to the OP's use case), won't the client (say a
> Thunderbird user) be presented with the LE certificate for server.com and
> not one from his ow
On Thu, Jul 19, 2018 at 11:15:34PM -0700, dln wrote:
> The advice to use the MX record to 'redirect' email for client-domain.net to
> mail.server.com (for example) will work happily.
>
> However (referring to the OP's use case), won't the client (say a
> Thunderbird user) be presented with the L
Apologies if 'jumping in'.
The advice to use the MX record to 'redirect' email for client-domain.net to
mail.server.com (for example) will work happily.
However (referring to the OP's use case), won't the client (say a
Thunderbird user) be presented with the LE certificate for server.com and
not
Jul 19 13:40:39 mx31 postfix-p25/smtpd[96635]: NOQUEUE:
client=mail.rosedale.ca[66.135.118.147]
Jul 19 13:40:39 mx31 postfix-p25/smtpd[96635]: lost connection after
DATA (0 bytes) from mail.rosedale.ca[66.135.118.147]
Jul 19 13:40:39 mx31 postfix-p25/smtpd[96635]: disconnect from
mail.
On Thu, Jul 19, 2018 at 02:30:52PM -0400, James B. Byrne wrote:
> > You really need to show more of the (non-verbose) logging for this
> > session and the below. You're cutting out critical context.
>
> Jul 19 13:40:39 mx31 postfix-p25/smtpd[96635]: NOQUEUE:
> client=mail.rosedale.ca[66.135.11
On Thu, July 19, 2018 10:19, Viktor Dukhovni wrote:
>
> This does not look *at all* similar to me. The client sent:
>
> EHLO
> STARTTLS + TLS complete handshake
> EHLO(inside TLS encrypted stream)
> MAIL FROM: (inside TLS encrypted stream)
> RCPT T
On Thu, July 19, 2018 10:42, Viktor Dukhovni wrote:
> On Thu, Jul 19, 2018 at 10:22:38AM -0400, James B. Byrne wrote:
>
>> After changing the client certificate request to 'no' we get a
>> little further in the negotiation but it still fails:
>
> No, you get 100% of the way through the TLS handsh
On Thu, Jul 19, 2018 at 10:22:38AM -0400, James B. Byrne wrote:
> After changing the client certificate request to 'no' we get a little
> further in the negotiation but it still fails:
No, you get 100% of the way through the TLS handshake, the problem
is with SMTP inside the now encrypted channel
After changing the client certificate request to 'no' we get a little
further in the negotiation but it still fails:
. . .
Jul 19 09:31:37 mx32 postgrey[29869]: action=pass, reason=triplet
found, client_name=mail.rosedale.ca, client_address=66.135.118.147,
sender=jtho...@connectrans.com, recipient
On Thu, Jul 19, 2018 at 09:14:30AM -0400, James B. Byrne wrote:
> We are encountering errors with several domains similar to the one
> reported by samba.org:
>
> Jul 18 22:36:38 mx31 postfix-p25/smtpd[17802]: lost connection after
> DATA (0 bytes) from mailroot5.namespro.ca[158.85.87.68]
> Jul 18
On Wed, July 11, 2018 14:13, James B. Byrne wrote:
> On Wed, July 11, 2018 11:12, Viktor Dukhovni wrote:
>> On Wed, Jul 11, 2018 at 10:13:48AM -0400, James B. Byrne wrote:
>>
>>> > The connecting client did not like one of the certificates in the
>>> > chain. Perhaps it expected to find a workin
11 matches
Mail list logo