Re: [OpenSMTPD] portable snapshot opensmtpd-201505121836p1 available

2015-05-15 Thread Ashish SHUKLA
On Tue, 12 May 2015 18:36:42 +0200 (CEST), gilles chehade gil...@poolp.org 
said:
| A new opensmtpd portable snapshot is available at:

| http://www.opensmtpd.org/archives/opensmtpd-201505121836p1.tar.gz

| Checksum:

|   SHA256 (opensmtpd-201505121836p1.tar.gz) =
|   42ccd5cd13377cc84e7040bf0e92a2277ef311c5c27d5dc731abed085a4e6507

| A summary of the content of this snapshot is available below.

| Please test and let us know if it breaks something!

Tested on FreeBSD 10.x with OpenSSL 1.0.2. Certificate verification which was
unexpectedly failing with previous snapshot earlier, and seems to work as
expected now.

HTH
-- 
Ashish SHUKLA

“There was truth and there was untruth, and if you clung to the truth even
against the whole world, you were not mad.” (George Orwell, Nineteen
Eighty-Four, 1949)

Sent from my Emacs


signature.asc
Description: PGP signature


Re: IO Error: tlsv1 alert decode error

2015-05-15 Thread Gilles Chehade
On Wed, May 13, 2015 at 01:27:44PM +0200, Eric Ripa wrote:
 Okay. So I've looked further into this, the destination MX record contains 6 
 addresses. The first 5 generates the below TLS IO Error, but the 6th doesn't 
 seem to be up to respond on SMTP queries. So what I believe is happening is 
 that OpenSMTPD retries all alternative MX records when TLS is failing on the 
 first ones.. but then the last isn't up so it lingers with  'Network error on 
 destination MXs'
 
 Any input on how to do a workaround? Is it possible to force non-tls on 
 certain destinations or change the fallback algorithm? 
 

I'll have a look today


-- 
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: [OpenSMTPD] portable snapshot opensmtpd-201505121836p1 available

2015-05-15 Thread Seth
On Fri, 15 May 2015 13:22:40 -0700, Gilles Chehade gil...@poolp.org  
wrote:
This is now fixed in git, will be part of next snapshot to be published  
this week-end


That did the trick, thanks.

BTW, if you're running FreeBSD and installing over a packaged version, you  
probably need to remove some symlinks first or the 'make install' step  
will fail.


rm /usr/local/bin/sendmail /usr/local/sbin/newaliases  
/usr/local/sbin/mailq; make install


--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org



TLS Policy Database and the 'relay tls verify' option....like peas and carrots?

2015-05-15 Thread Seth
There's been some discussion on the list recently about using the 'relay  
tls verify' to mitigate STARTTLS downgrade attacks. [1]


Gilles suggested using something like this in smtpd.conf as a protective  
measure:


table validcrt file:/etc/mail/hosts-with-valid-certs
accept for domain validcrt relay tls verify

The question then becomes, how to build the list of domains in the  
'validcrt' table.


I've been performing this manually by applying some text processing tools  
to the maillogs , but figured there has to be a better way.


The other week I noticed a host 'tls-scan.informatik.uni-bremen.de'  
showing up in my spamd logs. I visited the web page and found this  
statement on their web site:


The TLS Policy Database collects information about the TLS capability and  
certificate validity of mailservers on the internet. We provide a simple  
DNS based database to help you to secure you outgoing email connections.  
[2]


Perfect! This could be a useful resource for building a table of STARTTLS  
capable mailservers that present verifiable certificates. Combine that  
with a rule using the 'relay tls verify' option and I believe this would  
greatly improve email transport security.


[1] http://www.mail-archive.com/misc%40opensmtpd.org/msg01967.html
[2] http://tls-scan.informatik.uni-bremen.de/

--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org



Re: IO Error: tlsv1 alert decode error

2015-05-15 Thread Eric Ripa
Hi Gilles,

I don’t know how far you got with this. I have resolved the issue, cause 
unknown.

First, I actually had 5.4.3 and not 5.4.4. I was certain that I had upgraded. 
Anyway… so I simply shutdown smtpd, upgraded to 5.4.5 and booted it up again. 
Then rescheduling the emails worked fine much better  with proper downgrade.

Hopefully it was fixed by the version change (something in this area probably 
changed as the message formatting was a bit different).

Heres a log excerpt:

May 15 23:08:13 mail smtpd[5853]: smtp-out: Connecting to 
smtp+tls://[REDACTED]:25 (mms.[REDACTED].com) on session c1bf6e17bee0f395...
May 15 23:08:13 mail smtpd[5853]: smtp-out: Connected on session 
c1bf6e17bee0f395
May 15 23:08:17 mail smtpd[5853]: smtp-out: TLS Error on session 
c1bf6e17bee0f395: TLS failed, downgrading to plain
May 15 23:08:17 mail smtpd[5853]: smtp-out: Connecting to smtp://[REDACTED]:25 
(mms.[REDACTED].com) on session c1bf6e17bee0f395...
May 15 23:08:17 mail smtpd[5853]: smtp-out: Connected on session 
c1bf6e17bee0f395
May 15 23:08:19 mail smtpd[5853]: relay: Ok for bc9c69f19a657426: 
session=c1bf6e17bee0f395, from=[REDACTED], to=[REDACTED], rcpt=-, 
source=192.168.132.233, relay=[REDACTED] (mms.[REDACTED].com), d
elay=2d23m40s, stat=250 ok:  Message 64860805 accepted
May 15 23:08:29 mail smtpd[5853]: smtp-out: Closing session c1bf6e17bee0f395: 1 
message sent.


Thanks for any effort you put into this!

Eric

 On 15 May 2015, at 09:46, Gilles Chehade gil...@poolp.org wrote:
 
 On Wed, May 13, 2015 at 01:27:44PM +0200, Eric Ripa wrote:
 Okay. So I've looked further into this, the destination MX record contains 6 
 addresses. The first 5 generates the below TLS IO Error, but the 6th doesn't 
 seem to be up to respond on SMTP queries. So what I believe is happening is 
 that OpenSMTPD retries all alternative MX records when TLS is failing on the 
 first ones.. but then the last isn't up so it lingers with  'Network error 
 on destination MXs'
 
 Any input on how to do a workaround? Is it possible to force non-tls on 
 certain destinations or change the fallback algorithm? 
 
 
 I'll have a look today
 
 
 -- 
 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