Re: Postfix cannot start tls: handshake failure

2017-03-29 Thread Viktor Dukhovni 

> On Mar 30, 2017, at 12:03 AM, Den1  wrote:
> 
>> smtp_tls_ciphers = medium
>> smtp_tls_exclude_ciphers =
>> MD5,SRP,PSK,aDSS,kECDH,kDH,SEED,IDEA,RC2,RC5,RC4
> 
> Why would you exclude these ciphers

Because:

  * MD5 is weak, obsolete and unnecessary
  * SRP and PSK require special code to use, and excluding these
is actually a NOOP, but makes clearer that they'll never be used.
  * DSS is weak, obsolete and unnecessary
  * The kECDH and kDH "fixed DH" algorithms should never have been added
to OpenSSL and were removed in OpenSSL 1.1.0.  They are not needed.
  * SEED, IDEA, RC2, and RC5 are are never used and are not needed.
  * RC4 is weak and no longer needed.
  
Shorter cipherlists avoid some interoperability issues.  Especially
with older Windows systems, but to interoperate with those you'd need
to leave RC4 enabled.  Such systems have largely been replaced, you're
not likely to run into them.

> and make them medium, Louis? 

The cipher grade in Postfix sets a "floor" on the ciphers used, that
is only medium or better.  Nobody is "making them medium":

http://www.postfix.org/postconf.5.html#smtp_tls_ciphers

-- 
Viktor.

RE: Postfix cannot start tls: handshake failure

2017-03-29 Thread Den1 
L.P.H. van Belle wrote
> smtp_tls_ciphers = medium
> smtp_tls_exclude_ciphers =
> MD5,SRP,PSK,aDSS,kECDH,kDH,SEED,IDEA,RC2,RC5,RC4
> 
> Greetz, 
> Louis

Why would you exclude these ciphers and make them medium, Louis? 






--
View this message in context: 
http://postfix.1071664.n5.nabble.com/Postfix-cannot-start-tls-handshake-failure-tp89684p89748.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Re: Queue ID availability for milters on multi-message connections/sessions?

2017-03-29 Thread Wietse Venema 
Below are the SMTP commands/responses, and the test-milter output
showing that the second "DATA" event is reported with the correct
queue ID.

Wietse

$ telnet 127.0.0.1 smtp
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
220-wzv.porcupine.org ESMTP Postfix
220 wzv.porcupine.org ESMTP Postfix
ehlo wzv.porcupine.org
250-wzv.porcupine.org
250-PIPELINING
250-SIZE 1024
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 SMTPUTF8
mail from:<>
250 2.1.0 Ok
rcpt to:
250 2.1.5 Ok
data
354 End data with .
blah
.
250 2.0.0 Ok: queued as 8E063A009F
mail from:<>
250 2.1.0 Ok
rcpt to:
250 2.1.5 Ok
data
354 End data with .
blah
.
250 2.0.0 Ok: queued as 2751DA009E
quit
221 2.0.0 Bye
Connection closed by foreign host.
$ exit
exit

$ ./test-milter -d 1 -p inet:@127.0.0.1
test_connect localhost AF_INET (127.0.0.1:44670)
macro: j="wzv.porcupine.org"
macro: v="Postfix 3.3-20170212"
macro: {daemon_addr}="127.0.0.1"
macro: {daemon_name}="wzv.porcupine.org"
test_reply 0

test_helo "wzv.porcupine.org"
macro: j="wzv.porcupine.org"
macro: v="Postfix 3.3-20170212"
macro: {daemon_addr}="127.0.0.1"
macro: {daemon_name}="wzv.porcupine.org"
test_reply 0

test_mail "<>"
macro: j="wzv.porcupine.org"
macro: v="Postfix 3.3-20170212"
macro: {daemon_addr}="127.0.0.1"
macro: {daemon_name}="wzv.porcupine.org"
macro: {mail_addr}=""
macro: {mail_host}="wzv.porcupine.org"
macro: {mail_mailer}="local"
test_reply 0

test_rcpt ""
macro: j="wzv.porcupine.org"
macro: v="Postfix 3.3-20170212"
macro: {daemon_addr}="127.0.0.1"
macro: {daemon_name}="wzv.porcupine.org"
macro: {mail_addr}=""
macro: {mail_host}="wzv.porcupine.org"
macro: {mail_mailer}="local"
macro: {rcpt_addr}="wietse@localhost"
macro: {rcpt_host}="wzv.porcupine.org"
macro: {rcpt_mailer}="local"
test_reply 0

test_data
macro: i="8E063A009F"
macro: j="wzv.porcupine.org"
macro: v="Postfix 3.3-20170212"
macro: {daemon_addr}="127.0.0.1"
macro: {daemon_name}="wzv.porcupine.org"
macro: {mail_addr}=""
macro: {mail_host}="wzv.porcupine.org"
macro: {mail_mailer}="local"
macro: {rcpt_addr}="wietse@localhost"
macro: {rcpt_host}="wzv.porcupine.org"
macro: {rcpt_mailer}="local"
test_reply 0

test_header "Message-Id" "<20170329233029.8e063a0...@wzv.porcupine.org>"
macro: i="8E063A009F"
macro: j="wzv.porcupine.org"
macro: v="Postfix 3.3-20170212"
macro: {daemon_addr}="127.0.0.1"
macro: {daemon_name}="wzv.porcupine.org"
macro: {mail_addr}=""
macro: {mail_host}="wzv.porcupine.org"
macro: {mail_mailer}="local"
macro: {rcpt_addr}="wietse@localhost"
macro: {rcpt_host}="wzv.porcupine.org"
macro: {rcpt_mailer}="local"
test_reply 0

test_header "Date" "Wed, 29 Mar 2017 19:30:20 -0400 (EDT)"
macro: i="8E063A009F"
macro: j="wzv.porcupine.org"
macro: v="Postfix 3.3-20170212"
macro: {daemon_addr}="127.0.0.1"
macro: {daemon_name}="wzv.porcupine.org"
macro: {mail_addr}=""
macro: {mail_host}="wzv.porcupine.org"
macro: {mail_mailer}="local"
macro: {rcpt_addr}="wietse@localhost"
macro: {rcpt_host}="wzv.porcupine.org"
macro: {rcpt_mailer}="local"
test_reply 0

test_header "From" "MAILER-DAEMON"
macro: i="8E063A009F"
macro: j="wzv.porcupine.org"
macro: v="Postfix 3.3-20170212"
macro: {daemon_addr}="127.0.0.1"
macro: {daemon_name}="wzv.porcupine.org"
macro: {mail_addr}=""
macro: {mail_host}="wzv.porcupine.org"
macro: {mail_mailer}="local"
macro: {rcpt_addr}="wietse@localhost"
macro: {rcpt_host}="wzv.porcupine.org"
macro: {rcpt_mailer}="local"
test_reply 0

test_eoh
macro: i="8E063A009F"
macro: j="wzv.porcupine.org"
macro: v="Postfix 3.3-20170212"
macro: {daemon_addr}="127.0.0.1"
macro: {daemon_name}="wzv.porcupine.org"
macro: {mail_addr}=""
macro: {mail_host}="wzv.porcupine.org"
macro: {mail_mailer}="local"
macro: {rcpt_addr}="wietse@localhost"
macro: {rcpt_host}="wzv.porcupine.org"
macro: {rcpt_mailer}="local"
test_reply 0

test_body 6 bytes
macro: i="8E063A009F"
macro: j="wzv.porcupine.org"
macro: v="Postfix 3.3-20170212"
macro: {daemon_addr}="127.0.0.1"
macro: {daemon_name}="wzv.porcupine.org"
macro: {mail_addr}=""
macro: {mail_host}="wzv.porcupine.org"
macro: {mail_mailer}="local"
macro: {rcpt_addr}="wietse@localhost"
macro: {rcpt_host}="wzv.porcupine.org"
macro: {rcpt_mailer}="local"
test_reply 0

test_eom
macro: i="8E063A009F"
macro: j="wzv.porcupine.org"
macro: v="Postfix 3.3-20170212"
macro: {daemon_addr}="127.0.0.1"
macro: {daemon_name}="wzv.porcupine.org"
macro: {mail_addr}=""
macro: {mail_host}="wzv.porcupine.org"
macro: {mail_mailer}="local"
macro: {rcpt_addr}="wietse@localhost"
macro: {rcpt_host}="wzv.porcupine.org"
macro: {rcpt_mailer}="local"
test_reply 0

test_mail "<>"
macro: j="wzv.porcupine.org"
macro: v="Postfix 3.3-20170212"
macro: {daemon_addr}="127.0.0.1"
macro: {daemon_name}="wzv.porcupine.org"
macro: {mail_addr}=""
macro: {mail_host}="wzv.porcupine.org"
macro: {mail_mailer}="local"
test_reply 0

test_rcpt ""
macro: j="wzv.porcupine.org"
macro: v="Postfix 3.3-20170212"
macro:

Re: Queue ID availability for milters on multi-message connections/sessions?

2017-03-29 Thread Wietse Venema 
Kris Deugau:
> Mar 29 16:35:14 jessie64 postfix/smtpd[17537]: connect from 
> localhost[127.0.0.1]
> Mar 29 16:35:27 jessie64 postfix/smtpd[17537]: 26F5E428A4: 
> client=localhost[127.0.0.1]
> Mar 29 16:36:02 jessie64 postfix/cleanup[17556]: 26F5E428A4: 
> message-id=
> Mar 29 16:36:03 jessie64 mimedefang.pl[17552]: 26F5E428A4: 
> clientip=127.0.0.1 smtpauth= from=kdeu...@deepnet.cx to=f...@example.com 
> messageid="" queueid=26F5E428A4"
> Mar 29 16:36:03 jessie64 postfix/qmgr[17527]: 26F5E428A4: 
> from=, size=324, nrcpt=1 (queue active)
> Mar 29 16:36:03 jessie64 postfix/local[17557]: 26F5E428A4: 
> to=, orig_to=, relay=local, 
> delay=42, delays=42/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to 
> command: procmail -a "$EXTENSION")
> Mar 29 16:36:03 jessie64 postfix/qmgr[17527]: 26F5E428A4: removed
> Mar 29 16:36:17 jessie64 postfix/smtpd[17537]: 55ADB428A4: 
> client=localhost[127.0.0.1]
> Mar 29 16:36:36 jessie64 postfix/cleanup[17556]: 55ADB428A4: 
> message-id=
> Mar 29 16:36:36 jessie64 mimedefang.pl[17552]: clientip=127.0.0.1 
> smtpauth= from=kdeu...@deepnet.cx to=b...@example.com 
> messageid="" queueid=NOQUEUE"
> Mar 29 16:36:36 jessie64 postfix/qmgr[17527]: 55ADB428A4: 
> from=, size=324, nrcpt=1 (queue active)
> Mar 29 16:36:36 jessie64 postfix/local[17557]: 55ADB428A4: 
> to=, orig_to=, relay=local, 
> delay=27, delays=27/0/0/0.03, dsn=2.0.0, status=sent (delivered to 
> command: procmail -a "$EXTENSION")
> Mar 29 16:36:36 jessie64 postfix/qmgr[17527]: 55ADB428A4: removed
> Mar 29 16:36:38 jessie64 postfix/smtpd[17537]: disconnect from 
> localhost[127.0.0.1] helo=1 mail=2 rcpt=2 data=2 quit=1 commands=8

I can't reproduce this. The Milter sends the queue ID as soon as
it is available (when a message has one recipient, that is with the
DATA command), with each message header, with end of headers, with
body, and with end-of-message. Same behavior with the first and
second message in an SMTP session. I observe this with the Postfix
test-milter program, and by looking at a tcpdump recording of the
traffic between Postfix and milter.

This is with default Postfix settings for macros (no milter-dependent
settings):

milter_mail_macros = i {auth_type} {auth_authen} {auth_author} {mail_addr} 
{mail_host} {mail_mailer}
milter_rcpt_macros = i {rcpt_addr} {rcpt_host} {rcpt_mailer}
milter_data_macros = i
milter_end_of_header_macros = i
milter_end_of_data_macros = i

With these settings Postfix dies not send a macro unless it actually
has a value. Postfix never uses NOQUEUE as a queue ID and never
sends NOQUEUE to the milter (confirmed by test-milter program and
tcpdump recording). Thus, your milter is making this up.

Wietse

Re: Queue ID availability for milters on multi-message connections/sessions?

2017-03-29 Thread Kris Deugau 

Wietse Venema wrote:

Kris Deugau:

I came across a bit of an information-passing glitch on a system that
uses a milter (MIMEDefang) to glue together complex filter policies.

MIMEDefang is configured to log sender, first recipient, Message-ID (if
any), and the queue ID, along with some filter result data, for each
message.

This works just fine for messages sent on their own connection.

However, if a remote system sends more than one message during a
connection/session, the queue IDs of the second and further messages are
not passed to/retrieved by the milter;  instead they're logged as
"NOQUEUE".  I've confirmed this works as expected with sendmail, but not
with any version of Postfix up through the current 3.3 snapshot.


Logged as NOQUEUE by Postfix? Milter? Something else? At what
protocol stage?  Envelope? End-of-body? Something else? Actual
logging would clarify a lot. I don't haver the time to drop what
I'm doing and spend hours to reverse engineer your conditions.


Sorry, guess I've been prodding this on and off for too long and forgot 
some of that wasn't as obvious as to me.


The literal 'NOQUEUE' is a placeholder MIMEDefang initializes its local 
reference copy of the i macro to.  smfi_getsymval(ctx, "i") is called in 
five places including end-of-message in the C that talks directly to 
libmilter.  The log action I've added that creates the mimedefang.pl log 
entries below is in a section run at end-of-message.


Here's the full mail log from a test system:

Mar 29 16:35:14 jessie64 postfix/smtpd[17537]: connect from 
localhost[127.0.0.1]
Mar 29 16:35:27 jessie64 postfix/smtpd[17537]: 26F5E428A4: 
client=localhost[127.0.0.1]
Mar 29 16:36:02 jessie64 postfix/cleanup[17556]: 26F5E428A4: 
message-id=
Mar 29 16:36:03 jessie64 mimedefang.pl[17552]: 26F5E428A4: 
clientip=127.0.0.1 smtpauth= from=kdeu...@deepnet.cx to=f...@example.com 
messageid="" queueid=26F5E428A4"
Mar 29 16:36:03 jessie64 postfix/qmgr[17527]: 26F5E428A4: 
from=, size=324, nrcpt=1 (queue active)
Mar 29 16:36:03 jessie64 postfix/local[17557]: 26F5E428A4: 
to=, orig_to=, relay=local, 
delay=42, delays=42/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to 
command: procmail -a "$EXTENSION")

Mar 29 16:36:03 jessie64 postfix/qmgr[17527]: 26F5E428A4: removed
Mar 29 16:36:17 jessie64 postfix/smtpd[17537]: 55ADB428A4: 
client=localhost[127.0.0.1]
Mar 29 16:36:36 jessie64 postfix/cleanup[17556]: 55ADB428A4: 
message-id=
Mar 29 16:36:36 jessie64 mimedefang.pl[17552]: clientip=127.0.0.1 
smtpauth= from=kdeu...@deepnet.cx to=b...@example.com 
messageid="" queueid=NOQUEUE"
Mar 29 16:36:36 jessie64 postfix/qmgr[17527]: 55ADB428A4: 
from=, size=324, nrcpt=1 (queue active)
Mar 29 16:36:36 jessie64 postfix/local[17557]: 55ADB428A4: 
to=, orig_to=, relay=local, 
delay=27, delays=27/0/0/0.03, dsn=2.0.0, status=sent (delivered to 
command: procmail -a "$EXTENSION")

Mar 29 16:36:36 jessie64 postfix/qmgr[17527]: 55ADB428A4: removed
Mar 29 16:36:38 jessie64 postfix/smtpd[17537]: disconnect from 
localhost[127.0.0.1] helo=1 mail=2 rcpt=2 data=2 quit=1 commands=8


and the SMTP transcript:

# telnet localhost 25
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 jessie64.pem-lan ESMTP Postfix
helo local
250 jessie64.pem-lan
mail from:kdeu...@deepnet.cx
250 2.1.0 Ok
rcpt to:f...@example.com
250 2.1.5 Ok
data
354 End data with .
Subject: test
Message-ID: 

test
.
250 2.0.0 Ok: queued as 26F5E428A4
mail from:kdeu...@deepnet.cx
250 2.1.0 Ok
rcpt to:b...@example.com
250 2.1.5 Ok
data
354 End data with .
Subject: test
Message-ID: 

test
.
250 2.0.0 Ok: queued as 55ADB428A4
quit
221 2.0.0 Bye
Connection closed by foreign host.
#


For completeness:
# sbin/postconf -n
alias_database = hash:/opt/pfcustom/etc/aliases
alias_maps = hash:/opt/pfcustom/etc/aliases
append_dot_mydomain = no
biff = no
compatibility_level = 2
default_transport = error
inet_protocols = ipv4
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
mydestination = jessie64.pem-lan, localhost.pem-lan, localhost, 
jessie64.deepnet.cx, jessie64, example.com

myhostname = jessie64.pem-lan
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 192.168.2.0/24
myorigin = jessie64.pem-lan
readme_directory = no
recipient_delimiter = +
relay_transport = error
relayhost =
smtpd_milters = unix:/var/spool/MIMEDefang/mimedefang.sock
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated 
defer_unauth_destination

virtual_alias_maps = texthash:/opt/pfcustom/etc/virtual_alias
#

-kgd

Re: need little help with DKIM, if possible.

2017-03-29 Thread Dominic Raferd 
On 29 March 2017 at 20:36, Fazzina, Angelo  wrote:

> Thank you Doug,
>
> I fixed the name so the unsupported character "_" is not used.
>
> Please review my latest test, as I have a question.
>
>
>
> Is there anything in the DKIM config files I can change to get rid of this
> message ?
>
>
>
> *Authentication-Results: verifier.port25.com ;
> dkim=pass (signature verifies; identity doesn't match any headers)
> header.d=mta4.uits.uconn.edu *
>
>
>
> Am I supposed to get the headers to match ?
>
> DKIM check details:
>
> Result: pass (signature verifies; identity doesn't match any
> headers)
>
> ID(s) verified: header.d=mta4.uits.uconn.edu
>
> Canonicalized Headers:
>
> to:check-a...@verifier.port25.com'0D''0A'
>
> from:"Fazzina,'20'Angelo"'20'< 
> ​​ 
> alf02013@ 
>
> ​​ 
> appmail.uconn.edu >'0D''0A'
>
> date:Wed,'20'29'20'Mar'20'2017'20'15:29:26'20'-0400'0D''0A'
>
> dkim-signature:v=1;'20'a=rsa-sha256;'20'c=relaxed/simple;'20'd=
> 
> ​​ 
> mta4.uits.uconn.edu;'20's=dkim1;'20't=1490815766;'20'bh=
> frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=;'20'h=To:From:
> Date:From;'20'b=
>
>
​The problem I think is that you have set up a dkim record for emails from
domain ​
​
mta4.uits.uconn.edu but you are sending an email from
​
appmail.uconn.edu  (i.e. the internal 'From:'
header is set to
​ 
alf02013@ 
​​ 
appmail.uconn.edu ). Hence the report that the
dkim identity ('d=') doesn't match any headers.

RE: need little help with DKIM, if possible.

2017-03-29 Thread Fazzina, Angelo 
Thank you Doug,

I fixed the name so the unsupported character "_" is not used.

Please review my latest test, as I have a question.



Is there anything in the DKIM config files I can change to get rid of this 
message ?



Authentication-Results: verifier.port25.com; dkim=pass (signature verifies; 
identity doesn't match any headers) header.d=mta4.uits.uconn.edu



Am I supposed to get the headers to match ?





RAW DATA BELOW:



Thank you for using the verifier,



The Port25 Solutions, Inc. team



==

Summary of Results

==

SPF check:  neutral

DomainKeys check:   neutral

DKIM check: pass

SpamAssassin check: ham





--

DKIM check details:

--

Result: pass (signature verifies; identity doesn't match any headers)

ID(s) verified: header.d=mta4.uits.uconn.edu

Canonicalized Headers:

to:check-a...@verifier.port25.com'0D''0A'

from:"Fazzina,'20'Angelo"'20''0D''0A'

date:Wed,'20'29'20'Mar'20'2017'20'15:29:26'20'-0400'0D''0A'


dkim-signature:v=1;'20'a=rsa-sha256;'20'c=relaxed/simple;'20'd=mta4.uits.uconn.edu;'20's=dkim1;'20't=1490815766;'20'bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=;'20'h=To:From:Date:From;'20'b=



Canonicalized Body:

'0D''0A'





DNS record(s):

dkim1._domainkey.mta4.uits.uconn.edu. 60 IN TXT "v=DKIM1; k=rsa; 
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/YIuJIABa9M7Ox5AXs6CP6z26d/i9JDrHW58YU/OzfsEr6yADboIOydCaiiVaNuwtkbxcatzd6/iutxWbAiY51rRAvVdBs2YIoGO6Glzeev66ft8I
 fMnHgxND438KIsdOjUmJZuglFJUWGzCYDSC1eq/zqDVncFwTxWkKW/qtxQIDAQAB"



Public key used for verification: dkim1._domainkey.mta4.uits.uconn.edu (1024 
bits)



NOTE: DKIM checking has been performed based on the latest DKIM specs

(RFC 4871 or draft-ietf-dkim-base-10) and verification may fail for

older versions.  If you are using Port25's PowerMTA, you need to use

version 3.2r11 or later to get a compatible version of DKIM.







==

Original Email

==



Return-Path: 

Received: from mta4.uits.uconn.edu (137.99.25.243) by verifier.port25.com id 
hrg5hc20i3g1 for ; Wed, 29 Mar 2017 15:29:26 
-0400 (envelope-from )

Authentication-Results: verifier.port25.com; spf=neutral (SPF-Result: None) 
smtp.mailfrom=alf02...@appmail.uconn.edu

Authentication-Results: verifier.port25.com; domainkeys=neutral (message not 
signed) header.From=alf02...@appmail.uconn.edu

Authentication-Results: verifier.port25.com; dkim=pass (signature verifies; 
identity doesn't match any headers) header.d=mta4.uits.uconn.edu

Received: from [137.99.80.129] (angelo.uits.uconn.edu [137.99.80.129])

by mta4.uits.uconn.edu (Postfix) with ESMTPSA id 3583C16F

for ; Wed, 29 Mar 2017 15:29:26 
-0400 (EDT)

DKIM-Filter: OpenDKIM Filter v2.11.0 mta4.uits.uconn.edu 3583C16F

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mta4.uits.uconn.edu;

s=dkim1; t=1490815766;

bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=;

h=To:From:Date:From;


b=t9zhBtRbQBNOIsdN1oa5DS51oRGWuczFcpqP+DjgZ8/ezzZk+8VvbHwITT5sGVVHj


CqbJSALLhbkUszq7XjYzV9Ro9A3EzudgNImg5PWL74sbPYdUg4BNiCce8UCqAb2xsh

nRXMvBq1QINwxp+oCOyi6Y4jE7E91NzYdk5v5SiI=

To: check-a...@verifier.port25.com

From: "Fazzina, Angelo" 

Message-ID: <64191897-59d3-6210-f79d-e88b755db...@appmail.uconn.edu>

Date: Wed, 29 Mar 2017 15:29:26 -0400

User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101

Thunderbird/45.4.0

MIME-Version: 1.0

Content-Type: text/plain; charset=utf-8; format=flowed

Content-Transfer-Encoding: 7bit



-Angelo Fazzina

Operating Systems Programmer / Analyst

University of Connecticut,  UITS, SSG, Server Systems

860-486-9075



-Original Message-
From: Doug [mailto:domain_name_t...@yahoo.com]
Sent: Friday, March 17, 2017 1:52 AM
To: postfix-users@postfix.org; Fazzina, Angelo 
Subject: Re: need little help with DKIM, if possible.







On Thu, 3/16/17, Fazzina, Angelo 
> wrote:



Subject: need little help with DKIM, if possible.

To: "postfix-users@postfix.org" 
>

Date: Thursday, March 16, 2017, 12:19 PM



Hi,  I ran this.

 opendkim-genkey -v -D /etc/opendkim/keys/uconn/ -d uconn.edu -s 2017_uconn_DKIM

 which created the private key and selector name



[]

Re: Queue ID availability for milters on multi-message connections/sessions?

2017-03-29 Thread Wietse Venema 
Kris Deugau:
> I came across a bit of an information-passing glitch on a system that 
> uses a milter (MIMEDefang) to glue together complex filter policies.
> 
> MIMEDefang is configured to log sender, first recipient, Message-ID (if 
> any), and the queue ID, along with some filter result data, for each 
> message.
> 
> This works just fine for messages sent on their own connection.
> 
> However, if a remote system sends more than one message during a 
> connection/session, the queue IDs of the second and further messages are 
> not passed to/retrieved by the milter;  instead they're logged as 
> "NOQUEUE".  I've confirmed this works as expected with sendmail, but not 
> with any version of Postfix up through the current 3.3 snapshot.

Logged as NOQUEUE by Postfix? Milter? Something else? At what
protocol stage?  Envelope? End-of-body? Something else? Actual
logging would clarify a lot. I don't haver the time to drop what
I'm doing and spend hours to reverse engineer your conditions.

Wietse

Queue ID availability for milters on multi-message connections/sessions?

2017-03-29 Thread Kris Deugau 
I came across a bit of an information-passing glitch on a system that 
uses a milter (MIMEDefang) to glue together complex filter policies.


MIMEDefang is configured to log sender, first recipient, Message-ID (if 
any), and the queue ID, along with some filter result data, for each 
message.


This works just fine for messages sent on their own connection.

However, if a remote system sends more than one message during a 
connection/session, the queue IDs of the second and further messages are 
not passed to/retrieved by the milter;  instead they're logged as 
"NOQUEUE".  I've confirmed this works as expected with sendmail, but not 
with any version of Postfix up through the current 3.3 snapshot.


Does the milter need the fix near the bottom of 
http://www.postfix.org/MILTER_README.html copied somewhere else?  Or is 
Postfix not (re?)setting this macro after the first message is done with?


-kgd

Re: Why aren't macros available to command syntax in pipe(8)?

2017-03-29 Thread Doug Barton 

On 03/29/2017 10:03 AM, Wietse Venema wrote:

Doug Barton:

On 03/29/2017 04:01 AM, Wietse Venema wrote:

Doug Barton:

Unlike .forward or files which exist for selected users, injecting
envelope data (e.g. user=${user}) into the pipe(8) execution context
could allow remote senders to execute code as any user on the system


Yes, that's what I want to do. :)  Still easily done with a wrapper script.


Use the local(8) delivery agent for delivery as the recipient.


The specific thing I was working on was getting postfix to run
spamassassin as the user, in order to take advantage of the user's bayes
db. I want postfix to deliver the mail with lmtp.


Did you search the web for 'per-user spamassassin'?


Yes. There were numerous more complex solutions, using the macro seemed 
simpler. :)


Like I said, in my OP, I solved that problem without the use of 
user=${user}, I was just curious as to the rationale.


Doug

Re: Why aren't macros available to command syntax in pipe(8)?

2017-03-29 Thread Wietse Venema 
Doug Barton:
> On 03/29/2017 04:01 AM, Wietse Venema wrote:
> > Doug Barton:
> >>> Unlike .forward or files which exist for selected users, injecting
> >>> envelope data (e.g. user=${user}) into the pipe(8) execution context
> >>> could allow remote senders to execute code as any user on the system
> >>
> >> Yes, that's what I want to do. :)  Still easily done with a wrapper script.
> >
> > Use the local(8) delivery agent for delivery as the recipient.
> 
> The specific thing I was working on was getting postfix to run 
> spamassassin as the user, in order to take advantage of the user's bayes 
> db. I want postfix to deliver the mail with lmtp.

Did you search the web for 'per-user spamassassin'?

Wietse

Re: Why aren't macros available to command syntax in pipe(8)?

2017-03-29 Thread Doug Barton 

On 03/29/2017 04:01 AM, Wietse Venema wrote:

Doug Barton:

Unlike .forward or files which exist for selected users, injecting
envelope data (e.g. user=${user}) into the pipe(8) execution context
could allow remote senders to execute code as any user on the system


Yes, that's what I want to do. :)  Still easily done with a wrapper script.


Use the local(8) delivery agent for delivery as the recipient.


The specific thing I was working on was getting postfix to run 
spamassassin as the user, in order to take advantage of the user's bayes 
db. I want postfix to deliver the mail with lmtp.


Doug

advice books (electronic ones better) for Postfix.

2017-03-29 Thread Soporte Infraestructura Operativa y Almacenamiento 
Hi people:
I'm looking to buy/download your recommended books (I prefer electronic ones to 
avoid paper) of Postfix;
>From novice to TopGun ones.

Thanks.

Este mensaje de correo electr?nico, incluidos los archivos adjuntos, es para el 
uso exclusivo de la persona a la que se ha enviado, y puede contener 
informaci?n que sea confidencial o protegida legalmente. Si usted no es el 
destinatario, o ha recibido este mensaje por error, no est? autorizado a 
copiar, distribuir, o utilizar de alguna manera este mensaje. Por favor 
notifique inmediatamente al remitente por correo electr?nico y suprimir 
permanentemente este mensaje y los archivos adjuntos. No se otorga ninguna 
garant?a de que este e-mail est? libre de errores o virus.
INSTITUTO COSTARRICENSE DE ELECTRICIDAD

When to use mandatory TLS ("encrypt", ...)

2017-03-29 Thread Viktor Dukhovni 
On Wed, Mar 29, 2017 at 06:44:54AM -0700, Den1 wrote:

> Well, Viktor was talking about those:
> 
> smtp_tls_security_level = encrypt -or- secure 
> smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt 
> 
> and my question was about those as well. You may read it once again since
> you have this one set:

You use mandatory TLS when all your mail is sent to a small set of
relay hosts that are known to support TLS.  If these have usable
certificates you can verify, you should consider using "secure" to
guard against active attacks, otherwise use "encrypt".

-- 
Viktor.

Re: Postfix cannot start tls: handshake failure

2017-03-29 Thread Viktor Dukhovni 
On Wed, Mar 29, 2017 at 05:03:51AM -0700, Den1 wrote:

> I was wondering is it actually advisable to use tls on smtp? When I tried it
> out with my self-signed certificates just to see if it's of any convenience
> to implement this feature I received the following response:
> 
> TLS required, but was not offered by host -or- we do not run TLS engine -or-
> certificate is not trusted

This is not a Postfix log message.  For fact-based answers, please post
verbatim Postfix logs.  For alternative-fact-based answers, by all means
please elide the logs and post an anecdotal re-interpretation of what
Postfix reported.

> smtp_tls_security_level = encrypt -or- secure
> smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt 

Are you sending all email via a single "relayhost" (a.k.a. a 
smarthost)?  If not, and you're sending to MX hosts of all
possible destination domains, then opportunistic TLS with
"may" or opportunistic DANE TLS with "dane" are the only
practical TLS settings.

These two lines are unlikely to be your entire "postconf -n" output.
Which was it, "encrypt" or "secure"?  It best to resolve problems
with one setting at a time, ideally first the more permissive
"encrypt" if that's appropriate.


> smtp_tls_security_level = may
> smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt 
> 
> it simply went through without giving any "feedback" or warnings.

Try:

smtp_tls_loglevel = 1

> smtp_tls_cert_file = -and-
> smtp_tls_key_file =
> 
> are they not required?

http://www.postfix.org/postconf.5.html#smtp_tls_cert_file

-- 
Viktor.

Re: Postfix cannot start tls: handshake failure

2017-03-29 Thread Viktor Dukhovni 
On Wed, Mar 29, 2017 at 04:14:35AM -0700, oakley wrote:

> *openssl s_client -connect (mydomain.com):443 -servername (mydomain.com)*
> 

Why on earth are you wasting our time showing results of connections
to an HTTPS service.  In every message you post, show the current
*Postfix* configuration, *logs* from *Postfix* that show the problem
you're still having, and any *relevant* diagnostic information you're
able to obtain with other tools, e.g. (when relevant) from:

openssl s_client -starttls smtp -connect :

where  and  match the "relay=" field from the problem
log entry and perhaps also your Postfix "relayhost=[relay]:port"
setting.

> I've been playing with OpenSSL to try and locate the issue, and I think it
> has something to do with my certificate. I noticed the certificate was
> updated on the date this all went down hill, too.
> 
> Do you think this has a possibility? 

I think it is a possibility that you're wasting our time with
useless speculative digressions.  Your Postfix logs will show
precisely why you're having problems delivering mail.  If you post
no logs, any answer you get is no better than rolling dice.

-- 
Viktor.

RE: Postfix cannot start tls: handshake failure

2017-03-29 Thread Den1 
Well, Viktor was talking about those:

smtp_tls_security_level = encrypt -or- secure 
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt 

and my question was about those as well. You may read it once again since
you have this one set:

smtp_tls_security_level = may

and I think it's not the same for smtp as it works for me with 'may', but
it's quite different with encrypt or secure.



--
View this message in context: 
http://postfix.1071664.n5.nabble.com/Postfix-cannot-start-tls-handshake-failure-tp89684p89733.html
Sent from the Postfix Users mailing list archive at Nabble.com.

RE: Postfix cannot start tls: handshake failure

2017-03-29 Thread L . P . H . van Belle 
Sorry about that, i was thinking your talking about the remote connecting to 
you. So, it's you to remote ( so the smtp_tls settings ) 

I did setup also for client myself, but that more how official you need to have 
some things.

Its about the same, for the client setup im using : 
# TLS Client (outgoing)
smtp_tls_key_file = /etc/postfix/newreq.pem 
smtp_tls_cert_file = /etc/postfix/newcert.pem 
smtp_tls_CAfile = /etc/postfix/cacert.pem
smtp_tls_protocols = !SSLv2,!SSLv3
smtp_tls_ciphers = medium
smtp_tls_exclude_ciphers = MD5,SRP,PSK,aDSS,kECDH,kDH,SEED,IDEA,RC2,RC5,RC4
smtp_tls_security_level = may
smtp_tls_loglevel = 1

but i do use official certificates and i then i do get the 
Trusted TLS connection established 

Maybe a tip, setup lets encrypt certificates, and test with that. 
Then you can see if you get the needed trusted connections. 


Greetz, 

Louis



> -Oorspronkelijk bericht-
> Van: webmas...@lshipping.info [mailto:owner-postfix-us...@postfix.org]
> Namens Den1
> Verzonden: woensdag 29 maart 2017 14:50
> Aan: postfix-users@postfix.org
> Onderwerp: RE: Postfix cannot start tls: handshake failure
> 
> Hi Louis,
> 
> Thank you for your input, I appreciate. I have smtpd running OK with all
> the
> key_file, cert_file and so on. I was asking about smtp. These two are
> different :-)
> 
> 
> 
> 
> 
> --
> View this message in context:
> http://postfix.1071664.n5.nabble.com/Postfix-cannot-start-tls-handshake-
> failure-tp89684p89731.html
> Sent from the Postfix Users mailing list archive at Nabble.com.

RE: Postfix cannot start tls: handshake failure

2017-03-29 Thread Den1 
Hi Louis,

Thank you for your input, I appreciate. I have smtpd running OK with all the
key_file, cert_file and so on. I was asking about smtp. These two are
different :-)





--
View this message in context: 
http://postfix.1071664.n5.nabble.com/Postfix-cannot-start-tls-handshake-failure-tp89684p89731.html
Sent from the Postfix Users mailing list archive at Nabble.com.

RE: Postfix cannot start tls: handshake failure

2017-03-29 Thread L . P . H . van Belle 
Yes is advicable to enable TLS.

Whats is your OS and Postfix version?

For example, i use Debian. 
And when you want to use : ca-certificates.crt 
You need to setup as debian expects and it includes your cert in the 
ca-certifcate.crt, so thats why i want to know the os and version of postfix. 

( debian/ubuntu setup ) Read:  
https://www.brightbox.com/blog/2014/03/04/add-cacert-ubuntu-debian/ 

Next to read postfix tls: 
http://www.postfix.org/TLS_README.html 

The setup for TLS can differ a bit compaired to versions 2.x and 3.x 

But this should be sufficient to start with. 

## TLS
smtpd_use_tls = yes
smtpd_tls_key_file = /etc/postfix/newreq.pem
smtpd_tls_cert_file = /etc/postfix/newcert.pem
smtpd_tls_CAfile = /etc/postfix/cacert.pem
smtpd_tls_loglevel = 3
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

And a test site for you. 
https://ssl-tools.net/mailservers 

and a nice site with stronger settings.
https://cipherli.st/ 

Hope that this helps you a bit further.


Greetz, 

Louis


> -Oorspronkelijk bericht-
> Van: webmas...@lshipping.info [mailto:owner-postfix-us...@postfix.org]
> Namens Den1
> Verzonden: woensdag 29 maart 2017 14:04
> Aan: postfix-users@postfix.org
> Onderwerp: Re: Postfix cannot start tls: handshake failure
> 
> I was wondering is it actually advisable to use tls on smtp? When I tried
> it
> out with my self-signed certificates just to see if it's of any
> convenience
> to implement this feature I received the following response:
> 
> TLS required, but was not offered by host -or- we do not run TLS engine -
> or-
> certificate is not trusted
> 
> on
> 
> smtp_tls_security_level = encrypt -or- secure
> smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
> 
> when I tried the following:
> 
> smtp_tls_security_level = may
> smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
> 
> it simply went through without giving any "feedback" or warnings. My
> understanding also is that it just wasn't secure / encrypted with this
> 'may'
> so that's why it went through OK.
> 
> what about the rest of the settings of
> 
> smtp_tls_cert_file = -and-
> smtp_tls_key_file =
> 
> are they not required?
> 
> Could anyone comment on the above, please? Many thanks!
> 
> 
> 
> 
> 
> --
> View this message in context:
> http://postfix.1071664.n5.nabble.com/Postfix-cannot-start-tls-handshake-
> failure-tp89684p89727.html
> Sent from the Postfix Users mailing list archive at Nabble.com.

Re: Postfix cannot start tls: handshake failure

2017-03-29 Thread Den1 
I was wondering is it actually advisable to use tls on smtp? When I tried it
out with my self-signed certificates just to see if it's of any convenience
to implement this feature I received the following response:

TLS required, but was not offered by host -or- we do not run TLS engine -or-
certificate is not trusted

on

smtp_tls_security_level = encrypt -or- secure
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt 

when I tried the following:

smtp_tls_security_level = may
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt 

it simply went through without giving any "feedback" or warnings. My
understanding also is that it just wasn't secure / encrypted with this 'may'
so that's why it went through OK. 

what about the rest of the settings of

smtp_tls_cert_file = -and-
smtp_tls_key_file =

are they not required?

Could anyone comment on the above, please? Many thanks!





--
View this message in context: 
http://postfix.1071664.n5.nabble.com/Postfix-cannot-start-tls-handshake-failure-tp89684p89727.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Re: Postfix cannot start tls: handshake failure

2017-03-29 Thread oakley 
*openssl s_client -connect (mydomain.com):443 -servername (mydomain.com)*


CONNECTED(0003)
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited,
CN = COMODO ECC Certification Authority
verify error:num=20:unable to get local issuer certificate
---
Certificate chain
 0 s:/OU=Domain Control Validated/OU=PositiveSSL
Multi-Domain/CN=sni74706.cloudflaressl.com
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC
Domain Validation Secure Server CA 2
 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC
Domain Validation Secure Server CA 2
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC
Certification Authority
 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC
Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust
External CA Root

*(removing the begin certificate content) 
After the END certificate it continues with the following:*

subject=/OU=Domain Control Validated/OU=PositiveSSL
Multi-Domain/CN=sni74706.cloudflaressl.com
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO
ECC Domain Validation Secure Server CA 2
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 4141 bytes and written 450 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-AES128-GCM-SHA256
Server public key is 256 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-ECDSA-AES128-GCM-SHA256
Session-ID:
4284FEE486BBCDE1F754F8012FBFF519865D501EE7FFC8BEE7817A80F4FD0CD9
Session-ID-ctx:
Master-Key:
03DC32DD1440B7D95E9AC427859660DC6F0F34C507A4C9EA10B67AE479E4FECC5C3C07478671E937BD50642E4CE3457D
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 64800 (seconds)
TLS session ticket:
 - 5a b7 92 79 44 c6 8a 1a-62 ef 2e b1 5a 14 44 c4  
Z..yD...b...Z.D.
0010 - 50 b3 e4 d0 ba 11 7b d1-a8 62 f9 50 0b 6d 06 ef  
P.{..b.P.m..
0020 - b7 cb 15 f0 ee 8b 4e 95-4f 9e bd ac ae 92 32 9e  
..N.O.2.
0030 - 48 ef 8b 92 b7 e7 3f e0-e1 39 b3 a3 0c 7c 72 a9  
H.?..9...|r.
0040 - 37 bc 2e bf d6 fc 4e 40-e5 cb 14 8e a1 22 a2 ff  
7.N@."..
0050 - dc 48 e4 6a 29 51 e9 21-f1 01 74 c5 f4 fc 2f 7e  
.H.j)Q.!..t.../~
0060 - 6d dc 1c bd 97 9c df 4f-49 e1 15 63 5f 0f 82 54  
m..OI..c_..T
0070 - 8e 51 6e dc fe c1 78 39-e9 33 a2 ca 05 5d 97 41  
.Qn...x9.3...].A
0080 - 0a ce 89 5b 82 7c 36 3c-3c b2 57 17 05 9a a7 1a  
...[.|6<<.W.
0090 - d1 9c 05 bc 5e 4d 53 47-37 b9 ee a2 c1 b1 41 5b  
^MSG7.A[
00a0 - 1f bd 84 0d ce 44 53 ee-da 6f 6b eb a1 55 2c c8  
.DS..ok..U,.
00b0 - ec 8f 31 f1 90 f9 31 28-09 c3 08 2c 53 17 6d ed  
..1...1(...,S.m.

Start Time: 1490781136
Timeout   : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
closed



I've been playing with OpenSSL to try and locate the issue, and I think it
has something to do with my certificate. I noticed the certificate was
updated on the date this all went down hill, too.

Do you think this has a possibility? 

 





--
View this message in context: 
http://postfix.1071664.n5.nabble.com/Postfix-cannot-start-tls-handshake-failure-tp89684p89726.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Re: Why aren't macros available to command syntax in pipe(8)?

2017-03-29 Thread Wietse Venema 
Doug Barton:
> > Unlike .forward or files which exist for selected users, injecting
> > envelope data (e.g. user=${user}) into the pipe(8) execution context
> > could allow remote senders to execute code as any user on the system
> 
> Yes, that's what I want to do. :)  Still easily done with a wrapper script.

Use the local(8) delivery agent for delivery as the recipient.
http:://www.postfix.org/postconf.5.html#mailbox_command
http:://www.postfix.org/postconf.5.html#mailbox_command_maps
http:://www.postfix.org/postconf.5.html#forward_path

The pipe(8) delivery agent is for delivery with a fixed role.

Wietse