Re: avoiding overload on port 587
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 smime.p7s Description: S/MIME Cryptographic Signature
Re: avoiding overload on port 587
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
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. 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. Regards Andreas smime.p7s Description: S/MIME Cryptographic Signature
Re: avoiding overload on port 587
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 Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
Re: avoiding overload on port 587
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
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 Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
Re: avoiding overload on port 587
* 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! -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
Re: avoiding overload on port 587
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
Am 30.11.2012 11:52, schrieb Tomas Macek: 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. please reread the doku why and how using submission as its used with auth only, no spammer will ever deliver mail unless he has a valid auth via submission, most attacks running against submission are brute force attacks ,try finding user and auth accouts combination to hack in for brute force fail2ban or simular is good enough, process limits or mail send limits are managed by other stuff i.e postfix parameters and/or policy servers Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
Re: avoiding overload on port 587
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
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 so i wrote a mail syslog parser script reading direct from a syslog pipe grep and echo bot ip in i.e recent iptables modul you may do like this with brute force ips too Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
Re: avoiding overload on port 587
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. 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 at that port as you should and there is no widely used here is my submission port announcement as it is with port 25 per MX records in DNS. Port 587 has independant settings and limits and is *not* tied to port 25 settings. It is possible that port 587 resources are also tied up because of dictionary attack or DoS but this can be tackled by limiting connections per client and maybe
Re: send specified email to a public folder.
On Thu, Nov 29, 2012 at 6:42 PM, Noel Jones njo...@megan.vbhcs.org wrote: On 11/29/2012 6:18 AM, Muhammad Yousuf Khan wrote: i created a public namespace in dovecot on root (/public) there are two folders inside public. /public/HR and /public/News i want, when only HR send email to hr.annou...@mydomain.com it will deliver to the /public/HR when other users try to send email to hr.annou...@mydomain.com their access must denied. To control in postfix what users can send to what address, see the examples here: http://www.postfix.org/RESTRICTION_CLASS_README.html Thanks, Very helpful for further studies. To deliver mail to a specific folder, see the dovecot list. -- Noel Jones
Re: avoiding overload on port 587
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
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 Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
Re: avoiding overload on port 587
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 at that
Re: avoiding overload on port 587
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: 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? Wietse
Re: avoiding overload on port 587
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: 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? http://www.postfix.org/STRESS_README.html 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
Re: avoiding overload on port 587
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
Outbound auth
I have the following smtpd entry in master.cf smtp inet n - n - - smtpd -o content_filter=lmtp:unix:/tmp/dspam.sock -o relay_recipient_maps=hash:/etc/postfix/relay_recipients What settings would I need to add to requre authentication for outbound email and no authentication for inbound email? Thanks in advance
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. This is part of the common-sense safety engineering that has gone into building Postfix. I don't think it is reasonable to expect that all those details are spelled out in documentation. The interested reader can explore the source code. Unlike the behavior that is promised in the Postfix documentation, I am at liberty to change internals. In the rare case that this changes the documented behavior, then I provide an elaborate safety net so that the change will not break existing configurations. You're welcome to explore Postfix internals, but there are no guarantees that what you see will be there in the next release. If your configuration depends on the exact details of Postfix internals, then your configuration will break without prior warning. No safety nets will be provided for changes in internals. Wietse
alias_maps are not being read correctly
I am setup a 2.6.6 server with virtual domains and the entries in an alias_maps file (/etc/postfix/aliases) which look like this: localuser :include:/etc/postfix/massmail/localuser localuser2 :include:/etc/postfix/massmail/localuser2 When trying to deliver to the users (echo test | mail -s test localuser) I get the error: postfix/virtual[7904]: 2E4381F2D: to=localu...@domain.tld, relay=virtual, delay=0.05, delays=0.03/0.01/0/0.02, dsn=5.1.1, status=bounced (unknown user: localu...@domain.tld) postfix/virtual[7904]: 2E4381F2D: to=localus...@domain.tld, relay=virtual, delay=0.05, delays=0.03/0.01/0/0.02, dsn=5.1.1, status=bounced (unknown user: localus...@domain.tld) It appears that the alias_maps files are not even being read, not sure what I am missing? postconf -n alias_database = hash:/etc/aliases, hash:/etc/postfix/aliases alias_maps = hash:/etc/aliases, hash:/etc/postfix/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 html_directory = no inet_interfaces = x.x.x.x inet_protocols = all mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydomain = wwt.net myhostname = mail-1.wwt.net myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES relayhost = omrcd1.parcel-airstreamcomm.net sample_directory = /usr/share/doc/postfix-2.6.6/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop unknown_local_recipient_reject_code = 550 virtual_alias_maps = mysql:/etc/postfix/virtual.aliases.cf, mysql:/etc/postfix/virtual.aliases.mutli.cf virtual_gid_maps = mysql:/etc/postfix/virtual.gids.cf virtual_mailbox_base = /mail virtual_mailbox_domains = mysql:/etc/postfix/virtual.domains.cf virtual_mailbox_maps = mysql:/etc/postfix/virtual.users.cf virtual_minimum_uid = 10 virtual_uid_maps = mysql:/etc/postfix/virtual.uids.cf
Re: alias_maps are not being read correctly
l...@airstreamcomm.net: I am setup a 2.6.6 server with virtual domains and the entries in an alias_maps file (/etc/postfix/aliases) which look like this: localuser :include:/etc/postfix/massmail/localuser localuser2 :include:/etc/postfix/massmail/localuser2 As documented this format is supported in ALIAS_MAPS not VIRTUAL_ALIAS_MAPS Wietse
Re: alias_maps are not being read correctly
On 11/30/12 10:22 AM, Wietse Venema wrote: l...@airstreamcomm.net: I am setup a 2.6.6 server with virtual domains and the entries in an alias_maps file (/etc/postfix/aliases) which look like this: localuser :include:/etc/postfix/massmail/localuser localuser2 :include:/etc/postfix/massmail/localuser2 As documented this format is supported in ALIAS_MAPS not VIRTUAL_ALIAS_MAPS Wietse Understood, however I am wondering why the alias_maps are not working in my instance as it appears as if they are not being used at all. I am not sure if this is a symptom of my configuration, or the intended functionality. In my configuration is have: alias_database = hash:/etc/aliases, hash:/etc/postfix/aliases alias_maps = hash:/etc/aliases, hash:/etc/postfix/aliases Either of these maps appear to be recognized?
Re: make error - ATTENTION: Unknown system type: FreeBSD 9.0-RELEASE
Wow...thank you Wietse! I *think* I know how to apply this, but can someone confirm this for me - I think I can just copy and paste your code into a file, name it, and then: patch –p0 /path/to/patch/patch_name.patch Right so far? What file am I applying the patch to? The makedefs file, right? I have to execute the patch command from within the same directory that the makedefs file is also in, right? Ed
automatically modified email name when sent
Hi: I thought I would try it on the Postfix group see if I can get a solution to the problem. When I released the email from the quarantined list in Dspam, the email name would change to something else. In my case, it was supposed to be cha...@mydomain.com--and it changed to hq??g...@mydomain.com. Therefore it gave me an bounced status for unknown user. Any suggestions how should I correct this? Thanks! Nov 29 16:56:51 mail postfix/qmgr[21713]: 4404738: from=, size=1187, nrcpt=1 (queue active) Nov 29 16:56:51 mail postfix/local[19968]: 4404738: to=hq??g...@mydomain.com, relay=local, delay=0.17, delays=0.15/0.01/0/0.02, dsn=5.1.1, status=bounced (unknown user: hq??g) Nov 29 16:56:51 mail postfix/qmgr[21713]: 4404738: removed
Re: alias_maps are not being read correctly
On 11/30/2012 10:45 AM, l...@airstreamcomm.net wrote: On 11/30/12 10:22 AM, Wietse Venema wrote: l...@airstreamcomm.net: I am setup a 2.6.6 server with virtual domains and the entries in an alias_maps file (/etc/postfix/aliases) which look like this: localuser :include:/etc/postfix/massmail/localuser localuser2 :include:/etc/postfix/massmail/localuser2 As documented this format is supported in ALIAS_MAPS not VIRTUAL_ALIAS_MAPS Wietse Understood, however I am wondering why the alias_maps are not working in my instance as it appears as if they are not being used at all. I am not sure if this is a symptom of my configuration, or the intended functionality. alias_maps are used by local(8) during delivery of local mail, and is not used by virtual domains. In my configuration is have: alias_database = hash:/etc/aliases, hash:/etc/postfix/aliases This defines the databases to be rebuilt when you issue the newaliases command. This has no effect on what alias databases are used during local(8) delivery. http://www.postfix.org/postconf.5.html#alias_database alias_maps = hash:/etc/aliases, hash:/etc/postfix/aliases List of databases used during local(8) delivery. http://www.postfix.org/postconf.5.html#alias_maps http://www.postfix.org/aliases.5.html Either of these maps appear to be recognized? These maps are not used during virtual delivery. Please see virtual_alias_maps; note the format is different. http://www.postfix.org/postconf.5.html#virtual_alias_maps http://www.postfix.org/virtual.5.html It might be helpful to review http://www.postfix.org/ADDRESS_REWRITING_README.html -- Noel Jones
Re: automatically modified email name when sent
On 11/30/2012 11:09 AM, c cc wrote: Hi: I thought I would try it on the Postfix group see if I can get a solution to the problem. When I released the email from the quarantined list in Dspam, the email name would change to something else. In my case, it was supposed to be cha...@mydomain.com--and it changed to hq??g...@mydomain.com. Therefore it gave me an bounced status for unknown user. Any suggestions how should I correct this? Thanks! Seems like a question for your Dspam quarantine support channel. Maybe there is a documented way to modify the recipient of a mail in quarantine, or to release a quarantined message to a specified recipient. In postfix, you can add a virtual_alias_maps entry mapping the bad user to to the intended recipient, but this requires you know the bad recipient prior to releasing the message. This is complicated by the possibility that the ?? represent non-printable characters remapped for safe logging. -- Noel Jones Nov 29 16:56:51 mail postfix/qmgr[21713]: 4404738: from=, size=1187, nrcpt=1 (queue active) Nov 29 16:56:51 mail postfix/local[19968]: 4404738: to=hq??g...@mydomain.com, relay=local, delay=0.17, delays=0.15/0.01/0/0.02, dsn=5.1.1, status=bounced (unknown user: hq??g) Nov 29 16:56:51 mail postfix/qmgr[21713]: 4404738: removed
Re: alias_maps are not being read correctly
On 11/30/12 11:17 AM, Noel Jones wrote: On 11/30/2012 10:45 AM, l...@airstreamcomm.net wrote: On 11/30/12 10:22 AM, Wietse Venema wrote: l...@airstreamcomm.net: I am setup a 2.6.6 server with virtual domains and the entries in an alias_maps file (/etc/postfix/aliases) which look like this: localuser :include:/etc/postfix/massmail/localuser localuser2 :include:/etc/postfix/massmail/localuser2 As documented this format is supported in ALIAS_MAPS not VIRTUAL_ALIAS_MAPS Wietse Understood, however I am wondering why the alias_maps are not working in my instance as it appears as if they are not being used at all. I am not sure if this is a symptom of my configuration, or the intended functionality. alias_maps are used by local(8) during delivery of local mail, and is not used by virtual domains. In my configuration is have: alias_database = hash:/etc/aliases, hash:/etc/postfix/aliases This defines the databases to be rebuilt when you issue the newaliases command. This has no effect on what alias databases are used during local(8) delivery. http://www.postfix.org/postconf.5.html#alias_database alias_maps = hash:/etc/aliases, hash:/etc/postfix/aliases List of databases used during local(8) delivery. http://www.postfix.org/postconf.5.html#alias_maps http://www.postfix.org/aliases.5.html Either of these maps appear to be recognized? These maps are not used during virtual delivery. Please see virtual_alias_maps; note the format is different. http://www.postfix.org/postconf.5.html#virtual_alias_maps http://www.postfix.org/virtual.5.html It might be helpful to review http://www.postfix.org/ADDRESS_REWRITING_README.html -- Noel Jones Thanks for the clarification Noel, from your explanation it appears my relay is virtual so the alias_maps are not going to be recognized for the domains that are hosted virtually. I just created a mysql table with a source and destination column like so: massmailaddr - destaddr1 massmailaddr - destaddr2 ... Added virtual_alias_map = mysql:/etc/postfix/massmail.cf: hosts = x.x.x.x, y.y.y.y user = user password = password dbname = massmail query = SELECT destination FROM entries WHERE source = '%s' postmap -q massmailaddr mysql:/etc/postfix/massmail.cf: destaddr1, destaddr2, ... And had success. I also had to update the value for virtual_alias_expansion_limit as my customer needed to deliver to more than the default 1000 addresses.
user lookup error
I recently upgraded our mail servers from FreeBSD 7.3 running postfix 2.8.7 to FreeBSD 8.3 running postfix 2.9.3. We have account information stored in mysql and are using libnns-mysql to access the information through the normal password routines. After the upgrade, when a user does not exist I get an error looking up the passwd info: Nov 30 10:39:59 server postfix/local[50947]: warning: error looking up passwd info for user: Invalid argument Nov 30 10:39:59 server postfix/local[50947]: 6F8985082A: to=user@domain, orig_to=alias@domain, relay=local, delay=163222, delays=163222/0/0/0.04, dsn=4.0.0, status=deferred (user lookup error) Because it is a temporary error, it keeps trying over and over. In the case of aliases, the valid recipients get a copy each time it retries. Delivery to users that exist works fine. IMAP and POP work fine. All other system functions work fine. We've been using the libnss-mysql module for a very long time, over 5 years, and we've never had a problem before. Does anyone have suggestions on how to debug this? Thanks, Dan
Re: make error - ATTENTION: Unknown system type: FreeBSD 9.0-RELEASE
Solved! With the help of a co-worker, I used the -l parameter of patch to get it to ignore whitespace. Prior to that, I kept getting hunk failures. The command I used is: patch –Cl –p0 patch_name.patch first to Check for errors and then just patch –l –p0 patch_name.patch. Thank you Wietse. Ed
VERP clarification
Am I right in thinking that it's the mailing software/client (Be that Mailman/Major Domino/Interspire/OpenEMM etc) that is responsible for creating the VERP address, and that it's not something I can get POSTFIX to do on the fly (perhaps with a milter or header rewrite) at SMTP time? I've read - but don't fully 'get' - the docs, so I'm really looking for a basic 'yes you can, read this' or 'no, that's the job of the client' type answer. Kind regards Sam
Re: VERP clarification
On 11/30/2012 1:27 PM, Sam Jones wrote: Am I right in thinking that it's the mailing software/client (Be that Mailman/Major Domino/Interspire/OpenEMM etc) that is responsible for creating the VERP address, and that it's not something I can get POSTFIX to do on the fly (perhaps with a milter or header rewrite) at SMTP time? I've read - but don't fully 'get' - the docs, so I'm really looking for a basic 'yes you can, read this' or 'no, that's the job of the client' type answer. Kind regards Sam If your mailing list software creates VERP addresses, postfix will happily use them. Postfix also has built-in support for creating VERP while sending mail. http://www.postfix.org/VERP_README.html Official postfix docs can be found here: http://www.postfix.org/documentation.html The docs are one of postfix's best features. -- Noel Jones
Re: VERP clarification
Noel, once more you help me out. Thank you so very much. I did look at that, but didn't fully understand it. Now I know I CAN do it, I'll work with it and experiment. Thank you so much, Sam On Fri, 2012-11-30 at 13:35 -0600, Noel Jones wrote: On 11/30/2012 1:27 PM, Sam Jones wrote: Am I right in thinking that it's the mailing software/client (Be that Mailman/Major Domino/Interspire/OpenEMM etc) that is responsible for creating the VERP address, and that it's not something I can get POSTFIX to do on the fly (perhaps with a milter or header rewrite) at SMTP time? I've read - but don't fully 'get' - the docs, so I'm really looking for a basic 'yes you can, read this' or 'no, that's the job of the client' type answer. Kind regards Sam If your mailing list software creates VERP addresses, postfix will happily use them. Postfix also has built-in support for creating VERP while sending mail. http://www.postfix.org/VERP_README.html Official postfix docs can be found here: http://www.postfix.org/documentation.html The docs are one of postfix's best features. -- Noel Jones
Re: user lookup error
Dan Lists: Nov 30 10:39:59 server postfix/local[50947]: warning: error looking up passwd info for user: Invalid argument The getpwnam_r() SYSTEM LIBRARY ROUTINE reports an error, with errno set to EINVAL (Invalid argument). Find out why the SYSTEM LIBRARY ROUTINE reports this error. Because it is a temporary error, it keeps trying over and over. In the case of aliases, the valid recipients get a copy each time it retries. Set an owner-name alias to avoid that. Postfix will return mail if the user does not exist. In this case, it never gets a definitive ruling, therefore it defers delivery. Wietse
Re: avoiding overload on port 587
On 11/30/2012 7:27 AM, Tomas Macek wrote: On Fri, 30 Nov 2012, Wietse Venema wrote: 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, there is a really easy solution to this problem of yours, and it doesn't take in depth technical understanding of the inner workings of Postfix to achieve it. Simply physically separate your inbound public SMTP traffic from your user submission relay traffic. I.e. setup a separate dedicated box that ONLY performs submission on TCP 587 with auth and outbound relay. I.e. disable the smtpd server on TCP 25. And implement Postscreen on the current public SMTP server. Inform your clients that the change will be complete in 14 days, or whatever time frame you choose, and that they must switch submission to the new IP+port with username and password before that deadline. After the deadline, disable submission/relaying on the public SMTP server, forcing stragglers to convert to using the new submission server. Separating these functions doesn't require a second physical server, but it has a number of advantages for you and your users. First is that it fixes the problem of high public SMTP traffic causing problems for submissions. Second, if you have to take one server down for hardware maintenance only one function goes down, not both. Third, if desired, you can locate the two servers in different locations, on different networks. Etc, etc. Many orgs with high traffic loads separate the public SMTP and user submission functions onto separate boxes. Some have entire farms of servers dedicated to each function. -- Stan
Re: Dot forward not reading links
wimpunk: Hi, I've been wondering why my .forward files didn't worked like I expected and finally I found out dotforward doesn't accept linked files. Is there any reason why dotforward doesn't read links? In src/local/dotforward.c (line232 of the latest debian version) I wanted to change What if the symlink points to /dev/zero or /dev/random? Wietse
Re: Dot forward not reading links
On Fri, Nov 30, 2012 at 11:10 PM, Wietse Venema wie...@porcupine.org wrote: wimpunk: Hi, I've been wondering why my .forward files didn't worked like I expected and finally I found out dotforward doesn't accept linked files. Is there any reason why dotforward doesn't read links? In src/local/dotforward.c (line232 of the latest debian version) I wanted to change What if the symlink points to /dev/zero or /dev/random? Wietse It would fail because the file would be world writable. wimpunk.
Re: Dot forward not reading links
wimpunk: On Fri, Nov 30, 2012 at 11:10 PM, Wietse Venema wie...@porcupine.org wrote: wimpunk: Hi, I've been wondering why my .forward files didn't worked like I expected and finally I found out dotforward doesn't accept linked files. Is there any reason why dotforward doesn't read links? In src/local/dotforward.c (line232 of the latest debian version) I wanted to change What if the symlink points to /dev/zero or /dev/random? Wietse It would fail because the file would be world writable. Right, and your point is that all malicious symlinks under all user's home directories will always resolve to a world-writable file, so I should not have to worry about such things. Wietse
Re: avoiding overload on port 587
Am 30.11.2012 22:57, schrieb Stan Hoeppner: Simply physically separate your inbound public SMTP traffic from your user submission relay traffic. I.e. setup a separate dedicated box that ONLY performs submission on TCP 587 with auth and outbound relay. I.e. disable the smtpd server on TCP 25. And implement Postscreen on the current public SMTP server. Separating these functions doesn't require a second physical server, but it has a number of advantages for you and your users. First is that it fixes the problem of high public SMTP traffic causing problems for submissions. Second, if you have to take one server down for hardware maintenance only one function goes down, not both. in a perfect world in the real world submission is useless if IMAP is down because the client will fail to store in sent messages PHYSICAL boxes are not needed in 900 out of 1000 environments these days virtualization i sued which let you define maximum hardware ressources for each virtual machine and gives you easy to maintain high-ability opitions with a second host with virtualization and failover it makes sense to use different virtual servers but mostly not for real physical machines because if ONE goes down you have a problem which is not solved quickly and will in many cases affect other boxes and service quality at all with the watsd money for 5 small/mid boxes you get two real ones as virtualization host - on our new host with 96 GB of RAM we can easy define ressources at runtime, with physical ones they have too less ressources or wasted ones signature.asc Description: OpenPGP digital signature
Re: avoiding overload on port 587
On 11/30/2012 4:48 PM, Reindl Harald wrote: in the real world submission is useless if IMAP is down because the client will fail to store in sent messages In the real world most road warriors use POP, not IMAP, and those with consistent connectivity that do make use of IMAP do it via web mail. So the sent items folder isn't an issue. Note the OP mentioned laptop users as his submitters, not desktop users. Laptop implies roaming, or he'd have used a different descriptive term. PHYSICAL boxes are not needed in 900 out of 1000 environments Reindl, nobody here has ever heard of virtualization, so it's good that you give us all a lesson with every 3rd post. ;) That said, given the ongoing clock issues that all the guest/hypervisor combos have always experienced to some degree, and will forever experience no matter how good the mitigation hacks, it is my opinion, and Wietse's, and many others, that mail is not really a suitable application for most virtual environments. I'm sure you'll now write at least 5 paragraphs telling us why we're wrong, but it will be fruitless typing, as you won't change our minds. In the OP's case, deploying a second box is a helluva lot easier than building a virtual infrastructure from the ground up simply to solve this one issue. And of course he could do it with a single Postfix instance, or dual instance, on the one box, but a second box gives him some additional flexibility, not to mention IO headroom for queues and logs. -- Stan
Re: avoiding overload on port 587
Am 01.12.2012 00:19, schrieb Stan Hoeppner: On 11/30/2012 4:48 PM, Reindl Harald wrote: in the real world submission is useless if IMAP is down because the client will fail to store in sent messages In the real world most road warriors use POP, not IMAP, and those with consistent connectivity that do make use of IMAP do it via web mail. So the sent items folder isn't an issue. Note the OP mentioned laptop users as his submitters, not desktop users. Laptop implies roaming, or he'd have used a different descriptive term. in the real world THSE DAYS especially road warriors use IMAP and not POP3! notebook, workstation, tablet, smartphone have fun with your cummunication as business user if you think sent items folder isn't an issue signature.asc Description: OpenPGP digital signature
Re: avoiding overload on port 587
Stan Hoeppner: That said, given the ongoing clock issues that all the guest/hypervisor combos have always experienced to some degree, and will forever experience no matter how good the mitigation hacks, it is my opinion, and Wietse's, and many others, that mail is not really a suitable application for most virtual environments. I'm sure you'll now write at Um, I have pointed out failures. I do not claim that all virtualization environments fail to meet the requirements. Wietse
Re: avoiding overload on port 587
On 11/30/2012 6:08 PM, Wietse Venema wrote: Stan Hoeppner: That said, given the ongoing clock issues that all the guest/hypervisor combos have always experienced to some degree, and will forever experience no matter how good the mitigation hacks, it is my opinion, and Wietse's, and many others, that mail is not really a suitable application for most virtual environments. I'm sure you'll now write at Um, I have pointed out failures. I do not claim that all virtualization environments fail to meet the requirements. Wietse My apologies for the mis-attribution Wietse. I agree not all virtual environments have clock problems serious enough to avoid deploying mail servers. I stated most, which may likely be better described today as many. It's still a problem with Linux on ESX though not as bad as it once was, and it's bad today with Linux on Linux. I would think with IBM's ingenuity and 30 some years of virtual machine experience that Linux on zSeries would have no clock drift at all, but I have no first hand experience with this platform, and I have no experience and pay no attention to what Oracle is doing with Solaris virtualization, containers I believe they call it. -- Stan
Re: avoiding overload on port 587
On 11/30/2012 5:24 PM, Reindl Harald wrote: Am 01.12.2012 00:19, schrieb Stan Hoeppner: On 11/30/2012 4:48 PM, Reindl Harald wrote: in the real world submission is useless if IMAP is down because the client will fail to store in sent messages In the real world most road warriors use POP, not IMAP, and those with consistent connectivity that do make use of IMAP do it via web mail. So the sent items folder isn't an issue. Note the OP mentioned laptop users as his submitters, not desktop users. Laptop implies roaming, or he'd have used a different descriptive term. in the real world THSE DAYS especially road warriors use IMAP and not POP3! notebook, workstation, tablet, smartphone Germany is not the U.S., and neither are Czechoslovakia. The preferred protocol is dictated by availability of connectivity. There are large swaths of the U.S., mainly the midwest, that have poor connectivity. Road warriors traveling in these areas will prefer POP. I'm sure the same is true in other parts of the world with sparse tower population. have fun with your cummunication as business user if you think sent items folder isn't an issue For many users having a universal sent items folder, or INBOX for that matter, is impractical. Most of the road warriors I know (and BTW road warrior by definition is a traveling salesperson using a car and roads for movement, not flights between cities) use separate mailboxes on their smart phones and laptops. The smart phone account, maybe more than one, is used for ad hoc communication with clients, friends, family, etc, and sometimes home office personnel. The account used via the laptop is for official business only. With such a setup a universal sent items folder is unnecessary, and often unwanted. For instance... With many companies in the US, the company provides the laptop to the road warrior, complete with company mailbox, AND spyware, keystroke logger, etc. The road warrior provides his/her own phone, and uses a separate public email provider (gmail) specifically to prevent big brother from seeing all of his/her communications. Here the universal sent items folder is absolutely NOT desirable, especially if it resides on the company IMAP server, where all emails can be spied upon. -- Stan
