Query about restriction scenario in RESTRICTION_CLASS_README

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Query about restriction scenario in RESTRICTION_CLASS_README

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 itself. [Please do comment whether
postfix is suitable for this purpose.]

I am able to get the basic aliases functionality, Reply-To header
modification etc. working fine.

I just need a recipe to restrict senders to the members of the mailing
list - only for the protected email id which is the list email id.

The search led me to the following write up in
/usr/share/examples/postfix/RESTRICTION_CLASS_README:

   In the general case you need two lookup tables: one table that lists
   destinations that need to be protected, and one table that lists domains
   that are allowed to send to the protected destinations.


    /etc/postfix/main.cf:
        smtpd_recipient_restrictions =
            ...
            check_recipient_access hash:/etc/postfix/protected_destinations
            ...the usual stuff...

        smtpd_restriction_classes = insiders_only
        insiders_only = check_sender_access hash:/etc/postfix/insiders, reject

    /etc/postfix/protected_destinations:
        [hidden email]   insiders_only
        [hidden email] insiders_only

    /etc/postfix/insiders:
        my.domain       OK  matches my.domain and subdomains
        another.domain  OK  matches another.domain and subdomains


I am unable to follow this example, particularly due to the ellipsis part.
Would appreciate if someone could elaborate this a bit further.


Mayuresh
Reply | Threaded
Open this post in threaded view
|

Re: Query about restriction scenario in RESTRICTION_CLASS_README

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 doing it with MTA itself. [Please do comment whether
> postfix is suitable for this purpose.]
>
> I am able to get the basic aliases functionality, Reply-To header
> modification etc. working fine.
>
> I just need a recipe to restrict senders to the members of the mailing
> list - only for the protected email id which is the list email id.
>
> The search led me to the following write up in
> /usr/share/examples/postfix/RESTRICTION_CLASS_README:
>
>    In the general case you need two lookup tables: one table that lists
>    destinations that need to be protected, and one table that lists domains
>    that are allowed to send to the protected destinations.
>
>
>     /etc/postfix/main.cf:
>         smtpd_recipient_restrictions =
>             ...
>             check_recipient_access hash:/etc/postfix/protected_destinations
>             ...the usual stuff...
>
>         smtpd_restriction_classes = insiders_only
>         insiders_only = check_sender_access hash:/etc/postfix/insiders, reject
>
>     /etc/postfix/protected_destinations:
>         [hidden email]   insiders_only
>         [hidden email] insiders_only
>
>     /etc/postfix/insiders:
>         my.domain       OK  matches my.domain and subdomains
>         another.domain  OK  matches another.domain and subdomains
>
>
> I am unable to follow this example, particularly due to the ellipsis part.
> Would appreciate if someone could elaborate this a bit further.

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
        ...other anti-spam things...

     smtpd_recipient_restrictions =
         check_recipient_access hash:/etc/postfix/protected_destinations

Otherwise everything has to be squeezed into smtpd_recipient_restrictions,
and that makes things ugly.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Query about restriction scenario in RESTRICTION_CLASS_README

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
> ...other anti-spam things...
>
>      smtpd_recipient_restrictions =
> check_recipient_access hash:/etc/postfix/protected_destinations
>
> Otherwise everything has to be squeezed into smtpd_recipient_restrictions,
> and that makes things ugly.

Thanks for sharing the snippet.

Comparing this with the README example of the OP, what is equivalent of
insiders_only in your example i.e. the list of senders who are allowed to
send to protected destination.

My scenario is the sender restriction should apply only on the protected
destination, not on others.

Mayuresh
Reply | Threaded
Open this post in threaded view
|

Re: Query about restriction scenario in RESTRICTION_CLASS_README

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
> > reject_unauth_destination
> > ...other anti-spam things...
> >
> >      smtpd_recipient_restrictions =
> > check_recipient_access hash:/etc/postfix/protected_destinations
> >
> > Otherwise everything has to be squeezed into smtpd_recipient_restrictions,
> > and that makes things ugly.
>
> Thanks for sharing the snippet.
>
> Comparing this with the README example of the OP, what is equivalent of
> insiders_only in your example i.e. the list of senders who are allowed to
> send to protected destination.
>
> My scenario is the sender restriction should apply only on the protected
> destination, not on others.

Don't get confused by names. You can use the name 'list_members'
instead of 'insiders' if you like. The names don't change the
principle of how things work.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Query about restriction scenario in RESTRICTION_CLASS_README

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 =
> > > permit_mynetworks
> > > permit_sasl_authenticated
> > > reject_unauth_destination
> > > ...other anti-spam things...
> > >
> > >      smtpd_recipient_restrictions =
> > > check_recipient_access hash:/etc/postfix/protected_destinations
> > >
> > > Otherwise everything has to be squeezed into smtpd_recipient_restrictions,
> > > and that makes things ugly.
> >
> > Thanks for sharing the snippet.
> >
> > Comparing this with the README example of the OP, what is equivalent of
> > insiders_only in your example i.e. the list of senders who are allowed to
> > send to protected destination.
> >
> > My scenario is the sender restriction should apply only on the protected
> > destination, not on others.
>
> Don't get confused by names. You can use the name 'list_members'
> instead of 'insiders' if you like. The names don't change the
> principle of how things work.

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?

Mayuresh
Reply | Threaded
Open this post in threaded view
|

Re: Query about restriction scenario in RESTRICTION_CLASS_README

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 =
            ...
            check_recipient_access hash:/etc/postfix/protected_destinations
            ...the usual stuff...

        smtpd_restriction_classes = insiders_only
        insiders_only = check_sender_access hash:/etc/postfix/insiders, reject

    /etc/postfix/protected_destinations:
        [hidden email]   insiders_only
        [hidden email] insiders_only

    /etc/postfix/insiders:
        my.domain       OK  matches my.domain and subdomains
        another.domain  OK  matches another.domain and subdomains

Look, two hash maps!

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.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Query about restriction scenario in RESTRICTION_CLASS_README

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
Reply | Threaded
Open this post in threaded view
|

Re: Query about restriction scenario in RESTRICTION_CLASS_README

Mayuresh
In reply to this post by Wietse Venema
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 reject and reject_unauth_destination?
I thought it's about rejecting with proper code. But looks like it has
different semantics.

The problem with `reject' is the sender's server returns the mail calling
us as `improperly configured'. (Hope that doesn't lead to blacklisting!) I
think it's better to reject with proper error code.

Mayuresh
Reply | Threaded
Open this post in threaded view
|

Re: Query about restriction scenario in RESTRICTION_CLASS_README

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 exact difference between reject and reject_unauth_destination?

reject, with error code:
    http://www.postfix.org/access.5.html (section: REJECT ACTIONS)

reject_unauth_destination:
    http://www.postfix.org/postconf.5.html#reject_unauth_destination

> I thought it's about rejecting with proper code. But looks like it has
> different semantics.
>
> The problem with `reject' is the sender's server returns the mail calling
> us as `improperly configured'. (Hope that doesn't lead to blacklisting!) I
> think it's better to reject with proper error code.

If you are unable to follow the example, then do not use it, or get
professional advice (I am not available).

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Query about restriction scenario in RESTRICTION_CLASS_README

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 additional remark gmail makes is "the remote server is
misconfigured".

Why would it call it misconfigured despite getting a legitimate code?

Mayuresh
Reply | Threaded
Open this post in threaded view
|

Re: Query about restriction scenario in RESTRICTION_CLASS_README

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 one that was used.
>
> But an additional remark gmail makes is "the remote server is
> misconfigured".
>
> Why would it call it misconfigured despite getting a legitimate code?

Because this is the Postfix mailing list, not gmail support.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Query about restriction scenario in RESTRICTION_CLASS_README

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".
> >
> > Why would it call it misconfigured despite getting a legitimate code?
>
> Because this is the Postfix mailing list, not gmail support.

Sorry. Read "other server" instead of gmail.

The reason to ask this question on postfix list is to figure out whether
my configuration* is flawed as some other servers report.

[* as discussed on this thread before where sending email to protected ids
is restricted to a list of senders. Others get a reject 554 5.7.1.]

I agree I am not too knowledgable about mail servers and sorry if my very
basic questions annoy you. But I am just trying to build the skill and
in my experience of the world mailing lists are a great place to ask such
queries. Usually.

Mayuresh
Reply | Threaded
Open this post in threaded view
|

Re: Query about restriction scenario in RESTRICTION_CLASS_README

Bill Cole-3
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 is
>>> misconfigured".
>>>
>>> Why would it call it misconfigured despite getting a legitimate
>>> code?
>>
>> Because this is the Postfix mailing list, not gmail support.
>
> Sorry. Read "other server" instead of gmail.

This is also not a mailing list for the support of unspecified "other
servers."

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.

Reply | Threaded
Open this post in threaded view
|

Re: Query about restriction scenario in RESTRICTION_CLASS_README

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 signing off right away.

All I wanted was some experience sharing with people who may have faced
similar issues.

Even a statement like there is no problem with your conf, the other
servers are sometimes unreasonable could have helped.

Sorry to have bothered you.

Good luck.

Mayuresh
Reply | Threaded
Open this post in threaded view
|

Re: Query about restriction scenario in RESTRICTION_CLASS_README

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 participated in. I
>am certainly signing off right away.
>
>All I wanted was some experience sharing with people who may have faced
>similar issues.
>
>Even a statement like there is no problem with your conf, the other
>servers are sometimes unreasonable could have helped.

you should understand that it's hard for us to know why does gmail say that
your mail server is misconfigured. Especially when you haven't provided any
such message.

It's gmail or other servers who say that and we (at least some of us) don't
maintain gmail servers.

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
2B|!2B, that's a question!