Permit mail from any MX of [local|virtual]_domains
Peter Rabbitson
My primary mail server has the following restrictions configuration:
smtpd_delay_reject = yes
smtpd_client_restrictions =
check_client_access hash:/etc/postfix/config/filter_client.tbl
smtpd_sender_restrictions =
reject_unknown_sender_domain
check_sender_access hash:/etc/postfix/config/filter_sender.tbl
smtpd_recipient_restrictions =
permit_mynetworks
reject_unauth_destination
reject_unlisted_recipient
check_client_access cidr:/etc/postfix/mx_backups.cidr
check_policy_service inet:127.0.0.1:10023
reject_rbl_client zen.spamhaus.org
smtpd_data_restrictions =
sleep 1
reject_unauth_pipelining
Where /etc/postfix/mx_backups.cidr gives an OK to the IP address of my
backup MX which is the same for all local_domains and virtual_domains. I
do this to protect myself from the slim chance of the backup MX being
listed on spamhaus, which will result in all mail being rejected (the
backup MX runs on a consumer SBC DSL line, which is exempt from the PBL
due to having a static IP, but one never knows).
I was wondering if it is possible to replace it with some check that
would simply verify if the client is a listed MX, removing the need to
update mx_backups.cidr along with the DNS in the future. I looked at the
permit_mx_backup option but the documentation explicitly states that
"permit_mx_backup no longer accepts the address when the local mail
system is primary MX for the recipient domain" which is exactly the case
here.
Is there a way to automate this configuration in some way, or what I
have is as good as it can get?
Thank you
Peter
Martin Schmitt
> I was wondering if it is possible to replace it with some check that
> would simply verify if the client is a listed MX, removing the need to
> update mx_backups.cidr along with the DNS in the future. I looked at the
> permit_mx_backup option but the documentation explicitly states that
> "permit_mx_backup no longer accepts the address when the local mail
> system is primary MX for the recipient domain" which is exactly the case
> here.
>
> Is there a way to automate this configuration in some way, or what I
> have is as good as it can get?
It might be doable in a somewhat reliable fashion by means of policy
delegation and a few lines of your favourite programming language.
My recommendation, however, would be to get rid of the backup MX
altogether if you need to work around its limitations like that. Life
without a backup MX isn't as bad as you probably imagine. :-)
-martin
--
Martin Schmitt - Schmitt Systemberatung - http://www.scsy.de
DE 35415 Pohlheim, Gießener Str. 18
DE 65307 Bad Schwalbach, Am Bräunchesberg 9
Linux/UNIX - Internet - E-Mail Infrastructure - Antispam/Antivirus
- "What goes up, must come down. Ask any system administrator." -
Peter Rabbitson
> Peter Rabbitson schrieb:
>
>> I was wondering if it is possible to replace it with some check that
>> would simply verify if the client is a listed MX, removing the need to
>> update mx_backups.cidr along with the DNS in the future. I looked at the
>> permit_mx_backup option but the documentation explicitly states that
>> "permit_mx_backup no longer accepts the address when the local mail
>> system is primary MX for the recipient domain" which is exactly the case
>> here.
>>
>> Is there a way to automate this configuration in some way, or what I
>> have is as good as it can get?
>
> It might be doable in a somewhat reliable fashion by means of policy
> delegation and a few lines of your favourite programming language.
This is a cool idea, I will give it a try.
> My recommendation, however, would be to get rid of the backup MX
> altogether if you need to work around its limitations like that. Life
> without a backup MX isn't as bad as you probably imagine. :-)
>
A backup MX is not a necessarily evil thing. It helps get mail when the
primary MX is down for maintenance or other reasons, and the sending
SMTP has some insane retry times in the order of hours (more often than
not from what I have observed). It really pleases the management when a
postfix flush gets them their mail immediately after a problem has been
resolved, instead of being at the mercy of an unknown remote SMTP server.
Peter Rabbitson
policy server. Here is what it does:
* Extracts the domain of 'recipient' (takes everything to the right of
the last @)
* Builds a list of all A records of all MX records of the extracted
domain name
* Checks if 'client_address' matches any of the resolved A records
* If a match is found returns action=PERMIT otherwise action=DUNNO
reject_unauth_destination is placed in front of the
check_policy_service, ensuring that PERMIT can potentially be returned
only for final destination or relayed messages, that come from one of
our MXes.
Thanks
Peter
Erwan David
> Hi,
>
> On 8/14/07, Martin Schmitt <m...@scsy.de> wrote:Peter Rabbitson schrieb:
> > I wanted to make sure I am doing the right thing before I deploy my
> > policy server. Here is what it does:
>
> in MX?
> MX are for incoming mail pourposes, and for example in my installation we
> have differentiated incoming mail servers (MX) and outgoing mail servers
> (not mandatory, but listed in SPF records).
> What are your intentions deploying this policy server?
Many ISP have separate ingoing and outgoing email servers, in order to
distribute the load.
Even the small company ( ~60 people) I work for has different outgoing and
incoming servers.
--
Erwan
Peter Rabbitson
> Hi,
>
> On 8/14/07, *Martin Schmitt* <m...@scsy.de <mailto:m...@scsy.de>>
> wrote:Peter Rabbitson schrieb:
> > I wanted to make sure I am doing the right thing before I deploy my
> > policy server. Here is what it does:
>
> listed in MX?
> MX are for incoming mail pourposes, and for example in my installation
> we have differentiated incoming mail servers (MX) and outgoing mail
> servers (not mandatory, but listed in SPF records).
> What are your intentions deploying this policy server?
>
My apologies, I didn't realize I trimmed the entire original thread. The
original problem is stated here:
http://groups.google.com/group/list.postfix.users/browse_frm/thread/859e117f7b87df8b/2488d7230b969a32
Jan P. Kessler
Hi Peter,
maybe you should include some sort of caching. Otherwise multi-recipient
messages may lead to very high load/io. There will be 100 queries for a
message to 100 recipients.
To achive this efficiently your policy server should not be invoked by
spawn. If you implement your own listener I'd recommend a non-forking
(multiplexing) type. So you don't have to bother with IPC or other
things for cache exchange between children. Net::Server::Multiplex does
a nice job for that.
Regards, Jan
Jan P. Kessler
> Jan P. Kessler:
>
>>
>> Hi Peter,
>>
>> maybe you should include some sort of caching. Otherwise multi-recipient
>> messages may lead to very high load/io. There will be 100 queries for a
>> message to 100 recipients.
>>
>
> process. Postfix doesn't run one process per query.
>
> Wietse
>
Yes of course. Maybe I should have been more detailed:
1.) As long as you don't gather multiple requests and compare their
recipient domains, there will be 100 queries to perform for a 100
recipient mail. This is imo far too much - even for DNS caches (well of
course this might depend on your infrastructure and the amount of
traffic you have to deal with). So maybe it would be better to have some
sort of caching.
2.) Caching-Caveeats: Of course spawn does not create a new process per
mail. But there will be multiple processes (nearly as many as smtpds,
right?) and as long as you don't want to deal with interprocess
communication, these spawned processes can't share a single cache, which
is not that effective. With a single, multiplexing daemon this will be
easy to achive (but do not forget to wipe old cache entries - you don't
want to create memleaks).
Don't get me wrong - spawn is a great feature (you don't have to deal
with all that socket stuff) but in my opinion not the right thing for
that task.
Regards, Jan