On Tue, 2004-12-21 at 09:42 +0100, Giuliano Gavazzi wrote:
> I am going to add a domain to relay on one of my servers and
> naturally have been asking myself what method to use to check for the
> recipient. Clearly recipient callout is an option but if the local
> part is not cached it will temporarily fail (when the primary is
> unreachable; the rest is spam...).
> So, what about using dns records?
It works for me, albeit slightly differently.
For a start, I don't put it in the 'example.com' domain -- I put it in a
private 'example.com.mail' domain which is slaved on all the MX hosts
but not directly visible in the outside world. I never did understand
why people want to abuse the public namespace (including abominations
like having different 'views' of example.com depending in whether you're
inside or outside the company at the time, instead of just the public-
facing 'example.com' and a nice, simple, separate 'example.internal').
You can also use Dynamic DNS to allow people to update aliases at
virtual domains which they own, and with a suitable tool which is setuid
to get at the DDNS key, to allow users to update their _own_ address.
See
http://david.woodhou.se/eximconf/include/routers-dns-virtual
It expects a file in CONFDIR/conf/DNS_VIRTUAL which has a lookup from
the mail domain name to the DNS domain in which to look up the aliases
-- so in your case it might simply be:
example.com:lusers.example.com
If the forwarding address has no @ sign it's taken to be a new localpart
at the same original domain -- if it _starts_ with an @ sign, then the
same localpart is used at the newly-provided domain. Multiple addresses
can be comma-separated.
So where your example had a '1' you may use "@mailhost.example.com".
Where your example had a failure, you may use ":fail:not here anymore"
in your TXT record.
Note that I special-case the 'postmaster' localpart. If you don't
special-case that in your routers, you need to make sure it's in the
DNS.
> Opinions?
For virtual domains, this is useful because it lets _each_ MX host
forward the mail to its ultimate destination. They're not just backup MX
hosts waiting for the primary to come back up; I adjust the priorities
purely according to the available network bandwidth and CPU.
For just MX backup, if all the mail is _actually_ going the same way
anyway, it's probably overkill. You might as well just include
'require verify=recipient/callout/use_sender/defer_ok' in your RCPT ACL
for the domains in question. _Most_ of the time the primary will be up
and you'll reject mail which it would reject. Only occasionally will you
accept something you shouldn't, and have to bounce it.
More important it to make sure your content checks are in sync. Make
sure the primary isn't going to reject anything on the basis of its
_content_, which your backup is willing to accept.
--
dwmw2
