Puzzled by installation message on obsolete files/directories
In connection with various other problems I shall probably need help with later, I thought I might re-install Postfix 2.8.3 from ports in FreeBSD 8.2. As part of the install I get the following messages: Note: the following files or directories still exist but are no longer part of Postfix: /etc/postfix/access /etc/postfix/aliases /etc/postfix/canonical /etc/postfix/generic /etc/postfix/header_checks /etc/postfix/postfix-files /etc/postfix/relocated /etc/postfix/transport /etc/postfix/virtual /etc/postfix/postfix-script /etc/postfix/post-install When I go to www.postfix.org I can find documentation on some of these files (I haven't checked them all but did check header_checks and transport) and there is no mention of these being obsolete! TIA Bernard Higonnet
Re: Puzzled by installation message on obsolete files/directories
On Sun, 2011-08-07 at 15:15:14 +0200, Bernard T. Higonnet wrote: In connection with various other problems I shall probably need help with later, I thought I might re-install Postfix 2.8.3 from ports in FreeBSD 8.2. As part of the install I get the following messages: FYI: 2.8.4 is the latest version in ports. Note: the following files or directories still exist but are no longer part of Postfix: /etc/postfix/access /etc/postfix/aliases /etc/postfix/canonical /etc/postfix/generic /etc/postfix/header_checks /etc/postfix/postfix-files /etc/postfix/relocated /etc/postfix/transport /etc/postfix/virtual /etc/postfix/postfix-script /etc/postfix/post-install These files are indeed obsolete, as indicated by their flags in conf/postfix-files. You will notice that postfix-script, postfix-files and post-install are still placed in the $daemon_directory; their redundant placement in $config_directory is obsolete. Similarly, the other files noted above were replicas of man pages which are still installed. -- Sahil Tandon sa...@freebsd.org
Re: Simplest way to enable smtpd_authorized_xforward_hosts for any/all clients?
On Fri, Aug 5, 2011 at 2:10 PM, Noel Jones njo...@megan.vbhcs.org wrote: On 8/5/2011 3:26 PM, Jack Bates wrote: What's the simplest way to enable smtpd_authorized_xforward_hosts for any/all clients? That sounds very wrong. What problem are you trying to solve? I want to control access to this MTA with a firewall. The only client permitted access is an upstream instance of Postfix, via smtpd_proxy_filter. I want this client to use XFORWARD, so I want to enable smtpd_authorized_xforward_hosts unconditionally. What's the simplest way?
Re: Multiple Domains, Mail Gateway, Two Mail Servers
Wow, over 48 hours and no solution(s) suggested? Everybody on vacation? :) Regards, Jim -- Note: My mail server employs *very* aggressive anti-spam filtering. If you reply to this email and your email is rejected, please accept my apologies and let me know via my web form at http://jimsun.LinxNet.com/contact/scform.php.
Re: Multiple Domains, Mail Gateway, Two Mail Servers
On Sun, 2011-08-07 at 11:08:13 -0400, Jim Seymour wrote: Wow, over 48 hours and no solution(s) suggested? Everybody on vacation? :) It is the weekend! :-) Without being privy to configuration details (IIRC you only shared a general description of mail routing), I think transport_maps on the gateway might solve your problem. -- Sahil Tandon sa...@freebsd.org
Re: Simplest way to enable smtpd_authorized_xforward_hosts for any/all clients?
On Sun, Aug 07, 2011 at 08:03:47AM -0700, Jack Bates wrote: On Fri, Aug 5, 2011 at 2:10 PM, Noel Jones njo...@megan.vbhcs.org wrote: On 8/5/2011 3:26 PM, Jack Bates wrote: What's the simplest way to enable smtpd_authorized_xforward_hosts for any/all clients? That sounds very wrong. What problem are you trying to solve? I want to control access to this MTA with a firewall. The only client permitted access is an upstream instance of Postfix, via smtpd_proxy_filter. I want this client to use XFORWARD, so I want to enable smtpd_authorized_xforward_hosts unconditionally. What's the simplest way? Restating the solutions I gave you in IRC that day (I assuming it was you, because the question and description of the issue was identical): smtpd_authorized_xforward_hosts = static:all or smtpd_authorized_xforward_hosts = 0.0.0.0/0, [::/0] These can be preceded by exclusions. For details, see: http://www.postfix.org/postconf.5.html#smtpd_authorized_xforward_hosts -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: Multiple Domains, Mail Gateway, Two Mail Servers
On 2011-08-07 17:08, Jim Seymour wrote: Wow, over 48 hours and no solution(s) suggested? Everybody on vacation? :) Don't hijack another poster's thread. And yes, it IS the summer vacation. -- J.
Re: Simplest way to enable smtpd_authorized_xforward_hosts for any/all clients?
On 8/7/2011 12:36 PM, /dev/rob0 wrote: On Sun, Aug 07, 2011 at 08:03:47AM -0700, Jack Bates wrote: On Fri, Aug 5, 2011 at 2:10 PM, Noel Jones njo...@megan.vbhcs.org wrote: On 8/5/2011 3:26 PM, Jack Bates wrote: What's the simplest way to enable smtpd_authorized_xforward_hosts for any/all clients? That sounds very wrong. What problem are you trying to solve? I want to control access to this MTA with a firewall. The only client permitted access is an upstream instance of Postfix, via smtpd_proxy_filter. I want this client to use XFORWARD, so I want to enable smtpd_authorized_xforward_hosts unconditionally. What's the simplest way? Restating the solutions I gave you in IRC that day (I assuming it was you, because the question and description of the issue was identical): smtpd_authorized_xforward_hosts = static:all or smtpd_authorized_xforward_hosts = 0.0.0.0/0, [::/0] These can be preceded by exclusions. For details, see: http://www.postfix.org/postconf.5.html#smtpd_authorized_xforward_hosts No, the above solution is wrong. The only client IP that should be in smtpd_authorized_xforward_hosts is the upstream postfix server. # main.cf smtpd_authorized_xforward_hosts = ip.of.upstream.postfix Putting static:all or equivalent would allow an unauthorized client to spoof their IP address. (in this case, using static:all might not matter if a firewall prevents outside access, but it's still wrong.) -- Noel Jones
Re: Multiple Domains, Mail Gateway, Two Mail Servers
On Sun, 07 Aug 2011 20:02:22 +0200 Jeroen Geilman articulated: On 2011-08-07 17:08, Jim Seymour wrote: Wow, over 48 hours and no solution(s) suggested? Everybody on vacation? :) Don't hijack another poster's thread. And yes, it IS the summer vacation. Only if you are north of the Equator. -- Jerry ✌ postfix-u...@seibercom.net _ TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html And I alone am returned to wag the tail.
Re: Multiple Domains, Mail Gateway, Two Mail Servers
On 8/7/2011 11:02 AM, Jeroen Geilman wrote: On 2011-08-07 17:08, Jim Seymour wrote: Wow, over 48 hours and no solution(s) suggested? Everybody on vacation? :) Don't hijack another poster's thread. And yes, it IS the summer vacation. Sorry, I must have missed something; whose thread was hijacked? Chris
Re: Simplest way to enable smtpd_authorized_xforward_hosts for any/all clients?
On Sun, Aug 07, 2011 at 02:10:35PM -0500, Noel Jones wrote: On 8/7/2011 12:36 PM, /dev/rob0 wrote: On Sun, Aug 07, 2011 at 08:03:47AM -0700, Jack Bates wrote: On Fri, Aug 5, 2011 at 2:10 PM, Noel Jones njo...@megan.vbhcs.org wrote: On 8/5/2011 3:26 PM, Jack Bates wrote: What's the simplest way to enable smtpd_authorized_xforward_hosts for any/all clients? That sounds very wrong. What problem are you trying to solve? I want to control access to this MTA with a firewall. The only client permitted access is an upstream instance of Postfix, via smtpd_proxy_filter. I want this client to use XFORWARD, so I want to enable smtpd_authorized_xforward_hosts unconditionally. What's the simplest way? Restating the solutions I gave you in IRC that day (I assuming it was you, because the question and description of the issue was identical): smtpd_authorized_xforward_hosts = static:all or smtpd_authorized_xforward_hosts = 0.0.0.0/0, [::/0] These can be preceded by exclusions. For details, see: http://www.postfix.org/postconf.5.html#smtpd_authorized_xforward_hosts No, the above solution is wrong. The only client IP that should be in smtpd_authorized_xforward_hosts is the upstream postfix server. # main.cf smtpd_authorized_xforward_hosts = ip.of.upstream.postfix Apparently this upstream IP is dynamic, he said in IRC. Agreed, it sounds very strange. Putting static:all or equivalent would allow an unauthorized client to spoof their IP address. (in this case, using static:all might not matter if a firewall prevents outside access, but it's still wrong.) That was my reasoning, along with if it breaks, Jack gets to keep both pieces. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: Simplest way to enable smtpd_authorized_xforward_hosts for any/all clients?
On 8/7/2011 3:52 PM, /dev/rob0 wrote: On Sun, Aug 07, 2011 at 02:10:35PM -0500, Noel Jones wrote: # main.cf smtpd_authorized_xforward_hosts = ip.of.upstream.postfix Apparently this upstream IP is dynamic, he said in IRC. Agreed, it sounds very strange. If the upstream is dynamic, there would presumably be some way for the firewall to be updated. Such an update could also include updating the postfix main.cf and loading postfix. Putting static:all or equivalent would allow an unauthorized client to spoof their IP address. (in this case, using static:all might not matter if a firewall prevents outside access, but it's still wrong.) That was my reasoning, along with if it breaks, Jack gets to keep both pieces. When you knowingly give bad advice (not pointing fingers, I do it too -- still trying to quit), make sure to clearly label it as such. I didn't see any warning on your post to the list. -- Noel Jones
Re: Simplest way to enable smtpd_authorized_xforward_hosts for any/all clients?
On Sun, Aug 07, 2011 at 03:59:10PM -0500, Noel Jones wrote: On 8/7/2011 3:52 PM, /dev/rob0 wrote: On Sun, Aug 07, 2011 at 02:10:35PM -0500, Noel Jones wrote: # main.cf smtpd_authorized_xforward_hosts = ip.of.upstream.postfix Apparently this upstream IP is dynamic, he said in IRC. Agreed, it sounds very strange. If the upstream is dynamic, there would presumably be some way for the firewall to be updated. Such an update could also include updating the postfix main.cf and loading postfix. Agreed, that would be best. Putting static:all or equivalent would allow an unauthorized client to spoof their IP address. (in this case, using static:all might not matter if a firewall prevents outside access, but it's still wrong.) That was my reasoning, along with if it breaks, Jack gets to keep both pieces. When you knowingly give bad advice (not pointing fingers, I do it too -- still trying to quit), make sure to clearly label it as such. I didn't see any warning on your post to the list. Good point. I did say something in IRC, but you're right, repetition here was warranted. An awful mess could ensue if the firewall failed at the moment an XFORWARD-capable spambot hit. (I don't know if such ratware exists, but there is no reason why it could not. Only reason it *might* not is that defaults for announcing XFORWARD are rightly restricted. Ratware of this type wouldn't accomplish much.) Another idea, better but not ideal, would be to at least limit the smtpd_authorized_xforward_hosts to a netblock of possible addresses for the upstream. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Postscreen, Greylisting, Penalty Time
I see some previous posts regarding this - just my 2 cents worth. There mig= ht be multiple triggers for the penalty time, but, one I'd like to see woul= d be just like postscreen_dnsbl_threshold, perhaps postscreen_dnsbl_penalty= _threshold. In this way, I might want a score of 3 to trigger block, but, a= score of 1 to trigger the penalty time. Similar to what one can do with mi= lter-greylist for example. Of course, one problem with using Postscreen in this manner is what some of= the greylisting programs have added support for - mail servers who send th= e second attempt from a different nearby IP. Most of them allow some sort o= f mask. One could whitelist them, and, get around this I suppose. Am just hoping postscreen will support some form of greylisting so that a s= eparate greylisting program is not needed for those who wish to greylist. P= ostscreen would be the best (least expensive) place to do so imho. Steve
