I believe the new format is more restrictive, directly associating the ssl cert 
with the destination.  In this case the cert may have always been failing to 
match the hostname, and smtpd was just rolling with it.  Edge cases like this 
seem to be why the syntax change was necessary, so you could specify the 
behavior on failure to establish tls to destination.  Default smtp behavior is 
to opportunistically use tls, but gracefully fail to plaintext rather than fail 
to send.

Nice documentation of your problem and fix for the list.  :-)

   ED.


> On Nov 19, 2023, at 2:08 AM, paul <p...@lotek.nz> wrote:
> 
> Ok, I seem to have made this work. I replaced mydomain.com (which is really 
> just an alias) in the action clause, with the server's name from the hosting 
> provider, and messages are now being accepted and delivered.
> 
> Thanks to anybody who looked at this. I am curious as to why this may have 
> happened ’though, if anybody cares to comment.
> 
> Thanks,
> Paul.
> 
> 
> 
>> On 19/11/2023, at 2:20 PM, paul <p...@lotek.nz> wrote:
>> 
>> Hi list,
>> 
>> Some time ago I set up opensmtpd on a debian device to forward emails to a 
>> remote mailserver for delivery. It's been working beautifully for a couple 
>> of years now, and continues to do so. Now I'm attempting to set up a similar 
>> device the same way however I cannot get the smptd.conf file to work with 
>> the new format.
>> 
>> I've read the man page and found a number of examples on the web with subtle 
>> differences, but I havnt been able to get anything to work.
>> 
>> Here is the old, working .conf file:
>> listen on localhost
>> table aliases file:/etc/aliases
>> table secrets file:/etc/secrets
>> accept for local alias <aliases> deliver to mbox
>> accept for any relay via tls+auth://p...@mydomain.com auth <secrets>
>> 
>> And here is what I'm trying:
>> table aliases file:/etc/aliases
>> table secrets file:/etc/secrets
>> listen on localhost
>> action "localmail" mbox alias <aliases>
>> action "outbound" relay host smtp+tls://p...@mydomain.com auth <secrets>
>> match from local for local action "localmail"
>> match from local for any action "outbound"
>> 
>> Here are some snippets from the syslogs
>> old way - working
>> Nov 19 13:31:45 pumpshed smtpd[631]: 311de33e8257add4 mta event=connected
>> Nov 19 13:31:47 pumpshed smtpd[631]: 311de33e8257add4 mta event=starttls 
>> ciphers=version=TLSv1.2, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256
>> Nov 19 13:31:47 pumpshed smtpd[631]: smtp-out: Server certificate 
>> verification succeeded on session 311de33e8257add4
>> 
>> new way - fails:
>> Nov 19 13:30:14 play1 smtpd[28337]: 94dbb1ad70252b45 mta connected
>> Nov 19 13:30:15 play1 smtpd[28337]: 94dbb1ad70252b45 mta tls 
>> ciphers=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
>> Nov 19 13:30:16 play1 smtpd[28337]: 94dbb1ad70252b45 mta ssl_check_name: no 
>> match for 'no-tek.com' in cert
>> Nov 19 13:30:16 play1 smtpd[28337]: 94dbb1ad70252b45 mta error reason=SSL 
>> certificate check failed
>> 
>> Is the new version more restrictive that the old? Is there anything I'm 
>> missing to achieve this functionality? Or is there a better way than what 
>> I'm attemptin?
>> 
>> Thanks for any help with this.
>> Paul
>> 
>> 
>> 
> 


Reply via email to