Why forwarding is a Bad Thing

[Jim Reid]

>>>>> "Kevin" == Kevin Darcy <kcd at daimlerchrysler.com> writes:

    Kevin> As Jim knows, I happen to advocate the use of wildcard MX
    Kevin> records for outbound mail routing in an internal-root
    Kevin> context.

And as Kevin knows, I don't.

    Kevin> What I think Jim
    Kevin> may fail to appreciate, however, is that I advocate it for
    Kevin> many of the *same* reasons that I advocate *against*
    Kevin> forwarding -- because it centralizes mail routes (_roughly_
    Kevin> analogous to name-resolution paths) in a single place,
    Kevin> where there is a higher probability of competent
    Kevin> administration. Just as I shudder at the thought of junior
    Kevin> admins all over the enterprise configuring all sorts of
    Kevin> screwy, hard-coded, undocumented forwarding kruft, I
    Kevin> shudder at the though of junior admins all over the
    Kevin> enterprise configuring all sorts of screwy, hard-coded,
    Kevin> undocumented mail routing kruft. I'd rather centralize the
    Kevin> top-level delegation information *and* the top-level mail
    Kevin> routing information (wildcard MXes) somewhere where I can
    Kevin> keep a watchful eye on it. 

If a properly designed mail architecture is deployed, it's easy to do
this without the need for complex mail setups or, worse, fouling up
the DNS with wildcards. [The initial question was about wildcarding in
general, not just wildcard MX records.] For example in most mail
systems, it is trivial to configure them to send all non-local mail
(for some definition of local) to a smart mail relay. It's even
possible to provide and document company standard configurations for
those setups. The smart mail relays would be operated by the
organisation's clueful mail people. ie The complexity and intelligence
about mail routing and relaying is handled by the systems and people
that have the resources and skills to do that job reliably.