Disconnecting session 5fd878b9641e7bb7: CA failure

[Óscar Rubén Cuéllar Valcárcel]

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

[jung]

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

[Gilles Chehade]

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

[Marcus MERIGHI]

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 to  will 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