problems with virtual_alias_maps

[Tomas Macek]

Hi, I'm confused about how works the map tables in Postfix, I'm using the 
2.4.1 version.


I have setup the virtual_mailbox_domains to return the domain names, for 
that we are the final destination and I have also setup the 
virtual_alias_maps for trivial rewrite of some addresses.


My problem:
The virtual_mailbox_domains DOES NOT contain the domain 'mydomain.com' (it 
looks for it in the PostgreSQL database, the proper row with the domain 
name is not returned).
The virtual_alias_maps contains a map, that returns some alias in the 
'mydomain.com'.


The result is, that when someone from the internet sends the mail to 
the alias of @mydomain.com over my server and if the alias is listed in 
the virtual_alias_maps map, the server will receive the mail and tries to 
deliver it to the aliased mailbox.


The problem is clear: we are not the final destination of the 
@mydomain.com and we are delivering for the aliases in the domain.


Is that a normal Postfix's behaviour or I'm doing something wrong? I was 
looking at the docs Virtual domain hosting and Lookup table overview, but 
couldn't find any answer.


Best regards, Tomas

Re: problems with virtual_alias_maps

[Tomas Macek]

Yes, that's what I returning now: not found - the domain was not found in 
the virtual_mailbox_domains table


Tomas


On Thu, 22 Oct 2009, Noel Jones wrote:


On 10/22/2009 2:35 AM, Tomas Macek wrote:

Hi, I'm confused about how works the map tables in Postfix, I'm using
the 2.4.1 version.

I have setup the virtual_mailbox_domains to return the domain names


When you use a table for virtual_mailbox_domains, it must not return a list 
of domains.  Rather, postfix looks up the domain and expects either a match 
(indicated by any response) or not found.


See:
http://www.postfix.org/postconf.5.html#virtual_mailbox_domains
http://www.postfix.org/postconf.5.html#mydestination (which explains the 
syntax expected from virtual_mailbox_domains)

http://www.postfix.org/ADDRESS_CLASS_README.html
http://www.postfix.org/DATABASE_README.html


 -- Noel Jones

Re: bad recipient address passed to the content filter

[Tomas Macek]

On Mon, 12 Dec 2011, Noel Jones wrote:


On 12/12/2011 7:08 AM, Tomas Macek wrote:

I'm using Postfix 2.8.5 built from source and amavisd-new 2.6.4 from
Scientific Linux distribution. I have virtual domain 'virtdom.cz' and
some subdomain 'subdomain.virtdom.cz'. The server receives the
message and
passes it to amavisd-new.

As you can see from the config, the re...@virtdom.cz shlould be
rewritten to
re...@subdomain.virtdom.cz and then passed to amavisd-new. The map
always
finds the key/value pair, but then Postfix does not pass the newly
found
address to amavis. Why?
Below are 2 different cases, that appear - the first one is bad
delivery, the
second is the proper one where things work properly as expected.
You can see it on the recipient address passed to the
amavisd-new on port 10024 (find ESMTP::10024). I cannot fully
reproduce this
error, it happens somehow.


Typically this is caused by improper use of
receive_override_options = no_address_mappings
somewhere in your config.


Even if proper and bad behaviour happens accidentaly?
I will try to setup another server and will try to tune the setup.

Tomas

Re: bad recipient address passed to the content filter

[Tomas Macek]

On Tue, 13 Dec 2011, Tomas Macek wrote:




On Mon, 12 Dec 2011, Noel Jones wrote:


On 12/12/2011 7:08 AM, Tomas Macek wrote:

I'm using Postfix 2.8.5 built from source and amavisd-new 2.6.4 from
Scientific Linux distribution. I have virtual domain 'virtdom.cz' and
some subdomain 'subdomain.virtdom.cz'. The server receives the
message and
passes it to amavisd-new.

As you can see from the config, the re...@virtdom.cz shlould be
rewritten to
re...@subdomain.virtdom.cz and then passed to amavisd-new. The map
always
finds the key/value pair, but then Postfix does not pass the newly
found
address to amavis. Why?
Below are 2 different cases, that appear - the first one is bad
delivery, the
second is the proper one where things work properly as expected.
You can see it on the recipient address passed to the
amavisd-new on port 10024 (find ESMTP::10024). I cannot fully
reproduce this
error, it happens somehow.


Typically this is caused by improper use of
receive_override_options = no_address_mappings
somewhere in your config.


Even if proper and bad behaviour happens accidentaly?
I will try to setup another server and will try to tune the setup.

Tomas



After doing some testing it seemed that it did not work only if mail goes 
through smtps, so I 
removed the no_address_mappings from the line with smtps in my master.cf 
and now it works (thanks to Noel!)
Strange is, that one of our customer said, that he made things working by 
removing antivirus software from his computer :-))


Regards Tomas

logging whitelisted IPs

[Tomas Macek]

I'd like to have an whitelist based on hash:file table, for example this 
http://www.howtoforge.com/how-to-whitelist-hosts-ip-addresses-in-postfix - 
it's simple.


When I have a line

1.2.3.4 REJECT You were blacklisted

it's logged including reason of rejecting (of course).

But when I have a line

1.2.3.4 OK You were whitelisted

it's not logged at all and I don't know why the IP was able to sent a mail 
through the mailserver and why. Is there any possibility to achieve that?


Tomas

using postscreen on port 25

[Tomas Macek]

I'd like to use postcreen as some kind of spam protection. According to 
documentation


* postscreen(8) should not be used on SMTP ports that receive mail 
from end-user clients (MUAs). In a typical deployment, postscreen(8) is 
used on the port 25 service, while MUA clients submit mail via the 
submission service (port 587) which normally requires client 
authentication.



But we have clients, that send mails on both port 25 and 587. I 
really cannot use postscreen? I don't 
understand why exactly. What will happen if I use it?


Tomas

Re: Upgrade ...

[Tomas Macek]

On Thu, 29 Dec 2011, Barbara M. wrote:



I read the already suggested:

http://stevejenkins.com/blog/2011/01/building-postfix-2-8-on-rhel5-centos-5-
from-source/

My current situation is:
- Old server CentOS 4.x based (Postfix 2.2)

I want to migrate to a new CentOS 6.x (Postfix 2.6)

My plan is to update Postfix (and dovecot, procmail), in the old box to the 
release in the new box and when tested, move user/data to the new box (new 
box is 64 bit while old box is 32 bit, but hope this isn't a problem).
Copying the old /etc/postfix dir to the new server and restarting the service 
seems work well (not tested local delivery, procmail, ...).


There is some guidolines that I can study/follow to have a painless 
migration?


Thanks, B.


At least, I would recommend you to read all the release notes of all 
version from yours to the past from here: 
http://www.postfix.org/announcements.html

You could maybe find there something usefull...

Tomas

reply-to header in this list

[Tomas Macek]

Hi list, is there any reason why the Reply-to: header is not set to 
postfix-users in this list? When I press Reply button, I'm replying to 
From: address, when pressing 'Reply to all', I'm replying to both the list 
and the sender personaly. But why should I reply to the sender 
personaly? Could anyone here (Wietse?) setup this list with 
proper Reply to: header? Or is there any reason for this?


Best regards, Tomas

Re: reply-to header in this list

[Tomas Macek]

On Wed, 4 Jan 2012, Jerry wrote:


On Wed, 4 Jan 2012 13:01:07 +0100
Erwan David articulated:


On Wed, Jan 04, 2012 at 12:37:53PM CET, Tomas Macek
ma...@fortech.cz said:

Hi list, is there any reason why the Reply-to: header is not set to
postfix-users in this list? When I press Reply button, I'm replying
to From: address, when pressing 'Reply to all', I'm replying to both
the list and the sender personaly. But why should I reply to the
sender personaly? Could anyone here (Wietse?) setup this list with
proper Reply to: header? Or is there any reason for this?

Best regards, Tomas



There 3 possible ways to answer :
to the poster, to the list, to all.
Setting the Reply-To: prevents the first possibility.

Some MUAs have a answer to list command.


This is one of those topics that gets debated on various lists from time
to time. From the dozen or so lists that I am associated with, it seems
that the consensus is that if a message is posted to the list, it
should be answered (replied-to) on list. Many posters, including
myself, routinely discard mail sent directly to them from a poster on
a mailing list. If a poster desired a personalized or directed response,
they can so indicate in their post. You will notice that Sahil Tandon
did just that in a recent post.

Now, to answer you specific question, I don't know. I am not even sure
why a List-Id: is not included, although I am told that there is
support for it in some RFC. I would assume that Wietse would be the
best person to ask.



Since I see many mails even from this list, that were sent to me directly, 
I think the Reply to: would help to many people here. I also only delete 
those emails without reading. Too many people are familiar only with the 
Reply button and don't see any other. I don't say sorry for that, but 
that's the 
way it is. Mime mailer (Alpine) even does not have Reply To List button, 
so I always rewrite the headers (I did not write the question because 
of that!).


Tomas

Re: message_size_limit causes postfix to stop delivering messages

[Tomas Macek]

On Sun, 5 Feb 2012, Wietse Venema wrote:


Nick Bright:

On 2/4/2012 12:20 PM, Ralf Hildebrandt wrote:

* Nick Brightnick.bri...@valnet.net:


Upon restarting postfix with message_size_limit in place it simply
wouldn't deliver any mail. It accepts the mail in to SMTP just fine,
but it never gets delivered.


Logs?



There are no log entries other than normal entries reflecting that the
messages have been accepted for delivery, though per another posters'
recommendation; I will enable debug logging and give it another look. I
also installed postfix-perl-utils and will examine which queue the
messages are piling up in with pfHandle during my next test.


Postfix logs all attempts to deliver mail, whether
or not successful.

Please do not turn on debug logging, it will just make
the problem harder to diagnose.

You probably have a bug in the VDA patch that breaks
when the message size limit exceeds the mailbox size
limit. Their code does not handle that correctly.

Wietse



What should be a proper behaviour in this case?
If the patched virtual 
agent gets from the queue the message, that exceeds the mailbox size 
limit, it can only bounce or drop the message. It does something else? Or 
what's bad?


Tomas

Re: performance problems

[Tomas Macek]

On Fri, 30 Mar 2012, Jeremie CEINTREY wrote:


mails are in active queue.

Amavis Processes :
$max_servers =3D 8; # 2 processes by core

Actually, the server is ok, not stressed at all, the relay mail is slow.



What from amavis do you have in your master.cf file?

The master.cf option -o max_use=XXX in the amavis line must correspond 
to the $max_servers from amavisd.conf. This was once my own bottleneck :-)


Best Regards, Tomas

Re: performance problems

[Tomas Macek]

On Fri, 30 Mar 2012, Ralf Hildebrandt wrote:


* Tomas Macek ma...@fortech.cz:

On Fri, 30 Mar 2012, Jeremie CEINTREY wrote:


mails are in active queue.

Amavis Processes :
$max_servers =3D 8; # 2 processes by core

Actually, the server is ok, not stressed at all, the relay mail is slow.



What from amavis do you have in your master.cf file?

The master.cf option -o max_use=XXX in the amavis line must
correspond to the $max_servers from amavisd.conf. This was once my
own bottleneck :-)


That's not correct.

max_use specifies how often Postfix RE-USES a service instance

The NUMBER (column maxproc) should correspond to $max_servers from 
amavisd.conf.



Oops! Thank you for the correction!

T.

Re: Filter incoming mail by sender - forward, otherwise autoreply

[Tomas Macek]

Now I think that policy and or after queue filtering are good solutions,
but both seem rather complex for a relatively easy problem.


If you will create something what policyd does (www.policyd.org) using 
http://www.postfix.org/SMTPD_POLICY_README.html, you are able 
to do something with the mail except the address rewriting, so you 
cannot forward the mail anywhere. So this is IMHO not a good way for you.


What about some kind of milter? If you write a milter rewriting address, 
you can forward the mail to an alias that sends the mail into some pipe 
program acting as autoreply...


Tomas

Re: 4xx too many errors question

[Tomas Macek]

On Wed, 17 Oct 2012, Wietse Venema wrote:


Tomas Macek:

So my question is how can I get this error message on my own computer,
when I did not sent any email to the server in last hour? According to
this experience, this seems to be per server settings. Or am I missing
something?


The error counter is a PER SESSION property. It starts at zero,
then it is incremented by one for every error reply.

- What error replies does the client receive? Look at the
maillog file after:

   # postconf -e debug_peer_list = address-of-client
   # postfix reload

- How many error replies before Postfix hangs up?

   $ postconf smtpd_hard_error_limit

Wietse



The part of the log is here:

Oct 11 12:26:44 mail postfix/smtpd[4546]:  my.pc.host.name[x.x.x.x]: RSET
Oct 11 12:26:44 mail postfix/smtpd[4546]:  my.pc.host.name[x.x.x.]: 250 2.0.0 
Ok
Oct 11 12:26:44 mail postfix/smtpd[4546]:  my.pc.host.name[x.x.x.x]: 421 4.7.0 
our.server.name Error: too many errors
Oct 11 12:26:44 mail postfix/smtpd[4546]: too many errors after RSET from 
my.pc.host.name[x.x.x.x]

The postconf smtpd_hard_error_limit output:
smtpd_hard_error_limit = ${stress?1}${stress:20}

The strange thing is, that my IP adress was blocked with 421, when I send 
that day just a few mails (using Alpine on Linux). But the server was 
under heavy load, so the 
smtpd_*_error_limit seemed to me to be per server options, not per 
session, because I didn't see any reason why my computer should receive 
421 from the server.


Tomas

Re: 4xx too many errors question

[Tomas Macek]

On Wed, 17 Oct 2012, Wietse Venema wrote:


Tomas Macek:

The part of the log is here:

Oct 11 12:26:44 mail postfix/smtpd[4546]:  my.pc.host.name[x.x.x.x]: RSET
Oct 11 12:26:44 mail postfix/smtpd[4546]:  my.pc.host.name[x.x.x.]: 250 2.0.0 
Ok
Oct 11 12:26:44 mail postfix/smtpd[4546]:  my.pc.host.name[x.x.x.x]: 421 4.7.0 
our.server.name Error: too many errors


Postfix does not allow clients to send an unlimited number of
commands like NOOP or RSET.

The default setting is:

   smtpd_junk_command_limit = ${stress?1}${stress:100}

This means: under server overload conditions, Postfix will immediately
disconnect a client that sends commands like NOOP or RSET, instead
of sending mail.


Oct 11 12:26:44 mail postfix/smtpd[4546]: too many errors after RSET from 
my.pc.host.name[x.x.x.x]

The postconf smtpd_hard_error_limit output:
smtpd_hard_error_limit = ${stress?1}${stress:20}


What was the effective hard error limit: 1 or 20?


I still don't understand what exactly means the ${stress?1}${stress:20} 
writing. According to the doc, the server should have this set normally 
to 20, in stress to just 1. How can I know, what was the actual setting?



Look at the output from:

$ grep STRESS the-maillog-file


Many thanks, now I see it:

Oct 11 12:24:45 mail postfix/master[10574]: warning: service smtp (25) 
has reached its process limit 100: new clients may experience noticeable 
delays
Oct 11 12:24:45 mail postfix/master[10574]: warning: to avoid this 
condition, increase the process count in master.cf or reduce the service 
time per client
Oct 11 12:24:45 mail postfix/master[10574]: warning: see 
http://www.postfix.org/STRESS_README.html for examples of stress-adapting 
configuration settings


I will read the stress-adapting document.

Tomas

avoiding overload on port 587

[Tomas Macek]

I don't understand now, how Postfix behaves when listenting on 
submission port 587.
Our mailserver is sometimes overloaded on port 25, so we want to use 
postscreen. But I don't understand, how Postfix works when it's stressed 
on port 587, when spammers connect to that opened port and want send their 
emails. In document http://www.postfix.org/STRESS_README.html there 
is:


NOTE: To avoid overload delays for end-user mail clients, enable the 
submission service entry in master.cf (present since Postfix 2.1), and 
tell users to connect to this instead of the public SMTP service.


Should this mean, that Postfix by default does not use counters like 
smtpd_hard_error_limit, smtpd_junk_command_limit and maybe others on 
sumission port? On 
this port I would prefer using some kind of smtp auth and this port should 
be world accessible to allow the clients using other networks to 
authenticate and send emails.


Regards, Tomas

Re: avoiding overload on port 587

[Tomas Macek]

On Fri, 30 Nov 2012, lst_ho...@kwsoft.de wrote:



Zitat von Tomas Macek ma...@fortech.cz:

I don't understand now, how Postfix behaves when listenting on submission 
port 587.
Our mailserver is sometimes overloaded on port 25, so we want to use 
postscreen. But I don't understand, how Postfix works when it's stressed on 
port 587, when spammers connect to that opened port and want send their 
emails. In document http://www.postfix.org/STRESS_README.html there is:


NOTE: To avoid overload delays for end-user mail clients, enable the 
submission service entry in master.cf (present since Postfix 2.1), and 
tell users to connect to this instead of the public SMTP service.


Should this mean, that Postfix by default does not use counters like 
smtpd_hard_error_limit, smtpd_junk_command_limit and maybe others on 
sumission port? On this port I would prefer using some kind of smtp auth 
and this port should be world accessible to allow the clients using other 
networks to authenticate and send emails.




Port 587 is by default nothing special for Postfix because it is mostly a 
clone of the Port 25 service. The *intended* difference is that Port 587 
should only accept mail by authenticated users, so no chance for spammers if 
they don't own valid credentials. To actually see the difference between Port 
25 and Port 587 settings you have to compare the entries in master.cf.


Regards

Andreas



OK, so there is a chance for spammers to overload the server using 
submission port 587 (the server says then service smtp (25) has
reached its process limit 200) by exhausting number of available ports 
and the MUA clients then can have also problems to send their

emails? I'm I right?
If I'm, then I don't understand, why to split the processes into 
submission 587 and normal 25, because if the MUA client send the mail
through 25 (hope with postscreen), there is a chance that the 25 is not 
overloaded (because it uses postscreen) and he will be rather

able to send his email compared to 587.
Or I don't still understand something ... :-)

Andreas: sorry for my direct answer to you, my mistake

Tomas

Re: avoiding overload on port 587

[Tomas Macek]

On Fri, 30 Nov 2012, Robert Schetterer wrote:


Am 30.11.2012 11:12, schrieb Tomas Macek:

On Fri, 30 Nov 2012, lst_ho...@kwsoft.de wrote:



Zitat von Tomas Macek ma...@fortech.cz:


I don't understand now, how Postfix behaves when listenting on
submission port 587.
Our mailserver is sometimes overloaded on port 25, so we want to use
postscreen. But I don't understand, how Postfix works when it's
stressed on port 587, when spammers connect to that opened port and
want send their emails. In document
http://www.postfix.org/STRESS_README.html there is:

NOTE: To avoid overload delays for end-user mail clients, enable
the submission service entry in master.cf (present since Postfix
2.1), and tell users to connect to this instead of the public SMTP
service.

Should this mean, that Postfix by default does not use counters like
smtpd_hard_error_limit, smtpd_junk_command_limit and maybe others on
sumission port? On this port I would prefer using some kind of smtp
auth and this port should be world accessible to allow the clients
using other networks to authenticate and send emails.



Port 587 is by default nothing special for Postfix because it is
mostly a clone of the Port 25 service. The *intended* difference is
that Port 587 should only accept mail by authenticated users, so no
chance for spammers if they don't own valid credentials. To actually
see the difference between Port 25 and Port 587 settings you have to
compare the entries in master.cf.

Regards

Andreas



OK, so there is a chance for spammers to overload the server using
submission port 587 (the server says then service smtp (25) has
reached its process limit 200) by exhausting number of available
ports and the MUA clients then can have also problems to send their
emails? I'm I right?
If I'm, then I don't understand, why to split the processes into
submission 587 and normal 25, because if the MUA client send the mail
through 25 (hope with postscreen), there is a chance that the 25 is not
overloaded (because it uses postscreen) and he will be rather
able to send his email compared to 587.
Or I don't still understand something ... :-)

Andreas: sorry for my direct answer to you, my mistake

Tomas


you dont want to use postscreen with your valid user , therefor use
submission port with auth and tls them, if problems with limits ,do
higher it etc

i general whenever a port is open public, there is a chance to fire on
it, avoiding this is i.e a firewall job

MfG Robert Schetterer


I cannot apply firewall rules on 587, because our clients travel with 
their notebooks and still want to send their emails through our 
mailserver.


Tomas

Re: avoiding overload on port 587

[Tomas Macek]

On Fri, 30 Nov 2012, lst_ho...@kwsoft.de wrote:



Zitat von Tomas Macek ma...@fortech.cz:


On Fri, 30 Nov 2012, lst_ho...@kwsoft.de wrote:



Zitat von Tomas Macek ma...@fortech.cz:

I don't understand now, how Postfix behaves when listenting on submission 
port 587.
Our mailserver is sometimes overloaded on port 25, so we want to use 
postscreen. But I don't understand, how Postfix works when it's stressed 
on port 587, when spammers connect to that opened port and want send 
their emails. In document http://www.postfix.org/STRESS_README.html 
there is:


NOTE: To avoid overload delays for end-user mail clients, enable the 
submission service entry in master.cf (present since Postfix 2.1), and 
tell users to connect to this instead of the public SMTP service.


Should this mean, that Postfix by default does not use counters like 
smtpd_hard_error_limit, smtpd_junk_command_limit and maybe others on 
sumission port? On this port I would prefer using some kind of smtp auth 
and this port should be world accessible to allow the clients using other 
networks to authenticate and send emails.




Port 587 is by default nothing special for Postfix because it is mostly a 
clone of the Port 25 service. The *intended* difference is that Port 587 
should only accept mail by authenticated users, so no chance for spammers 
if they don't own valid credentials. To actually see the difference 
between Port 25 and Port 587 settings you have to compare the entries in 
master.cf.


Regards

Andreas



OK, so there is a chance for spammers to overload the server using 
submission port 587 (the server says then service smtp (25) has
reached its process limit 200) by exhausting number of available ports 
and the MUA clients then can have also problems to send their

emails? I'm I right?


The number of available ports is a OS thing, Postfix can be configured in 
master.cf the not allow more than maxproc-column service processes *per 
service*. So if you have 200 maxproc for Port 25 and another 200 for Port 587 
your OS must be able to handle at least 400 connections (open ports, fds 
etc.). If 200 are reached at Port 25 Postfix will still accept up until 200 
connections on Port 587, but refuses any further connections on Port 25.


According to the doc:
It works as follows. When a public network service such as the SMTP 
server runs into an all server ports are busy condition, the Postfix 
master(8) daemon logs a warning, restarts the service (without 
interrupting existing network sessions), and runs the service with -o 
stress=yes on the server process command line:


Just see all server ports are busy: what means the ports? Because I 
experieced the stress=yes at smtpd processes, when just 121 smtpd 
processes were running that time.


If I'm, then I don't understand, why to split the processes into submission 
587 and normal 25, because if the MUA client send the mail
through 25 (hope with postscreen), there is a chance that the 25 is not 
overloaded (because it uses postscreen) and he will be rather

able to send his email compared to 587.
Or I don't still understand something ... :-)


No, MUA should use Port 587 and *authentication*. Port 25 is for MTA --- 
MTA transfer *without* authentication. It does work to use Port 25 with MUA 
but it is not recommended these days. Postscreen is able to prevent some 
spammer connections to actually allocate one of this 200 port 25 processes so 
the boundery is higher but still applies.


Andreas


Yes, I understand this well and know about it and this is what I want. But 
don't undrestand howto avoid overloading the server, when spammers will 
try to connect and send their mails to the port 587.
If the Postfix's behaviour on port 587 is the same as with 25, it seems to 
me to be better to let the MUAs to send their mail to 25. In the 
postscreen the mynetworks are automatically whitelisted and on 25 they 
have better chance to send their mails, because 25 should not be 
overloaded because of postscreen used.


Using firewall on 587 is useless, because our clients travel with their 
computers even around Europe and want to send their mails.


Toamas

Re: avoiding overload on port 587

[Tomas Macek]

On Fri, 30 Nov 2012, Ralf Hildebrandt wrote:


* Robert Schetterer r...@sys4.de:

Am 30.11.2012 11:44, schrieb Tomas Macek:

I cannot apply firewall rules on 587, because our clients travel with
their notebooks and still want to send their emails through our mailserver.


use fail2ban etc for blocking dynamic, brute force attacks to
submission, normally this never matched on legal clients cause they know
their passwords and submission should used only, with password auth and
tls , if afraid for dummy users, choose low blocking time


That should be sufficient!


Fail2ban looks good, I will try it. But I'm worrying about to many filter 
rules in fail2ban chain, that could lead into slowing down the whole 
machine. The force attacks are often really brute and the IP's of 
the clients change often also. But this could be a good way...


Tomas

Re: avoiding overload on port 587

[Tomas Macek]

On Fri, 30 Nov 2012, Robert Schetterer wrote:


Am 30.11.2012 12:07, schrieb Tomas Macek:

Fail2ban looks good, I will try it. But I'm worrying about to many
filter rules in fail2ban chain, that could lead into slowing down the
whole machine. The force attacks are often really brute and the IP's of
the clients change often also. But this could be a good way...


fail2ban is not very heavyweight with ipset
however most brute force are running against pop3 and imap these days
not submission

what i had ,was ,fail2ban log parsing was to slow with millions of bot
cons on port 25


Yes, I'm also worrying now about the performance of fail2ban on 200 MB of
maillog on our machine. But I will try it, maybe this will be enaugh for 
us.



so i wrote a mail syslog parser script


This is really interesting solution (!), hope I will be able also to 
connect to the syslog's pipe and read the mesages. But I don't know how 
right now, I still was not studiing this, but I believe, that this would 
have much bigger performance! Thanks for the idea!


Tomas

Re: avoiding overload on port 587

[Tomas Macek]

On Fri, 30 Nov 2012, lst_ho...@kwsoft.de wrote:



Zitat von Tomas Macek ma...@fortech.cz:


On Fri, 30 Nov 2012, lst_ho...@kwsoft.de wrote:



Zitat von Tomas Macek ma...@fortech.cz:


On Fri, 30 Nov 2012, lst_ho...@kwsoft.de wrote:



Zitat von Tomas Macek ma...@fortech.cz:

I don't understand now, how Postfix behaves when listenting on 
submission port 587.
Our mailserver is sometimes overloaded on port 25, so we want to use 
postscreen. But I don't understand, how Postfix works when it's 
stressed on port 587, when spammers connect to that opened port and 
want send their emails. In document 
http://www.postfix.org/STRESS_README.html there is:


NOTE: To avoid overload delays for end-user mail clients, enable the 
submission service entry in master.cf (present since Postfix 2.1), 
and tell users to connect to this instead of the public SMTP service.


Should this mean, that Postfix by default does not use counters like 
smtpd_hard_error_limit, smtpd_junk_command_limit and maybe others on 
sumission port? On this port I would prefer using some kind of smtp 
auth and this port should be world accessible to allow the clients 
using other networks to authenticate and send emails.




Port 587 is by default nothing special for Postfix because it is mostly 
a clone of the Port 25 service. The *intended* difference is that Port 
587 should only accept mail by authenticated users, so no chance for 
spammers if they don't own valid credentials. To actually see the 
difference between Port 25 and Port 587 settings you have to compare the 
entries in master.cf.


Regards

Andreas



OK, so there is a chance for spammers to overload the server using 
submission port 587 (the server says then service smtp (25) has
reached its process limit 200) by exhausting number of available ports 
and the MUA clients then can have also problems to send their

emails? I'm I right?


The number of available ports is a OS thing, Postfix can be configured in 
master.cf the not allow more than maxproc-column service processes *per 
service*. So if you have 200 maxproc for Port 25 and another 200 for Port 
587 your OS must be able to handle at least 400 connections (open ports, 
fds etc.). If 200 are reached at Port 25 Postfix will still accept up 
until 200 connections on Port 587, but refuses any further connections on 
Port 25.


According to the doc:
It works as follows. When a public network service such as the SMTP 
server runs into an all server ports are busy condition, the Postfix 
master(8) daemon logs a warning, restarts the service (without interrupting 
existing network sessions), and runs the service with -o stress=yes on 
the server process command line:


Just see all server ports are busy: what means the ports? Because I 
experieced the stress=yes at smtpd processes, when just 121 smtpd processes 
were running that time.




So if you have the default max of 100 smtp port 25 service process Postfix 
will restart the port 25 service with stress=yes to kick in more aggressive 
timeouts to faster free up processes. This has nothing todo with the service 
for port 587.


There is still one thing, that I don't understand: when exactly the 
postfix says that he is not stressed and restarts the processes with 
stress=no?
This is not done when less then default_process_limit smtpd processes are 
run, because I experienced on my system (default_process_limit = 200), 
that smtpd with stress=yes were run when there were just 121 smtpd's run 
in total. Strange?


If I'm, then I don't understand, why to split 
the processes into 

submission 587 and normal 25, because if the MUA client send the mail
through 25 (hope with postscreen), there is a chance that the 25 is not 
overloaded (because it uses postscreen) and he will be rather

able to send his email compared to 587.
Or I don't still understand something ... :-)


No, MUA should use Port 587 and *authentication*. Port 25 is for MTA --- 
MTA transfer *without* authentication. It does work to use Port 25 with 
MUA but it is not recommended these days. Postscreen is able to prevent 
some spammer connections to actually allocate one of this 200 port 25 
processes so the boundery is higher but still applies.


Andreas


Yes, I understand this well and know about it and this is what I want. But 
don't undrestand howto avoid overloading the server, when spammers will try 
to connect and send their mails to the port 587.
If the Postfix's behaviour on port 587 is the same as with 25, it seems to 
me to be better to let the MUAs to send their mail to 25. In the postscreen 
the mynetworks are automatically whitelisted and on 25 they have better 
chance to send their mails, because 25 should not be overloaded because of 
postscreen used.


Using firewall on 587 is useless, because our clients travel with their 
computers even around Europe and want to send their mails.


There is no benefit for spammers to direct to Port 587 if you only allow 
authenticated mail submission

Re: avoiding overload on port 587

[Tomas Macek]

On Fri, 30 Nov 2012, Robert Schetterer wrote:


Am 30.11.2012 12:50, schrieb Tomas Macek:

This is really interesting solution (!), hope I will be able also to
connect to the syslog's pipe and read the mesages. But I don't know how
right now, I still was not studiing this, but I believe, that this would
have much bigger performance! Thanks for the idea!


we will write a small blog about this soon



Looks great! Where? This will make my work much more easy! ;-)
Thanks!

Tomas

Re: avoiding overload on port 587

[Tomas Macek]

On Fri, 30 Nov 2012, Wietse Venema wrote:


Tomas Macek:

There is still one thing, that I don't understand: when exactly the
postfix says that he is not stressed and restarts the processes with
stress=no?
This is not done when less then default_process_limit smtpd processes are
run, because I experienced on my system (default_process_limit = 200),
that smtpd with stress=yes were run when there were just 121 smtpd's run
in total. Strange?


Strange, do you really expect Postfix to flip status immediately
when load drops under the limit, or do you expect it to behave in
a more rational manner and announce that peace has come when the
load has stayed under the limit for some minimal amount of time?


And what is the minimal amount of time? I'm still unable to find it, how 
much time that means.


Tomas

Re: avoiding overload on port 587

[Tomas Macek]

On Fri, 30 Nov 2012, lst_ho...@kwsoft.de wrote:



Zitat von Tomas Macek ma...@fortech.cz:


On Fri, 30 Nov 2012, lst_ho...@kwsoft.de wrote:



Zitat von Tomas Macek ma...@fortech.cz:


On Fri, 30 Nov 2012, lst_ho...@kwsoft.de wrote:



Zitat von Tomas Macek ma...@fortech.cz:

I don't understand now, how Postfix behaves when listenting on 
submission port 587.
Our mailserver is sometimes overloaded on port 25, so we want to use 
postscreen. But I don't understand, how Postfix works when it's 
stressed on port 587, when spammers connect to that opened port and 
want send their emails. In document 
http://www.postfix.org/STRESS_README.html there is:


NOTE: To avoid overload delays for end-user mail clients, enable the 
submission service entry in master.cf (present since Postfix 2.1), 
and tell users to connect to this instead of the public SMTP service.


Should this mean, that Postfix by default does not use counters like 
smtpd_hard_error_limit, smtpd_junk_command_limit and maybe others on 
sumission port? On this port I would prefer using some kind of smtp 
auth and this port should be world accessible to allow the clients 
using other networks to authenticate and send emails.




Port 587 is by default nothing special for Postfix because it is mostly 
a clone of the Port 25 service. The *intended* difference is that Port 
587 should only accept mail by authenticated users, so no chance for 
spammers if they don't own valid credentials. To actually see the 
difference between Port 25 and Port 587 settings you have to compare the 
entries in master.cf.


Regards

Andreas



OK, so I spent some time reading config params in doc and topics in 
various forums and decided to setup my submission port 587 like this:


submission inet n   -   n   -   -   smtpd
-o smtpd_etrn_restrictions=reject
-o smtpd_sasl_auth_enable=yes
-o 
smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject

I decided not to use the smtpd_sasl_exceptions_networks = $mynetworks, 
because I experienced, that Opera M2 mail client sends the auth 
credentials even if none auth is offered by the mail server... don't know 
why, but maybe there is still some other mail client with this strange 
behaviour...


Do you agree with this setup? Any further recomendations?

Tomas

spaces when using -o in master.cf

[Tomas Macek]

I have line like this

smtpd_client_restrictions = check_policy_service inet:127.0.0.1:24575, ...

in my main.cf

I would like the $smtpd_client_restrictions to override in master.cf, 
something like:


submission inet n  -   n   -   -   smtpd
	-o smtpd_client_restrictions=check_policy_service 
inet:127.0.0.1:24575


but the space between check_policy_service and inet is a problem.

How can I write this (if it's possible generally)? I know, that the doc 
says, the spaces are not allowed but maybe there is a way...


Regards, Tomas

Re: spaces when using -o in master.cf

[Tomas Macek]

On Mon, 3 Dec 2012, Reindl Harald wrote:




Am 03.12.2012 14:42, schrieb Tomas Macek:

I have line like this

smtpd_client_restrictions = check_policy_service inet:127.0.0.1:24575, ...

in my main.cf

I would like the $smtpd_client_restrictions to override in master.cf, something 
like:

submission inet n  -   n   -   -   smtpd
-o smtpd_client_restrictions=check_policy_service inet:127.0.0.1:24575

but the space between check_policy_service and inet is a problem.

How can I write this (if it's possible generally)? I know, that the doc says, 
the spaces are not allowed but maybe
there is a way...


main.cf
whatever_smtpd_client_restrictions = check_policy_service inet:127.0.0.1:24575

master.cf:
-o smtpd_client_restrictions=$whatever_smtpd_client_restrictions


Thanks, this seems to be also the solution.

But according to the http://marc.info/?l=postfix-usersm=108075412814545 
(found after really long time) the , (comma) did the job:


-o smtpd_client_restrictions=check_policy_service,inet:127.0.0.1:24575

How this can work?? :-o

Tomas

Re: avoiding overload on port 587

[Tomas Macek]

2) why would you setup a submission service that doesn't require auth
from MUAs?


It's because they never had to. It is 
a 
historical problem. Now we have thousands of customers, that never had to 
authenticate, so there is no power to force them to do it now.


These days I'm spending the time by splitting the server into port 25 
(MTA connections) and 587 (MUA connections) - just see my previous 
posts, and can do NOTHING with the 
clients, that never autenticated. I can send them email, to please them, 
and then force 
the authentication on port 587, but I'm pretty sure, that thousands of 
them 
will not reflect the email and they will call here and complain about 
functionality of the email service - this is common for end users 
these days. And after that, I will lose my job... :-) And many of them are 
also unable to reconfigure their Outlooks.


So the result at submission port must be something like this:

submission inet n  -   n   -   -   smtpd
-o smtpd_etrn_restrictions=reject
-o smtpd_sasl_auth_enable=yes
-o content_filter=
-o receive_override_options=no_header_body_checks
-o 
smtpd_client_restrictions=check_policy_service,inet:127.0.0.1:24575,permit_mynetworks,permit_sasl_authenticated,reject


Tomas

Re: avoiding overload on port 587

[Tomas Macek]

On Tue, 4 Dec 2012, Reindl Harald wrote:




Am 04.12.2012 07:58, schrieb Tomas Macek:



2) why would you setup a submission service that doesn't require auth
from MUAs?


It's because they never had to. It is a historical problem. Now we have 
thousands of customers, that never had to
authenticate, so there is no power to force them to do it now.


than you have lost any game


Still hope I didn't. My roadmap:
1) split 25 and 587 with permit_mynetworks on 587 and thus allow the 
people without auth to send their email to 587


2) by means of prerouting rule of iptables redirect sending emails from 
$mynetworks to 587


3) the rest of the users are the ones, that travel with their notebooks 
around country and change providers and they will have to reconfigure 
their computers. There is no other chance. These are dozens.


Tomas

Re: avoiding overload on port 587

[Tomas Macek]

On Tue, 4 Dec 2012, Robert Schetterer wrote:


Am 04.12.2012 08:20, schrieb Tomas Macek:

On Tue, 4 Dec 2012, Reindl Harald wrote:




Am 04.12.2012 07:58, schrieb Tomas Macek:



2) why would you setup a submission service that doesn't require auth
from MUAs?


It's because they never had to. It is a historical problem. Now we
have thousands of customers, that never had to
authenticate, so there is no power to force them to do it now.


than you have lost any game


Still hope I didn't. My roadmap:
1) split 25 and 587 with permit_mynetworks on 587 and thus allow the
people without auth to send their email to 587





2) by means of prerouting rule of iptables redirect sending emails from
$mynetworks to 587


dont do that, makes no sense


Everyone here says me, that MUAs should send their mails through 587. I 
can't do that without iptables, because all the people here have Outlook 
Expresses setup with port 25 for sending emails from default 
configuration.


Tomas

prevent server from receiving mail for root@localhost

[Tomas Macek]

Hello, I'm trying to prevent my testing postfix installation 2.8.4 from 
being 
abused by emails that will go to the root@localhost email address. 
I found out that it receives these messages accindetally, when I 
tested my configuration.
The root@localhost must be accessible, when the mail comes from localhost 
machine and not be accessible from the rest of the world - that's clear. 
My server will receive email from many virtual domains.


I believe the right cfg place is smtpd_recipient_restrictions where I have 
this:


smtpd_recipient_restrictions = permit_mynetworks,
   check_recipient_access 
hash:/etc/postfix/block_localhost,

   permit_sasl_authenticated,
   permit_auth_destination,
   reject

block_localhost:
--
root@localhost REJECT
root@localhost.mydomain REJECT

mynetworks = x.x.x.x/x x.x.x.x/x x.x.x.x/x 127.0.0.1 10.0.0.0/22

According to the debug of the smtpd process, the restriction in 
block_localhost file does not match the root@localhost key, but it matches 
the root@localhost.$mydomain. This must be (doc says) because it's after 
the rewrite process.



Questions:
---
1) is the smtpd_recipient_restrictions right place for such a restriction? 
Any other documents I should read? (already tried google, 
http://ubuntuforums.org/showthread.php?t=2250363, 
http://archive.groovy.net/z-portal/postfix/faq.html#some_local, ...)


2) when I came from outside world, the restriction worked:
...
250 DSN
mail from: root@localhost
250 2.1.0 Ok
rcpt to: root@localhost
554 5.7.1 root@localhost: Recipient address rejected: Access denied


but when I came from 127.0.0.1, the mail was received - why exactly? But 
this is the behaviour I expected and wanted - that's OK. But I'm afraid of 
some misunderstanding of something...


mail from: root@localhost
250 2.1.0 Ok
rcpt to: root@localhost
250 2.1.5 Ok

3) do I have a chance to place the restriction table before the rewrite 
process, so it would match the original root@localhost address? Where/how?


Thank you
Best regards, Tomas

Re: prevent server from receiving mail for root@localhost

[Tomas Macek]

Tomas Macek:

Hello, I'm trying to prevent my testing postfix installation 2.8.4 from
being
abused by emails that will go to the root@localhost email address.
I found out that it receives these messages accindetally, when I
tested my configuration.
The root@localhost must be accessible, when the mail comes from localhost
machine and not be accessible from the rest of the world - that's clear.
My server will receive email from many virtual domains.

I believe the right cfg place is smtpd_recipient_restrictions where I have
this:

smtpd_recipient_restrictions = permit_mynetworks,
check_recipient_access


This allows all mail from local networks.

http://www.postfix.org/postconf.5.html#permit_mynetworks
http://www.postfix.org/postconf.5.html#mynetworks


2) when I came from outside world, the restriction worked:
but when I came from 127.0.0.1, the mail was received - why exactly? But


Because of permit_mynetworks/mynetworks.

Wietse



Many thanks to all of you guys!

But I have still one question...

What about if I'd would prefer to receive the mail for root@localhost from 
just localhost and not from other places? = not from the rest of 
mynetworks, not from outside of mynetworks - does this have any sense to 
setup such a configuration? Is there any possibility to have sucha a 
configuration?


Tomas

Re: prevent server from receiving mail for root@localhost

[Tomas Macek]

On Tue, 23 Dec 2014, li...@rhsoft.net wrote:



Am 23.12.2014 um 15:03 schrieb Tomas Macek:

  Tomas Macek:
   Hello, I'm trying to prevent my testing postfix installation 2.8.4 
   from

   being
   abused by emails that will go to the root@localhost email address.
   I found out that it receives these messages accindetally, when I
   tested my configuration.
   The root@localhost must be accessible, when the mail comes from
   localhost
   machine and not be accessible from the rest of the world - that's 
   clear.

   My server will receive email from many virtual domains.
  
   I believe the right cfg place is smtpd_recipient_restrictions where I

   have
   this:
  
   smtpd_recipient_restrictions = permit_mynetworks,

   check_recipient_access
 
  This allows all mail from local networks.
 
 http: //www.postfix.org/postconf.5.html#permit_mynetworks

 http: //www.postfix.org/postconf.5.html#mynetworks
 
   2) when I came from outside world, the restriction worked:
   but when I came from 127.0.0.1, the mail was received - why exactly? 
   But
 
  Because of permit_mynetworks/mynetworks.


 Many thanks to all of you guys!

 But I have still one question...

 What about if I'd would prefer to receive the mail for root@localhost
 from just localhost and not from other places? = not from the rest of
 mynetworks, not from outside of mynetworks - does this have any sense to
 setup such a configuration? Is there any possibility to have sucha a
 configuration?


it *may* make sense but is questionable and may lead in more complex setups 
than one wants if it comes to troubleshooting or a new tech stuff needs to 
understand the setups


that's one reason why we *strictly? split inbound MX on a own machine doing 
all the filtering and hand over clean messages via SMTP to the real 
mailserver


in that case you can have there completly different rules and blacklist all 
sorts of internal addresses because you know that mailflow comes from the 
outside - there also you can apply a large amount of HELO/PTR rules, RBLs, 
SPF and what not else because you can expect only MTA's try to deliver mail 
and any sign of a ordianry mail-client is a clear reject (a MUA has to use 
his submission server, if not it's mostly a botnet zombie deliver 
spam/malware)


that way you can have different rules for mynetworks as well as forbid own 
domains as envelope while mail from the submission server relays to the 
outside world and store messages for your own domains without touch the MX




Thank you for the explanation. I will stay at the standard cfg what was 
mentioned before.


Mary Christmas to everyone!
Tomas

Re: please for submission port cfg review

[Tomas Macek]

On Fri, 4 Sep 2015, Viktor Dukhovni wrote:


On Fri, Sep 04, 2015 at 09:44:50AM +0200, Tomas Macek wrote:


Here is the result cfg:

submission inet n  -   n   -   -   smtpd
-o smtpd_etrn_restrictions=reject
-o smtpd_sasl_auth_enable=yes
-o content_filter=smtp-amavis:[127.0.0.1]:10024
-o syslog_name=submission
-o receive_override_options=no_header_body_checks
-o smtpd_tls_security_level=may


Why "may", rather than "encrypt"?


Oops, that settings was there because of testing. I'm sometimes putting 
the smtp commands to the telnet cmd line. This will be changed for sure.



-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o 
smtpd_recipient_restrictions=check_recipient_access,hash:/etc/postfix/block_localhost,check_policy_service,inet:127.0.0.1:24575,permit_mynetworks,permit_sasl_authenticated,reject


Why not set this to "$mua_recipient_restrictions", and define the
latter in main.cf?


Fine, thanks, I'll change it.


The "check_policy_service,inet:127.0.0.1:24575" is per client IP counter,
that counts how many emails were sent by particular IP address in last X
seconds. It sometimes helps to report misused client and/or password and
some other things. Maybe this should be added rather to the
smtpd_client_restrictions?


Client IPs are not so interesting in botnets, much better to
aggregate by SASL login name (and rate limit potentially compromised
accounts).



OK, thanks, I'll think about it.

Thank you for help!
Tomas

Re: please for submission port cfg review

[Tomas Macek]

On Fri, 4 Sep 2015, Tomas Macek wrote:


On Fri, 4 Sep 2015, Viktor Dukhovni wrote:


 On Fri, Sep 04, 2015 at 09:44:50AM +0200, Tomas Macek wrote:

>  Here is the result cfg:
> 
>  submission inet n  -   n   -   -   smtpd

>  -o smtpd_etrn_restrictions=reject
>  -o smtpd_sasl_auth_enable=yes
>  -o content_filter=smtp-amavis:[127.0.0.1]:10024
>  -o syslog_name=submission
>  -o receive_override_options=no_header_body_checks
>  -o smtpd_tls_security_level=may

 Why "may", rather than "encrypt"?


Oops, that settings was there because of testing. I'm sometimes putting the 
smtp commands to the telnet cmd line. This will be changed for sure.



>  -o smtpd_client_restrictions=
>  -o smtpd_helo_restrictions=
>  -o smtpd_sender_restrictions=
>  -o 
>  smtpd_recipient_restrictions=check_recipient_access,hash:/etc/postfix/block_localhost,check_policy_service,inet:127.0.0.1:24575,permit_mynetworks,permit_sasl_authenticated,reject


 Why not set this to "$mua_recipient_restrictions", and define the
 latter in main.cf?


Fine, thanks, I'll change it.

>  The "check_policy_service,inet:127.0.0.1:24575" is per client IP 
>  counter,

>  that counts how many emails were sent by particular IP address in last X
>  seconds. It sometimes helps to report misused client and/or password and
>  some other things. Maybe this should be added rather to the
>  smtpd_client_restrictions?

 Client IPs are not so interesting in botnets, much better to
 aggregate by SASL login name (and rate limit potentially compromised
 accounts).



OK, thanks, I'll think about it.

Thank you for help!
Tomas


Hi, now I'm using above configuration and I'm trying to setup better the
smtpd_sender_restrictions option. I tried it already with this:

-o smtpd_sender_restrictions=reject

or like this:

-o smtpd_sender_restrictions=reject_unknown_sender_domain

which should according to documentation  mean, that when someone puts bad 
MAIL FROM domain part, it's rejected. But on my system it isn't, but I 
can't see why.


The first example should reject any mail after any "mail from:", the
second should reject mail from any bogus domain. In both cases my system
says "250 2.1.0 Ok" like when the smtpd_sender_restrictions option was
skipped.

Does anyone has any ideas?

Regards, Tomas

Re: please for submission port cfg review

[Tomas Macek]

On Thu, Sep 03, 2015 at 03:05:07PM +0200, Tomas Macek wrote:


submission inet n  -   n   -   -   smtpd
-o smtpd_etrn_restrictions=reject
-o smtpd_sasl_auth_enable=yes
-o content_filter=smtp-amavis:[127.0.0.1]:10024
-o syslog_name=submission
-o receive_override_options=no_header_body_checks
-o smtpd_tls_security_level=encrypt
-o smtpd_tls_loglevel=1
-o smtpd_timeout=${stress?10}${stress:30}
-o smtpd_junk_command_limit=${stress?2}${stress:20}
-o smtpd_soft_error_limit=${stress?5}${stress:5}
-o smtpd_hard_error_limit=${stress?7}${stress:7}
-o smtpd_starttls_timeout=${stress?7}${stress:60}
-o address_verify_poll_count=${stress?1}${stress:3}
-o 



smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,permit_auth_destination,reject


You mistake is overriding "smtpd_client_restrictions", you should
override "smtpd_recipient_restrictions", which is where anti-relay
control is implemented in Postfix.  Also you SHOULD NOT include
'permit_auth_destination' on the submission port.  Whether amavis
is appropriate for submission is your call (I see you've disabled header
and body checks).

 -o smtpd_client_restrictions=
 -o smtpd_helo_restrictions=
 -o smtpd_sender_restrictions=
 -o 


smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject

 -o smtpd_data_restrictions=
 -o smtpd_end_of_data_restrictions=
 # Uncomment For Postfix 2.10 or later
 # -o smtpd_relay_restrictions=

The stock master.cf file distributed with Postfix source contains:

   #submission inet n   -   n   -   -   smtpd
   #  -o syslog_name=postfix/submission
   #  -o smtpd_tls_security_level=encrypt
   #  -o smtpd_sasl_auth_enable=yes
   #  -o smtpd_reject_unlisted_recipient=no
   #  -o smtpd_client_restrictions=$mua_client_restrictions
   #  -o smtpd_helo_restrictions=$mua_helo_restrictions
   #  -o smtpd_sender_restrictions=$mua_sender_restrictions
   #  -o smtpd_recipient_restrictions=
   #  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
   #  -o milter_macro_daemon_name=ORIGINATING

That's usually the best starting point for further customization.
Note that this uses indirection via "mua_*_restrictions" to leave
the actual definitions up to main.cf, and should perhaps do likewise
for "data" and "end_of_data" restrictions.  Because this is taken
from Postfix 3.1 (snapshot) it uses "relay" rather than "recipient"
restrictions.


You might find similar commented-out content in 
$daemon_directory/master.cf

for your Postfix version.



--
Viktor.


I appologize myself, that I'm not following the original thread, because I 
accidentaly removed the original message. I'm sorry.


Here is the result cfg:

submission inet n  -   n   -   -   smtpd
-o smtpd_etrn_restrictions=reject
-o smtpd_sasl_auth_enable=yes
-o content_filter=smtp-amavis:[127.0.0.1]:10024
-o syslog_name=submission
-o receive_override_options=no_header_body_checks
-o smtpd_tls_security_level=may
-o smtpd_tls_loglevel=1
-o smtpd_timeout=${stress?10}${stress:30}
-o smtpd_junk_command_limit=${stress?2}${stress:20}
-o smtpd_soft_error_limit=${stress?5}${stress:5}
-o smtpd_hard_error_limit=${stress?7}${stress:7}
-o smtpd_starttls_timeout=${stress?7}${stress:60}
-o address_verify_poll_count=${stress?1}${stress:3}
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o 
smtpd_recipient_restrictions=check_recipient_access,hash:/etc/postfix/block_localhost,check_policy_service,inet:127.0.0.1:24575,permit_mynetworks,permit_sasl_authenticated,reject

-o smtpd_data_restrictions=
-o smtpd_end_of_data_restrictions=

Hope this is much better, but still any comments appreciated!

I still left the Amavis check, if I remove it, I will remove the 
"content_filter" and "receive_override_options=no_header_body_checks".
This allows the Amavis to see the message untouched as it came to the 
system.


I added the "check_recipient_access,hash:/etc/postfix/block_localhost" - 
this contains access table that should prevent anyone from mailing to 
root@localhost and some other similar destinations. Some strange clients 
do it.


The "check_policy_service,inet:127.0.0.1:24575" is per client IP counter, 
that counts how many emails were sent by particular IP address in last X 
seconds. It sometimes helps to report misused client and/or password 
and some other things. Maybe this should be added rather to the 
smtpd_client_restrictions?


Many thanks, Tomas

please for submission port cfg review

[Tomas Macek]

Hi, I'm using Postfix 2.8.x and trying to configure properly the 
submission port 587 in our very new Postfix installation.
I tried to read the doc and 
the result is below. The submission port should be used by clients 
from both inside and outside of $mynetworks, so it will be exposed to the 
rest of the world (spammers, ...). Hope it's a normal idea.
I tried to configure it very restrictive and I'd like to try to kick off 
the spammers from the server as soon as possible to avoid stressing the 
mailserver, but still allow our normal clients (Thunderbirds, Outloooks) 
to send the email. I 
don't have so much experiences in this manner, so I don't know for example 
if the smtpd_tls_security_level=encrypt is valuable or not - if it makes 
the spammer's lifes more difficult (that was the goal of this settings). 
I'm also 
unsure if the Amavis check is valuable or not - I'm about to remove it. 
The next thing I'm unsure is how this restrictive settings will affect the 
clients with mobile phone 2G-mobile/edge slow connections.
Sending emails to root@* and *@localhost* is restricted in the global cfg 
of the main.cf file.


I know, that at least in some of the options I'm breaking the rules 
(smtpd_timeout for example), but according to doc it should work and it's 
necessary for me to find a suitable settings.


Please for any comments, suggestions etc.

Best regards, Tomas



submission inet n  -   n   -   -   smtpd
-o smtpd_etrn_restrictions=reject
-o smtpd_sasl_auth_enable=yes
-o content_filter=smtp-amavis:[127.0.0.1]:10024
-o syslog_name=submission
-o receive_override_options=no_header_body_checks
-o smtpd_tls_security_level=encrypt
-o smtpd_tls_loglevel=1
-o smtpd_timeout=${stress?10}${stress:30}
-o smtpd_junk_command_limit=${stress?2}${stress:20}
-o smtpd_soft_error_limit=${stress?5}${stress:5}
-o smtpd_hard_error_limit=${stress?7}${stress:7}
-o smtpd_starttls_timeout=${stress?7}${stress:60}
-o address_verify_poll_count=${stress?1}${stress:3}
-o 
smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,permit_auth_destination,reject

Re: Restricting the scope of "success" notifications

[Tomas Macek]

On Mon, 31 Jul 2017, Matus UHLAR - fantomas wrote:


On 31.07.17 09:16, Tomas Macek wrote:
Hello, our system is sometimes under attack of spammers using 
"NOTIFY=SUCCESS" param in "rcpt to: " header. And because of a random 
From address, the DSN message obviously goes to an nonexistent server 
or user.


I've read the "Restricting the scope of "success" notifications" topic at 
http://www.postfix.org/DSN_README.html#scope and I'd like to ask you about 
some details:


1) if I turn off the DSN for the networks outside of $mynetwork, do I 
understand it well, that we will not send them (to the outside world) any 
more DSNs with "user over quota" or "access denied"?

We won't be sending anything probably in that case, just asking to be sure.


Correct. DSN at SMTP level means that you take care of sending DSNs, missing
DSN will cause sender to issue DSNs by themselves.
Therefore your server will only send DSNs the old way - if it fails to
deliver message (or if the delay crosses delay_warning_time)

2) how much is it normal to turn off the DSN for outside world? What is 
your settings?


seems it will become much more common now, since many servers receive spam
of that kind.

I am trying to prevent notifications to messages considered spam but that

needs support from spam filter.  You can send NOTIFY= to filter over LMTP,
where filter would pass it back to postfix (over LMTP again).

If filter was able to strip NOTIFY=, we'd have fine control over when to
send notifications...

1. I don't know how effective would this be. Maybe we'd need to disable
notifies at all.

2. seems that postfix 2.9 doesn't send NOTIFY=SUCCESS to LMTP filter, but
   sends notify imediately. 2.11 does not have this problem.
   see http://marc.info/?l=postfix-users=150107262526121=2


Thanks!
And what about to use a before-queue Milter? May it be helpful?
According to doc http://www.postfix.org/MILTER_README.html#limitations 
there is supposed to be a limitation if we use before-queue filters 
only and I don't have any.


The doc says:
---
When you use the before-queue content filter for incoming SMTP mail (see 
SMTPD_PROXY_README), Milter applications have access only to the SMTP 
command information; they have no access to the message header or body, 
and cannot make modifications to the message or to the envelope.

---

Is Milter able in that case modify headers?

Tomas

NOTIFY=SUCCESS in Milter

[Tomas Macek]

Hello,
I'm trying to get to know, if there is a chance to see in Milter, that the 
"NOTIFY=xxx,yyy,zzz" was specified by a client at rcpt to command like 
this:



RCPT TO: NOTIFY=SUCCESS,FAILURE,DELAY

If there is a chance, where I should find it? Is it supposed to be to seen 
in some of those params available in a "envelope recipient filter" 
function?


Still none of those macro params has given me the NOTIFY param, I 
can see just the recipient address.


Best regards
Tomas

Restricting the scope of "success" notifications

[Tomas Macek]

Hello, our system is sometimes under attack of spammers using 
"NOTIFY=SUCCESS" param in "rcpt to: " header. And because of a random From 
address, the DSN message obviously goes to an nonexistent server 
or user.


I've read the "Restricting the scope of "success" notifications" topic at 
http://www.postfix.org/DSN_README.html#scope and I'd like to ask you about 
some details:


1) if I turn off the DSN for the networks outside of $mynetwork, do I 
understand it well, that we will not send them (to the outside world) any 
more DSNs with "user over quota" or "access denied"?
We won't be sending anything probably in that case, just asking to be 
sure.


2) how much is it normal to turn off the DSN for outside world? What is 
your settings?


Regards
Tomas

Re: NOTIFY=SUCCESS in Milter

[Tomas Macek]

On Mon, 7 Aug 2017, Matus UHLAR - fantomas wrote:


On Thu, 3 Aug 2017, Matus UHLAR - fantomas wrote:
> just for curiosity: under what circumstances are you going to drop NOTIFY
> parameters?
> because, postfix can do this per sending IP


On 07.08.17 11:27, Tomas Macek wrote:
Yes, I have found it out too. I wanted to create a Milter removing just the 
SUCCESS and/or DELAY and keeping just the FAILURE.


this is the default when there'd no NOTIFY= command.
There's no need modifying NOTIFY=, disabling DSN in the smtpd helo reply
does just the same.


And is it also Postfix's behaviour when it does not advertise the DSN on 
ehlo request?


Tomas

Re: NOTIFY=SUCCESS in Milter

[Tomas Macek]

On Thu, 3 Aug 2017, A. Schulze wrote:




Am 03.08.2017 um 07:32 schrieb Tomas Macek:


I'm trying to get to know, if there is a chance to see in Milter that the 
"NOTIFY=xxx,yyy,zzz" was specified by a client at rcpt to command


Hello Tomas,

from the milter API Doku:

xxfi_envrcpt:
 ctxOpaque context structure.
 argv   Null-terminated SMTP command arguments; argv[0] is guaranteed to be the 
recipient address. Later arguments are the ESMTP arguments.

The "Later arguments are the ESMTP arguments" is your "hope" ...
but I never tested/used that.

Andreas



Hello Andreas,

you are right!

This is a relevant piece from my log:

mlfi_envrcpt: argv[0] = <m...@address.cz>, argv[1] = 
NOTIFY=SUCCESS,FAILURE,DELAY

So I'm writing a Milter to tackle the spammers my own way!

Thank you!

Tomas

Re: NOTIFY=SUCCESS in Milter

[Tomas Macek]

On Thu, 3 Aug 2017, Matus UHLAR - fantomas wrote:


> Am 03.08.2017 um 07:32 schrieb Tomas Macek:
> > I'm trying to get to know, if there is a chance to see in Milter that 
> > the "NOTIFY=xxx,yyy,zzz" was specified by a client at rcpt to command



On Thu, 3 Aug 2017, A. Schulze wrote:
> from the milter API Doku:
> 
> xxfi_envrcpt:

>  ctx   Opaque context structure.
>  argv 	Null-terminated SMTP command arguments; argv[0] is guaranteed 
>  to be the recipient address. Later arguments are the ESMTP arguments.
> 
> The "Later arguments are the ESMTP arguments" is your "hope" ...

> but I never tested/used that.


On 03.08.17 14:09, Tomas Macek wrote:

This is a relevant piece from my log:

 mlfi_envrcpt: argv[0] = <m...@address.cz>, argv[1] =
 NOTIFY=SUCCESS,FAILURE,DELAY

So I'm writing a Milter to tackle the spammers my own way!


just for curiosity: under what circumstances are you going to drop NOTIFY
parameters?
because, postfix can do this per sending IP


Yes, I have found it out too. I wanted to create a Milter removing just 
the SUCCESS and/or DELAY and keeping just the FAILURE.



I'd prefer patch to amavisd-milter if possible ;-)


I'd rather create a new program, I don't like keep up-to-date patches.

Tomas

virtual domain alias & check_recipient_access

[Tomas Macek]

Hello, I need to redirect all the email coming to one domain to another 
like this:


@alias-domain.com -> @real-domain.com

which means when a mail is coming to my.n...@alias-domain.com, it's first 
translated to my.n...@real-domain.com and later delivered to the mailbox.


I have found this in the virtual(5) doc:

-
@domain address, address, ...
...
  Note:  @domain is a wild-card. With this form, the Postfix SMTP
  server accepts mail for any recipient in domain, regardless of
  whether that recipient exists.  This may turn your mail system
  into a backscatter source:  Postfix first accepts mail for
  non-existent recipients and then tries to return that mail as
  "undeliverable" to the often forged sender address.

  To avoid backscatter with mail for a wild-card domain, replace
  the wild-card mapping with explicit 1:1 mappings, or add a
  reject_unverified_recipient restriction for that domain:

  smtpd_recipient_restrictions =
  ...
  reject_unauth_destination
  check_recipient_access
  inline:{example.com=reject_unverified_recipient}
  unverified_recipient_reject_code = 550

  In the above example, Postfix may contact a remote server if the
  recipient is aliased to a remote address.
-

I'd like to go the way with the "check_recipient_access" option, but don't 
know how to do it with databased map:


smtpd_recipient_restrictions =
...
reject_unauth_destination
check_recipient_access pgsql:map_file ?
unverified_recipient_reject_code = 550

What is the correct settings instead of those "?" please? Any hint?

Thanks, Tomas

Re: virtual domain alias & check_recipient_access

[Tomas Macek]

On Fri, 21 Dec 2018, Wietse Venema wrote:


Tomas Macek:

   smtpd_recipient_restrictions =
   ...
   reject_unauth_destination
   check_recipient_access
   inline:{example.com=reject_unverified_recipient}
   unverified_recipient_reject_code = 550

   In the above example, Postfix may contact a remote server if the
   recipient is aliased to a remote address.
-

I'd like to go the way with the "check_recipient_access" option, but don't
know how to do it with databased map:

smtpd_recipient_restrictions =
...
reject_unauth_destination
check_recipient_access pgsql:map_file ?
unverified_recipient_reject_code = 550

What is the correct settings instead of those "?" please? Any hint?


Use inline for reject_unverified_recipient, and use pgsql:map_file
for other things.

smtpd_recipient_restrictions =
   ...
   reject_unauth_destination
   check_recipient_access inline:{example.com=reject_unverified_recipient}
   check_recipient_access pgsql:map_file
unverified_recipient_reject_code = 550


I filled in my alias domain name instead of the "example.com", but the 
system still accepts mail to "nonexist...@alias-domain.com". The 
example.com in the example above should be the destination or the alias 
domain? Or is that a misunderstanding of the system from me?


Tomas