From: mouss (no email)
Date: Fri Sep 05 2008 - 07:53:24 EDT
Paul Cocker wrote:
> I'm setting up a postfix 2.3.3 mail server which is to be the primary
> outgoing mail server and act as a secondary incoming mail server for
> three domains (only one of which is of any real size).
> I haven't used postfix before so I'm wading through the configuration
> and documentation and without having any special requirements most of
> the defaults appear sane.
Make sure to read the doc on
> So far as I understand it I will need to configure the following
> Mydestination - to allow it to collect mail on behalf of my domains
mydestination is the list of "local" domains: mail is delivered to unix
accounts on this machine.
> Mynetworks - so it knows where internal mail will be coming from
these are networks you control and trust. by default, they are allowed
to relay via the server (there is a permit_mynetworks in the default
smtpd_recipient_restrictions). if the box need not relay mail for other
machines, just set
mynetworks = 127.0.0.1
> Both of those seem simple enough, my question is about having it as the
> secondary MX record. Is there a parameter you need to configure to tell
> postfix it is to pass e-mail to the top of the MX chain, or will it do a
> name lookup and discover this for itself?
if you want this, don't put the domain in mydestination. put the domain
relay_domains, and put the list of valid addresses in relay_recipient_maps.
the list of valid recipients is required to avoid backscatter (later
bounces when your postfix finds out that the address doesn't exist, but
since spammers forge the sender address, the bounce goes to an
innocent). see the BACKSCATTER README
An alternative is to use reject_unverified_recipient at the end of
smtpd_recipient_restrictions. but you'd better avoid this. in particular
if you are talking about a "backup MX", reject_unverified_recipient may
fail (it checks the cache, but otherwise asks the other server. the last
action will obviously fail if the final server is down). if you insist,
check the docs about reject_unverified_recipient and other *_verify_*
parameters (all parameters are documented on
> Is there anything else I need to take into consideration or configure?
> Beyond chroot that is, which is something I will investigate next.
don't chroot untill everything works as desired.
More generally, don't bang bang. go step by step. change one thing, test
the results, document that somewhere, then go for the next change. while
this may be boring, you'll have a working configuration all the time, it
makes it troubleshooting easier, and you have a documentation of
everything you did (so if the machine dies, you can reproduce the steps.
and if you go on vacation, quit or hire someone else, he can does the job).