Re: Authentication attempts for x...@com.au addresses

[Bill Cole]

On 2 Apr 2019, at 23:14, James Brown wrote:

We have Stunnel receive the traffic on port 465 and 587 and forward on 
to 127.0.0.1 on port 25.


That seems odd. Why?

The whole point of having submission channels distinct from port 25 SMTP 
is to allow you to put different restrictions on inbound and outbound 
traffic. If they are just forwarded to port 25 looking like the 
loopback, you lose that capacity for nuanced access control and lose 
your ability to conform to the submission standard on submission ports.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole

Re: Authentication attempts for x...@com.au addresses

[Bill Cole]

On 2 Apr 2019, at 8:10, James Brown wrote:

Thanks Esteban. I have fail2ban installed. Unfortunately each attempt 
comes from a different IP (botnet I presume). I’m finding this all 
the time now, so fail2ban seems to be no longer much use.


Was just hoping there was a Postfix or Dovecot setting I could use to 
ignore these submission attempts.


While fail2ban with its stock config isn't going to help much, the 
approach Michael suggested can work.


I use a more draconian but slower approach, with a custom log watcher 
that immediately blocks any IP from touching relevant ports (110, 143, 
465, 587, 993, and 995) if it fails an auth attempt in any /16 that has 
not had a successful authentication in the past week. Those firewall 
rules eventually age out if not hit. Once a week, I manually use those 
automated rules to identify ranges at the RIR allocation block or 
visible route level that will almost surely never legitimately attempt 
mail auth on my system and ban them from those ports permanently. I also 
have a simple web mechanism for users to punch an opening for their 
current IP.


That is a reasonable fit for a small mail system. I don't think it would 
be feasible with a large set of users, particularly heavy travelers or 
people who frequently change devices (i.e. prone to auth failures from 
unfamiliar networks) and who are mystified by the "URL knocking" trick. 
When I first started this, the weekly triage & escalation was a 
substantial chunk of work but after a year of adding new ranges as they 
appear, I now have only a handful of probes per week to check out and 
often no new larger blocks to shun.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole

Re: Authentication attempts for x...@com.au addresses

[James Brown]

> On 3 Apr 2019, at 9:45 am, Curtis Maurand  > wrote:
> 
> 
> 
> On 4/2/19 5:39 PM, @lbutlr wrote:
>> On 2 Apr 2019, at 14:30, Esteban L > > wrote:
>>> The times are in seconds, so you'll need to calculate those times.
>> a month is 2629743 seconds. An hour, of course is 3600, but I prefer 86400 
>> which is one day.
>> 
>> BTW, pi seconds is very close to 1 nano century.
>> 
>> 
> I agree with @ibutr that 86400 is a good number. Now to find the where to 
> change the iptables rule to "-j DROP"
> 
> I like to just silently drop the connection. It becomes a sort of reverse DOS 
> in that they keep opening sockets, but you're effectively not listening.  
> It's been very effective in my experience.  To be sure, they will keep 
> changing sources once they realize the host is unreachable from any 
> particular source. If I end up blocking TOR or vpn users that are trying to 
> do nefarious things, then so be it.  I don't need to waste CPU cycles sending 
> responses. fail2ban is a resource hog as it is.
> 
> Cheers,
> Curtis

Thanks all for your replies. Increasing both Ban time and Find time are good 
and I’ll do that. Looking through the logs I can see some repeated IPs for IMAP 
failures, but over long times (eg maybe once or twice a day max).

We have Stunnel receive the traffic on port 465 and 587 and forward on to 
127.0.0.1 on port 25. So that is why I can’t write a Fail2ban rule for this log 
line:

auth-worker(42777): Info: sql(cont...@com.au 
,127.0.0.1): unknown user (given password: Password123)

as it would ban localhost, not the original IP that Stunnel received.

Thanks,

James.

Re: Bug report: problem with smtp_mx_address_limit = 0

[Wietse Venema]

Luc Pardon:
> On the same topic: what if smtp_mx_address_limit was simply made to
> apply for each family separately? E.g. the default of 5 would mean: keep
> max 5 IPv6 addresses _and_ max 5 IPv4's ?

The purpose of these and other Postfix limits is not to frustrate
legitimate mail operators. Instead the purpose is to maintain sanity
under insane conditions. Therefore I would not be comfortable with
suddenly doubling these limits.

I prefer to remove the ability to disable safety mechanisms. If
sites want to receive MX responses that specify a bazillion hosts
(none of which is likely to respond), then they can configure Postfix
to try all those hosts, and watch their mail queues melt down.

Wietse

Re: Authentication attempts for x...@com.au addresses

[Curtis Maurand]

On 4/2/19 5:39 PM, @lbutlr wrote:

On 2 Apr 2019, at 14:30, Esteban L  wrote:

The times are in seconds, so you'll need to calculate those times.

a month is 2629743 seconds. An hour, of course is 3600, but I prefer 86400 
which is one day.

BTW, pi seconds is very close to 1 nano century.


I agree with @ibutr that 86400 is a good number. Now to find the where 
to change the iptables rule to "-j DROP"


I like to just silently drop the connection. It becomes a sort of 
reverse DOS in that they keep opening sockets, but you're effectively 
not listening.  It's been very effective in my experience.  To be sure, 
they will keep changing sources once they realize the host is 
unreachable from any particular source. If I end up blocking TOR or vpn 
users that are trying to do nefarious things, then so be it.  I don't 
need to waste CPU cycles sending responses. fail2ban is a resource hog 
as it is.


Cheers,
Curtis

--
Best Regards Curtis Maurand
mailto:cur...@maurand.com

Re: Authentication attempts for x...@com.au addresses

[@lbutlr]

On 2 Apr 2019, at 14:30, Esteban L  wrote:
> The times are in seconds, so you'll need to calculate those times.

a month is 2629743 seconds. An hour, of course is 3600, but I prefer 86400 
which is one day.

BTW, pi seconds is very close to 1 nano century.


-- 
<[TN]FBMachine> I got kicked out of Barnes and Noble once for moving all
the bibles into the fiction section

Re: problems follow with certain rules

[Viktor Dukhovni]

On Tue, Apr 02, 2019 at 07:15:58PM +0200, Francesc Peñalvez wrote:

> smtpd_client_restrictions = permit_mynetworks permit_inet_interfaces
>  permit_tls_all_clientcerts permit_sasl_authenticated 
> permit_auth_destination
>  check_client_access hash:/etc/postfix/access

The "permit_tls_all_clientcerts" here is currently a NOOP, given
the rest of your configuration, but is a bad idea, and should be
remove.

> smtpd_tls_CAfile = /etc/postfix/postfix.ca.pem
> smtpd_tls_CApath = /etc/ssl/certs

Your authorized CAs likely include the usual panoply of public CAs,
and you should not be trusting clients with some random certificate
from any of these.

As luck would have it, you're not configured to request client
certs, hence the "NOOP", but this could change later.

-- 
Viktor.

Re: Authentication attempts for x...@com.au addresses

[Esteban L]

I agree with Ron Wheeler.

The default settings for Dovecot and Postfix are solid. The default settings 
for Fail2ban, on the other hand, are inadequate. Not because its a bad program, 
but rather that 1.) the default settings are a little lenient, and 2.) hackers 
know those default settings.

You'll need to set the findtime, jailtime, and attempts more strict.


I set the findtime to an hour, the jail time to a month, and attempts to 2.

The times are in seconds, so you'll need to calculate those times.




On April 2, 2019 2:10:24 PM GMT+02:00, James Brown  wrote:
>Thanks Esteban. I have fail2ban installed. Unfortunately each attempt
>comes from a different IP (botnet I presume). I’m finding this all the
>time now, so fail2ban seems to be no longer much use.
>
>Was just hoping there was a Postfix or Dovecot setting I could use to
>ignore these submission attempts.
>
>James.
>
>
>> On 2 Apr 2019, at 7:43 pm, Esteban L > wrote:
>> 
>> You will need to install fail2ban to ip block failed attempts.
>> 
>> As you have correctly assumed, a malicious person is trying to hack
>into you mail server.
>> 
>> Fail2ban is a required application now and days.
>> 
>> On April 2, 2019 8:57:06 AM GMT+02:00, James Brown
>mailto:jlbr...@bordo.com.au>> wrote:
>> Not sure if this is a Dovecot or Postfix issue we use Dovecot for
>authentication for Postfix. Mailboxes are stored in MySQL.
>> 
>> Have noticed this today:
>> 
>> auth-worker(42777): Info: sql(cont...@com.au
>,127.0.0.1): unknown user (given password:
>someone123)
>> 
>> Also i...@com.au  etc.
>> 
>> They are coming through on port 465.
>> 
>> Obviously my domain is not ‘com.au ’ - how can I stop
>these attempts from even being considered?
>> 
>> I did update to Postfix 3.4.5 yesterday. Running Dovecot 2.3.5.
>> 
>> Thanks,
>> 
>> James.
>> 
>> 
>> 
>> 
>> -- 
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: problems follow with certain rules

[Francesc Peñalvez]

yes every change in access i use postmap access

i I will try the changes that you suggest and I will comment something

Thanks for help

El 02/04/2019 a las 21:11, Noel Jones escribió:

Great.

Change this:

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
 defer_unauth_destination permit_inet_interfaces check_client_access
 hash:/etc/postfix/access reject_unknown_reverse_client_hostname 


to this:
smtpd_relay_restrictions =
  permit_mynetworks
  permit_sasl_authenticated
  reject_unauth_destination


Did you remember to postmap your access map?
postmap hash:/etc/postfix/access





On 4/2/2019 1:49 PM, Francesc Peñalvez wrote:

the problem that I have already described
I have several rules against spamers and one of them is to reject the 
ips that are not resolved.
So when the resolution of the dns fails those ips are rejected for 
not having an inverse. In the access I have the ips that interest me 
that these locks pass, but even so, as you can see in the connection 
log are rejected by not solve the ip.
Those ips really do have an inverse but for some fault it does not 
resolve at the moment of connecting with my postfix.

The two postconf are from the server with which I have this problem.
In other emails I was told that the rule of the inverse resolution 
reject_unknown_reverse_client_hostname was earlier in the line than 
the access, so I changed the position but still I still have this 
failure.
The example of SMTP that I have set, although it does not match the 
ip, as I have put in another email is an ip of the same company, in 
this case a digital newspaper that uses several ips to send emails.


the problem I do not have it in the shipment if not in the reception 
of mails.
I am sorry not to explain myself, I hope that I understand what I 
want to express


El 02/04/2019 a las 20:08, Noel Jones escribió:

On 4/2/2019 12:15 PM, Francesc Peñalvez wrote:
the problem is with the directive 
reject_unknown_reverse_client_hostname when there is a failure in 
the resolution of the ip blocks the connection with this ip, to 
avoid adding the access file the ip as indicated in the first mail, 
but still blocking that ip by not resolving. activate the debug on 
that ip in case I saw the reason and that's what I get between many 
data when that ip connects


I don't quite understand what you're trying to say above, you don't 
show logs indicating the problem you're trying to solve, and your 
example SMTP session doesn't seem to match your posted config, so 
I'll give some general pointers.


In your posted config, no locally delivered mail gets past the 
"permit_auth_destination" statements, bypassing most of your 
restrictions.


Mail must be permitted (or not rejected) in every 
smtpd_*_restrictions section to be accepted.


It doesn't make much sense to use both 
reject_unknown_client_hostname and 
reject_unknown_reverse_client_hostname, especially with 
reject_unknown_reverse_client_hostname listed second.


Looks like you have a lot of duplicated statements.

In master.cf for your submission and smtps listeners, you should 
disable all those extra restrictions, eg.

  -o smtpd_helo_restrictions=
  -o smtpd_client_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o smtpd_recipient_restrictions=



  -- Noel Jones





  Out: 250-ETRN
  Out: 250-AUTH PLAIN LOGIN
  Out: 250-AUTH=PLAIN LOGIN
  Out: 250-ENHANCEDSTATUSCODES
  Out: 250-8BITMIME
  Out: 250 DSN
  In:  MAIL From: SIZE=118853
  Out: 250 2.1.0 Ok
  In:  RCPT To:
  Out: 450 4.7.25 Client host rejected: cannot find your hostname,
  [217.124.241.125]
  In:  DATA
  Out: 554 5.5.1 Error: no valid recipients
  In:  RSET
  Out: 250 2.0.0 Ok
  In:  QUIT
  Out: 221 2.0.0 Bye

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
allow_percent_hack = no
allow_untrusted_routing = yes
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_list = 213.4.61.170 195.77.249.6 212.0.124.176
home_mailbox = Maildir/
html_directory = no
inet_interfaces = all
inet_protocols = ipv4
mail_owner = postfix
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq
manpage_directory = /usr/local/man
masquerade_domains = almogavers.net
message_size_limit = 10240
meta_directory = /etc/postfix
milter_default_action = accept
milter_protocol = 6
mydestination = ns.almogavers.net, localhost.almogavers.net, 
localhost,
 canalonanismo.org, canalonanismo.es, almogavers.net, 
web.almogavers.net,

 active.almogavers.net, 5.39.93.184, 37.187.18.41
myhostname = almogavers.net
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 192.168.1.2
 almogavers.net 192.168.1.0/24
mynetworks_style = class
newaliases_path = 

Re: problems follow with certain rules

[Noel Jones]

Great.

Change this:

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
 defer_unauth_destination permit_inet_interfaces check_client_access
 hash:/etc/postfix/access reject_unknown_reverse_client_hostname 


to this:
smtpd_relay_restrictions =
  permit_mynetworks
  permit_sasl_authenticated
  reject_unauth_destination


Did you remember to postmap your access map?
postmap hash:/etc/postfix/access





On 4/2/2019 1:49 PM, Francesc Peñalvez wrote:

the problem that I have already described
I have several rules against spamers and one of them is to reject 
the ips that are not resolved.
So when the resolution of the dns fails those ips are rejected for 
not having an inverse. In the access I have the ips that interest me 
that these locks pass, but even so, as you can see in the connection 
log are rejected by not solve the ip.
Those ips really do have an inverse but for some fault it does not 
resolve at the moment of connecting with my postfix.

The two postconf are from the server with which I have this problem.
In other emails I was told that the rule of the inverse resolution 
reject_unknown_reverse_client_hostname was earlier in the line than 
the access, so I changed the position but still I still have this 
failure.
The example of SMTP that I have set, although it does not match the 
ip, as I have put in another email is an ip of the same company, in 
this case a digital newspaper that uses several ips to send emails.


the problem I do not have it in the shipment if not in the reception 
of mails.
I am sorry not to explain myself, I hope that I understand what I 
want to express


El 02/04/2019 a las 20:08, Noel Jones escribió:

On 4/2/2019 12:15 PM, Francesc Peñalvez wrote:
the problem is with the directive 
reject_unknown_reverse_client_hostname when there is a failure in 
the resolution of the ip blocks the connection with this ip, to 
avoid adding the access file the ip as indicated in the first 
mail, but still blocking that ip by not resolving. activate the 
debug on that ip in case I saw the reason and that's what I get 
between many data when that ip connects


I don't quite understand what you're trying to say above, you 
don't show logs indicating the problem you're trying to solve, and 
your example SMTP session doesn't seem to match your posted 
config, so I'll give some general pointers.


In your posted config, no locally delivered mail gets past the 
"permit_auth_destination" statements, bypassing most of your 
restrictions.


Mail must be permitted (or not rejected) in every 
smtpd_*_restrictions section to be accepted.


It doesn't make much sense to use both 
reject_unknown_client_hostname and 
reject_unknown_reverse_client_hostname, especially with 
reject_unknown_reverse_client_hostname listed second.


Looks like you have a lot of duplicated statements.

In master.cf for your submission and smtps listeners, you should 
disable all those extra restrictions, eg.

  -o smtpd_helo_restrictions=
  -o smtpd_client_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o smtpd_recipient_restrictions=



  -- Noel Jones





  Out: 250-ETRN
  Out: 250-AUTH PLAIN LOGIN
  Out: 250-AUTH=PLAIN LOGIN
  Out: 250-ENHANCEDSTATUSCODES
  Out: 250-8BITMIME
  Out: 250 DSN
  In:  MAIL From:  SIZE=118853
  Out: 250 2.1.0 Ok
  In:  RCPT To:
  Out: 450 4.7.25 Client host rejected: cannot find your hostname,
  [217.124.241.125]
  In:  DATA
  Out: 554 5.5.1 Error: no valid recipients
  In:  RSET
  Out: 250 2.0.0 Ok
  In:  QUIT
  Out: 221 2.0.0 Bye

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
allow_percent_hack = no
allow_untrusted_routing = yes
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_list = 213.4.61.170 195.77.249.6 212.0.124.176
home_mailbox = Maildir/
html_directory = no
inet_interfaces = all
inet_protocols = ipv4
mail_owner = postfix
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d 
$LOGNAME

mailbox_size_limit = 0
mailq_path = /usr/bin/mailq
manpage_directory = /usr/local/man
masquerade_domains = almogavers.net
message_size_limit = 10240
meta_directory = /etc/postfix
milter_default_action = accept
milter_protocol = 6
mydestination = ns.almogavers.net, localhost.almogavers.net, 
localhost,
 canalonanismo.org, canalonanismo.es, almogavers.net, 
web.almogavers.net,

 active.almogavers.net, 5.39.93.184, 37.187.18.41
myhostname = almogavers.net
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 
192.168.1.2

 almogavers.net 192.168.1.0/24
mynetworks_style = class
newaliases_path = /usr/bin/newaliases
non_smtpd_milters = inet:localhost:3277
notify_classes = bounce, 2bounce, delay, policy, protocol, 
resource, software
postscreen_access_list = permit_mynetworks 

Re: problems follow with certain rules

[Francesc Peñalvez]

the problem that I have already described
I have several rules against spamers and one of them is to reject the 
ips that are not resolved.
So when the resolution of the dns fails those ips are rejected for not 
having an inverse. In the access I have the ips that interest me that 
these locks pass, but even so, as you can see in the connection log are 
rejected by not solve the ip.
Those ips really do have an inverse but for some fault it does not 
resolve at the moment of connecting with my postfix.

The two postconf are from the server with which I have this problem.
In other emails I was told that the rule of the inverse resolution 
reject_unknown_reverse_client_hostname was earlier in the line than the 
access, so I changed the position but still I still have this failure.
The example of SMTP that I have set, although it does not match the ip, 
as I have put in another email is an ip of the same company, in this 
case a digital newspaper that uses several ips to send emails.


the problem I do not have it in the shipment if not in the reception of 
mails.
I am sorry not to explain myself, I hope that I understand what I want 
to express


El 02/04/2019 a las 20:08, Noel Jones escribió:

On 4/2/2019 12:15 PM, Francesc Peñalvez wrote:
the problem is with the directive 
reject_unknown_reverse_client_hostname when there is a failure in the 
resolution of the ip blocks the connection with this ip, to avoid 
adding the access file the ip as indicated in the first mail, but 
still blocking that ip by not resolving. activate the debug on that 
ip in case I saw the reason and that's what I get between many data 
when that ip connects


I don't quite understand what you're trying to say above, you don't 
show logs indicating the problem you're trying to solve, and your 
example SMTP session doesn't seem to match your posted config, so I'll 
give some general pointers.


In your posted config, no locally delivered mail gets past the 
"permit_auth_destination" statements, bypassing most of your 
restrictions.


Mail must be permitted (or not rejected) in every smtpd_*_restrictions 
section to be accepted.


It doesn't make much sense to use both reject_unknown_client_hostname 
and reject_unknown_reverse_client_hostname, especially with 
reject_unknown_reverse_client_hostname listed second.


Looks like you have a lot of duplicated statements.

In master.cf for your submission and smtps listeners, you should 
disable all those extra restrictions, eg.

  -o smtpd_helo_restrictions=
  -o smtpd_client_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o smtpd_recipient_restrictions=



  -- Noel Jones





  Out: 250-ETRN
  Out: 250-AUTH PLAIN LOGIN
  Out: 250-AUTH=PLAIN LOGIN
  Out: 250-ENHANCEDSTATUSCODES
  Out: 250-8BITMIME
  Out: 250 DSN
  In:  MAIL From:  SIZE=118853
  Out: 250 2.1.0 Ok
  In:  RCPT To:
  Out: 450 4.7.25 Client host rejected: cannot find your hostname,
  [217.124.241.125]
  In:  DATA
  Out: 554 5.5.1 Error: no valid recipients
  In:  RSET
  Out: 250 2.0.0 Ok
  In:  QUIT
  Out: 221 2.0.0 Bye

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
allow_percent_hack = no
allow_untrusted_routing = yes
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_list = 213.4.61.170 195.77.249.6 212.0.124.176
home_mailbox = Maildir/
html_directory = no
inet_interfaces = all
inet_protocols = ipv4
mail_owner = postfix
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq
manpage_directory = /usr/local/man
masquerade_domains = almogavers.net
message_size_limit = 10240
meta_directory = /etc/postfix
milter_default_action = accept
milter_protocol = 6
mydestination = ns.almogavers.net, localhost.almogavers.net, localhost,
 canalonanismo.org, canalonanismo.es, almogavers.net, 
web.almogavers.net,

 active.almogavers.net, 5.39.93.184, 37.187.18.41
myhostname = almogavers.net
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 192.168.1.2
 almogavers.net 192.168.1.0/24
mynetworks_style = class
newaliases_path = /usr/bin/newaliases
non_smtpd_milters = inet:localhost:3277
notify_classes = bounce, 2bounce, delay, policy, protocol, resource, 
software
postscreen_access_list = permit_mynetworks 
cidr:/etc/postfix/trusted_ips.cidr

postscreen_blacklist_action = drop
postscreen_dnsbl_action = enforce
postscreen_dnsbl_reply_map = 
texthash:/etc/postfix/postscreen_dnsbl_reply

postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.[2..11]*3
 b.barracudacentral.org=127.0.0.[2..11]*2 bl.spamcop.net 
swl.spamhaus.org*-4

postscreen_dnsbl_threshold = 1
postscreen_dnsbl_ttl = 10m
postscreen_greet_action = enforce
queue_directory = /var/spool/postfix
readme_directory = no
recipient_delimiter = +

Re: problems follow with certain rules

[Noel Jones]

On 4/2/2019 12:15 PM, Francesc Peñalvez wrote:
the problem is with the directive 
reject_unknown_reverse_client_hostname when there is a failure in 
the resolution of the ip blocks the connection with this ip, to 
avoid adding the access file the ip as indicated in the first mail, 
but still blocking that ip by not resolving. activate the debug on 
that ip in case I saw the reason and that's what I get between many 
data when that ip connects


I don't quite understand what you're trying to say above, you don't 
show logs indicating the problem you're trying to solve, and your 
example SMTP session doesn't seem to match your posted config, so 
I'll give some general pointers.


In your posted config, no locally delivered mail gets past the 
"permit_auth_destination" statements, bypassing most of your 
restrictions.


Mail must be permitted (or not rejected) in every 
smtpd_*_restrictions section to be accepted.


It doesn't make much sense to use both 
reject_unknown_client_hostname and 
reject_unknown_reverse_client_hostname, especially with 
reject_unknown_reverse_client_hostname listed second.


Looks like you have a lot of duplicated statements.

In master.cf for your submission and smtps listeners, you should 
disable all those extra restrictions, eg.

  -o smtpd_helo_restrictions=
  -o smtpd_client_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o smtpd_recipient_restrictions=



  -- Noel Jones





  Out: 250-ETRN
  Out: 250-AUTH PLAIN LOGIN
  Out: 250-AUTH=PLAIN LOGIN
  Out: 250-ENHANCEDSTATUSCODES
  Out: 250-8BITMIME
  Out: 250 DSN
  In:  MAIL From:  SIZE=118853
  Out: 250 2.1.0 Ok
  In:  RCPT To:
  Out: 450 4.7.25 Client host rejected: cannot find your hostname,
  [217.124.241.125]
  In:  DATA
  Out: 554 5.5.1 Error: no valid recipients
  In:  RSET
  Out: 250 2.0.0 Ok
  In:  QUIT
  Out: 221 2.0.0 Bye

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
allow_percent_hack = no
allow_untrusted_routing = yes
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_list = 213.4.61.170 195.77.249.6 212.0.124.176
home_mailbox = Maildir/
html_directory = no
inet_interfaces = all
inet_protocols = ipv4
mail_owner = postfix
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq
manpage_directory = /usr/local/man
masquerade_domains = almogavers.net
message_size_limit = 10240
meta_directory = /etc/postfix
milter_default_action = accept
milter_protocol = 6
mydestination = ns.almogavers.net, localhost.almogavers.net, localhost,
     canalonanismo.org, canalonanismo.es, almogavers.net, 
web.almogavers.net,

     active.almogavers.net, 5.39.93.184, 37.187.18.41
myhostname = almogavers.net
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 192.168.1.2
     almogavers.net 192.168.1.0/24
mynetworks_style = class
newaliases_path = /usr/bin/newaliases
non_smtpd_milters = inet:localhost:3277
notify_classes = bounce, 2bounce, delay, policy, protocol, resource, 
software
postscreen_access_list = permit_mynetworks 
cidr:/etc/postfix/trusted_ips.cidr

postscreen_blacklist_action = drop
postscreen_dnsbl_action = enforce
postscreen_dnsbl_reply_map = 
texthash:/etc/postfix/postscreen_dnsbl_reply

postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.[2..11]*3
     b.barracudacentral.org=127.0.0.[2..11]*2 bl.spamcop.net 
swl.spamhaus.org*-4

postscreen_dnsbl_threshold = 1
postscreen_dnsbl_ttl = 10m
postscreen_greet_action = enforce
queue_directory = /var/spool/postfix
readme_directory = no
recipient_delimiter = +
sample_directory = /etc/postfix
sender_bcc_maps = hash:/etc/postfix/bcc
sender_dependent_default_transport_maps = hash:/etc/postfix/dependent
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
shlib_directory = /usr/lib/postfix
smtp_dns_support_level = enabled
smtp_host_lookup = dns
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_ciphers = medium
smtp_tls_loglevel = 1
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_security_level = dane
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_use_tls = yes
smtpd_client_restrictions = permit_mynetworks permit_inet_interfaces
     permit_tls_all_clientcerts permit_sasl_authenticated 
permit_auth_destination

     check_client_access hash:/etc/postfix/access
smtpd_hard_error_limit = 20
smtpd_helo_restrictions = permit_mynetworks, check_client_access
     hash:/etc/postfix/access, check_client_access
     cidr:/etc/postfix/trusted_ips.cidr, reject_invalid_hostname, 
permit

smtpd_milters = inet:localhost:3277
smtpd_recipient_restrictions = permit_mynetworks 
permit_sasl_authenticated
     check_client_access hash:/etc/postfix/access 
permit_auth_destination

     reject_unauth_destination reject_invalid_hostname
     

Re: problems follow with certain rules

[Francesc Peñalvez]

the ip of my last mail does not match the first, but it is from the same 
company that uses several ips and all of them are added to the access file

El 02/04/2019 a las 19:15, Francesc Peñalvez escribió:
the problem is with the directive 
reject_unknown_reverse_client_hostname when there is a failure in the 
resolution of the ip blocks the connection with this ip, to avoid 
adding the access file the ip as indicated in the first mail, but 
still blocking that ip by not resolving. activate the debug on that ip 
in case I saw the reason and that's what I get between many data when 
that ip connects


 Out: 250-ETRN
 Out: 250-AUTH PLAIN LOGIN
 Out: 250-AUTH=PLAIN LOGIN
 Out: 250-ENHANCEDSTATUSCODES
 Out: 250-8BITMIME
 Out: 250 DSN
 In:  MAIL From:  SIZE=118853
 Out: 250 2.1.0 Ok
 In:  RCPT To:
 Out: 450 4.7.25 Client host rejected: cannot find your hostname,
 [217.124.241.125]
 In:  DATA
 Out: 554 5.5.1 Error: no valid recipients
 In:  RSET
 Out: 250 2.0.0 Ok
 In:  QUIT
 Out: 221 2.0.0 Bye

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
allow_percent_hack = no
allow_untrusted_routing = yes
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_list = 213.4.61.170 195.77.249.6 212.0.124.176
home_mailbox = Maildir/
html_directory = no
inet_interfaces = all
inet_protocols = ipv4
mail_owner = postfix
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq
manpage_directory = /usr/local/man
masquerade_domains = almogavers.net
message_size_limit = 10240
meta_directory = /etc/postfix
milter_default_action = accept
milter_protocol = 6
mydestination = ns.almogavers.net, localhost.almogavers.net, localhost,
    canalonanismo.org, canalonanismo.es, almogavers.net, 
web.almogavers.net,

    active.almogavers.net, 5.39.93.184, 37.187.18.41
myhostname = almogavers.net
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 192.168.1.2
    almogavers.net 192.168.1.0/24
mynetworks_style = class
newaliases_path = /usr/bin/newaliases
non_smtpd_milters = inet:localhost:3277
notify_classes = bounce, 2bounce, delay, policy, protocol, resource, 
software
postscreen_access_list = permit_mynetworks 
cidr:/etc/postfix/trusted_ips.cidr

postscreen_blacklist_action = drop
postscreen_dnsbl_action = enforce
postscreen_dnsbl_reply_map = texthash:/etc/postfix/postscreen_dnsbl_reply
postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.[2..11]*3
    b.barracudacentral.org=127.0.0.[2..11]*2 bl.spamcop.net 
swl.spamhaus.org*-4

postscreen_dnsbl_threshold = 1
postscreen_dnsbl_ttl = 10m
postscreen_greet_action = enforce
queue_directory = /var/spool/postfix
readme_directory = no
recipient_delimiter = +
sample_directory = /etc/postfix
sender_bcc_maps = hash:/etc/postfix/bcc
sender_dependent_default_transport_maps = hash:/etc/postfix/dependent
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
shlib_directory = /usr/lib/postfix
smtp_dns_support_level = enabled
smtp_host_lookup = dns
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_ciphers = medium
smtp_tls_loglevel = 1
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_security_level = dane
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_use_tls = yes
smtpd_client_restrictions = permit_mynetworks permit_inet_interfaces
    permit_tls_all_clientcerts permit_sasl_authenticated 
permit_auth_destination

    check_client_access hash:/etc/postfix/access
smtpd_hard_error_limit = 20
smtpd_helo_restrictions = permit_mynetworks, check_client_access
    hash:/etc/postfix/access, check_client_access
    cidr:/etc/postfix/trusted_ips.cidr, reject_invalid_hostname, permit
smtpd_milters = inet:localhost:3277
smtpd_recipient_restrictions = permit_mynetworks 
permit_sasl_authenticated

    check_client_access hash:/etc/postfix/access permit_auth_destination
    reject_unauth_destination reject_invalid_hostname
    reject_unknown_recipient_domain reject_unknown_client_hostname
    reject_unknown_reverse_client_hostname reject_unverified_recipient
    check_policy_service inet:127.0.0.1:10023
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
    defer_unauth_destination permit_inet_interfaces check_client_access
    hash:/etc/postfix/access reject_unknown_reverse_client_hostname
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous noplaintext
smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
smtpd_sender_restrictions = permit_mynetworks check_client_access
    hash:/etc/postfix/access permit_auth_destination 
permit_sasl_authenticated
    check_sender_access inline:{ { almogavers.net = REJECT local 
sender from

    unauthorized client } }
smtpd_tls_CAfile = /etc/postfix/postfix.ca.pem
smtpd_tls_CApath = 

Re: problems follow with certain rules

[Francesc Peñalvez]

the problem is with the directive reject_unknown_reverse_client_hostname 
when there is a failure in the resolution of the ip blocks the 
connection with this ip, to avoid adding the access file the ip as 
indicated in the first mail, but still blocking that ip by not 
resolving. activate the debug on that ip in case I saw the reason and 
that's what I get between many data when that ip connects


 Out: 250-ETRN
 Out: 250-AUTH PLAIN LOGIN
 Out: 250-AUTH=PLAIN LOGIN
 Out: 250-ENHANCEDSTATUSCODES
 Out: 250-8BITMIME
 Out: 250 DSN
 In:  MAIL From:  SIZE=118853
 Out: 250 2.1.0 Ok
 In:  RCPT To:
 Out: 450 4.7.25 Client host rejected: cannot find your hostname,
 [217.124.241.125]
 In:  DATA
 Out: 554 5.5.1 Error: no valid recipients
 In:  RSET
 Out: 250 2.0.0 Ok
 In:  QUIT
 Out: 221 2.0.0 Bye

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
allow_percent_hack = no
allow_untrusted_routing = yes
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_list = 213.4.61.170 195.77.249.6 212.0.124.176
home_mailbox = Maildir/
html_directory = no
inet_interfaces = all
inet_protocols = ipv4
mail_owner = postfix
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq
manpage_directory = /usr/local/man
masquerade_domains = almogavers.net
message_size_limit = 10240
meta_directory = /etc/postfix
milter_default_action = accept
milter_protocol = 6
mydestination = ns.almogavers.net, localhost.almogavers.net, localhost,
canalonanismo.org, canalonanismo.es, almogavers.net, web.almogavers.net,
active.almogavers.net, 5.39.93.184, 37.187.18.41
myhostname = almogavers.net
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 192.168.1.2
almogavers.net 192.168.1.0/24
mynetworks_style = class
newaliases_path = /usr/bin/newaliases
non_smtpd_milters = inet:localhost:3277
notify_classes = bounce, 2bounce, delay, policy, protocol, resource, software
postscreen_access_list = permit_mynetworks cidr:/etc/postfix/trusted_ips.cidr
postscreen_blacklist_action = drop
postscreen_dnsbl_action = enforce
postscreen_dnsbl_reply_map = texthash:/etc/postfix/postscreen_dnsbl_reply
postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.[2..11]*3
b.barracudacentral.org=127.0.0.[2..11]*2 bl.spamcop.net swl.spamhaus.org*-4
postscreen_dnsbl_threshold = 1
postscreen_dnsbl_ttl = 10m
postscreen_greet_action = enforce
queue_directory = /var/spool/postfix
readme_directory = no
recipient_delimiter = +
sample_directory = /etc/postfix
sender_bcc_maps = hash:/etc/postfix/bcc
sender_dependent_default_transport_maps = hash:/etc/postfix/dependent
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
shlib_directory = /usr/lib/postfix
smtp_dns_support_level = enabled
smtp_host_lookup = dns
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_ciphers = medium
smtp_tls_loglevel = 1
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_security_level = dane
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_use_tls = yes
smtpd_client_restrictions = permit_mynetworks permit_inet_interfaces
permit_tls_all_clientcerts permit_sasl_authenticated permit_auth_destination
check_client_access hash:/etc/postfix/access
smtpd_hard_error_limit = 20
smtpd_helo_restrictions = permit_mynetworks, check_client_access
hash:/etc/postfix/access, check_client_access
cidr:/etc/postfix/trusted_ips.cidr, reject_invalid_hostname, permit
smtpd_milters = inet:localhost:3277
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated
check_client_access hash:/etc/postfix/access permit_auth_destination
reject_unauth_destination reject_invalid_hostname
reject_unknown_recipient_domain reject_unknown_client_hostname
reject_unknown_reverse_client_hostname reject_unverified_recipient
check_policy_service inet:127.0.0.1:10023
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
defer_unauth_destination permit_inet_interfaces check_client_access
hash:/etc/postfix/access reject_unknown_reverse_client_hostname
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous noplaintext
smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
smtpd_sender_restrictions = permit_mynetworks check_client_access
hash:/etc/postfix/access permit_auth_destination permit_sasl_authenticated
check_sender_access inline:{ { almogavers.net = REJECT local sender from
unauthorized client } }
smtpd_tls_CAfile = /etc/postfix/postfix.ca.pem
smtpd_tls_CApath = /etc/ssl/certs
smtpd_tls_cert_file = /etc/postfix/postfix.cert.pem
smtpd_tls_ciphers = medium
smtpd_tls_key_file = /etc/postfix/postfix.key.pem
smtpd_tls_mandatory_ciphers = high
smtpd_tls_protocols = !SSLv2, !SSLv3

Re: problems follow with certain rules

[Bill Cole]

On 2 Apr 2019, at 11:17, Francesc Peñalvez wrote:

following the instructions given to me place the access in front of 
the rule that is not supported ips unresolved, and as I still have the 
same problems I added a debug to that ip that interests me and among 
other things in this debug I find this:
16:43:05 ns postfix / smtpd [28258]: generic_checks: name = 
check_client_access
Apr 2 16:43:05 ns postfix / smtpd [28258]: check_namadr_access: name 
unknown addr 213.4.61.170
Apr 2 16:43:05 ns postfix / smtpd [28258]: check_domain_access: 
unknown
Apr 2 16:43:05 ns postfix / smtpd [28258]: maps_find: hash: / etc / 
postfix / access: unknown: not found
Apr 2 16:43:05 ns postfix / smtpd [28258]: check_addr_access: 
213.4.61.170

my access file contains:
213.4.61.170 OK

Where do I have the error?


It is impossible for us to tell, because you have not provided enough 
information.
The solution may be as simple as using 'postmap' to rebuild the 
operational form of the access map (e.g. /etc/postfix/access.db) or it 
may be something more complex.


See http://www.postfix.org/DEBUG_README.html#mail for how to effectively 
report problems here.


Most importantly:

1. Turn off debug logging.
2. Provide the output of 'postconf -nf' and 'postconf -Mf'
3. Provide log lines relevant to a single SMTP session with the problem.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole

Re: problems follow with certain rules

[Noel Jones]

On 4/2/2019 10:17 AM, Francesc Peñalvez wrote:
following the instructions given to me place the access in front of 
the rule that is not supported ips unresolved, and as I still have 
the same problems I added a debug to that ip that interests me and 
among other things in this debug I find this:
16:43:05 ns postfix / smtpd [28258]: generic_checks: name = 
check_client_access
Apr 2 16:43:05 ns postfix / smtpd [28258]: check_namadr_access: name 
unknown addr 213.4.61.170

Apr 2 16:43:05 ns postfix / smtpd [28258]: check_domain_access: unknown
Apr 2 16:43:05 ns postfix / smtpd [28258]: maps_find: hash: / etc / 
postfix / access: unknown: not found
Apr 2 16:43:05 ns postfix / smtpd [28258]: check_addr_access: 
213.4.61.170

my access file contains:
213.4.61.170 OK

Where do I have the error?




There's not enough context here for anyone to say what the problem is.

If you need more help:
http://www.postfix.org/DEBUG_README.html#mail

Don't post debug logs unless specifically requested.  Normal postfix 
logging is sufficient to solve the vast majority of problems.




  -- Noel Jones

Re: Authentication attempts for x...@com.au addresses

[Dominic Raferd]

On Tue, 2 Apr 2019 at 09:45, Esteban L  wrote:

> You will need to install fail2ban to ip block failed attempts.
>
> As you have correctly assumed, a malicious person is trying to hack into
> you mail server.
>
> Fail2ban is a required application now and days.
>
> On April 2, 2019 8:57:06 AM GMT+02:00, James Brown 
> wrote:
>>
>> Not sure if this is a Dovecot or Postfix issue we use Dovecot for 
>> authentication for Postfix. Mailboxes are stored in MySQL.
>>
>> Have noticed this today:
>>
>> auth-worker(42777): Info: sql(cont...@com.au,127.0.0.1): unknown user (given 
>> password: someone123)
>>
>> Also i...@com.au etc.
>>
>> They are coming through on port 465.
>>
>> Obviously my domain is not ‘com.au’ - how can I stop these attempts from 
>> even being considered?
>>
>> I did update to Postfix 3.4.5 yesterday. Running Dovecot 2.3.5.
>>
>>
OP: since the attempts *are* being blocked by dovecot (via postfix) are you
sure you need to do anything? Unless the attempts are putting your system
under such load that it might fail to provide good service I think you
should stop worrying. Alternatively if you can identify a unique pattern in
the client names for these hack attempts that might provide another way to
block them.

BTW, where authentication is attempted for a real user but with a wrong
password we regard it as helpful - we use the data to warn users about
passwords that they might have used elsewhere but which have now escaped
into bad hands. It has picked up several real world cases (where
email/password data on external websites had evidently been hacked). (This
strategy might not be appropriate for a third-party mail provider but it
works for us.)

problems follow with certain rules

[Francesc Peñalvez]

following the instructions given to me place the access in front of the 
rule that is not supported ips unresolved, and as I still have the same 
problems I added a debug to that ip that interests me and among other 
things in this debug I find this:
16:43:05 ns postfix / smtpd [28258]: generic_checks: name = 
check_client_access
Apr 2 16:43:05 ns postfix / smtpd [28258]: check_namadr_access: name 
unknown addr 213.4.61.170

Apr 2 16:43:05 ns postfix / smtpd [28258]: check_domain_access: unknown
Apr 2 16:43:05 ns postfix / smtpd [28258]: maps_find: hash: / etc / 
postfix / access: unknown: not found

Apr 2 16:43:05 ns postfix / smtpd [28258]: check_addr_access: 213.4.61.170
my access file contains:
213.4.61.170 OK

Where do I have the error?

--




smime.p7s
Description: Firma criptográfica S/MIME

Re: Authentication attempts for x...@com.au addresses

[Michael]

This will only help if you're getting multiple attempts from one subnet, 
but I've been able to use fail2ban to block IP ranges instead of single 
IPs. You just have to be careful or you may block more IPs than you 
want. I recommend setting fail2ban to NOT start up on boot while testing 
in case you lock yourself out. You can reboot your VM to regain access.


Create a custom action file

  cp action.d/iptables-multiport.conf 
action.d/iptables-multiport-subnet.local


Comment out the default ban and unban lines, and replace them with 
these:


actionban =  -I f2b- 1 -s `echo  | sed -e 
"s/\([0-9]*.\)\([0-9]*.\)\([0-9]*.\)\([0-9]*\)/\1\2\30\/24/"` -j 

actionunban =  -D f2b- -s `echo  | sed -e 
"s/\([0-9]*.\)\([0-9]*.\)\([0-9]*.\)\([0-9]*\)/\1\2\30\/24/"` -j 



Then in your jail.local, you add this to the specific jail you want to 
block subnets on. I don't recommend using this as the default for all 
jails.

banaction = iptables-multiport-subnet



On 2019-04-02 8:30 am, Ron Wheeler wrote:

There does not seem to be a completely foolproof and easy to manage 
solution.


In my case, I modified the fail2ban time in jail to block the IP for 
days rather than hours and did a close look at the expressions defining 
the bad attempts to be sure that I got all (I hope) of the cases that 
were appearing.

They will run out of compromised sites/IPs at some point.
If you notice that the blocked IPs show entire class C blocks that are 
in countries where you do not really care about serving, you can 
manually block the entire class C at the outside edge of your firewall 
until someone that you actually want to let in complains.


If you have sshd running, that is another critical service to watch.

Everything is under attack all the time and the huge amount of money 
spent by G7 governments on cybersecurity is not having any noticeable 
reduction in this annoyance.
Sorry for the short rant but we should not have to waste so much energy 
and bandwidth on this given the billions (pick a currency) that are 
being spent.
I am afraid that it is mostly spent on training people who were not 
recruited with the right skills and going to international conferences 
to talk about how serious the problem is.


Ron

On 4/2/19 8:10 AM, James Brown wrote: Thanks Esteban. I have fail2ban 
installed. Unfortunately each attempt comes from a different IP (botnet 
I presume). I'm finding this all the time now, so fail2ban seems to be 
no longer much use.


Was just hoping there was a Postfix or Dovecot setting I could use to 
ignore these submission attempts.


James.

On 2 Apr 2019, at 7:43 pm, Esteban L  wrote:

You will need to install fail2ban to ip block failed attempts.

As you have correctly assumed, a malicious person is trying to hack 
into you mail server.


Fail2ban is a required application now and days.

On April 2, 2019 8:57:06 AM GMT+02:00, James Brown 
 wrote:


Not sure if this is a Dovecot or Postfix issue we use Dovecot for 
authentication for Postfix. Mailboxes are stored in MySQL.


Have noticed this today:

auth-worker(42777): Info: sql(cont...@com.au,127.0.0.1): unknown user 
(given password: someone123)


Also i...@com.au etc.

They are coming through on port 465.

Obviously my domain is not 'com.au' - how can I stop these attempts 
from even being considered?


I did update to Postfix 3.4.5 yesterday. Running Dovecot 2.3.5.

Thanks,

James.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Authentication attempts for x...@com.au addresses

[Ron Wheeler]

There does not seem to be a completely foolproof and easy to manage 
solution.


In my case, I modified the fail2ban time in jail to block the IP for 
days rather than hours and did a close look at the expressions defining 
the bad attempts to be sure that I got all (I hope) of the cases that 
were appearing.

They will run out of compromised sites/IPs at some point.
If you notice that the blocked IPs show entire class C blocks that are 
in countries where you do not really care about serving, you can 
manually block the entire class C at the outside edge of your firewall 
until someone that you actually want to let in complains.



If you have sshd running, that is another critical service to watch.

Everything is under attack all the time and the huge amount of money 
spent by G7 governments on cybersecurity is not having any noticeable 
reduction in this annoyance.
Sorry for the short rant but we should not have to waste so much energy 
and bandwidth on this given the billions (pick a currency) that are 
being spent.
I am afraid that it is mostly spent on training people who were not 
recruited with the right skills and going to international conferences 
to talk about how serious the problem is.


Ron


On 4/2/19 8:10 AM, James Brown wrote:
Thanks Esteban. I have fail2ban installed. Unfortunately each attempt 
comes from a different IP (botnet I presume). I’m finding this all the 
time now, so fail2ban seems to be no longer much use.


Was just hoping there was a Postfix or Dovecot setting I could use to 
ignore these submission attempts.


James.


On 2 Apr 2019, at 7:43 pm, Esteban L > wrote:


You will need to install fail2ban to ip block failed attempts.

As you have correctly assumed, a malicious person is trying to hack 
into you mail server.


Fail2ban is a required application now and days.

On April 2, 2019 8:57:06 AM GMT+02:00, James Brown 
mailto:jlbr...@bordo.com.au>> wrote:


Not sure if this is a Dovecot or Postfix issue we use Dovecot for 
authentication for Postfix. Mailboxes are stored in MySQL.

Have noticed this today:

auth-worker(42777): Info: sql(cont...@com.au  
,127.0.0.1): unknown user (given password: someone123)

alsoi...@com.au    etc.

They are coming through on port 465.

Obviously my domain is not ‘com.au  ’ - how can I stop these 
attempts from even being considered?

I did update to Postfix 3.4.5 yesterday. Running Dovecot 2.3.5.

Thanks,

James.




--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Bug report: problem with smtp_mx_address_limit = 0

[Luc Pardon]

On 2/04/19 13:21, Wietse Venema wrote:
> Probably better to not allow a limit-less smtp_mx_address_limit,
> as it makes Postfix vulnerable to resource exhaustion attack.
> 
>   Wietse
> 

Fair enough, but then the docs for smtp_mx_address_limit ought to be
changed to remove the "or zero (no limit)" at the end.

I'd also suggest an explicit warning in case it is still set to zero,
instead of the rather misleading (and inaccurate) "server unavailable or
unable to receive mail" for any MX with both A and  records.



On the same topic: what if smtp_mx_address_limit was simply made to
apply for each family separately? E.g. the default of 5 would mean: keep
max 5 IPv6 addresses _and_ max 5 IPv4's ?

That would a) eliminate the need for balancing the mix, b) simplify the
code, and c) allow the client to honor the smtp_address_preference
setting in a safe way.

Separate limit parameters for each family would also do the job, but
that would probably be overkill.

Luc

Re: Remove user agent information in the email header

[Matt Anton]

On 2 Apr 2019, at 8:42, André Rodier wrote:

> Hello,

Hello,

> I would like to delete automatically User-Agent or X-Mailer information
> in the headers of outgoing emails.
>
> I have tried the header_checks, and it works, but with all emails, even
> those received.
>
> Can you tell me how to proceed, please?
>
> Thanks,

Make an header_checks table only for the submission service:

[master.cf]
submission […]
[…]
-o 
receive_override_options=header_checks,pcre:$config_directory/header_checks_submission.pcre
[…]

-- 
matt [at] lv223.org
GPG key ID: 7D91A8CA


signature.asc
Description: OpenPGP digital signature

RE: nfs as storage for mail queue

[De Petter Mattheas]

Hello


We have a ntp server onboard our vessels that syncs time true gps sat.
All our servers get there time from that server that how we sync time.




Met vriendelijke groeten 
Kind regards  
De Petter Mattheas   
Technical support engineer - projects team 
IT-Department Jan De Nul Dredging N.V.
T +32 (0)53 73 95 53  
F +32 (0)53 21 00 31  
www.jandenul.com    

-Original Message-
From: owner-postfix-us...@postfix.org  On 
Behalf Of Wietse Venema
Sent: 02 April 2019 13:16
To: Postfix users 
Subject: Re: nfs as storage for mail queue

De Petter Mattheas:
> Hello
> Can somebody help me?

$ su
[password here]
# postfix set-permissions
# postfix check

Repeat until there are no warnings.

BTW I cannot confirm whether a WINDOWS server can satisfy the file system 
properties that Postfix requires: see the section "Postfix file system 
requirements" in http://www.postfix.org/features.html

If those file system requirements are not satisfied, then Postfix is not 
supported, end of story, you are on your own.

Since you decided to use NFS, you also need to read up on the NFS workarounds 
in http://www.postfix.org/NFS_README.html

In particular this one:

* Problem: when a file server's "time of day" clock is not synchronized with 
the [Postfix server]'s "time of day" clock, email deliveries are delayed by a 
minute or more.

* Workaround: Postfix explicitly sets file time stamps to avoid delays with new 
mail (Postfix uses "last modified" file time stamps to decide when a queue file 
is ready for delivery).

How are you going to synchronize file server clock and Postfix server clocks? 
If they differ then Postfix will work poorly.

Wietse

Any reaction to this e-mail or any other mail, including any
files transmitted therewith to sender's e-mail address(es)
shall be dealt with not as private, but as business
communication(s) and shall be registered as such.

Re: Bug report: problem with smtp_mx_address_limit = 0

[Wietse Venema]

Probably better to not allow a limit-less smtp_mx_address_limit,
as it makes Postfix vulnerable to resource exhaustion attack.

Wietse

Re: nfs as storage for mail queue

[Wietse Venema]

De Petter Mattheas:
> Hello
> Can somebody help me?

$ su
[password here]
# postfix set-permissions
# postfix check

Repeat until there are no warnings.

BTW I cannot confirm whether a WINDOWS server can satisfy the file
system properties that Postfix requires: see the section "Postfix file
system requirements" in http://www.postfix.org/features.html

If those file system requirements are not satisfied, then Postfix
is not supported, end of story, you are on your own.

Since you decided to use NFS, you also need to read up on the NFS
workarounds in http://www.postfix.org/NFS_README.html

In particular this one:

* Problem: when a file server's "time of day" clock is not synchronized
with the [Postfix server]'s "time of day" clock, email deliveries
are delayed by a minute or more.

* Workaround: Postfix explicitly sets file time stamps to avoid
delays with new mail (Postfix uses "last modified" file time stamps
to decide when a queue file is ready for delivery).

How are you going to synchronize file server clock and Postfix
server clocks? If they differ then Postfix will work poorly.

Wietse

Bug report: problem with smtp_mx_address_limit = 0

[Luc Pardon]

According to the docs, the smtp_mx_address_limit parameter determines
"the maximal number of MX (mail exchanger) IP addresses that can result
from mail exchanger lookups, or zero (no limit)".

However, when setting it to zero, the SMTP client won't even attempt to
deliver to a server that has _both_ IPv4 _and_ IPv6 addresses. Instead,
the mail is deferred forever (and 4 days ;-) with the error message
"4.4.4 server unavailable or unable to receive mail".

Yet a Perl script can connect to all these addresses just fine, and even
deliver mail when talking SMTP to the other side.



The problem seems to be that the function "smtp_balance_inet_proto" (in
smtp_addr.c) does not treat "0" as the special "no limit" case. Instead,
it treats it literally as a limit of zero IP's.

The function contains the line:

  if (v4_count > 0 && v6_count > 0 && v4_count + v6_count > addr_limit)

and inside the "if" block, a clever algorithm attempts to create a mix
of IPv4 and IPv6 addresses, by eliminating some of each kind, while
enforcing the limit.

But when addr_limit is set to 0, all IP's are eliminated from the list.



I confirmed that by adding "-v" to the smtp client in master.cf and
sending an e-mail to an address in a domain with one MX that has one A
and one .

The Postfix logs show that both IP's are found in DNS :

"begin  address list"
"pref 300 host /
"pref 300 host /
"end  address list"

The logs then continue with the tell-tale entry:

"v6_target=0, v4_target=0"

Followed by the two lines:

"begin smtp_balance_inet_proto result address list"
"end smtp_balance_inet_proto result address list"

With nothing in between...


Note that, in the above, I have obfuscated the host name and IP
addresses. I think I could safely post them here, but I suppose that
they won't be needed. Besides, postfix.org has 3 A's and 3 's and
could probably be used as a test case as well ;-)



Adding "addr_limit > 0" as the first condition in the "if" statement
above would likely take care of the problem.

IMHO, a more elegant (because more readable) solution would be to put an
explicit extra test in front of the (already long) "if", like this:

if (addr_limit == 0) {
return (addr_list);
}

A suitable comment in front would make it even more clear.


I have not provided a patch as this seems such a trivial change. In the
Postfix 3.4.5 source code, the offending "if" statement is at line 409
of smtp_addr.c. Alternatively, you can go straight to the
smtp_balance_inet_proto() function in there.

However, this also means that I haven't tested if my proposed solution
actually works. If somebody tells me that it is not (or may not be)
sufficient, I'm willing to dig further myself.


In any case, a fix is not urgent, since there is an easy workaround, and
that is: "don't RTFM", i.e. leave smtp_mx_address_limit at its default of 5.

And if you really want "no limit", you can set it to a ridiculously high
value, such as 100.



>From the changelog, this seems to have been introduced on 20170505, and
in any case, smtp_addr.c has a timestamp of Dec 27, 2017.

If this has been reported already, I apologize. I did a quick search
only and came up empty. If I missed it, this "bug report" becomes a "bug
reminder" :-)


It goes without saying, I hope, that the other client parameters in
main.cf have to be set to the proper values to trigger the bug (e.g.
smtp_balance_inet_proto = yes).



Luc Pardon

Postfix and smfi_setmlreply() milter command resulting in SMTP protocol breakage.

[Andreas Thienemann]

Hi,

I have a locally developed milter using the python-milter bindings which 
seems to trigger a Postfix bug.


The milter in question uses the smfi_setmlreply() command to set a 
multiline response as defined in rfc5321.


Multiline replies should result in the smtpd replying with something like 
the following to e.g. a rejected DATA command:


450-4.7.1 Line 1
450-4.7.1 Line 2
450 4.7.1 Line 3

Postfix however seems to fold the reply into a single line:

450-4.7.1 Line 1  450-4.7.1 Line 2  450 4.7.1 Line 3

SMTP clients like swaks will now run into a timeout as the response 
indicates a multiline response (XXX-) but no further lines are coming.


I did test my milter using the Net::Milter Perl package which simulates a 
Milter-enabled MTA as well as actually running it against sendmail as well 
as postfix.


Net::Milter and sendmail to reply correctly using well-formed multiline 
responses while postfix does line-folding and thus breaks the SMTP specs.


The python code to trigger such a multiline response is super simple:

  def eom(self):
  self.setreply('550', '5.7.1', 'Test Milter rejection Reason',
  'Test Milter rejection Reason 01',
  'Test Milter rejection Reason 02')
  return Milter.TEMPFAIL

In order to rule out a problem in the Python implementation, I also tested 
a sample milter written in C using the libmilter library directly. 
Modifying the sendmail-8.15.2/libmilter/example.c file to have the 
following eom handler:


sfsistat
mlfi_eom(ctx)
SMFICTX *ctx;
{
char *rcode = "450";
char *xcode = "4.7.1";
char *reason = "Test Milter rejection Reason";
char *reason01 = "Test Milter rejection Reason 01";
char *reason02 = "Test Milter rejection Reason 02";


(void) mlfi_cleanup(ctx, false);
smfi_setmlreply(ctx, rcode, xcode, reason, reason01, reason02);
return SMFIS_TEMPFAIL;
}

Compiling the milter using gcc -o sample_milter example.c -lmilter 
-lpthread and then starting it using ./sample_milter -p 
inet:10020@localhost gives the following output in sendmail:


 -> DATA
  > : 44 41 54 41  0D 0ADATA..
<   : 33 35 34 20  45 6E 74 65  72 20 6D 61  69 6C 2C 20354.Enter.mail,.
<   0016: 65 6E 64 20  77 69 74 68  20 22 2E 22  20 6F 6E 20end.with.".".on.
<   0032: 61 20 6C 69  6E 65 20 62  79 20 69 74  73 65 6C 66a.line.by.itself
<   0048: 0D 0A ..
<-  354 Enter mail, end with "." on a line by itself
 ->
 -> .
  > : 0D 0A 2E 0D  0A   .
<   : 34 35 30 2D  34 2E 37 2E  31 20 54 65  73 74 20 4D450-4.7.1.Test.M
<   0016: 69 6C 74 65  72 20 72 65  6A 65 63 74  69 6F 6E 20ilter.rejection.
<   0032: 52 65 61 73  6F 6E 0D 0A  34 35 30 2D  34 2E 37 2EReason..450-4.7.
<   0048: 31 20 54 65  73 74 20 4D  69 6C 74 65  72 20 72 651.Test.Milter.re
<   0064: 6A 65 63 74  69 6F 6E 20  52 65 61 73  6F 6E 20 30jection.Reason.0
<   0080: 31 0D 0A 34  35 30 20 34  2E 37 2E 31  20 54 65 731..450.4.7.1.Tes
<   0096: 74 20 4D 69  6C 74 65 72  20 72 65 6A  65 63 74 69t.Milter.rejecti
<   0112: 6F 6E 20 52  65 61 73 6F  6E 20 30 32  0D 0A  on.Reason.02..
<** 450-4.7.1 Test Milter rejection Reason
<** 450-4.7.1 Test Milter rejection Reason 01
<** 450 4.7.1 Test Milter rejection Reason 02
 -> QUIT
  > : 51 55 49 54  0D 0AQUIT..
<   : 32 32 31 20  32 2E 30 2E  30 20 6D 61  69 6C 69 6E221.2.0.0.mailin
<   0016: 30 31 2E 6D  78 2E 62 61  77 75 65 2E  6E 65 74 2001.mx.bawue.net.
<   0032: 63 6C 6F 73  69 6E 67 20  63 6F 6E 6E  65 63 74 69closing.connecti
<   0048: 6F 6E 0D 0A   on..
<-  221 2.0.0 mailin01.mx.bawue.net closing connection
=== Connection closed with remote host.


The comparable postfix output:

$ swaks --server localhost --from '<>' --to test@localhost -d '.' --raw
[...]
 -> DATA
  > : 44 41 54 41  0D 0ADATA..
<   : 33 35 34 20  45 6E 64 20  64 61 74 61  20 77 69 74354.End.data.wit
<   0016: 68 20 3C 43  52 3E 3C 4C  46 3E 2E 3C  43 52 3E 3Ch..<
<   0032: 4C 46 3E 0D  0A   LF>..
<-  354 End data with .
 ->
 -> .
  > : 0D 0A 2E 0D  0A   .
<   : 34 35 30 2D  34 2E 37 2E  31 20 54 65  73 74 20 4D450-4.7.1.Test.M
<   0016: 69 6C 74 65  72 20 72 65  6A 65 63 74  69 6F 6E 20ilter.rejection.
<   0032: 52 65 61 73  6F 6E 20 20  34 35 30 2D  34 2E 37 2EReason..450-4.7.
<   0048: 31 20 54 65  73 74 20 4D  69 6C 74 65  72 20 72 651.Test.Milter.re
<   0064: 6A 65 63 74  69 6F 6E 20  52 65 61 73  6F 6E 20 30jection.Reason.0
<   0080: 31 20 20 34  35 30 20 34  2E 37 2E 31  20 54 65 731..450.4.7.1.Tes
<   0096: 74 20 4D 69  6C 74 65 72  20 72 65 6A  65 63 74 69t.Milter.rejecti
<   0112: 6F 6E 20 

Re: Authentication attempts for x...@com.au addresses

[Esteban L]

You will need to install fail2ban to ip block failed attempts.

As you have correctly assumed, a malicious person is trying to hack into you 
mail server.

Fail2ban is a required application now and days.

On April 2, 2019 8:57:06 AM GMT+02:00, James Brown  wrote:
>Not sure if this is a Dovecot or Postfix issue we use Dovecot for
>authentication for Postfix. Mailboxes are stored in MySQL.
>
>Have noticed this today:
>
>auth-worker(42777): Info: sql(cont...@com.au,127.0.0.1): unknown user
>(given password: someone123)
>
>Also i...@com.au etc.
>
>They are coming through on port 465.
>
>Obviously my domain is not ‘com.au’ - how can I stop these attempts
>from even being considered?
>
>I did update to Postfix 3.4.5 yesterday. Running Dovecot 2.3.5.
>
>Thanks,
>
>James.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Postfix 3.4.4 compile problems on Solaris 11

[Jaco Lesch]

On 4/1/19 20:08, Wietse Venema wrote:

Wietse Venema:

unix_dgram_connect.c: In function 'unix_dgram_connect':
unix_dgram_connect.c:63:24: error: expected identifier or '(' before
numeric constant
   struct sockaddr_un sun;
  ^

Any idea why identical code in src/util/unix_listen.c compiles
without error?

unix_dgram_connect.c is new with Postfix 3.4, but most of the code
is identical to unix_listen.c (in particular both files use 'sun').

But it does not have the line with

#undef sun

that the other unix_*.c files have.

Add this, and it compiles (on my Solaris9 VM).

Wietse

Wietse and Guys

Thanks for the feedback and solution. Have done as suggested, tested on 
both GCC 7.3.0 and DeveloperStudio 12.6, both working fine and producing 
working binaries.


Regards

--
---
Jaco Lesch
SAIX HLS
Email: ja...@saix.net

Re: Remove user agent information in the email header

[André]

On 2 April 2019 08:18:46 BST, Nick  wrote:
>On 2019-04-02 07:42 BST, André Rodier wrote:
>> I have tried the header_checks, and it works, but with all emails,
>> even those received.
>> 
>> Can you tell me how to proceed, please?
>
>
>HTH

Thanks a lot, this is perfect.

André.
-- 
André

Re: Remove user agent information in the email header

[Nick]

On 2019-04-02 07:42 BST, André Rodier wrote:
> I have tried the header_checks, and it works, but with all emails,
> even those received.
> 
> Can you tell me how to proceed, please?


HTH
-- 
Nick

RE: nfs as storage for mail queue

[De Petter Mattheas]

Found a solution to my problem in archive

http://postfix.1071664.n5.nabble.com/scan-dir-push-open-directory-defer-Permission-denied-td90566.html

thanks Witse



Met vriendelijke groeten
Kind regards
De Petter Mattheas
Technical support engineer - projects team
IT-Department Jan De Nul Dredging N.V.
T +32 (0)53 73 95 53
F +32 (0)53 21 00 31
www.jandenul.com

From: De Petter Mattheas
Sent: 02 April 2019 08:39
To: Postfix users 
Subject: nfs as storage for mail queue

Hello

Can somebody help me?

So I have setup the nfs share on a windows server 2016 with nfs server role.

Security is set on the device ip of the postfix server read-write with allow 
root access.

In the main conf of postfix I have set the queue to the right dir

queue_directory = /mnt/mail

fstab is set as:
10.7.248.45:/Mailq /mnt/mail nfs defaults 0 0

When I start the postfix service it writes all the folder structure on the 
share but fails to start with error.

● postfix.service - Postfix Mail Transport Agent
   Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Tue 2019-04-02 08:15:59 CEST; 1min 
5s ago
  Process: 1730 ExecStopPost=/etc/postfix/system/cond_slp deregister 
(code=exited, status=0/SUCCESS)
  Process: 1510 ExecStartPost=/etc/postfix/system/cond_slp register 
(code=exited, status=0/SUCCESS)
  Process: 1508 ExecStartPost=/etc/postfix/system/wait_qmgr 60 (code=exited, 
status=0/SUCCESS)
  Process: 1634 ExecStart=/usr/sbin/postfix start (code=exited, 
status=1/FAILURE)
  Process: 1623 ExecStartPre=/etc/postfix/system/update_postmaps (code=exited, 
status=0/SUCCESS)
  Process: 1622 ExecStartPre=/etc/postfix/system/update_chroot (code=exited, 
status=0/SUCCESS)
  Process: 1621 ExecStartPre=/etc/postfix/system/config_postfix (code=exited, 
status=0/SUCCESS)
  Process: 1620 ExecStartPre=/bin/echo Starting mail service (Postfix) 
(code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 19660)
   CGroup: /system.slice/postfix.service

Apr 02 08:15:57 eqx-postfix01 systemd[1]: Starting Postfix Mail Transport 
Agent...
Apr 02 08:15:57 eqx-postfix01 echo[1620]: Starting mail service (Postfix)
Apr 02 08:15:57 eqx-postfix01 postfix[1634]: postsuper: fatal: scan_dir_push: 
open directory defer: Permission denied
Apr 02 08:15:57 eqx-postfix01 postfix/postsuper[1728]: fatal: scan_dir_push: 
open directory defer: Permission denied
Apr 02 08:15:58 eqx-postfix01 postfix/postfix-script[1729]: fatal: Postfix 
integrity check failed!
Apr 02 08:15:59 eqx-postfix01 systemd[1]: postfix.service: Control process 
exited, code=exited status=1
Apr 02 08:15:59 eqx-postfix01 systemd[1]: Failed to start Postfix Mail 
Transport Agent.
Apr 02 08:15:59 eqx-postfix01 systemd[1]: postfix.service: Unit entered failed 
state.
Apr 02 08:15:59 eqx-postfix01 systemd[1]: postfix.service: Failed with result 
'exit-code'.


Where or what am I doing wrong?
Do I need to change other parameters in Main.cf as well?

Please help I’m stuck on this.


Met vriendelijke groeten
Kind regards
De Petter Mattheas
Technical support engineer - projects team
IT-Department Jan De Nul Dredging N.V.
T +32 (0)53 73 95 53
F +32 (0)53 21 00 31
www.jandenul.com


Any reaction to this e-mail or any other mail, including any
files transmitted therewith to sender's e-mail address(es)
shall be dealt with not as private, but as business
communication(s) and shall be registered as such.

Re: nfs as storage for mail queue

[Dominic Raferd]

On Tue, 2 Apr 2019 at 07:40, De Petter Mattheas <
mattheas.depet...@jandenul.com> wrote:

> Hello
>
>
>
> Can somebody help me?
>
>
>
> So I have setup the nfs share on a windows server 2016 with nfs server
> role.
>
>
>
> Security is set on the device ip of the postfix server read-write with
> allow root access.
>
>
>
> In the main conf of postfix I have set the queue to the right dir
>
>
>
> queue_directory = /mnt/mail
>
>
>
> fstab is set as:
>
> 10.7.248.45:/Mailq /mnt/mail nfs defaults 0 0
>
>
>
> When I start the postfix service it writes all the folder structure on the
> share but fails to start with error.
>
>
>
> ● postfix.service - Postfix Mail Transport Agent
>
>Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled;
> vendor preset: enabled)
>
>Active: failed (Result: exit-code) since Tue 2019-04-02 08:15:59 CEST;
> 1min 5s ago
>
>   Process: 1730 ExecStopPost=/etc/postfix/system/cond_slp deregister
> (code=exited, status=0/SUCCESS)
>
>   Process: 1510 ExecStartPost=/etc/postfix/system/cond_slp register
> (code=exited, status=0/SUCCESS)
>
>   Process: 1508 ExecStartPost=/etc/postfix/system/wait_qmgr 60
> (code=exited, status=0/SUCCESS)
>
>   Process: 1634 ExecStart=/usr/sbin/postfix start (code=exited,
> status=1/FAILURE)
>
>   Process: 1623 ExecStartPre=/etc/postfix/system/update_postmaps
> (code=exited, status=0/SUCCESS)
>
>   Process: 1622 ExecStartPre=/etc/postfix/system/update_chroot
> (code=exited, status=0/SUCCESS)
>
>   Process: 1621 ExecStartPre=/etc/postfix/system/config_postfix
> (code=exited, status=0/SUCCESS)
>
>   Process: 1620 ExecStartPre=/bin/echo Starting mail service (Postfix)
> (code=exited, status=0/SUCCESS)
>
> Tasks: 0 (limit: 19660)
>
>CGroup: /system.slice/postfix.service
>
>
>
> Apr 02 08:15:57 eqx-postfix01 systemd[1]: Starting Postfix Mail Transport
> Agent...
>
> Apr 02 08:15:57 eqx-postfix01 echo[1620]: Starting mail service (Postfix)
>
> Apr 02 08:15:57 eqx-postfix01 postfix[1634]: postsuper: fatal:
> scan_dir_push: open directory defer: Permission denied
>
> Apr 02 08:15:57 eqx-postfix01 postfix/postsuper[1728]: fatal:
> scan_dir_push: open directory defer: Permission denied
>
> Apr 02 08:15:58 eqx-postfix01 postfix/postfix-script[1729]: fatal: Postfix
> integrity check failed!
>
> Apr 02 08:15:59 eqx-postfix01 systemd[1]: postfix.service: Control process
> exited, code=exited status=1
>
> Apr 02 08:15:59 eqx-postfix01 systemd[1]: Failed to start Postfix Mail
> Transport Agent.
>
> Apr 02 08:15:59 eqx-postfix01 systemd[1]: postfix.service: Unit entered
> failed state.
>
> Apr 02 08:15:59 eqx-postfix01 systemd[1]: postfix.service: Failed with
> result 'exit-code'.
>
>
>
>
>
> Where or what am I doing wrong?
>
> Do I need to change other parameters in Main.cf as well?
>
>
>
> Please help I’m stuck on this.
>
>
On my systems (Ubuntu 18.04) the default queue directory has:

# ls /var/spool/postfix -ld
drwxr-xr-x 20 root root 4096 Dec 15 07:05 /var/spool/postfix

and many of the directories under it are owned by postfix, two of them
(/var/spool/postfix/public and /var/spool/postfix/maildrop) with group
postdrop. So I think - at the least - 'postfix' user must have r-x
permissions on the queue directory.

Authentication attempts for x...@com.au addresses

[James Brown]

Not sure if this is a Dovecot or Postfix issue we use Dovecot for 
authentication for Postfix. Mailboxes are stored in MySQL.

Have noticed this today:

auth-worker(42777): Info: sql(cont...@com.au,127.0.0.1): unknown user (given 
password: someone123)

Also i...@com.au etc.

They are coming through on port 465.

Obviously my domain is not ‘com.au’ - how can I stop these attempts from even 
being considered?

I did update to Postfix 3.4.5 yesterday. Running Dovecot 2.3.5.

Thanks,

James.

Remove user agent information in the email header

[André Rodier]

Hello,

I would like to delete automatically User-Agent or X-Mailer information
in the headers of outgoing emails.

I have tried the header_checks, and it works, but with all emails, even
those received.

Can you tell me how to proceed, please?

Thanks,
André

-- 
André Rodier
HomeBox: https://github.com/progmaticltd/homebox

nfs as storage for mail queue

[De Petter Mattheas]

Hello

Can somebody help me?

So I have setup the nfs share on a windows server 2016 with nfs server role.

Security is set on the device ip of the postfix server read-write with allow 
root access.

In the main conf of postfix I have set the queue to the right dir

queue_directory = /mnt/mail

fstab is set as:
10.7.248.45:/Mailq /mnt/mail nfs defaults 0 0

When I start the postfix service it writes all the folder structure on the 
share but fails to start with error.

● postfix.service - Postfix Mail Transport Agent
   Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Tue 2019-04-02 08:15:59 CEST; 1min 
5s ago
  Process: 1730 ExecStopPost=/etc/postfix/system/cond_slp deregister 
(code=exited, status=0/SUCCESS)
  Process: 1510 ExecStartPost=/etc/postfix/system/cond_slp register 
(code=exited, status=0/SUCCESS)
  Process: 1508 ExecStartPost=/etc/postfix/system/wait_qmgr 60 (code=exited, 
status=0/SUCCESS)
  Process: 1634 ExecStart=/usr/sbin/postfix start (code=exited, 
status=1/FAILURE)
  Process: 1623 ExecStartPre=/etc/postfix/system/update_postmaps (code=exited, 
status=0/SUCCESS)
  Process: 1622 ExecStartPre=/etc/postfix/system/update_chroot (code=exited, 
status=0/SUCCESS)
  Process: 1621 ExecStartPre=/etc/postfix/system/config_postfix (code=exited, 
status=0/SUCCESS)
  Process: 1620 ExecStartPre=/bin/echo Starting mail service (Postfix) 
(code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 19660)
   CGroup: /system.slice/postfix.service

Apr 02 08:15:57 eqx-postfix01 systemd[1]: Starting Postfix Mail Transport 
Agent...
Apr 02 08:15:57 eqx-postfix01 echo[1620]: Starting mail service (Postfix)
Apr 02 08:15:57 eqx-postfix01 postfix[1634]: postsuper: fatal: scan_dir_push: 
open directory defer: Permission denied
Apr 02 08:15:57 eqx-postfix01 postfix/postsuper[1728]: fatal: scan_dir_push: 
open directory defer: Permission denied
Apr 02 08:15:58 eqx-postfix01 postfix/postfix-script[1729]: fatal: Postfix 
integrity check failed!
Apr 02 08:15:59 eqx-postfix01 systemd[1]: postfix.service: Control process 
exited, code=exited status=1
Apr 02 08:15:59 eqx-postfix01 systemd[1]: Failed to start Postfix Mail 
Transport Agent.
Apr 02 08:15:59 eqx-postfix01 systemd[1]: postfix.service: Unit entered failed 
state.
Apr 02 08:15:59 eqx-postfix01 systemd[1]: postfix.service: Failed with result 
'exit-code'.


Where or what am I doing wrong?
Do I need to change other parameters in Main.cf as well?

Please help I’m stuck on this.


Met vriendelijke groeten
Kind regards
De Petter Mattheas
Technical support engineer - projects team
IT-Department Jan De Nul Dredging N.V.
T +32 (0)53 73 95 53
F +32 (0)53 21 00 31
www.jandenul.com


Any reaction to this e-mail or any other mail, including any
files transmitted therewith to sender's e-mail address(es)
shall be dealt with not as private, but as business
communication(s) and shall be registered as such.

Re: Ubuntu 18.04 /etc/aliases

[황병희]

> For Debian and derivatives like Ubuntu, yes.

Thanks for confirmation!!!

Sincerely, Byung-Hee from South Korea.

-- 
^고맙습니다 _地平天成_ 감사합니다_^))//