Re: Issue with SASL authentication

2017-05-26 Thread Patrick Ben Koetter
Daniel,

* Daniel Bareiro :
> So it's all limited to that saslauth is not able to authenticate without
> the realm. What I can not find out is why this happens. I do not see the
> difference in the configuration between both servers.
> 
> In any case, it seems that Cyrus IMAP is able to run smoothly. But it's
> not the same with Postfix. Anyway I'm still thinking what can differ
> between both servers so that the authentication without realm does not
> work here.

I have no idea why the domain needs to be appended on one machine and doesn't
have to on another one, but *if* all your SASL users are within the same
domain (realm) Postfix can 'add' it for you.

Assuming 'server2' is your domain/realm put this in main.cf:

smtpd_sasl_local_domain = server2

p@rick


-- 
[*] sys4 AG
 
https://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, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein
 


Re: Recipient Restrictions

2017-05-26 Thread GP

On 05/24/2017 06:00 PM, Noel Jones wrote:

On 5/24/2017 8:11 AM, GP wrote:

Hi all,

is it possible to have restrictions that apply to certain users only
with postfix ?

Yes, using either smtpd_restriction_classes or an external policy
service.
http://www.postfix.org/RESTRICTION_CLASS_README.html
http://www.postfix.org/SMTPD_POLICY_README.html



For example I want some users not to be able to send or receive
messages
more than 2MB in size  . Can it be done ?

Size is a little tricky if you have to deal with multi-recipient
mail, but your best choice here is an external policy service such
as postfwd.
http://postfwd.org/



   -- Noel Jones


Thanks for all the info , you gave me food for thought !

-- George


Can this SASL configuration be improved

2017-05-26 Thread Cecil Westerhof
In my main.cf I have:

# SASL stuff

smtp_sasl_auth_enable = yes
smtp_sasl_tls_security_options = noanonymous
smtp_tls_security_level = encrypt
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noplaintext, noanonymous
smtpd_sasl_auth_enable = no
# Because of POODLE vulnerability
smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
smtpd_tls_protocols=!SSLv2,!SSLv3
smtp_tls_mandatory_protocols=!SSLv2,!SSLv3
smtp_tls_protocols=!SSLv2,!SSLv3

​Is this OK, or can it be improved?​

-- 
Cecil Westerhof


RE: Can this SASL configuration be improved

2017-05-26 Thread Fazzina, Angelo
Hi,
Have you considered limiting weak ciphers ?

smtpd_tls_exclude_ciphers =


-ALF

-Angelo Fazzina
Operating Systems Programmer / Analyst
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 Cecil Westerhof
Sent: Friday, May 26, 2017 11:23 AM
To: Postfix users 
Subject: Can this SASL configuration be improved

In my main.cf I have:

# SASL stuff

smtp_sasl_auth_enable = yes
smtp_sasl_tls_security_options = noanonymous
smtp_tls_security_level = encrypt
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noplaintext, noanonymous
smtpd_sasl_auth_enable = no
# Because of POODLE vulnerability
smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
smtpd_tls_protocols=!SSLv2,!SSLv3
smtp_tls_mandatory_protocols=!SSLv2,!SSLv3
smtp_tls_protocols=!SSLv2,!SSLv3

​Is this OK, or can it be improved?​

--
Cecil Westerhof


Re: Can this SASL configuration be improved

2017-05-26 Thread Viktor Dukhovni

> On May 26, 2017, at 11:29 AM, Fazzina, Angelo  
> wrote:
> 
> Have you considered limiting weak ciphers ?
>  
> smtpd_tls_exclude_ciphers =

That layer of tweak is neither recommended nor needed.  What is recommended is:

smtpd_tls_ciphers = medium
smtp_tls_ciphers = medium

these are default values in reasonably recent versions of Postfix.

As to the OP's question without a description of the requirements, it can't
be answered.  His settings are fairly normal.  Most of these are TLS settings,
is there perhaps confusion between "SASL" and "SSL"?

More specific questions, get more meaningful answers.

-- 
Viktor.



smtp_tls-security_level .may/dane/encrypt

2017-05-26 Thread John
I currently use "smtp_tls_security_level = dane"  but recent discussion 
have made me wonder if I should change that. Maybe encrypt.


john A



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
smtp   inet  n   -   n   -   1   postscreen
smtpd  pass  -   -   n   -   -   smtpd
-o cleanup_service_name=pre-cleanup
pickup fifo  n   -   n   60  1   pickup
-o cleanup_service_name=pre-cleanup
submission inet  n   -   n   -   30  smtpd
-o content_filter=smtp-amavis:[127.0.0.1]:10026
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_sasl_type=dovecot
-o smtpd_sasl_path=private/dovecot-auth
-o smtpd_sasl_local_domain=$mydomain
-o broken_sasl_auth_clients=yes
-o smtpd_sasl_authenticated_header=yes
-o smtpd_client_restrictions=
-o smtpd_data_restrictions=
-o smtpd_etrn_restrictions=reject
-o smtpd_helo_restrictions=
-o {smtpd_recipient_restrictions=check_sender_access 
hash:/etc/postfix/maps/submission_access, reject}
-o smtpd_relay_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_client_connection_count_limit=15
-o smtpd_client_connection_rate_limit=80
-o smtpd_delay_reject=yes
-o cleanup_service_name=pre-cleanup
qmgr   fifo  n   -   n   300 1   qmgr
tlsmgr unix  -   -   n   1000?   1   tlsmgr
rewriteunix  -   -   n   -   -   trivial-rewrite
bounce unix  -   -   n   -   0   bounce
defer  unix  -   -   n   -   0   bounce
trace  unix  -   -   n   -   0   bounce
verify unix  -   -   n   -   1   verify
flush  unix  n   -   n   1000?   0   flush
proxymap   unix  -   -   n   -   -   proxymap
proxywrite unix  -   -   n   -   1   proxymap
smtp   unix  -   -   n   -   -   smtp
-o smtp_sasl_auth_enable=no
-o smtp_bind_address=74.116.186.178
-o smtp_bind_address6=2606:6d00:100:4301::1:200
relay  unix  -   -   n   -   -   smtp
showq  unix  n   -   n   -   -   showq
error  unix  -   -   n   -   -   error
retry  unix  -   -   n   -   -   error
discardunix  -   -   n   -   -   discard
local  unix  -   n   n   -   -   local
virtualunix  -   n   n   -   -   virtual
lmtp   unix  -   -   n   -   -   lmtp
anvil  unix  -   -   n   -   1   anvil
scache unix  -   -   n   -   1   scache
smtp-amavis unix -   -   n   -   4   smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
-o smtp_tls_note_starttls_offer=no
127.0.0.1:10025 inet n   -   n   -   -   smtpd
-o content_filter=
-o mynetworks=127.0.0.0/8
-o smtpd_delay_reject=no
-o smtpd_client_restrictions=permit_mynetworks,reject
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_relay_restrictions=permit_mynetworks,reject
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=reject_unauth_pipelining
-o smtpd_end_of_data_restrictions=
-o smtpd_restriction_classes=
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o local_header_rewrite_clients=
-o local_recipient_maps=
-o 
receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters
-o smtpd_tls_security_level=none
-o local_recipient_maps=
-o relay_recipient_maps=
pre-cleanup unix n   -   n   -   0   cleanup
-o virtual_alias_maps=
cleanupunix  n   -   n   -   0   cleanup
-o mime_header_checks=
-o nested_header_checks=
-o header_checks=
-o body_checks=
dnsblogunix  -   -   n   -   0   dnsblog
tlsproxy   unix  -   -   n   -   0   tlsproxy
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
bounce_size_limit = 65536
compatibility_level = 2
content_filter = smtp-amavis:[127.0.0.1]:10024
default_process_limit = 20
delay_warning_time = 12h
disable_vrfy_command = yes
header_size_limit = 32768
home_mailbox = Maildir/
html_directory = /usr/share/doc/postfix/html
inet_protocols = all
mailbox_transport = lmtp:unix:private/dovecot-lmtp
message_size_limit = 32768000
mime_header_checks = pcre:/etc/postfix/maps/mime_header_checks.pcre
mydestination = localhost, localhost.localdomain, localdomain
mydomain = klam.ca
m

Re: smtp_tls-security_level .may/dane/encrypt

2017-05-26 Thread Viktor Dukhovni

> On May 26, 2017, at 9:40 PM, John  wrote:
> 
> I currently use "smtp_tls_security_level = dane"  but recent discussion have 
> made me wonder if I should change that. Maybe encrypt.

These address entirely different use-cases.  So no.

Use "encrypt" when all mail goes to a single relayhost with no way
to authenticate that relayhost.

Use "dane" when delivering "direct to MX", that is, wherever the
MX records of various domains might point.

-- 
Viktor.



Re: smtp_tls-security_level .may/dane/encrypt

2017-05-26 Thread John

Thanks Viktor.

I try not to mess with my configuration too much, working on the 
principal is it ain't broke don't fix it.


John A


On 5/26/17 9:44 PM, Viktor Dukhovni wrote:

On May 26, 2017, at 9:40 PM, John  wrote:

I currently use "smtp_tls_security_level = dane"  but recent discussion have 
made me wonder if I should change that. Maybe encrypt.

These address entirely different use-cases.  So no.

Use "encrypt" when all mail goes to a single relayhost with no way
to authenticate that relayhost.

Use "dane" when delivering "direct to MX", that is, wherever the
MX records of various domains might point.




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



Re: smtp_tls-security_level .may/dane/encrypt

2017-05-26 Thread Viktor Dukhovni

> On May 26, 2017, at 10:01 PM, John  wrote:
> 
>>> I currently use "smtp_tls_security_level = dane"  but recent discussion 
>>> have made me wonder if I should change that. Maybe encrypt.
>> These address entirely different use-cases.  So no.
>> 
>> Use "encrypt" when all mail goes to a single relayhost with no way
>> to authenticate that relayhost.
>> 
>> Use "dane" when delivering "direct to MX", that is, wherever the
>> MX records of various domains might point.

Do you now understand why each setting is applicable to the use-case
in question?  Or still not really?  It's a shame to just cargo-cult
settings without knowing what they mean...

-- 
Viktor.