Noel Jones wrote:
DJ Lucas wrote:
Hi guys, I believe that I already have the answer to this pretty
basic setup, but I just wanted to do a quick sanity check.
I'm setting up a backup MX, and for one of the domains that it will
relay to, it should do no filtering whatsoever as there is a Symantec
device in front of the primary. The device is configured with a
catch-all, and I have verified that no backscatter is generated when
sending to an invalid address, and the admin of that server wants to
review everything coming at him.
The other three domains are very small, servicing less than 80 users
total. I had planned to validate the recipient addresses via hash
tables...I can automatically generate these..in fact probably only
one table need be present for (I think) only something like 74 users.
Carefully consider if a backup MX is really needed... They are nothing
but spam magnets.
Make sure the symantec gateway really eats *everything* thrown at it.
Anything it rejects will cause you to generate a bounce. Send enough
bogus bounces and YOU will get blacklisted.
I honestly don't care about getting blacklisted as this server should
never send to anything but the 4 mail hosts, however, I do care about
adding to the amount of junk messages flying about. I've tested pretty
thoroughly (AFAICT with self-made junk messages, even faked backscatter
attempts) and have been unable to get a 4xx or 5xx response from it
unless the target domain is unknown.
Did you read the postfix docs about setting up a backup MX?
http://www.postfix.org/STANDARD_CONFIGURATION_README.html#backup
Yes, hence the mention of relay_recipient_maps below, which is why I
chose to go with access maps, and ask about the lack of
relay_recipient_maps. I guess I probably should just go ahead and add
one anyway, the access maps would be generated by cron anyway, so no
biggie to add two more commands to the job and meet the expectation,
though I asked about the necessity in my other response to mouss.
<Snip>
Since you're using this as an access map, you'll need to explicitly
reject the ones that don't match. Add:
example1.com REJECT 5.1.1 no recipient by that name
example2.com REJECT 5.1.1 no recipient by that name
example3.com REJECT 5.1.1 no recipient by that name
OK..noted.
# Validate recipients (except for example.com) and do normal checks
smtpd_recipient_restrictions =
reject_unauth_destination should go here.
OK. TY.
check_recipient_access hash:/etc/postfix/example.com,
OK, example.com is whitelisted from further checks.
reject_non_fqdn_sender,
reject_unauth_pipelining,
reject_unauth_pipelining is ineffective here. Put it under
smtpd_data_restrictions instead.
Yes, mentioned in previous thread. Had it in the wrong place in my own
config too, and was even told about it previously, though I missed the
connection due to further conversation in the threads. Thanks for
spelling it out.
reject_unknown_recipient_domain
This will never fire - you've accepted the domains you relay for, and
rejected the ones you don't. Nothing is left.
Removed. Thanks.
Also, this server will handle no mail locally. I explicitly ignored
'permit_mynetworks'.
Usually one would set "mynetworks = 127.0.0.1" and use
permit_mynetworks, but this isn't a requirement.
Thinking again on that one, it'd be nice for cron jobs to be able to
notify me of problems. :-) Added.
I simply use the internal domain name of the site that it is at,
since it is not resolvable from the outside world
(backupmx.mailhost.local). Additionally, I did not use
relay_recipient_maps, is it still required with the suggested
configuration?
While it's usually better to stick with the "standard" config, you're
OK as is. You should probably document what you've done so you
remember what you did and why 10 months from now.
In light of that note, I'll be gracious with the comments, and since it
is the expected configuration, I'll go ahead and add the
relay_recipient_maps (though IIUC, it'll never be used). I'm not really
concerned for myself. I will have it documented locally. But, should I
get run over by a bus... :-)
Next question, and down to the real purpose of this server's existence,
is there any gotchas about tweaking the retry times? I had planned to
drop the minimal_retry_time to 60s (accounting for server reboots and
the lot), and the maximal_retry_time to 1800s (30 min). If it is within
my control (barring any ISP problems) I will not let one of those hosts
be down for more than a couple of hours at absolute worst.
Thanks for the tips.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
