Re: Query about restriction scenario in RESTRICTION_CLASS_README

2019-01-19 Thread Matus UHLAR - fantomas
On Thu, Jan 17, 2019 at 11:22:46AM -0500, Bill Cole wrote: You truly need to ask whoever runs that other server to explain why they believe your server is misconfigured if you want a definitive answer. On 18.01.19 07:06, Mayuresh wrote: This is certainly strangest of the mailing lists I ever

Re: Query about restriction scenario in RESTRICTION_CLASS_README

2019-01-17 Thread Mayuresh
On Thu, Jan 17, 2019 at 11:22:46AM -0500, Bill Cole wrote: > You truly need to ask whoever runs that other server to explain why they > believe your server is misconfigured if you want a definitive answer. This is certainly strangest of the mailing lists I ever participated in. I am certainly

Re: Query about restriction scenario in RESTRICTION_CLASS_README

2019-01-17 Thread Bill Cole
On 17 Jan 2019, at 11:03, Mayuresh wrote: On Thu, Jan 17, 2019 at 10:47:18AM -0500, Wietse Venema wrote: The default code of 5.7.1 is the one I want as well. Log and the bounced mail to gmail confirms that was the one that was used. But an additional remark gmail makes is "the remote server

Re: Query about restriction scenario in RESTRICTION_CLASS_README

2019-01-17 Thread Mayuresh
On Thu, Jan 17, 2019 at 10:47:18AM -0500, Wietse Venema wrote: > > The default code of 5.7.1 is the one I want as well. Log and the bounced > > mail to gmail confirms that was the one that was used. > > > > But an additional remark gmail makes is "the remote server is > > misconfigured". > > > >

Re: Query about restriction scenario in RESTRICTION_CLASS_README

2019-01-17 Thread Wietse Venema
Mayuresh: > On Thu, Jan 17, 2019 at 07:25:42AM -0500, Wietse Venema wrote: > > reject, with error code: > > http://www.postfix.org/access.5.html (section: REJECT ACTIONS) > > > > The default code of 5.7.1 is the one I want as well. Log and the bounced > mail to gmail confirms that was the

Re: Query about restriction scenario in RESTRICTION_CLASS_README

2019-01-17 Thread Mayuresh
On Thu, Jan 17, 2019 at 07:25:42AM -0500, Wietse Venema wrote: > reject, with error code: > http://www.postfix.org/access.5.html (section: REJECT ACTIONS) > The default code of 5.7.1 is the one I want as well. Log and the bounced mail to gmail confirms that was the one that was used. But an

Re: Query about restriction scenario in RESTRICTION_CLASS_README

2019-01-17 Thread Wietse Venema
Mayuresh: > On Wed, Jan 16, 2019 at 07:14:37AM -0500, Wietse Venema wrote: > > insiders_only = check_sender_access hash:/etc/postfix/insiders, > > reject > > On above line if I replace reject with reject_unauth_destination it > becomes permissive rather than rejecting. > > What is the

Re: Query about restriction scenario in RESTRICTION_CLASS_README

2019-01-16 Thread Mayuresh
On Wed, Jan 16, 2019 at 07:14:37AM -0500, Wietse Venema wrote: > insiders_only = check_sender_access hash:/etc/postfix/insiders, reject On above line if I replace reject with reject_unauth_destination it becomes permissive rather than rejecting. What is the exact difference between

Re: Query about restriction scenario in RESTRICTION_CLASS_README

2019-01-16 Thread Mayuresh
On Wed, Jan 16, 2019 at 07:14:37AM -0500, Wietse Venema wrote: > All I suggested was to split smtpd_recipient_restrictions > and use smtpd_relay_restrictions for the spam blocks. > > That was, TO SPLIT smtpd_recipient_restrictions, NOT TO REMOVE > the hash maps. Ok, thanks. Mayuresh

Re: Query about restriction scenario in RESTRICTION_CLASS_README

2019-01-16 Thread Wietse Venema
Mayuresh: > Sure. Basically I see only one hash in your snippet - that of the > protected destinations. I did not notice a hash of senders allowed to send > to the protected destinations. Am I missing something? Original example: /etc/postfix/main.cf: smtpd_recipient_restrictions =

Re: Query about restriction scenario in RESTRICTION_CLASS_README

2019-01-15 Thread Mayuresh
On Tue, Jan 15, 2019 at 08:58:57PM -0500, Wietse Venema wrote: > Mayuresh: > > On Tue, Jan 15, 2019 at 01:31:44PM -0500, Wietse Venema wrote: > > > This example can be simplified by using smtpd_relay_restrictions > > > (Posfix 2.10 and later). > > > > > > smtpd_relay_restrictions = > > >

Re: Query about restriction scenario in RESTRICTION_CLASS_README

2019-01-15 Thread Wietse Venema
Mayuresh: > On Tue, Jan 15, 2019 at 01:31:44PM -0500, Wietse Venema wrote: > > This example can be simplified by using smtpd_relay_restrictions > > (Posfix 2.10 and later). > > > > smtpd_relay_restrictions = > > permit_mynetworks > > permit_sasl_authenticated > >

Re: Query about restriction scenario in RESTRICTION_CLASS_README

2019-01-15 Thread Mayuresh
On Tue, Jan 15, 2019 at 01:31:44PM -0500, Wietse Venema wrote: > This example can be simplified by using smtpd_relay_restrictions > (Posfix 2.10 and later). > > smtpd_relay_restrictions = > permit_mynetworks > permit_sasl_authenticated > reject_unauth_destination >

Re: Query about restriction scenario in RESTRICTION_CLASS_README

2019-01-15 Thread Wietse Venema
Mayuresh: > I am using postfix 3.1.4 on NetBSD 8. > > I am trying the idea of setting up a mailing list for a fairly static > group of size not exceeding around 300, with postfix. I am doing this on a > VPS server and want a solution that is conservative on resource footprint, > hence considering

Query about restriction scenario in RESTRICTION_CLASS_README

2019-01-15 Thread Mayuresh
I am using postfix 3.1.4 on NetBSD 8. I am trying the idea of setting up a mailing list for a fairly static group of size not exceeding around 300, with postfix. I am doing this on a VPS server and want a solution that is conservative on resource footprint, hence considering doing it with MTA