Re: aquamail helo option

[David Mehler]

Hello Viktor,

Thank you again for your reply.

I had to remove the mua* options in submission from the upstream
master.cf that I loaded, otherwise it loaded fine. I'm not using them.

I think I have it, the pfs that is. Can I get a postconf -nf and a
postconf -Mf sanitized of your configuration? I'd like to compare it
with mine.

Thanks.
Dave.


On 4/23/18, Viktor Dukhovni  wrote:
>
>
>> On Apr 23, 2018, at 12:29 AM, David Mehler  wrote:
>>
>> Thanks. So I can drop in master.cf upstream without inputting mua*
>> parameters in my main.cf?
>
> Generally not the whole file, but you can use the stock file as a
> starting template from which to borrow appropriate service definitions
> or specific override settings.
>
>> I've got a few options in my master.cf file submission service that
>> are not in the upstream file, are they still relevant in 3.3?
>>
>> smtp   inet  n   -   n   -   1   postscreen
>>-o smtpd_sasl_auth_enable=no
>
> That setting is the default, and if you don't set to "yes" in main.cf,
> the override is not needed, but could be a harmless "safety net".
>
>> dnsblogunix  -   -   n   -   0   dnsblog
>> tlsproxy   unix  -   -   n   -   0   tlsproxy
>
> These are needed for postscreen support.  You uncomment them in
> the stock file as needed.
>
>> and in submission:
>>-o smtpd_tls_dh1024_param_file=/etc/ssl/dhparam.pem
>
> See http://www.postfix.org/FORWARD_SECRECY_README.html#quick-start
> Don't get hung up the literal file name, what matters is the content,
> thus ideally a 2048-bit (Sophie Germain) prime group.
>
>>-o smtpd_sasl_type=dovecot
>>-o smtpd_sasl_path=private/auth
>
> Whatever SASL backend works for you.
>
>>-o smtpd_sasl_security_options=noanonymous
>>-o tls_preempt_cipherlist=yes
>
> These are fine.
>
> --
>   Viktor.
>
>

Re: aquamail helo option

[Viktor Dukhovni]

> On Apr 23, 2018, at 12:29 AM, David Mehler  wrote:
> 
> Thanks. So I can drop in master.cf upstream without inputting mua*
> parameters in my main.cf?

Generally not the whole file, but you can use the stock file as a
starting template from which to borrow appropriate service definitions
or specific override settings.

> I've got a few options in my master.cf file submission service that
> are not in the upstream file, are they still relevant in 3.3?
> 
> smtp   inet  n   -   n   -   1   postscreen
>-o smtpd_sasl_auth_enable=no

That setting is the default, and if you don't set to "yes" in main.cf,
the override is not needed, but could be a harmless "safety net".

> dnsblogunix  -   -   n   -   0   dnsblog
> tlsproxy   unix  -   -   n   -   0   tlsproxy

These are needed for postscreen support.  You uncomment them in
the stock file as needed.

> and in submission:
>-o smtpd_tls_dh1024_param_file=/etc/ssl/dhparam.pem

See http://www.postfix.org/FORWARD_SECRECY_README.html#quick-start
Don't get hung up the literal file name, what matters is the content,
thus ideally a 2048-bit (Sophie Germain) prime group.

>-o smtpd_sasl_type=dovecot
>-o smtpd_sasl_path=private/auth

Whatever SASL backend works for you.

>-o smtpd_sasl_security_options=noanonymous
>-o tls_preempt_cipherlist=yes

These are fine.

-- 
Viktor.

Re: aquamail helo option

[David Mehler]

Hi,

Thanks. So I can drop in master.cf upstream without inputting mua*
parameters in my main.cf?

I've got a few options in my master.cf file submission service that
are not in the upstream file, are they still relevant in 3.3?

smtp   inet  n   -   n   -   1   postscreen
-o smtpd_sasl_auth_enable=no

dnsblogunix  -   -   n   -   0   dnsblog
tlsproxy   unix  -   -   n   -   0   tlsproxy

and in submission:
-o smtpd_tls_dh1024_param_file=/etc/ssl/dhparam.pem
-o smtpd_sasl_type=dovecot
-o smtpd_sasl_path=private/auth
-o smtpd_sasl_security_options=noanonymous

-o tls_preempt_cipherlist=yes


Thanks.
Dave.


On 4/23/18, Viktor Dukhovni  wrote:
>
>
>> On Apr 23, 2018, at 12:10 AM, David Mehler  wrote:
>>
>> Thank you for your reply. I do see the differences between the
>> master.cf you reference and the one I've got. One thing do you have an
>> upstream reference for main.cf in GitHub? I'd looking for the mua*
>> definitions, my system does not have them.
>
> The default working configuration has empty values for the various
> $mua_mumble parameters.  Most sites don't need them, but if you do
> need additional controls, you set them to fit your needs.  The stock
> main.cf file does not define these parameters:
>
>   https://github.com/vdukhovni/postfix/blob/master/postfix/conf/main.cf
>
> --
>   Viktor.
>
>

Re: aquamail helo option

[Viktor Dukhovni]

> On Apr 23, 2018, at 12:10 AM, David Mehler  wrote:
> 
> Thank you for your reply. I do see the differences between the
> master.cf you reference and the one I've got. One thing do you have an
> upstream reference for main.cf in GitHub? I'd looking for the mua*
> definitions, my system does not have them.

The default working configuration has empty values for the various
$mua_mumble parameters.  Most sites don't need them, but if you do
need additional controls, you set them to fit your needs.  The stock
main.cf file does not define these parameters:

  https://github.com/vdukhovni/postfix/blob/master/postfix/conf/main.cf

-- 
Viktor.

Re: aquamail helo option

[David Mehler]

Hello Viktor,

Thank you for your reply. I do see the differences between the
master.cf you reference and the one I've got. One thing do you have an
upstream reference for main.cf in GitHub? I'd looking for the mua*
definitions, my system does not have them.

Thanks.
Dave.


On 4/22/18, Viktor Dukhovni  wrote:
>
>
>> On Apr 22, 2018, at 11:29 PM, David Mehler  wrote:
>>
>> Thanks for your reply. My postconf -nf and postconf -Mf are below as
>> is the relevant log portions. I'm suspecting that my various smtpd*
>> restrictions are wrong.
>
> Start with the default upstream master.cf file template for submission:
>
>
> https://github.com/vdukhovni/postfix/blob/master/postfix/conf/master.cf#L17
>
> AVOID complex restrict definitions in master.cf, use the indirect approach
> ($mua_client_restrictions, ...) from the stock master.cf file, with the
> actual definitions in main.cf.
>
> Only the shortest/simplest overrides that will never change should be
> explicitly defined in master.cf in.  For example, and likely the
> setting you're missing:
>
>-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
>
> --
>   Viktor.
>
>

Re: aquamail helo option

[Viktor Dukhovni]

> On Apr 22, 2018, at 11:29 PM, David Mehler  wrote:
> 
> Thanks for your reply. My postconf -nf and postconf -Mf are below as
> is the relevant log portions. I'm suspecting that my various smtpd*
> restrictions are wrong.

Start with the default upstream master.cf file template for submission:

  https://github.com/vdukhovni/postfix/blob/master/postfix/conf/master.cf#L17

AVOID complex restrict definitions in master.cf, use the indirect approach
($mua_client_restrictions, ...) from the stock master.cf file, with the
actual definitions in main.cf.

Only the shortest/simplest overrides that will never change should be
explicitly defined in master.cf in.  For example, and likely the
setting you're missing:

   -o smtpd_relay_restrictions=permit_sasl_authenticated,reject

-- 
Viktor.

Re: aquamail helo option

[David Mehler]

Hello,

Thanks for your reply. My postconf -nf and postconf -Mf are below as
is the relevant log portions. I'm suspecting that my various smtpd*
restrictions are wrong.

If you need any other files let me know.

Thanks.
Dave.

#postconf -nf
allow_percent_hack = no
append_dot_mydomain = no
biff = no
bounce_queue_lifetime = 1h
bounce_template_file = /usr/local/etc/postfix/bounce.cf
broken_sasl_auth_clients = no
command_directory = /usr/local/sbin
compatibility_level = 2
daemon_directory = /usr/local/libexec/postfix
data_directory = /var/db/postfix
delay_warning_time = 4h
disable_vrfy_command = yes
header_checks = pcre:/usr/local/etc/postfix/header_checks,
regexp:/usr/local/etc/postfix/phish419.regexp
html_directory = /usr/local/share/doc/postfix
in_flow_delay = 1s
inet_interfaces = xxx.xxx.xxx.xxx, 127.0.0.1
inet_protocols = ipv4
local_recipient_maps = $virtual_mailbox_maps
mail_owner = postfix
mailbox_size_limit = 0
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
maximal_backoff_time = 15m
maximal_queue_lifetime = 1h
message_size_limit = 52428800
meta_directory = /usr/local/libexec/postfix
milter_default_action = accept
milter_mail_macros = "i {mail_addr} {client_addr} {client_name} {auth_authen}"
milter_protocol = 6
mime_header_checks = regexp:/usr/local/etc/postfix/mime_header_checks
minimal_backoff_time = 5m
mydestination = localhost
mydomain = domain.com
myhostname = mail.domain.com
mynetworks = $config_directory/mynetworks
myorigin = $mydomain
newaliases_path = /usr/local/bin/newaliases
non_smtpd_milters = $smtpd_milters
postscreen_access_list = permit_mynetworks,
cidr:/usr/local/etc/postfix/postscreen_access.cidr,
cidr:/usr/local/etc/postfix/postscreen_spf_whitelist.cidr
postscreen_blacklist_action = drop
postscreen_dnsbl_action = drop
postscreen_dnsbl_reply_map =
pcre:/usr/local/etc/postfix/postscreen_dnsbl_reply_map.pcre
postscreen_dnsbl_sites = zen.spamhaus.org*3 b.barracudacentral.org*2
bl.spameatingmonkey.net*2 bl.spamcop.net dnsbl.sorbs.net psbl.surriel.com
bl.mailspike.net swl.spamhaus.org*-4
list.dnswl.org=127.[0..255].[0..255].0*-2
list.dnswl.org=127.[0..255].[0..255].1*-3
list.dnswl.org=127.[0..255].[0..255].[2..255]*-4
postscreen_dnsbl_threshold = 2
postscreen_dnsbl_whitelist_threshold = -1
postscreen_greet_action = drop
queue_directory = /var/spool/postfix
queue_run_delay = 5m
readme_directory = /usr/local/share/doc/postfix
recipient_delimiter = +
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
shlib_directory = /usr/local/lib/postfix
show_user_unknown_table_name = no
smtp_helo_timeout = 60s
smtp_tls_cert_file = $smtpd_tls_cert_file
smtp_tls_ciphers = high
smtp_tls_key_file = $smtpd_tls_key_file
smtp_tls_loglevel = 1
smtp_tls_mandatory_ciphers = medium
smtp_tls_mandatory_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK,
aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA
smtp_tls_mandatory_protocols = !SSLv2,!SSLv3, !TLSv1
smtp_tls_protocols = !SSLv2,!SSLv3, !TLSv1
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_use_tls = yes
smtpd_banner = $myhostname ESMTP
smtpd_client_restrictions = permit_mynetworks check_client_access
hash:/usr/local/etc/postfix/without_ptr reject_unknown_client_hostname
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks reject_invalid_helo_hostname
smtpd_milters = unix:/var/run/rspamd/milter.sock,inet:127.0.0.1:8472
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated
reject_unauth_destination check_helo_access
hash:/usr/local/etc/postfix/helo_access, ,check_helo_access
pcre:/usr/local/etc/postfix/helo_checks ,check_sender_mx_access
cidr:/usr/local/etc/postfix/bogus_mx check_sender_access
hash:/usr/local/etc/postfix/safe_addresses check_sender_access
hash:/usr/local/etc/postfix/auto-whtlst check_client_access
cidr:/usr/local/etc/postfix/spamfarms check_client_access
cidr:/usr/local/etc/postfix/sinokorea.cidr check_recipient_access
mysql:/usr/local/etc/postfix/db/recipient-access.cf permit_dnswl_client
list.dnswl.org=127.0.[2..14].[1..3] check_reverse_client_hostname_access
pcre:/usr/local/etc/postfix/fqrdns.pcre
reject_unknown_reverse_client_hostname reject_non_fqdn_sender
reject_invalid_helo_hostname reject_unlisted_recipient reject_rhsbl_client
dbl.spamhaus.org reject_rhsbl_sender dbl.spamhaus.org reject_rhsbl_helo
dbl.spamhaus.org check_policy_service unix:private/spf-policy
check_policy_service unix:private/dovecot-quota check_policy_service
unix:private/p0f-policy
smtpd_reject_unlisted_sender = yes
smtpd_relay_restrictions = reject_non_fqdn_recipient
reject_unknown_recipient_domain permit_mynetworks reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes

Re: aquamail helo option

[/dev/rob0]

On Sun, Apr 22, 2018 at 07:24:42PM -0400, David Mehler wrote:
> Is anyone using Android's Aquamail to send mail through postfix?
> If so, how do you have it configured?
> 
> My postfix is rejecting mail from Aquamail because it's helo is:
> 
> <[192.168.1.1]> basically it's internal ip.

What restriction do you have that is blocking this?  Include 
"postconf -nf ; postconf -Mf" and the entire non-verbose logs showing 
the rejection.  Perhaps you have a check_helo_access lookup; you 
should also show us what is in that lookup.

While you can, and I do, block such HELOs on port 25, you must not 
apply such a restriction to submitting clients.  A HELO like that is 
perfectly valid per RFC.

So perhaps the actual problem is that you're submitting on port 25, 
and your fix is to require users to submit on submission[s], ports 
587 or 465, and don't accept submitted mail on 25.  Your reply as 
detailed above will show this.

> I do not want to remove my restrictions can I get around this with 
> a map?

That would be a bad idea, and anyway, a question we couldn't answer 
without knowing how you blocked it.  The various Postfix HELO 
restrictions, such as:
+ reject_invalid_helo_hostname
+ reject_non_fqdn_helo_hostname
+ reject_unknown_helo_hostname
will NOT block that HELO string.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: dnsblog lifetime

[Doug Hardie]

> On 22 April 2018, at 05:50, Wietse Venema  wrote:
> 
> Doug Hardie:
>> I understood from the dnsblog man page that each dnsblog process
>> only lives for a "limited amount of time".  I noticed this because
>> I have over 50 dnsblog processes running on a fairly light duty
>> postfix server.  Some of them are over a week old.  At first I
>> thought they must have been orphaned, but looking through maillog,
>> I find entries in the last few minutes from the oldest and the
>> newest.  I didn't check all of them, but it appears they are all
>> in use.  Looking at the source for postfix-3.3-20180114 (on web),
>> it appears dnsblog checks one IP address and then exits.  I believe
>> I can limit the number of dnsblog processes in master.cf (currently
>> set to 0), but I am not sure that is a good idea.  How long are
>> these processes supposed to live?
> 
> According to source, dnsblog processes exclude themselves from the
> max_use limit (max_idle remains in effect). I suppose I turned off
> max_use because these processes are postscreen helpers. Postscreen
> was designed to handle a much larger client load than to the rest
> of Postfix. Under extreme loads like 1+ connections/second,
> one does not want to be creating 100+ processes/second, as that
> would limit scalability.
> 
> The dnsblog processes still terminate after 100s idle time. On my
> lightly-loaded server, there currently is no dnsblog process running.
> 
> Apparently your server has enough traffic to keep postscreen alive,
> and as a consequence, a collection of dnsblog processes.
> 
> I suppose you could reduce max_idle, but don't go overboard and
> set it to something small like 1s. That would be counterproductive.

Thanks for the info.  I never would have expected my server to be that busy.  I 
would suggest that the man page for dnsblog be updated in the first paragraph 
of configuration parameters to something like:

Changes to main.cf are picked up automatically as the dnsblog processes are 
started.  The dnsblog processes terminate after 100 seconds of idle time.  That 
is the default value and can be changed with the max idle configuration 
parameter.  However, reducing it to a small value is likely to be 
counterproductive.  Use the command "postfix reload" to speed up a change.

-- Doug

aquamail helo option

[David Mehler]

Hello,

Is anyone using Android's Aquamail to send mail through postfix? If
so, how do you have it configured?

My postfix is rejecting mail from Aquamail because it's helo is:

<[192.168.1.1]> basically it's internal ip.

I do not want to remove my restrictions can I get around this with a map?

Thanks.
Dave.

Re: dnsblog lifetime

[Wietse Venema]

Doug Hardie:
> I understood from the dnsblog man page that each dnsblog process
> only lives for a "limited amount of time".  I noticed this because
> I have over 50 dnsblog processes running on a fairly light duty
> postfix server.  Some of them are over a week old.  At first I
> thought they must have been orphaned, but looking through maillog,
> I find entries in the last few minutes from the oldest and the
> newest.  I didn't check all of them, but it appears they are all
> in use.  Looking at the source for postfix-3.3-20180114 (on web),
> it appears dnsblog checks one IP address and then exits.  I believe
> I can limit the number of dnsblog processes in master.cf (currently
> set to 0), but I am not sure that is a good idea.  How long are
> these processes supposed to live?

According to source, dnsblog processes exclude themselves from the
max_use limit (max_idle remains in effect). I suppose I turned off
max_use because these processes are postscreen helpers. Postscreen
was designed to handle a much larger client load than to the rest
of Postfix. Under extreme loads like 1+ connections/second,
one does not want to be creating 100+ processes/second, as that
would limit scalability.

The dnsblog processes still terminate after 100s idle time. On my
lightly-loaded server, there currently is no dnsblog process running.

Apparently your server has enough traffic to keep postscreen alive,
and as a consequence, a collection of dnsblog processes.

I suppose you could reduce max_idle, but don't go overboard and
set it to something small like 1s. That would be counterproductive.

Wiemaketse

Re: Read Only account

[chaouche yacine]

I use rob0's second suggestion which is using a map, it doesn't require that 
the user is authenticated.


in main.cf

smtpd_sender_restrictions = check_sender_access 
hash:/etc/postfix/maps/reject_senders





in maps/reject_senders

qq.com  REJECT   # Reject any mail from the qq.com domain (any user)
myu...@mydomain.tld REJECT   # Reject any mail from myu...@mydomain.tld


Yassine.

















On Friday, April 20, 2018, 9:44:52 PM GMT+1, Viktor Dukhovni 
 wrote: 







> On Apr 20, 2018, at 3:40 PM, @lbutlr  wrote:
> 
> How would I configure a user so that they could only read mail and not send 
> any mail (even to local users).


If you accept mail from strangers on port 25, and the user can reach
port 25 on your inbound MX host, then you can't prevent him from 
impersonating some stranger.  Authentication on port 25 is not
required.  You could firewall-off inbound port 25 from hosts on
your network, forcing the user to go off-site to send the "forbidden"
email.

-- 
-- 
    Viktor.