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
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?
> 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.
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? ;)