Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

How to relay for domain AND IP ?

216 views
Skip to first unread message

Chip Paswater

unread,
Aug 20, 2002, 9:45:54 PM8/20/02
to
So I understand how to relay for a specific domain (relay_domains = domain)

And I understand how to relay for a specific IP address (mynetworks = ip)

But how do I allow only a SPECIFIC ip to relay a SPECIFIC domain?

I figure it's some strange combination of smtpd_recipient_restrictions and
lookup tables, but I can't seem to figure it out.
-
To unsubscribe, send mail to majo...@postfix.org with content
(not subject): unsubscribe postfix-users

Chip Paswater

unread,
Aug 21, 2002, 7:31:38 PM8/21/02
to
> > But how do I allow only a SPECIFIC ip to relay a SPECIFIC domain?
> >
>
> Limited scalability, one map per group of source IP addresses.
>
> smtpd_restriction_classes =
> check_ipaccess1
>
> check_ipaccess1 =
> check_recipient_access hash:/etc/postfix/domain_access1
>
> smtpd_recipient_restrictions =
> ...
> permit_mynetworks,
> check_client_access hash:/etc/postfix/client_access,
> reject_unauth_destination
> ...
>
>
> client_access:
> 1.2.3.4 check_ipaccess1
>
> domain_access1:
> example.org OK
>
> --
> Viktor.


Thanks Viktor! A slightly modified (and tested) verson of this is as
follows:

smtpd_restriction_classes =
check_relayaccess

check_relayaccess =
check_sender_access hash:/etc/postfix/relay-domains

smtpd_recipient_restrictions =
reject_non_fqdn_sender
reject_unknown_sender_domain
check_client_access hash:/etc/postfix/reject
check_sender_access hash:/etc/postfix/reject
reject_maps_rbl
reject_unauth_pipelining
check_client_access hash:/etc/postfix/relay-ips
check_relay_domains

relay-ips:
# IP addresses in this file will be able to RELAY FROM domains listed in
# /etc/postfix/relay-domains
1.2.3.4 check_relayaccess

relay-domains:
# Domains in this file will be relayed FROM for IP addresses listed in
# /etc/postfix/relay-ips
example.com OK


This relay setup allows me to do the following:

Process mail FROM any domain TO example.com, a virtual domain (for inbound email).
Process mail FROM example.com, TO any domain, but only from 1.2.3.4 (for outbound email).

When I add amavisd, I'll likely have to add permit_mynetworks (mynetworks =
127.0.0.1) to allow amavis to re-inject scanned mail. Other than that, I think
my setup is pretty secure. Do you see any problems with my access controls?

Victor....@morganstanley.com

unread,
Aug 21, 2002, 9:12:19 PM8/21/02
to
On Wed, 21 Aug 2002, Chip Paswater wrote:

> Process mail FROM any domain TO example.com, a virtual domain (for inbound email).
> Process mail FROM example.com, TO any domain, but only from 1.2.3.4 (for outbound email).
>

From the above it is not clear what you want done when mail comes from
@example.com to @example.com with source IP that is not 1.2.3.4!

The configuration (not shown) we arrived at does not block it, but the
language can be read to require such blocking.

Please state your requirements more clearly.

Also it is better to use reject_unauth_destionation instead of
check_relay_domains, and to move as many filters that apply to inbound
mail as possible below reject_unauth_destination. This prevents surprises
with OK rules in access maps.

So instead of

permit_mynetworks,
check_sender_access hash:/foo
check_relay_domains

use

permit_mynetworks
reject_unauth_destination
check_sender_access hash:/foo
permit

The second form is not an open relay even if the acess table has an
unexpected OK entry.

For you "permit_mynetworks" is replaced by

check_client_access hash:/bar

with appropriate rules for each "trusted" network.

--
Viktor.

Chip Paswater

unread,
Aug 22, 2002, 3:58:48 AM8/22/02
to
> > Process mail FROM any domain TO example.com, a virtual domain (for inbound email).
> > Process mail FROM example.com, TO any domain, but only from 1.2.3.4 (for outbound email).
> >
>
> >From the above it is not clear what you want done when mail comes from
> @example.com to @example.com with source IP that is not 1.2.3.4!
>
> Please state your requirements more clearly.

Well, I assume the message would be accepted, but I'll test this tomorrow.
My goal is to accept any mail to example.com, unless it's denied for
some reason (invalid hostname, rbl, manual reject, etc).

> Also it is better to use reject_unauth_destionation instead of
> check_relay_domains, and to move as many filters that apply to inbound
> mail as possible below reject_unauth_destination. This prevents surprises
> with OK rules in access maps.
>
> So instead of
>
> permit_mynetworks,
> check_sender_access hash:/foo
> check_relay_domains
>
> use
>
> permit_mynetworks
> reject_unauth_destination
> check_sender_access hash:/foo
> permit
>
> The second form is not an open relay even if the acess table has an
> unexpected OK entry.
>
> For you "permit_mynetworks" is replaced by
>
> check_client_access hash:/bar
>
> with appropriate rules for each "trusted" network.

Ok, at first I didn't understand why I would want to use
reject_unauth_destionation instead of check_relay_domains, but now I'm
starting to get it. What you're saying is I should replace my "permit
unless reject" ruleset with "reject unless permit", right? Just like a
firewall, a "deny all, allow few" policy is much tighter than an "allow
all, deny few" policy. Do I understand that correctly?

Geez, this trinary stuff is complex.. Can't we just have simple
if/then/else statements? ;)

0 new messages