Disconnecting session 5fd878b9641e7bb7: CA failure
Hi, When I recibe a mail from hotmail or gmail, I have a failure. In maillog I can see: smtp-in: New session 5fd878b9641e7bb7 from host blu004-omc2s17.hotmail.com [65.55.111.92] smtp-in: Disconnecting session 5fd878b9641e7bb7: CA failure In my smtpd.conf pki mail.enabler.com.mx certificate "/etc/ssl/mail.enabler.com.mx.crt" pki mail.enabler.com.mx key "/etc/ssl/private/mail.enabler.com.mx.key" >From others smtp server I don't have any problem. Can someone help me? Thanks in advance -- Óscar Rubén Cuéllar Valcárcel Ama et fac quod vis -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
[OpenSMTPD] opensmtpd-extra master snapshot opensmtpd-extras-201605232202 available
A new opensmtpd-extras snapshot is available at: http://www.opensmtpd.org/archives/opensmtpd-extras-201605232202.tar.gz Checksum: SHA256 (opensmtpd-extras-201605232202.tar.gz) = dd61a16f4d4e553ef68b9ea9673f2b543b23b78f37a0975f62007204797ff7c6 A summary of the content of this snapshot is available below. Please test and let us know if it breaks something! If this snapshot doesn't work, please also test with a previous one, to help us spot where the issue is coming from. You can access all previous snapshots here: http://www.opensmtpd.org/archives/ The OpenSMTPD team ;-) Summary of changes since last snapshot (opensmtpd-extras-201605221324): -- - if no valid pipe received, don't call socketpair() to avoid fd leak - reintroduce the reset callback and update documentation - try to tweal and clarify the callback documentation - sync filters main return values - cleanup filter message state cleanup functions -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Incoming certificate verification
On Mon, May 23, 2016 at 10:19:42AM +0100, John Cox wrote: > Hi > > > [snip] > >yes, the rationale is explained in the commit log: > > > > Only enable SSL_VERIFY_PEER when the verify option is set on a listener. > > > > Always enabling SSL_VERIFY_PEER unnecessarily increases the number of > > messages/bytes in the TLS handshake and increases our attack surface, > > since we request and then process client certificates. > > Well I guess I disagree with the "unnecessarily" there, but thanks for > the info. If I got together the effort to build a patch that gives an > option to restore the old behaviour would: > > (a) there be any chance of the patch being accepted (i.e. is it > against policy to allow this option to be enabled) > (b) you prefer it to be a global or per-connection option and what > would you like the syntax to be? > > (No guarantees that I will be able to find the time but given it is > functionality that I want I guess I should try and put in the effort) > well, one way the patch would be accepted is if it adds an optional check feature so that: listen on [...] tls check listen on [...] tls-require check this would be optional and require explicit setting, it's just not going to be the default setup. -- Gilles Chehade https://www.poolp.org @poolpOrg -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Newbie questions
ed...@pettijohn-web.com (Edgar Pettijohn), 2016.05.21 (Sat) 20:32 (CEST): > > > On 05/20/16 13:26, Olivier Brunel wrote: > > Hello, > > > > I'm new to OpenSMTPD and while this looks really good so far, and with a > > configuration that can be both simple yet powerful/flexible at once, > > even after reading the man pages I still find myself with a few > > questions I can't answer, so I'm hoping I can get some help. > > > > * To make sure: whenever a mapping is used (virtual domains/users, > >aliases...) it always means there *needs* to be a match, and if not > >the rule "fails" and smtpd will move on to the next rule, rejecting > >the message if no other (matching) rule is found -- correct? > >For some cases the doc clearly states so, but not for others, so I'm > >unsure if that's just implied as well, or what's the behavior then? > When a message comes in it checks each rule from top to bottom until it > finds a match. First match wins. This of course is right regarding *access rules*. I just want to warn that "alias" and "virtual" are not part of the access rule. But "recipient" is. Examples to explain my experiences follow: An email towill only be delivered if that address is in , not if it's in : accept from any to "domain1.com" alias accept from any to "domain1.com" alias The same applies for "virtual". On the other hand, if you use "recipient", it is part of the access rule; in the example below the email will be delivered even if is only in . accept from any to "domain1.com" recipient relay ... accept from any to "domain1.com" recipient relay ... This is what my testing showed. Clue sticks appreciated! Bye, Marcus -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org