RE: Proper procedure for importing TLS cert & private key for Postfix use

2017-12-08 Thread Security Admin (NetSec) 
Ignore typo, was trying to obfuscate file.

"/etc/ssl/private/tlsprivate.key" does = "/etc/ssl/private/tlsprivatekey.key"



From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
On Behalf Of Fazzina, Angelo
Sent: Friday, December 08, 2017 10:29 AM
To: Security Admin (NetSec) ; 
postfix-users@postfix.org
Subject: RE: Proper procedure for importing TLS cert & private key for Postfix 
use

This
"/etc/ssl/private/tlsprivate.key":
Does not equal
"/etc/ssl/private/tlsprivatekey.key"


-ANGELO FAZZINA

UITS Service Manager:
Spam and Virus Prevention
Mass Mailing
G Suite/Gmail

ang...@uconn.edu
University of Connecticut,  UITS, SSG, Server Systems
860-486-9075

From: owner-postfix-us...@postfix.org 
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Security Admin (NetSec)
Sent: Friday, December 8, 2017 1:03 PM
To: postfix-users@postfix.org
Subject: Proper procedure for importing TLS cert & private key for Postfix use

Recently imported files that contained the TLS certificate and the private key.

Imported them to them proper directories and changed the default settings from 
the old cert & key files to the new files 
("smtpd_tls_cert_file=/etc/ssl/certs/tlscert.pem" and 
"smtpd_tls_key_file=/etc/ssl/private/tlsprivatekey.key").

When I ran a test e-mail to see if it worked, I got the following errors in 
"mail.log"


Dec  6 21:15:36 portus postfix/smtpd[18839]: warning: cannot get RSA private 
key from file "/etc/ssl/private/tlsprivate.key": disabling TLS support
Dec  6 21:15:36 portus postfix/smtpd[18839]: warning: TLS library problem: 
error:0906406D:PEM routines:PEM_def_callback:problems getting 
password:pem_lib.c:110:
Dec  6 21:15:36 portus postfix/smtpd[18839]: warning: TLS library problem: 
error:0906A068:PEM routines:PEM_do_header:bad password read:pem_lib.c:457:
Dec  6 21:15:36 portus postfix/smtpd[18839]: warning: TLS library problem: 
error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib:ssl_rsa.c:649:


Any thought on what I am doing wrong and how I might fix?  I am thinking 
possibly file permissions but did not want to chmod until I knew for sure.


Thanks in advance!


Ed Ray

Re: Proper procedure for importing TLS cert & private key for Postfix use

2017-12-08 Thread Viktor Dukhovni 


> On Dec 8, 2017, at 11:37 PM, Bill Cole 
>  wrote:
> 
> Assuming the mismatched filenames between your narrative and log lines is a 
> typo, I think the problem is identified in the 2nd & 3rd lines, citing 
> "password" problems. This implies that you have an encrypted private key 
> file, which I don't believe can be made to work with Postfix. Convert the key 
> to unencrypted form. To quote the man page for rsa(1ssl) :
> 
> openssl rsa -in key.pem -out keyout.pem

Basically correct, but since many extant version of OpenSSL
(prior to OpenSSL 1.1.0) don't explicitly ensure that key
output files are not world-readable, I'd suggest instead:

   # (umask 077; openssl rsa -in key.pem -out keyout.pem)

-- 
Viktor.

Re: Proper procedure for importing TLS cert & private key for Postfix use

2017-12-08 Thread Bill Cole 

On 8 Dec 2017, at 13:02 (-0500), Security Admin (NetSec) wrote:

Recently imported files that contained the TLS certificate and the 
private key.


Imported them to them proper directories and changed the default 
settings from the old cert & key files to the new files 
("smtpd_tls_cert_file=/etc/ssl/certs/tlscert.pem" and 
"smtpd_tls_key_file=/etc/ssl/private/tlsprivatekey.key").


When I ran a test e-mail to see if it worked, I got the following 
errors in "mail.log"



Dec  6 21:15:36 portus postfix/smtpd[18839]: warning: cannot get RSA 
private key from file "/etc/ssl/private/tlsprivate.key": disabling TLS 
support
Dec  6 21:15:36 portus postfix/smtpd[18839]: warning: TLS library 
problem: error:0906406D:PEM routines:PEM_def_callback:problems getting 
password:pem_lib.c:110:
Dec  6 21:15:36 portus postfix/smtpd[18839]: warning: TLS library 
problem: error:0906A068:PEM routines:PEM_do_header:bad password 
read:pem_lib.c:457:
Dec  6 21:15:36 portus postfix/smtpd[18839]: warning: TLS library 
problem: error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM 
lib:ssl_rsa.c:649:



Any thought on what I am doing wrong and how I might fix?  I am 
thinking possibly file permissions but did not want to chmod until I 
knew for sure.


Assuming the mismatched filenames between your narrative and log lines 
is a typo, I think the problem is identified in the 2nd & 3rd lines, 
citing "password" problems. This implies that you have an encrypted 
private key file, which I don't believe can be made to work with 
Postfix. Convert the key to unencrypted form. To quote the man page for 
rsa(1ssl) :


openssl rsa -in key.pem -out keyout.pem

--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole

Re: owner_request_special issue in postfix 3.2.3

2017-12-08 Thread Wietse Venema 
Laurent Frigault:
> owner-debuglolo:  l...@agneau.org
> owner-debuglolo-outgoing: owner-debugl...@listes2.agneau.org
> debuglolo-outgoing:   :include:/usr/local/etc/postfix/lists/debuglolo

Wietse:
> > If sending to debuglolo-outgoing, Postfix will replace the sender with
> > one of the following:
> > 
> > 1) owner-debugl...@listes2.agneau.org (expand_owner_alias = yes) 
> > 
> > 2) owner-debuglolo-outgoing (expand_owner_alias = no) which then
> > becomes owner-debuglolo-outgoing@$myorigin.
> > 
> > You appear to have configured Postfix to do 2).
> 
> None of the 2 are what I need.

This feature works as documented. IT REPLACES THE ENTIRE SENDER
regardless of what the sender was.

> I need the sender address to be rewritten from
> owner-debugl...@listes2.agneau.org to
> owner-debuglolo-outgo...@listes2.agneau.org

Then use canonical_maps. Postfix owner featres do not rewrite
addresses, they REPLACE addresses regardless of what the sender
was.

Wietse

RE: Proper procedure for importing TLS cert & private key for Postfix use

2017-12-08 Thread Fazzina, Angelo 
This
"/etc/ssl/private/tlsprivate.key":
Does not equal
"/etc/ssl/private/tlsprivatekey.key"


-ANGELO FAZZINA

UITS Service Manager:
Spam and Virus Prevention
Mass Mailing
G Suite/Gmail

ang...@uconn.edu
University of Connecticut,  UITS, SSG, Server Systems
860-486-9075

From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
On Behalf Of Security Admin (NetSec)
Sent: Friday, December 8, 2017 1:03 PM
To: postfix-users@postfix.org
Subject: Proper procedure for importing TLS cert & private key for Postfix use

Recently imported files that contained the TLS certificate and the private key.

Imported them to them proper directories and changed the default settings from 
the old cert & key files to the new files 
("smtpd_tls_cert_file=/etc/ssl/certs/tlscert.pem" and 
"smtpd_tls_key_file=/etc/ssl/private/tlsprivatekey.key").

When I ran a test e-mail to see if it worked, I got the following errors in 
"mail.log"


Dec  6 21:15:36 portus postfix/smtpd[18839]: warning: cannot get RSA private 
key from file "/etc/ssl/private/tlsprivate.key": disabling TLS support
Dec  6 21:15:36 portus postfix/smtpd[18839]: warning: TLS library problem: 
error:0906406D:PEM routines:PEM_def_callback:problems getting 
password:pem_lib.c:110:
Dec  6 21:15:36 portus postfix/smtpd[18839]: warning: TLS library problem: 
error:0906A068:PEM routines:PEM_do_header:bad password read:pem_lib.c:457:
Dec  6 21:15:36 portus postfix/smtpd[18839]: warning: TLS library problem: 
error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib:ssl_rsa.c:649:


Any thought on what I am doing wrong and how I might fix?  I am thinking 
possibly file permissions but did not want to chmod until I knew for sure.


Thanks in advance!


Ed Ray

Re: owner_request_special issue in postfix 3.2.3

2017-12-08 Thread Laurent Frigault 
On Thu, Dec 07, 2017 at 07:16:22PM -0500, Wietse Venema wrote:

> > I have an issue with owner_request_special . It rewrites correctly the
> > local part of the sender address BUT, it replaces the right part of the
> > sender address with myorigin (or myhostname) instead of keeping it.
> > 
> > My config :
> > OS: FreeBSD 11.1-RELEASE-p4
> > postfix: postfix-3.2.3,1 (from freebsd package)
> > 
> > > myhostname = mail.agneau.org
> > > mydomain = agneau.org
> > > myorigin = mail.agneau.org
> > > mydestination = mail.agneau.org, listes2.agneau.org, listes3.agneau.org
> > > relay_domains = agneau.org bergerie.agneau.org
> > > alias_maps = hash:$config_directory/aliases
> > > alias_database = hash:$config_directory/aliases
> > My debug aliases in $config_directory/aliases :
> > 
> > owner-debuglolo:l...@agneau.org
> > owner-debuglolo-outgoing:   owner-debugl...@listes2.agneau.org
> > debuglolo-outgoing: :include:/usr/local/etc/postfix/lists/debuglolo
> > 
> > mail# cat lists/debuglolo
> > lfriga...@agneau.org
> > 
> > 
> > test command to reproduce the problem:
> > 
> > printf 'From: Laurent Frigault \nTo: 
> > debugl...@listes2.agneau.org\nSubject: test\n\ntest\n' |sendmail -oi -oee 
> > -fowner-debugl...@listes2.agneau.org debuglolo-outgo...@listes2.agneau.org
> > 
> > The enveloppe sender owner-debugl...@listes2.agneau.org if rewritten to
> > owner-debuglolo-outgo...@mail.agneau.org instead of 
> > owner-debuglolo-outgo...@listes2.agneau.org
> 
> If sending to debuglolo-outgoing, Postfix will replace the sender with
> one of the following:
> 
> 1) owner-debugl...@listes2.agneau.org (expand_owner_alias = yes) 
> 
> 2) owner-debuglolo-outgoing (expand_owner_alias = no) which then
> becomes owner-debuglolo-outgoing@$myorigin.
> 
> You appear to have configured Postfix to do 2).

None of the 2 are what I need.

I need the sender address to be rewritten from
owner-debugl...@listes2.agneau.org to
owner-debuglolo-outgo...@listes2.agneau.org

There is nothing in local(8) man page saying that owner_request_special
will replace the right part by $myorigin

   owner_request_special (yes)
  Give special treatment to owner-listname and listname-request
  address localparts: don't split such addresses when the
  recipient_delimiter is set to "-".


For now, the only solution I found working , is to use
sender_canonical_maps to fix the rewritten domain part :
sender_canonical_classes = envelope_sender
sender_canonical_maps = hash:$config_directory/sender_canonical

mail# cat sender_canonical
owner-debuglolo-outgo...@mail.agneau.org
owner-debuglolo-outgo...@listes2.agneau.org

Do you have a better solution ?


-- 
Laurent Frigault |

Proper procedure for importing TLS cert & private key for Postfix use

2017-12-08 Thread Security Admin (NetSec) 
Recently imported files that contained the TLS certificate and the private key.

Imported them to them proper directories and changed the default settings from 
the old cert & key files to the new files 
("smtpd_tls_cert_file=/etc/ssl/certs/tlscert.pem" and 
"smtpd_tls_key_file=/etc/ssl/private/tlsprivatekey.key").

When I ran a test e-mail to see if it worked, I got the following errors in 
"mail.log"


Dec  6 21:15:36 portus postfix/smtpd[18839]: warning: cannot get RSA private 
key from file "/etc/ssl/private/tlsprivate.key": disabling TLS support
Dec  6 21:15:36 portus postfix/smtpd[18839]: warning: TLS library problem: 
error:0906406D:PEM routines:PEM_def_callback:problems getting 
password:pem_lib.c:110:
Dec  6 21:15:36 portus postfix/smtpd[18839]: warning: TLS library problem: 
error:0906A068:PEM routines:PEM_do_header:bad password read:pem_lib.c:457:
Dec  6 21:15:36 portus postfix/smtpd[18839]: warning: TLS library problem: 
error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib:ssl_rsa.c:649:


Any thought on what I am doing wrong and how I might fix?  I am thinking 
possibly file permissions but did not want to chmod until I knew for sure.


Thanks in advance!


Ed Ray

Re: PSA University of Michigan research IP space

2017-12-08 Thread Richard 


> Date: Friday, December 08, 2017 10:07:58 +
> From: Allen Coates 
> 
> On 08/12/17 03:59, Viktor Dukhovni wrote:
>> 
>> 
>>> On Dec 7, 2017, at 9:14 PM, li...@lazygranch.com wrote:
>>> 
>>> http://researchscan288.eecs.umich.edu/
>>> I never could find the research IP space and my email went
>>> unanswered. I just blocked the whole university. Link has the IP
>>> space as listed below:
>>> 141.212.121.0/24 
>>> 141.212.122.0/24
>> 
>> Seems rather an overreaction. So a few bots scan your system now
>> and then, for socially beneficial research purposes[1].  Does it
>> really make sense to block an entire university to try to avoid
>> this?
>> 
> 
> The netblocks (above) are not the whole university, but only the
> range used by the research scans.
> 
> The website (also above) explains what the research is all about,
> and should you wish to opt out of the research, invites you to drop
> the aforementioned netblocks in your firewall.
> 
> To me, this seems a very reasonable and equitable arrangement.
> 
> Allen C

Correct, hardly the "whole university" (or even the "research IP
space"). It's about 500 ipnumbers used by a sub-section of the
college of engineering. For a better sense of the university's
allocations, see the "related networks" link at:

add data from XFORWARD to policy delegation protocol

2017-12-08 Thread Deniss 
Hi,

there is XFORWARD command (http://www.postfix.org/XFORWARD_README.html)
that smtpd and smtp can do.

It may be useful to prodvide XFORWARD data to external policy server
(http://www.postfix.org/SMTPD_POLICY_README.html) via additional
attributes to allow to implement MTA1->MTA2<->policy_server scenarios.

Best,
Deniss

Re: PSA University of Michigan research IP space

2017-12-08 Thread Allen Coates 


On 08/12/17 03:59, Viktor Dukhovni wrote:
> 
> 
>> On Dec 7, 2017, at 9:14 PM, li...@lazygranch.com wrote:
>>
>> http://researchscan288.eecs.umich.edu/
>> I never could find the research IP space and my email went unanswered.
>> I just blocked the whole university. Link has the IP space as listed
>> below:
>> 141.212.121.0/24 
>> 141.212.122.0/24
> 
> Seems rather an overreaction. So a few bots scan your system now and then,
> for socially beneficial research purposes[1].  Does it really make sense
> to block an entire university to try to avoid this?
> 

The netblocks (above) are not the whole university, but only the range
used by the research scans.

The website (also above) explains what the research is all about, and
should you wish to opt out of the research, invites you to drop the
aforementioned netblocks in your firewall.

To me, this seems a very reasonable and equitable arrangement.

Allen C

Re: PSA University of Michigan research IP space

2017-12-08 Thread li...@lazygranch.com 
On Thu, 7 Dec 2017 22:59:46 -0500
Viktor Dukhovni  wrote:

> > On Dec 7, 2017, at 9:14 PM, li...@lazygranch.com wrote:
> > 
> > http://researchscan288.eecs.umich.edu/
> > I never could find the research IP space and my email went
> > unanswered. I just blocked the whole university. Link has the IP
> > space as listed below:
> > 141.212.121.0/24 
> > 141.212.122.0/24  
> 
> Seems rather an overreaction. So a few bots scan your system now and
> then, for socially beneficial research purposes[1].  Does it really
> make sense to block an entire university to try to avoid this?
> 

I'm in agreement with you regarding blocking an entire university, but
I couldn't get a reply regarding the research IP space, nor could I
find the IP space online until today. 

Email, being the means of resetting passwords, gets extra scrutiny by
me. Now that I have the research IP space, I have removed the full
block. 

Interesting commentary:
https://www.hackerfactor.com/blog/index.php?url=archives/775-Scans-and-Attacks.html

The problem is the researchers look like hackers. For web "research",
they may provide an address to contact them in the browser meta data.
Maybe they are researchers, and maybe not. 

I allow a fair number of bots to poke the server, even if they appear
dubious. One claims to research uptime, but if you ping me once a day,
I don't think that is much of a study. I have a gut feeling many of
these research bots are really zombies. The student has graduated and
the account never canceled. I'm sure you've heard the story (perhaps
legend) of the university sysadmin mapping the network and finding some
server tucked away in a closet that they had no idea was there.