Fwd: New tool detects malicious websites before they cause harm

2016-11-03 Thread James Reynolds
I thought people on this list might find this interesting.

James

> From: National Science Foundation Update 
> Reply-To: 
> Date: Wednesday, November 2, 2016 at 9:45 AM
> Subject: New tool detects malicious websites before they cause harm
> 
> You are subscribed to News - News From the Field for National Science 
> Foundation Update. This information has recently been updated, and is now 
> available.
> 
> New tool detects malicious websites before they cause harm
> 11/02/2016 10:13 AM EDT
> 
> Nick Feamster
> 
> The system, called PREDATOR, distinguishes between legitimate and malicious 
> purchasers of new websites. The system yields important insights into how 
> those two groups behave differently online even before the malicious users 
> have done anything obviously bad or harmful. These early signs could help 
> security professionals take preemptive measures, instead of waiting for a 
> security threat to surface.
> 
> 
> Full story at 
> https://www.princeton.edu/main/news/archive/S47/74/26M01/?section=topstories
> 
> Source
> Princeton University



Re: Getting false unknown user errors

2016-11-03 Thread Bill Cole

On 3 Nov 2016, at 8:34, @lbutlr wrote:


On 01 Nov 2016, at 03:15, wilfried.es...@essignetz.de wrote:


/etc/postfix/main.cf:
   content_filter = scan:localhost:10025
   receive_override_options = no_address_mappings

(from http://www.postfix.org/FILTER_README.html#advanced_filter)

And remove no_address_mappings from your "127.0.0.1:10025 
inet"-smtpd.


If receive_override_options is set to no_address_mappings won’t that 
apply to ALL locally received messages? That will not work as there 
are many locaddresses that expand via either virtual or mysql maps to 
the eventual address.



Which is fine. You've removed no_address_mappings from the smtpd 
instance on the output side of amavisd, so the expansions will happen 
there.


Re: Ubuntu 16.04lts & ssl unknown states

2016-11-03 Thread Viktor Dukhovni
On Thu, Nov 03, 2016 at 09:38:39PM +0100, Florian Piekert wrote:

> >> -rwxr-xr-x 1 root root  34768 Apr 13  2016 /usr/sbin/posttls-finger*
> > 
> > Perhaps "posttls-finger" is left over from an earlier install? Did
> > you build and install Postfix from source?
> 
> posttls-finger most probably is a relic of the default packages
> installation. pf is installed from source.

You should probably delete the left-over binary.

> > Here we see that the same "unknown state" issue happens with Postfix
> > out of the picture.  Both for local connections and connections to
> > Gmail. So this should be pursued on a suitable Ubuntu forum.
> 
> OK, I understand it then is more of an OS issue than a specific to pf. 
> Correct?

The issue is a common symptom of OpenSSL on your system and is NOT
Postfix-specific.

-- 
Viktor.


Re: Ubuntu 16.04lts & ssl unknown states

2016-11-03 Thread Florian Piekert
Am 03.11.2016 um 20:57 schrieb Viktor Dukhovni:

Hello Viktor,

you are correct, it is compiled & install from the source, like I did the last 
ten+? years on all of my machines. No issues on ubuntu 14.04, opensuse, or 
others. Only on 16.04. it causes me a pain.

I installed postfix from scratch with the default packages that come with 
16.04, then compiled the pf snapshot that was available at that time, with the 
configure file I slightly modified to pay tribute to the new system.

See the attached configure.postfix file with the args.

>> Since there is no tlsproxy running at the moment (removed the modifications
>> from Wietse and restarted pf, let's wait...?) I can't provide that output
>> at the moment. Or do you have a suggestion how to get one up & running?
> 
> You could go back to the previous configuration, but read on...
> 
>> On the other hand, my pf is the snapshot from 1101 and not any longer the 
>> default package that ubuntu delivered.
>>
>> root@blueberry:/var/lib/postfix# l /usr/sbin/post*
>> -rwxr-xr-x 1 root root  45160 Nov  1 22:04 /usr/sbin/postalias*
>> -rwxr-xr-x 1 root root  34216 Nov  1 22:04 /usr/sbin/postcat*
>> -rwxr-xr-x 1 root root 422752 Nov  1 22:04 /usr/sbin/postconf*
>> -rwxr-sr-x 1 root postdrop  34504 Nov  1 22:04 /usr/sbin/postdrop*
>> -rwxr-xr-x 1 root root  28960 Nov  1 22:04 /usr/sbin/postfix*
>> -rwxr-xr-x 1 root root   5017 Apr 13  2016 /usr/sbin/postfix-add-filter*
>> -rwxr-xr-x 1 root root   3923 Apr 13  2016 /usr/sbin/postfix-add-policy*
>> -rwxr-xr-x 1 root root  37856 Okt 26  2014 /usr/sbin/postgrey*
>> -rwxr-xr-x 1 root root  20696 Nov  1 22:04 /usr/sbin/postkick*
>> -rwxr-xr-x 1 root root  22608 Nov  1 22:04 /usr/sbin/postlock*
>> -rwxr-xr-x 1 root root  22384 Nov  1 22:04 /usr/sbin/postlog*
>> -rwxr-xr-x 1 root root  48512 Nov  1 22:04 /usr/sbin/postmap*
>> -rwxr-xr-x 1 root root  69928 Nov  1 22:04 /usr/sbin/postmulti*
>> -rwxr-sr-x 1 root postdrop  54304 Nov  1 22:04 /usr/sbin/postqueue*
>> -rwxr-xr-x 1 root root  60552 Nov  1 22:04 /usr/sbin/postsuper*
>> -rwxr-xr-x 1 root root  34768 Apr 13  2016 /usr/sbin/posttls-finger*
> 
> Perhaps "posttls-finger" is left over from an earlier install? Did
> you build and install Postfix from source?

posttls-finger most probably is a relic of the default packages installation. 
pf is installed from source.

 
> The OpenSSL version looks typical enough, is that "/usr/bin/openssl"
> or some other version?  What does "ldd" show for this binary?

yes, it is that version.
root@blueberry:/home/software# ldd /usr/bin/openssl
linux-vdso.so.1 =>  (0x7ffca532)
libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 
(0x7fcc7780a000)
libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 
(0x7fcc773c6000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fcc76ffc000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fcc76df8000)
/lib64/ld-linux-x86-64.so.2 (0x7fcc77a7d000)


> # openssl version -a
> OpenSSL 1.0.2g  1 Mar 2016
> built on: reproducible build, date unspecified
> platform: debian-amd64
> options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) 
> compiler: cc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS 
> -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack 
> -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
> -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
> -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM 
> -DGHASH_ASM -DECP_NISTZ256_ASM
> OPENSSLDIR: "/usr/lib/ssl"
> 
> Here we see that the same "unknown state" issue happens with Postfix
> out of the picture.  Both for local connections and connections to
> Gmail. So this should be pursued on a suitable Ubuntu forum.

OK, I understand it then is more of an OS issue than a specific to pf. Correct?

> # (sleep 1; printf "quit\r\n") |
>   openssl s_client -quiet -state -starttls smtp -connect localhost:25
>   SSL_connect:before/connect initialization
>   SSL_connect:SSLv2/v3 write client hello A
>   SSL_connect:unknown state
>   depth=1 O = Root CA, OU = http://www.cacert.org, CN = CA Cert Signing 
> Authority, emailAddress = supp...@cacert.org
>   verify return:1
>   depth=0 CN = yabba.dadd-do.de
>   verify return:1
>   SSL_connect:unknown state
>   SSL_connect:unknown state
>   SSL_connect:unknown state
>   SSL_connect:unknown state
>   SSL_connect:unknown state
>   SSL_connect:unknown state
>   SSL_connect:unknown state
>   SSL_connect:unknown state
>   SSL_connect:unknown state
>   SSL_connect:unknown state
>   SSL_connect:unknown state
>   250 DSN
>   

Re: test address expansion with LDAP mapping

2016-11-03 Thread Noel Jones
On 11/3/2016 1:12 PM, Stephen Ingram wrote:
> I found a way to test the expansion of normal .db maps:
> 
> postmap -q testuser 'postconf -h virtual_alias_maps'
> 
> however, it doesn't seem to work with LDAP maps. Is there a way to
> test those as well?
> 
> Steve


Yes, it works with LDAP maps.  What kind of error are you getting?

Make sure to use the ` back-tick character. Your above example shows
' single quotes; not the same!

If your virtual_alias_maps entry contains some kind of $redirection, eg.
virtual_alias_maps = $maptype:$mapdir/virtual.cf
you'll have to expand the $stuff by hand.



  -- Noel Jones


Re: Ubuntu 16.04lts & ssl unknown states

2016-11-03 Thread Viktor Dukhovni
On Thu, Nov 03, 2016 at 06:05:50PM +0100, Florian Piekert wrote:

> Since there is no tlsproxy running at the moment (removed the modifications
> from Wietse and restarted pf, let's wait...?) I can't provide that output
> at the moment. Or do you have a suggestion how to get one up & running?

You could go back to the previous configuration, but read on...

> On the other hand, my pf is the snapshot from 1101 and not any longer the 
> default package that ubuntu delivered.
> 
> root@blueberry:/var/lib/postfix# l /usr/sbin/post*
> -rwxr-xr-x 1 root root  45160 Nov  1 22:04 /usr/sbin/postalias*
> -rwxr-xr-x 1 root root  34216 Nov  1 22:04 /usr/sbin/postcat*
> -rwxr-xr-x 1 root root 422752 Nov  1 22:04 /usr/sbin/postconf*
> -rwxr-sr-x 1 root postdrop  34504 Nov  1 22:04 /usr/sbin/postdrop*
> -rwxr-xr-x 1 root root  28960 Nov  1 22:04 /usr/sbin/postfix*
> -rwxr-xr-x 1 root root   5017 Apr 13  2016 /usr/sbin/postfix-add-filter*
> -rwxr-xr-x 1 root root   3923 Apr 13  2016 /usr/sbin/postfix-add-policy*
> -rwxr-xr-x 1 root root  37856 Okt 26  2014 /usr/sbin/postgrey*
> -rwxr-xr-x 1 root root  20696 Nov  1 22:04 /usr/sbin/postkick*
> -rwxr-xr-x 1 root root  22608 Nov  1 22:04 /usr/sbin/postlock*
> -rwxr-xr-x 1 root root  22384 Nov  1 22:04 /usr/sbin/postlog*
> -rwxr-xr-x 1 root root  48512 Nov  1 22:04 /usr/sbin/postmap*
> -rwxr-xr-x 1 root root  69928 Nov  1 22:04 /usr/sbin/postmulti*
> -rwxr-sr-x 1 root postdrop  54304 Nov  1 22:04 /usr/sbin/postqueue*
> -rwxr-xr-x 1 root root  60552 Nov  1 22:04 /usr/sbin/postsuper*
> -rwxr-xr-x 1 root root  34768 Apr 13  2016 /usr/sbin/posttls-finger*

Perhaps "posttls-finger" is left over from an earlier install? Did
you build and install Postfix from source?

The OpenSSL version looks typical enough, is that "/usr/bin/openssl"
or some other version?  What does "ldd" show for this binary?

# openssl version -a
OpenSSL 1.0.2g  1 Mar 2016
built on: reproducible build, date unspecified
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) 
compiler: cc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS 
-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack 
-Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
-DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM 
-DGHASH_ASM -DECP_NISTZ256_ASM
OPENSSLDIR: "/usr/lib/ssl"

Here we see that the same "unknown state" issue happens with Postfix
out of the picture.  Both for local connections and connections to
Gmail. So this should be pursued on a suitable Ubuntu forum.

# (sleep 1; printf "quit\r\n") |
  openssl s_client -quiet -state -starttls smtp -connect localhost:25
  SSL_connect:before/connect initialization
  SSL_connect:SSLv2/v3 write client hello A
  SSL_connect:unknown state
  depth=1 O = Root CA, OU = http://www.cacert.org, CN = CA Cert Signing 
Authority, emailAddress = supp...@cacert.org
  verify return:1
  depth=0 CN = yabba.dadd-do.de
  verify return:1
  SSL_connect:unknown state
  SSL_connect:unknown state
  SSL_connect:unknown state
  SSL_connect:unknown state
  SSL_connect:unknown state
  SSL_connect:unknown state
  SSL_connect:unknown state
  SSL_connect:unknown state
  SSL_connect:unknown state
  SSL_connect:unknown state
  SSL_connect:unknown state
  250 DSN
  221 2.0.0 Bye
  SSL3 alert read:warning:close notify
  SSL3 alert write:warning:close notify

# (sleep 1; printf "quit\r\n") |
   openssl s_client -quiet -state -starttls smtp -connect smtp.gmail.com:587
  SSL_connect:before/connect initialization
  SSL_connect:SSLv2/v3 write client hello A
  SSL_connect:unknown state
  depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
  verify return:1
  depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
  verify return:1
  depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
  verify return:1
  depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = 
smtp.gmail.com
  verify return:1
  SSL_connect:unknown state
  SSL_connect:unknown state
  SSL_connect:unknown state
  SSL_connect:unknown state
  SSL_connect:unknown state
  SSL_connect:unknown state
  SSL_connect:unknown state
  SSL_connect:unknown state
  SSL_connect:unknown state
  250 SMTPUTF8
  221 2.0.0 closing connection g9sm9596385wjk.25 - gsmtp
  read:errno=0
  SSL3 alert write:warning:close notify
  
> postconf mail_version
> -> mail_version = 3.2-20161101

I very much doubt that Ubuntu shipped this Postfix version.  Looks
like 

Re: test address expansion with LDAP mapping

2016-11-03 Thread btb
On Nov 03, 2016, at 14.12, Stephen Ingram  wrote:
> 
> I found a way to test the expansion of normal .db maps:
> 
> postmap -q testuser 'postconf -h virtual_alias_maps'
> 
> however, it doesn't seem to work with LDAP maps. Is there a way to test those 
> as well?

it's worked as documented for me, as long as i can remember.

consult the following reference material included with the software:

postmap(1)
ldap_table(5)
LDAP_README

wherein syntax and multiple literal examples are provided.

beyond that, share actual input and output of the command[s] you are running, 
as well as the contents of your lookup map file.  obfuscate any credentials.

-ben

test address expansion with LDAP mapping

2016-11-03 Thread Stephen Ingram
I found a way to test the expansion of normal .db maps:

postmap -q testuser 'postconf -h virtual_alias_maps'

however, it doesn't seem to work with LDAP maps. Is there a way to test
those as well?

Steve


Re: Ubuntu 16.04lts & ssl unknown states

2016-11-03 Thread Florian Piekert
Am 03.11.2016 um 17:29 schrieb Viktor Dukhovni:

Hello Viktor, Wietse and everybody,

since there is no tlsproxy running at the moment (removed the modifications 
from Wietse and restarted pf, let's wait...?) I can't provide that output at 
the moment. Or do you have a suggestion how to get one up & running? I have a 
proxymap up sometimes...

But maybe the attached txt file providing what I could provide helps in 
understanding...? Especially the missing symbol aspect of posttls-finger?

On the other hand, my pf is the snapshot from 1101 and not any longer the 
default package that ubuntu delivered.

root@blueberry:/var/lib/postfix# l /usr/sbin/post*
-rwxr-xr-x 1 root root  45160 Nov  1 22:04 /usr/sbin/postalias*
-rwxr-xr-x 1 root root  34216 Nov  1 22:04 /usr/sbin/postcat*
-rwxr-xr-x 1 root root 422752 Nov  1 22:04 /usr/sbin/postconf*
-rwxr-sr-x 1 root postdrop  34504 Nov  1 22:04 /usr/sbin/postdrop*
-rwxr-xr-x 1 root root  28960 Nov  1 22:04 /usr/sbin/postfix*
-rwxr-xr-x 1 root root   5017 Apr 13  2016 /usr/sbin/postfix-add-filter*
-rwxr-xr-x 1 root root   3923 Apr 13  2016 /usr/sbin/postfix-add-policy*
-rwxr-xr-x 1 root root  37856 Okt 26  2014 /usr/sbin/postgrey*
-rwxr-xr-x 1 root root  20696 Nov  1 22:04 /usr/sbin/postkick*
-rwxr-xr-x 1 root root  22608 Nov  1 22:04 /usr/sbin/postlock*
-rwxr-xr-x 1 root root  22384 Nov  1 22:04 /usr/sbin/postlog*
-rwxr-xr-x 1 root root  48512 Nov  1 22:04 /usr/sbin/postmap*
-rwxr-xr-x 1 root root  69928 Nov  1 22:04 /usr/sbin/postmulti*
-rwxr-sr-x 1 root postdrop  54304 Nov  1 22:04 /usr/sbin/postqueue*
-rwxr-xr-x 1 root root  60552 Nov  1 22:04 /usr/sbin/postsuper*
-rwxr-xr-x 1 root root  34768 Apr 13  2016 /usr/sbin/posttls-finger*

That explains the difference of the file dates.

> openssl version -a
>   # (sleep 1; printf "quit\r\n") |
>   openssl s_client -quiet -state -starttls smtp -connect localhost:25
>   # (sleep 1; printf "quit\r\n") |
>   openssl s_client -quiet -state -starttls smtp -connect 
> smtp.gmail.com:587
> 
>   # postconf mail_version
>   # ldd /usr/sbin/posttls-finger  # IIRC Ubuntu ships it
> 
>   # pid=8057  # actual pid here
>   # cat /proc/$pid/maps
>   # ldd /proc/$pid/exe
>   # grep "tlsproxy/\[$pid\]" /var/log/mail.log | tail
> 
>   [ These should work, but Ubuntu may have packaged Postfix in
> some way that makes it otherwise: ]
> 
>   # d=$(/var/tmp/postfix/sbin/postconf -xh meta_directory)

I don't have that directory btw.

>   # cat $d/makedefs.out

Cheers,
Florian

===
Note:  this message was  send by me *only* if the  eMail message contains a
correct pgp signature corresponding to my address at  flo...@floppy.org. Do
you need my  PGP  public key? Check out http://www.floppy.org or send me an
email with  the subject "send pgp public key" to this address of mine. Thx!
openssl version -a
-> root@blueberry:/var/lib/postfix# openssl version -a
OpenSSL 1.0.2g  1 Mar 2016
built on: reproducible build, date unspecified
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) 
compiler: cc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS 
-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack 
-Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
-DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM 
-DGHASH_ASM -DECP_NISTZ256_ASM
OPENSSLDIR: "/usr/lib/ssl"


(sleep 1; printf "quit\r\n") |
 openssl s_client -quiet -state -starttls smtp -connect localhost:25
 ->
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:unknown state
depth=1 O = Root CA, OU = http://www.cacert.org, CN = CA Cert Signing 
Authority, emailAddress = supp...@cacert.org
verify return:1
depth=0 CN = yabba.dadd-do.de
verify return:1
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:unknown state
250 DSN
221 2.0.0 Bye
SSL3 alert read:warning:close notify
SSL3 alert write:warning:close notify


(sleep 1; printf "quit\r\n") |
 openssl s_client -quiet -state -starttls smtp -connect smtp.gmail.com:587
->
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:unknown state
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = 

Re: Ubuntu 16.04lts & ssl unknown states

2016-11-03 Thread Viktor Dukhovni

> On Nov 3, 2016, at 12:29 PM, Viktor Dukhovni  
> wrote:
> 
> # grep "tlsproxy/\[$pid\]" /var/log/mail.log | tail

Oops, misplaced '/' there, it should of course be:

# grep "/tlsproxy\[$pid\]" /var/log/mail.log | tail

-- 
Viktor.



Re: Ubuntu 16.04lts & ssl unknown states

2016-11-03 Thread Viktor Dukhovni
On Thu, Nov 03, 2016 at 12:48:01PM +0100, Florian Piekert wrote:

> Good morning everybody,
> 
> I was wondering for quite some weeks now how to fix this issue with my
> postfix. I had a brief discussion with Ralf Hildebrandt and he suggested
> asking via the users lists, that's what I am doing now.
> 
> I have the situation that the PF currently doesn't seem to get proper
> information about the state of the SSL connection, as you can see below.

Find the process id of a still running "tlsproxy", then post the
output of (multiple commands, so post each command followed by its
output, without changing line breaks with a blank line or two above
each command block):

# openssl version -a
# (sleep 1; printf "quit\r\n") |
openssl s_client -quiet -state -starttls smtp -connect localhost:25
# (sleep 1; printf "quit\r\n") |
openssl s_client -quiet -state -starttls smtp -connect 
smtp.gmail.com:587

# postconf mail_version
# ldd /usr/sbin/posttls-finger  # IIRC Ubuntu ships it

# pid=8057  # actual pid here
# cat /proc/$pid/maps
# ldd /proc/$pid/exe
# grep "tlsproxy/\[$pid\]" /var/log/mail.log | tail

[ These should work, but Ubuntu may have packaged Postfix in
  some way that makes it otherwise: ]

# d=$(/var/tmp/postfix/sbin/postconf -xh meta_directory)
# cat $d/makedefs.out

also report whether that proxy had already logged a similar message
by the time you found it.

> Any pointers what to check/where to lock/what to fix are highly appreciated.

This has the feel of a shared library issue.  The Postfix configuration
is largely irrelevant here, but chroot may play a role in this.

-- 
Viktor.


Any suggestions to the configurations of the mail server?

2016-11-03 Thread vod vos
Hi lists:



My needs:



1. serving as a mail server of a friend's web site.

2. TLS encrypt only, auth plain

3. 587 for client sending mails, 995 pop3s for client receiving mails, 25 for 
server sending and receiving mails

4. amavis-new

5. spamassassin

6. spf check

7. dmarc

8. opendkim



Are there any configuration errors below, 

and could you give me some suggestion to enhance the mail server, such as 
security?



Here is my postconf -n :



alias_database = hash:/etc/aliases

alias_maps = hash:/etc/aliases

append_dot_mydomain = no

biff = no

body_checks = regexp:/etc/postfix/body_checks

compatibility_level = 2

content_filter = smtp-amavis:[127.0.0.1]:10024

disable_vrfy_command = yes

header_checks = pcre:/etc/postfix/header_checks.pcre

inet_interfaces = all

inet_protocols = ipv4

local_recipient_maps = proxy:unix:passwd.byname $alias_maps

mailbox_size_limit = 0

milter_default_action = reject

milter_protocol = 6

mime_header_checks = $header_checks

mydestination = localhost, $mydomain

mydomain = example.com

myhostname = mail.example.com

mynetworks = host

myorigin = $mydomain

nested_header_checks = $header_checks

non_smtpd_milters = inet:localhost:12301, inet:localhost:54321

policyd-spf_time_limit = 3600

readme_directory = no

recipient_delimiter = +

relay_domains =

relayhost =

smtp-amavis_destination_concurrency_limit = 1

smtp_tls_note_starttls_offer = yes

smtp_tls_security_level = may

smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

smtp_use_tls = yes

smtpd_banner = $myhostname

smtpd_helo_required = yes

smtpd_helo_restrictions = 
reject_invalid_helo_hostname,reject_non_fqdn_helo_hostname,reject_unknown_helo_hostname

smtpd_junk_command_limit = 4

smtpd_milters = inet:localhost:12301, inet:localhost:54321

smtpd_recipient_restrictions = 
permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination,check_policy_service
 
unix:private/policyd-spf,reject_invalid_hostname,reject_unauth_pipelining,reject_non_fqdn_sender,reject_unknown_sender_domain,reject_non_fqdn_recipient,reject_unknown_recipient_domain,reject_unauth_pipelining,check_recipient_access
 hash:/etc/postfix/recipient_access

smtpd_relay_restrictions = permit_mynetworks, 
permit_sasl_authenticated,reject_unauth_destination

smtpd_sasl_auth_enable = yes

smtpd_sasl_path = private/auth

smtpd_sasl_security_options = noanonymous

smtpd_sasl_tls_security_options = noanonymous

smtpd_sasl_type = dovecot

smtpd_sender_restrictions = 
permit_sasl_authenticated,reject_non_fqdn_sender,reject_unknown_sender_domain,reject_sender_login_mismatch,reject_unverified_sender,check_sender_access
 hash:/etc/postfix/sender_access

smtpd_tls_auth_only = yes

smtpd_tls_cert_file = /etc/commando/live/mail.example.com/fullchain.pem

smtpd_tls_key_file = /etc/commando/live/mail.example.com/privkey.pem

smtpd_tls_loglevel = 1

smtpd_tls_protocols = !SSLv2, !SSLv3

smtpd_tls_received_header = yes

smtpd_tls_security_level = may

smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

smtpd_tls_session_cache_timeout = 3600s

smtpd_use_tls = yes







Thanks,



yours sincerely.








Re: Ubuntu 16.04lts & ssl unknown states

2016-11-03 Thread Florian Piekert
Am 03.11.2016 um 15:58 schrieb Wietse Venema:
> postconf \
> 'postscreen_bare_newline_enable = no' \
> 'postscreen_non_smtp_command_enable = no' \
> 'postscreen_pipelining_enable = no'
> 
>   postfix reload

Nov  3 16:03:51 blueberry postfix/smtp[12959]: SSL_connect:before/connect
initialization
Nov  3 16:03:51 blueberry postfix/smtp[12959]: SSL_connect:SSLv2/v3 write
client hello A
Nov  3 16:03:51 blueberry postfix/smtp[12959]: SSL_connect:unknown state
...
Nov  3 16:03:51 blueberry postfix/smtp[12959]: SSL_connect:unknown state
Nov  3 16:03:51 blueberry postfix/smtp[12959]: message repeated 10 times: [
SSL_connect:unknown state]

Negative.

-- 

Florian Piekert, PMP  flo...@floppy.org

Spargelweg 5Telephone+Fax: +49-179- 3928582
38179 Schwülper-Walle/Germany

===
Note:  this message was  send by me *only* if the  eMail message contains a
correct pgp signature corresponding to my address at  flo...@floppy.org. Do
you need my  PGP  public key? Check out http://www.floppy.org or send me an
email with  the subject "send pgp public key" to  this address of mine.Thx!



signature.asc
Description: OpenPGP digital signature


Re: Ubuntu 16.04lts & ssl unknown states

2016-11-03 Thread Wietse Venema
Florian Piekert:
> ==> mail/mail.log <==
> Nov  3 08:50:29 blueberry postfix/tlsproxy[8057]: CONNECT from
> [2a01:111:f400:fe02::31f]:39552

Does it make a difference after:

  postconf \
'postscreen_bare_newline_enable = no' \
'postscreen_non_smtp_command_enable = no' \
'postscreen_pipelining_enable = no'

  postfix reload

That eliminates postfix/tlsproxy from the equation.

Wietse



Re: Ubuntu 16.04lts & ssl unknown states

2016-11-03 Thread Ralf Hildebrandt
* Florian Piekert :

> Nov  3 08:50:30 blueberry postfix/tlsproxy[8057]: SSL_accept:unknown state

I checked my logs and couldn't find any log entries like the one above.

Hm, I am not using smtp(d)_tls_loglevel=2, but 1.

> smtp_tls_loglevel = 2
> smtpd_tls_loglevel = 2

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein


Re: Ubuntu 16.04lts & ssl unknown states

2016-11-03 Thread Florian Piekert
Am 03.11.2016 um 14:26 schrieb Fazzina, Angelo:

Hello Angelo,

please find attached my output, looks pretty good to me, similar to yours.

> Hi Florian,
> I am curious if you ran a basic telnet test of your SSL config, trying to 
> connect over port 465 or 587 ?
> Sorry for not reading your attachments.
> 
> I am attaching one file of the command and its output, showing example test 
> over both ports.
> Does your postfix respond like my example or you are not even able to do that 
> ?
> -ALF
> 
> -Angelo Fazzina
> Operating Systems Programmer / Analyst 
> University of Connecticut,  UITS, SSG-Linux/ M
> 860-486-9075

Cheers,
Florian

===
Note:  this message was  send by me *only* if the  eMail message contains a
correct pgp signature corresponding to my address at  flo...@floppy.org. Do
you need my  PGP  public key? Check out http://www.floppy.org or send me an
email with  the subject "send pgp public key" to  this address of mine.Thx!
root@blueberry:/home/software# openssl s_client -connect localhost:465
CONNECTED(0003)
depth=1 O = Root CA, OU = http://www.cacert.org, CN = CA Cert Signing 
Authority, emailAddress = supp...@cacert.org
verify return:1
depth=0 CN = yabba.dadd-do.de
verify return:1
---
Certificate chain
 0 s:/CN=yabba.dadd-do.de
   i:/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing 
Authority/emailAddress=supp...@cacert.org
 1 s:/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing 
Authority/emailAddress=supp...@cacert.org
   i:/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing 
Authority/emailAddress=supp...@cacert.org
---
Server certificate
-BEGIN CERTIFICATE-
MIIGJTCCBA2gAwIBAgIDEkl3MA0GCSqGSIb3DQEBDQUAMHkxEDAOBgNVBAoTB1Jv
b3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9y
dEBjYWNlcnQub3JnMB4XDTE2MDgxOTA1MjkyM1oXDTE3MDIxNTA1MjkyM1owIjEg
MB4GA1UEAxMXYmx1ZWJlcnJ5LnBvc3QtcGVpbmUuZGUwggIiMA0GCSqGSIb3DQEB
AQUAA4ICDwAwggIKAoICAQCyMxBTyzYZuIPqDDGAaZw3OaK6ntq2RCjdv1SNRHvQ
UCLj/2Qh6XCcANbLraU59rBy4ioPON6pX73fXnfRApOP3l9jVsiDrvwzDbu2XOzF
6u8vZhbcG889zIyj0aPaR3pRsleWkxJ5vsmHS/MoaG++LUTLWGyBGFv05bDDtXVj
QhdfDFW4JwDrznivbvu2bn3r09wiCb9J8f21Wr45n6vm6wmpsPXxiiUnzH08WvY8
xdHBOUKlfl4m7u+ZQ8YY/VchPzF5+zVvwh7vuGSvjL6TEznxZS5dtKSFKdQV2lXT
z6KYGuGoVfs+CzeeoW8OO34jQ33BU9puFxb41iFJapuwe61xxQ/my/DTq3aCfwu3
6YdX9QejeYBuBKY7lYNTFSzOkpP/KQbxUGLY+lIv9omPNYC6WtZEpf368pycXFSH
L5K0USpXPWA4Wc5O7k7xAXKKDAxYlIxIChPtEb4UylTmeinCbrOn3bs1igbvQ7dg
n1BcNMZSmQCP1nLlOiVSHqvhD6BfATF0WgDpdIFvtizP/ep0qpjlmYhUVzaOtKFy
KnNW8xGo03gICllHjx3ESWgvqw1b0zzvcIlmol19m61VzIp2mo2G1HxNdm3YtUhr
Ss9J0XpAXkXH9A8QSMJhZR0Rvt5X/g5NZgXg7Q20oiUlReoagikKyda2AeRlzHBX
nwIDAQABo4IBCzCCAQcwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCA6gwNAYD
VR0lBC0wKwYIKwYBBQUHAwIGCCsGAQUFBwMBBglghkgBhvhCBAEGCisGAQQBgjcK
AwMwMwYIKwYBBQUHAQEEJzAlMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5jYWNl
cnQub3JnLzAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLmNhY2VydC5vcmcv
cmV2b2tlLmNybDBJBgNVHREEQjBAghdibHVlYmVycnkucG9zdC1wZWluZS5kZaAl
BggrBgEFBQcIBaAZDBdibHVlYmVycnkucG9zdC1wZWluZS5kZTANBgkqhkiG9w0B
AQ0FAAOCAgEAePVVQx9jJIYgtjBIGjssZgaiHi2Q908IEiC0JxDIYL98jIpmlHHO
lZbaTurNh/n3HpC8sN52hVwA/Zbzna7XP5FbfvJhAHiaan/9jbPppP/nszvqP+pC
d9SMrn5qeByES8R1XvbhWsIUsJDsfe68Hh9q7hDVwIG1jMFFI1vRxr+2h0owGxc3
lHyVKVKqTukgxze+HCpiK6KVNZ+O8g1LaSI4Ejqk0f9TpUB3ejnMJVls4266dC6a
lemH0Lf1SIP6Dl8wlhxMnCk7wKb2kG5gi7aKshqOjcgRLc41pp2h3Wkba5Z/HDZ3
P1v+lpndKO4+PnAlsb3hSrQTPzs24kupMDHq7WNwt0XHl9oByxrIza+6YvufADi8
LMMOp6aq1UPv3k7UTzAn3XiSPC/jAkBFFQZYvFNuVF8NcCPAfeHnYNnxQqPA94Af
9uPo85o2tVMxcfPZ3ja/Ybj57Jy+7UvF2k6QS3ittdJTJ46bXqFXnYT350B6DnhS
HZfo18qIcf0kjZfHq0+GTblUEsiBFv7bKFH7mKhHavqUAZg3E1eF1jtZp3N3A66g
WENj2GNxaPHexYt5qZofz7k9dNuLuB/IIK03SvL8ErG8IScIWEBVy/kyi6HJ+8YW
+K5sf3tgUm1L/hyf8exlTAGQWfdLCYsgy6gByxdOS4Z1SOQer+IBS/k=
-END CERTIFICATE-
subject=/CN=yabba.dadd-do.de
issuer=/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing 
Authority/emailAddress=supp...@cacert.org
---
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: 
RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: 
RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 4394 bytes and written 443 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 8BEFEAEFA881F97A56AC14E6894249C6E1F583628382FB0877597DFF554539C2
Session-ID-ctx: 

RE: Ubuntu 16.04lts & ssl unknown states

2016-11-03 Thread Fazzina, Angelo
Hi Florian,
I am curious if you ran a basic telnet test of your SSL config, trying to 
connect over port 465 or 587 ?
Sorry for not reading your attachments.

I am attaching one file of the command and its output, showing example test 
over both ports.
Does your postfix respond like my example or you are not even able to do that ?
-ALF

-Angelo Fazzina
Operating Systems Programmer / Analyst 
University of Connecticut,  UITS, SSG-Linux/ M
860-486-9075

-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
On Behalf Of Florian Piekert
Sent: Thursday, November 3, 2016 7:48 AM
To: postfix-users@postfix.org
Subject: Ubuntu 16.04lts & ssl unknown states

Good morning everybody,

I was wondering for quite some weeks now how to fix this issue with my
postfix. I had a brief discussion with Ralf Hildebrandt and he suggested
asking via the users lists, that's what I am doing now.

I have the situation that the PF currently doesn't seem to get proper
information about the state of the SSL connection, as you can see below.

==> mail/mail.log <==
Nov  3 08:50:29 blueberry postfix/tlsproxy[8057]: CONNECT from
[2a01:111:f400:fe02::31f]:39552
Nov  3 08:50:29 blueberry postfix/tlsproxy[8057]: setting up TLS connection
from [2a01:111:f400:fe02::31f]:39552
Nov  3 08:50:29 blueberry postfix/tlsproxy[8057]:
[2a01:111:f400:fe02::31f]:39552: TLS cipher list
"aNULL:-aNULL:HIGH:MEDIUM:LOW:EXPORT:+RC4:@STRENGTH:!aNULL"
Nov  3 08:50:29 blueberry postfix/tlsproxy[8057]: SSL_accept:before/accept
initialization
Nov  3 08:50:30 blueberry postfix/tlsproxy[8057]: SSL_accept:unknown state
Nov  3 08:50:30 blueberry postfix/tlsproxy[8057]: message repeated 5 times:
[ SSL_accept:unknown state]
Nov  3 08:50:30 blueberry postfix/tlsproxy[8057]: SSL_accept:failed in
unknown state

It doesn't matter if it is an IPv6 host, if the host is in mynetworks or not
(all postfixes with CACert issues certs and working properly between each of
the others finely).

Any pointers what to check/where to lock/what to fix are highly appreciated.

And I will probably drop another mail around another issue in conjunction
with dovecot virtual user delivery pf->dovecot... but first this SSL thing...

Thanks!

Florian

===
Note:  this message was  send by me *only* if the  eMail message contains a
correct pgp signature corresponding to my address at  flo...@floppy.org. Do
you need my  PGP  public key? Check out http://www.floppy.org or send me an
email with  the subject "send pgp public key" to  this address of mine.Thx!

TEST 1
[  OK  ]
[root@mta4 ~]# openssl s_client -connect mta4.example.com:465
CONNECTED(0003)
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = 
AddTrust External CA Root
verify return:1
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN 
= USERTrust RSA Certification Authority
verify return:1
depth=1 C = US, ST = MI, L = Ann Arbor, O = Internet2, OU = InCommon, CN = 
InCommon RSA Server CA
verify return:1
depth=0 C = US, postalCode = 06269, ST = Connecticut, L = Storrs, street = MSB, 
O = University of Connecticut, OU = UITS, CN = mta4.example.com
verify return:1
---
Certificate chain
 0 s:/C=US/postalCode=06269/ST=Connecticut/L=Storrs/street=MSB/O=University of 
Connecticut/OU=UITS/CN=mta4.example.com
   i:/C=US/ST=MI/L=Ann Arbor/O=Internet2/OU=InCommon/CN=InCommon RSA Server CA
 1 s:/C=US/ST=MI/L=Ann Arbor/O=Internet2/OU=InCommon/CN=InCommon RSA Server CA
   i:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA 
Certification Authority
 2 s:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA 
Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External 
CA Root
 3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External 
CA Root
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External 
CA Root
---
Server certificate
-BEGIN CERTIFICATE-
MIIFbTCCBFWgAwIBAgIQUUUM6kkQWQV8kesbMKoP2TANBgkqhkiG9w0BAQsFADB2
MQswCQYDVQQGEwJVUzELMAkGA1UECBMCTUkxEjAQBgNVBAcTCUFubiBBcmJvcjES
MBAGA1UEChMJSW50ZXJuZXQyMREwDwYDVQQLEwhJbkNvbW1vbjEfMB0GA1UEAxMW
SW5Db21tb24gUlNBIFNlcnZlciBDQTAeFw0xNjAzMDEwMDAwMDBaFw0xOTAzMDEy
MzU5NTlaMIGjMQswCQYDVQQGEwJVUzEOMAwGA1UEERMFMDYyNjkxFDASBgNVBAgT
C0Nvbm5lY3RpY3V0MQ8wDQYDVQQHEwZTdG9ycnMxDDAKBgNVBAkTA01TQjEiMCAG
A1UEChMZVW5pdmVyc2l0eSBvZiBDb25uZWN0aWN1dDENMAsGA1UECxMEVUlUUzEc
MBoGA1UEAxMTbXRhNC51aXRzLnVjb25uLmVkdTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAKXs5Mhq4l4c+nMdwxFY3lndze/40SAuVhLUA2oiQ1j359tA
xu6UPoE5XaeYDevTSm7kG/GiTRrNJRWXqWcGAfqxU2smopOP1ybLSqYno8JG6bq7
IzQzOpUaT9jhqXhxYLwC7gNkw6FfFTwH3dzUCqMEDiceBf7Sbgu3cw53WeoXjYOD
4sLaidh4ZLRXTYGoTcrFUAosyM4GhNs9DFbRYJxYMTN/FLFHGi62EfLdWnynKHHm
ewsvOWTRwcC+mVxXOOrD24fNsX9PKshYbX+jBLXI/HCHgT8zx7MZUSYbk/tOjf5O

Re: How to write pcre rules to exclude attachment?

2016-11-03 Thread @lbutlr
On 02 Nov 2016, at 21:45, vod vos  wrote:
> HOW can we just receive just such as .jpg .png .mp4 and reject all other 
> attachment in a short regexp to do the job?

While you *CAN* do this (As Noel shows) you should not. Not only will you end 
up wit a maintenance nightmare, but you will always be dealing with rejected 
emails that (rightly) annoy your users.

If your intent is to make your users hate your mail server and avoid it at all 
costs, go ahead.

If you’d like to TEST this idea, then do what Noel suggests, but use

/^Content-(Disposition|Type).*name\s*=/  WARN

and check your logs for a month for the warnings so you get an idea of how many 
messages you’d be rejecting.

You might also want to check existing mail. If you have a large enough store of 
email, something like this will show the types of extensions actually present:

 grep -Er -o “^Content-(Disposition|Type).*name\s*=\"[^\"]+" 
/path/to/lots/of/email | awk -F\" '{print $2}’

(and will probably also show some surprising results including images with no 
extensions at all)




Re: Getting false unknown user errors

2016-11-03 Thread @lbutlr
On 01 Nov 2016, at 03:15, wilfried.es...@essignetz.de wrote:
> 
> /etc/postfix/main.cf:
>content_filter = scan:localhost:10025
>receive_override_options = no_address_mappings
> 
> (from http://www.postfix.org/FILTER_README.html#advanced_filter)
> 
> And remove no_address_mappings from your "127.0.0.1:10025 inet"-smtpd.

If receive_override_options is set to no_address_mappings won’t that apply to 
ALL locally received messages? That will not work as there are many 
locaddresses that expand via either virtual or mysql maps to the eventual 
address.




Ubuntu 16.04lts & ssl unknown states

2016-11-03 Thread Florian Piekert
Good morning everybody,

I was wondering for quite some weeks now how to fix this issue with my
postfix. I had a brief discussion with Ralf Hildebrandt and he suggested
asking via the users lists, that's what I am doing now.

I have the situation that the PF currently doesn't seem to get proper
information about the state of the SSL connection, as you can see below.

==> mail/mail.log <==
Nov  3 08:50:29 blueberry postfix/tlsproxy[8057]: CONNECT from
[2a01:111:f400:fe02::31f]:39552
Nov  3 08:50:29 blueberry postfix/tlsproxy[8057]: setting up TLS connection
from [2a01:111:f400:fe02::31f]:39552
Nov  3 08:50:29 blueberry postfix/tlsproxy[8057]:
[2a01:111:f400:fe02::31f]:39552: TLS cipher list
"aNULL:-aNULL:HIGH:MEDIUM:LOW:EXPORT:+RC4:@STRENGTH:!aNULL"
Nov  3 08:50:29 blueberry postfix/tlsproxy[8057]: SSL_accept:before/accept
initialization
Nov  3 08:50:30 blueberry postfix/tlsproxy[8057]: SSL_accept:unknown state
Nov  3 08:50:30 blueberry postfix/tlsproxy[8057]: message repeated 5 times:
[ SSL_accept:unknown state]
Nov  3 08:50:30 blueberry postfix/tlsproxy[8057]: SSL_accept:failed in
unknown state

It doesn't matter if it is an IPv6 host, if the host is in mynetworks or not
(all postfixes with CACert issues certs and working properly between each of
the others finely).

Any pointers what to check/where to lock/what to fix are highly appreciated.

And I will probably drop another mail around another issue in conjunction
with dovecot virtual user delivery pf->dovecot... but first this SSL thing...

Thanks!

Florian

===
Note:  this message was  send by me *only* if the  eMail message contains a
correct pgp signature corresponding to my address at  flo...@floppy.org. Do
you need my  PGP  public key? Check out http://www.floppy.org or send me an
email with  the subject "send pgp public key" to  this address of mine.Thx!

2bounce_notice_recipient = postmaster-bounce
address_verify_map = btree:/var/lib/postfix/verify
address_verify_negative_cache = yes
address_verify_negative_expire_time = 3d
address_verify_negative_refresh_time = 300s
address_verify_positive_expire_time = 31d
address_verify_positive_refresh_time = 7d
alias_database = btree:/etc/aliases
alias_maps = btree:/etc/aliases
allow_percent_hack = no
always_bcc =
biff = no
body_checks = regexp:/etc/postfix/body_checks.regexp
bounce_notice_recipient = postmaster-bounce
bounce_queue_lifetime = 1d
bounce_size_limit = 10240
broken_sasl_auth_clients = yes
canonical_maps = btree:/etc/postfix/canonical
command_directory = /usr/sbin
compatibility_level = 2
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/lib/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin xxgdb 
$daemon_directory/$process_name $process_id & sleep 5
default_database_type = btree
default_destination_concurrency_limit = 10
default_privs = nobody
default_process_limit = 12
defer_transports = hold
delay_notice_recipient = postmaster-delay
delay_warning_time = 2d
disable_dns_lookups = no
disable_vrfy_command = yes
error_notice_recipient = postmaster-error
header_checks = regexp:/etc/postfix/block255, 
regexp:/etc/postfix/header_checks.regexp
html_directory = /srv/www/yadda.dadd-do.de/html/postfix
inet_interfaces = all
inet_protocols = all
lmtp_tls_ciphers = export
lmtp_tls_mandatory_protocols = !SSLv2 !SSLv3
lmtp_tls_protocols = !SSLv2 !SSLv3
local_destination_concurrency_limit = 4
mail_owner = postfix
mail_spool_directory = /var/mail
mailbox_size_limit = 10
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
masquerade_classes = envelope_sender, header_sender, header_recipient
masquerade_domains =
masquerade_exceptions = root
maximal_queue_lifetime = 3d
message_size_limit = 12500
meta_directory = /etc/postfix
mydestination = localhost.$mydomain, localhost, localhost.localdomain, 
$myhostname
myhostname = yadda.dadd-do.de
mynetworks = 127.0.0.0/8 [::1]/128...
newaliases_path = /usr/bin/newaliases
notify_classes = bounce, resource, software, delay, policy
postscreen_access_list = permit_mynetworks 
cidr:/etc/postfix/postscreen_access.cidr
postscreen_bare_newline_action = drop
postscreen_bare_newline_enable = yes
postscreen_blacklist_action = drop
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites =
postscreen_dnsbl_threshold = 2
postscreen_greet_action = enforce
postscreen_non_smtp_command_enable = yes
postscreen_pipelining_enable = yes
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/packages/postfix/README_FILES
relay_domains = btree:/etc/postfix/relay_domains
relay_recipient_maps = btree:/etc/postfix/recipient_maps.outpost
relayhost = outpost.post-peine.de
relocated_maps = btree:/etc/postfix/relocated
resolve_dequoted_address = yes
sample_directory = /usr/share/doc/packages/postfix/samples
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
shlib_directory = 

Re: How to write pcre rules to exclude attachment?

2016-11-03 Thread Ralph Seichter
On 03.11.2016 04:45, vod vos wrote:

> HOW can we just receive just such as .jpg .png .mp4 and reject all
> other attachment in a short regexp to do the job?

That's not something that can be handled with a "short regexp".
I suggest you look into amavisd-new or other content filters
which work in combination with Postfix.

-Ralph


Re: [Feature-request] (smtpd_)milter_exceptions

2016-11-03 Thread Christian Rößner
> Am 02.11.2016 um 21:45 schrieb Christian Rößner 
> :
> 
>> Am 01.11.2016 um 13:48 schrieb Wietse Venema :
>> 
>> Christian Ro??ner:
>>> 
 Am 25.10.2016 um 08:22 schrieb Wietse Venema :
 
 Wietse Venema:
> Wietse Venema:
>> Looks like either 1) an exclusion mechanism or 2) a selection
>> mechanism would do the job.
>> 
>> 1) Nullifies the smtpd_milters setting depending on the client.
>> 
>> 2) Chooses the smtpd_milters setting depending on the client.
>> 
>> I'll think about it.
> 
> I've implemented the second variant. If you maintain configurations
> by hand, then excluding mynetworks will be a bit of extra work. I
> recommend that configurations aren't maintained by hand.
 
 Listed on ftp.porcupine.org/mirrors/postfix-release/index.html as
 postfix-3.2-20161024-nonprod.
>>> 
>>> I just compiled this version. I give it a try.
>> 
>> It needs one change, otherwise it segfaults without smtpd_milter_maps
>> setting. I'll push out an update later today.
>> 
>>> Currently I am not sure how to use this feature for my problem,
>>> as it does not really address my asked request. It is a boolean
>>> all-or-nothing setting. So now I turn off all milters for a
>>> system,... not exactly what I hoped.

Tested it and it works perfectly. Thanks a lot for implementing this feature

Christian
-- 
Erlenwiese 14, 36304 Alsfeld
T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345
USt-IdNr.: DE225643613, https://www.roessner-network-solutions.com




smime.p7s
Description: S/MIME cryptographic signature