Wildcards in MX Record Domain Names
Robert Setterlund
*.org IN MX 10 firewallrelay.mayo.org
*.gov IN MX 10 firewallrelay.mayo.org
*. IN MX 10 firewallrelay.mayo.org
These were supported in earlier versions but I have heard the support
was dropped
in version 8.
Cricket Liu
>
> *.org IN MX 10 firewallrelay.mayo.org
> *.gov IN MX 10 firewallrelay.mayo.org
> *. IN MX 10 firewallrelay.mayo.org
Yes.
> These were supported in earlier versions but I have heard the support
> was dropped in version 8.
No.
cricket
Acme Byte & Wire
cri...@acmebw.com
www.acmebw.com
Attend the next Internet Software Consortium/Acme Byte & Wire
DNS and BIND class! See www.acmebw.com/training.htm for
the schedule and to register for upcoming classes.
Joseph S D Yao
> Are the below MX records supported in Bind 8.X?
>
> *.org IN MX 10 firewallrelay.mayo.org
> *.gov IN MX 10 firewallrelay.mayo.org
> *. IN MX 10 firewallrelay.mayo.org
Yes. But this is probably not the right way of doing this. You should
really put a relay host into your sendmail.cf file, to send all
non-local e-mail to your firewall.
--
Joe Yao js...@cospo.osis.gov - Joseph S. D. Yao
COSPO/OSIS Computer Support EMT-B
-----------------------------------------------------------------------
This message is not an official statement of COSPO policies.
Kevin Darcy
> On Fri, Dec 10, 1999 at 11:16:40AM -0500, Robert Setterlund wrote:
> > Are the below MX records supported in Bind 8.X?
> >
> > *.org IN MX 10 firewallrelay.mayo.org
> > *.gov IN MX 10 firewallrelay.mayo.org
> > *. IN MX 10 firewallrelay.mayo.org
>
> Yes. But this is probably not the right way of doing this. You should
> really put a relay host into your sendmail.cf file, to send all
> non-local e-mail to your firewall.
Why? Is it easier to custom-configure dozens or hundreds of sendmail.cf's
than it is one master file on an internal root server? And what if you
want redundancy or load-balancing for outbound email? Sure, you could
probably hack that logic into the sendmail.cf too, but why bother when you
can just add a few more MX records to the internal root?
Plus, you're assuming they're running sendmail or something equally
manipulable...
- Kevin
Kevin Darcy
> >>>>> "Kevin" == Kevin Darcy <k...@daimlerchrysler.com> writes:
>
> >> > *.org IN MX 10 firewallrelay.mayo.org
> >> > *.gov IN MX 10 firewallrelay.mayo.org
> >> > *. IN MX 10 firewallrelay.mayo.org
> >> Yes. But this is probably not the right way of doing this.
> >> You should really put a relay host into your sendmail.cf file,
> >> to send all non-local e-mail to your firewall.
>
> Kevin> Why? Is it easier to custom-configure dozens or hundreds of
> Kevin> sendmail.cf's than it is one master file on an internal
> Kevin> root server? And what if you want redundancy or
> Kevin> load-balancing for outbound email? Sure, you could probably
> Kevin> hack that logic into the sendmail.cf too, but why bother
> Kevin> when you can just add a few more MX records to the internal
> Kevin> root?
>
> Because fixing the mail systems is the Right Thing to do.
Fixing? Circumventing the MX routing mechanism is a fix? I think that
cure is worse than the disease.
> After all
> it's them that are broken, not the DNS.
Broken in what way? I think using MX records is a perfectly valid way to
route mail. It seems to work fine for the Internet, why not intranets as
well? And it means your internal mailer configurations can be based on
the same routing paradigm as an Internet-connected mailer, which is
easier for some Internet-oriented junior admins to comprehend. Firewalls,
as usual, are often an exception here.
> It's also not a good idea to
> pollute your internal root zone with this sort of cruft, especially
> wildcard MX records.
I don't see this as pollution, or at worst, relatively benign pollution.
All I have in my internal root zone (other than the mandatory stuff like
SOA and NS records of course) are wildcard MX'es and delegations. Not
very crufty. And any admin trying to troubleshoot a mail routing problem
can just do an MX query anywhere on the network to see how their mail is
being routed, instead of having to parse out the smarthost name from a
sendmail.cf.
> It sets a precedent. When the next item of
> defective or misconfigured software comes along, you don't have a
> strong justification to refuse to kludge the DNS for that as well. If
> you're not careful, your root zone will end up in a mess of kludges
> and hacks that are hard to maintain or understand.
Well, mail routing is the only mechanism I can think of which has its own
record type in DNS apart from a generic name-to-address or
address-to-name mapping, and about which one might conceivably want to
"lie" in an internal-root context. If SRV or some other record type ever
evolves to this stage, then I would definitely reconsider my methodology.
But for the foreseeable future, MX'es are the only record type which get
"special" treatment in my internal root zone.
> These might also be
> interdependent in subtle and weird ways. The wildcarding could even
> break. Suppose you then have to add an A record for an external web
> site - say ibm.com - to your root zone because of some other broken
> application or stupid misconfiguration. Now the idiot mailers can't
> send mail to ibm.com because the A record for ibm.com will take
> precedence over the *.com MX wilcard. The more cruft that goes into
> the root zone, the worse that problem becomes.
Hmmm... Running an internal root zone pretty much assumes you have no
need to resolve external names in the first place, doesn't it? I'd never
need an A record for ibm.com since there is no way anyone internal can
connect to it (they'd have to go through an application proxy instead),
and therefore I never have these kinds of A-vs-MX conflicts. If someone
is polluting their internal root with unnecessary A records, then I think
they have a systemic problem and MX records aren't the only things that
are going to suffer from it.
> Sure, adding the wildcard MX records to the root zone is a quick and
> dirty hack. It's definitely much quicker to do than fix every internal
> mail system. However the long-term costs of maintaining and supporting
> this set-up are probably going to be far higher than the costs of
> doing things right from the outset. Just think of the extra (and
> unnecessary) complexity in the root zone and all the nasty problems
> that could flow from that name space pollution. And once you've
> started down that slippery slope, it's very hard to go back. Removing
> legacy cruft from the root zone can be almost impossible. Once it's
> there, people will use and abuse it for all sorts of things.
Well, as I said, I've made a special case for MX records, because we
happen to have software which can put them to a good and valid use.
I hold the line on everything else, and so my root zone is relatively
cruft-free. As for maintenance costs, we have hundreds of sendmail
instances internally which are quite happy just relying on MX records
than with some "smarthost" forward-up-the-line kind of configuration that
offers less options for load-balancing or redundancy. Since I'm
responsible for both the SMTP routing and the DNS architecture around
here, I find this to be the best of both worlds. Low maintenance,
relatively headache-free. I haven't had any reason to change my root zone
*or* make any major changes to a production sendmail.cf for months (and
the minor sendmail.cf change was only necessary because I like to keep
the Solaris sendmail.cf's as much in synch with the vendor-supplied
version as possible).
> Kevin> Plus, you're assuming they're running sendmail or something
> Kevin> equally manipulable...
>
> True. But even the most brain-dead mail software will usually have an
> option somewhere to forward mail via SMTP to a smart relay. "I'm too
> stupid or inflexible to route mail properly, but I know how to punt
> stuff to another mail server that can do this for me." In fact some
> of these idiot mail systems might not even need to be configured to
> know about MX records or use the DNS at all.
Point well taken, but this is my biggest gripe about such brain-dead mail
systems. Their lack of MX-awareness severely impairs their ability to
sanely do failover and/or load-balancing. Strategically, I think it's
better to hammer on the vendors to make their mailers MX-aware than to
dumb down one's own mail routing paradigm to the lowest common
denominator. They *have* to become MX-aware anyway, if anyone is going to
use them as Internet mail gateways, so it's in everybody's interests to
speed up that evolution.
- Kevin
Jim Reid
Kevin> Why? Is it easier to custom-configure dozens or hundreds of
Kevin> sendmail.cf's than it is one master file on an internal
Kevin> root server? And what if you want redundancy or
Kevin> load-balancing for outbound email? Sure, you could probably
Kevin> hack that logic into the sendmail.cf too, but why bother
Kevin> when you can just add a few more MX records to the internal
Kevin> root?
>> Because fixing the mail systems is the Right Thing to do.
Kevin> Fixing? Circumventing the MX routing mechanism is a fix?
And you think polluting your root zone with cruft because broken or
stupid mail systems can't be configured properly for an intranet is a
fix? :-)
Kevin> I think that cure is worse than the disease.
We'll have to agree to differ about that.
>> After all it's them that are broken, not the DNS.
Kevin> Broken in what way? I think using MX records is a perfectly
Kevin> valid way to route mail. It seems to work fine for the
Kevin> Internet, why not intranets as well?
I didn't say there was anything wrong with MX records, far from it.
What I did say was wrong is kludging your name space - and the root
zone in particular - because broken software mistakenly believes it is
on the Internet. [If someone put a gun to my head, I'd do this. But I
would *never* do it through choice. I've seen the problems - largely
self-inficted - this has caused some sites.] And for these broken mail
systems, there is an alternative: get them to punt their mail at
relays that can walk and chew gum at the same time. Fix the underlying
problem at source and all that.
>> It's also not a good idea to pollute your internal root zone
>> with this sort of cruft, especially wildcard MX records.
Kevin> I don't see this as pollution, or at worst, relatively
Kevin> benign pollution. All I have in my internal root zone
Kevin> (other than the mandatory stuff like SOA and NS records of
Kevin> course) are wildcard MX'es and delegations. Not very
Kevin> crufty. And any admin trying to troubleshoot a mail routing
Kevin> problem can just do an MX query anywhere on the network to
Kevin> see how their mail is being routed, instead of having to
Kevin> parse out the smarthost name from a sendmail.cf.
True, but with smart mail relays, this approach isn't necessary. If
you've gone to the trouble of running an internal root to close off
the outside world, why re-introduce the outside world in the form of
wildcard MX records for TLDs and anything else that takes your fancy?
Doesn't that seem a little odd?
>> It sets a precedent. When the next item of defective or
>> misconfigured software comes along, you don't have a strong
>> justification to refuse to kludge the DNS for that as well. If
>> you're not careful, your root zone will end up in a mess of
>> kludges and hacks that are hard to maintain or understand.
Kevin> Well, mail routing is the only mechanism I can think of
Kevin> which has its own record type in DNS apart from a generic
Kevin> name-to-address or address-to-name mapping, and about which
Kevin> one might conceivably want to "lie" in an internal-root
Kevin> context.
The issue here is names and naming, not record types. How many "lies"
have to be put in your root zone and how easy is it to control and
maintain that conspiracy? [How much of the outside world are you
prepared or obliged to replicate in the internal root?] Eventually
this approach will break down. If it works for you at present, then
that's fine. It's your net and your name space after all. It wouldn't
be my choice, but then again I'm not running your net.
>> These might also be interdependent in subtle and weird
>> ways. The wildcarding could even break. Suppose you then have
>> to add an A record for an external web site - say ibm.com - to
>> your root zone because of some other broken application or
>> stupid misconfiguration. Now the idiot mailers can't send mail
>> to ibm.com because the A record for ibm.com will take
>> precedence over the *.com MX wilcard. The more cruft that goes
>> into the root zone, the worse that problem becomes.
Kevin> Hmmm... Running an internal root zone pretty much assumes
Kevin> you have no need to resolve external names in the first
Kevin> place, doesn't it? I'd never need an A record for ibm.com
Kevin> since there is no way anyone internal can connect to it
I was using ibm.com as an example of what can go wrong if you start
adding cruft to the existing situation. Just suppose the Big Boss
demands you add such a name - he/he isn't interested in proxy servers
and wants to get to some important web site on the Internet. Now. What
do you say, "sorry, I can't because the company's email will break"?
Kevin> (they'd have to go through an application proxy instead),
Kevin> and therefore I never have these kinds of A-vs-MX
Kevin> conflicts. If someone is polluting their internal root with
Kevin> unnecessary A records, then I think they have a systemic
Kevin> problem and MX records aren't the only things that are
Kevin> going to suffer from it.
Indeed. But where we differ is where we draw the line. IMHO, adding
wildcard MX records for external names is already a step too far.
Kevin> Well, as I said, I've made a special case for MX records,
Kevin> because we happen to have software which can put them to a
Kevin> good and valid use. I hold the line on everything else,
Kevin> and so my root zone is relatively cruft-free.
Fine. I hope it remains straightforward to keep the lid on this can of
worms, sorry I mean "special case".
DNS Administration
> >>>>> "Kevin" == Kevin Darcy <k...@daimlerchrysler.com> writes:
>
> Kevin> Why? Is it easier to custom-configure dozens or hundreds of
> Kevin> sendmail.cf's than it is one master file on an internal
> Kevin> root server? And what if you want redundancy or
> Kevin> load-balancing for outbound email? Sure, you could probably
> Kevin> hack that logic into the sendmail.cf too, but why bother
> Kevin> when you can just add a few more MX records to the internal
> Kevin> root?
> >> Because fixing the mail systems is the Right Thing to do.
>
> Kevin> Fixing? Circumventing the MX routing mechanism is a fix?
>
> And you think polluting your root zone with cruft because broken or
> stupid mail systems can't be configured properly for an intranet is a
> fix? :-)
The mail systems are only "broken" or "stupid" if they can't get the job
done. But they *can* get the job done, using MX records, with a minimum
of muss and fuss, so are they really "broken" or "stupid", and do they
really need to be "fixed"? And if the "brokenness" or
"stupidity" consists only of the requirement to "pollute" the
internal-root zone with wildcards, then this strikes me as a bit of a
circular argument.
(Yes, I see the smiley, but in context I took it as a half-smiley at
most).
> Kevin> I think that cure is worse than the disease.
>
> We'll have to agree to differ about that.
>
> >> After all it's them that are broken, not the DNS.
>
> Kevin> Broken in what way? I think using MX records is a perfectly
> Kevin> valid way to route mail. It seems to work fine for the
> Kevin> Internet, why not intranets as well?
>
> I didn't say there was anything wrong with MX records, far from it.
> What I did say was wrong is kludging your name space - and the root
> zone in particular - because broken software mistakenly believes it is
> on the Internet.
I guess it's a matter of perspective, then. To me, a mailer that relies
on MX records isn't suffering from some sort of delusion that it's on the
Internet; it is simply trying to use a particular facility to route its
mail. The fact that this happens to be the same mail-routing facility as
the predominant one on the Internet is just a happy coincidence. Now, if
one chooses to implement that facility on one's intranet, fine. If one
chooses to use some other mail-routing facility or methodology, then
that's fine too, although I prefer MX routing because of the central
administration, flexibility and fault-tolerance. But I don't see anything
fundamentally "broken" or "wrong" with either approach.
> [If someone put a gun to my head, I'd do this. But I
> would *never* do it through choice. I've seen the problems - largely
> self-inficted - this has caused some sites.] And for these broken mail
> systems, there is an alternative: get them to punt their mail at
> relays that can walk and chew gum at the same time. Fix the underlying
> problem at source and all that.
And my viewpoint is that if wildcard TLD MX'es have caused problems at
some sites, it's not because the concept is fundamentally wrong, but
because it was not implemented correctly.
> >> It's also not a good idea to pollute your internal root zone
> >> with this sort of cruft, especially wildcard MX records.
>
> Kevin> I don't see this as pollution, or at worst, relatively
> Kevin> benign pollution. All I have in my internal root zone
> Kevin> (other than the mandatory stuff like SOA and NS records of
> Kevin> course) are wildcard MX'es and delegations. Not very
> Kevin> crufty. And any admin trying to troubleshoot a mail routing
> Kevin> problem can just do an MX query anywhere on the network to
> Kevin> see how their mail is being routed, instead of having to
> Kevin> parse out the smarthost name from a sendmail.cf.
>
> True, but with smart mail relays, this approach isn't necessary.
How "smart" is the relay if it can't failover or load-balance its
outbound Internet gateways? Sure, it's *possible* for a relay to just
"punt" mail, but is that *preferable* if you have the option of using
MX records? You seem to be valuing the abstract "purity" of internal-root
zones over the concrete benefits of MX-based routing for outbound
Internet mail. I think I'm being more pragmatic in this respect: an
internal root zone isn't created just to sit there and look pretty; it's
created to work and create value for the enterprise, and if that means it
needs to get a little dirty and "polluted" in order to reap the benefits
of MX-based routing, then so be it.
> If
> you've gone to the trouble of running an internal root to close off
> the outside world, why re-introduce the outside world in the form of
> wildcard MX records for TLDs and anything else that takes your fancy?
> Doesn't that seem a little odd?
No, not really. MX records just tell a mailer who handles mail for a
particular name or set of names. It's not a "lie" to say that gateway
X on my intranet handles mail for "ibm.com": it's the god-honest truth.
See, that's why MX records are fundamentally different conceptually from
A records -- they don't describe a *thing*, only a way to get somewhere;
more like directions to a house than a house itself. So it doesn't bother
me in the least that my MX records for a name or set of names differ from
the Internet's; because the reality is that the way of getting mail to
that organization from a mailer on my intranet is different from the way
that same mailer would deliver it if it were directly connected to the
Internet (okay, admittedly, one route is a *superset* of the other, but
they're still different ways).
> >> It sets a precedent. When the next item of defective or
> >> misconfigured software comes along, you don't have a strong
> >> justification to refuse to kludge the DNS for that as well. If
> >> you're not careful, your root zone will end up in a mess of
> >> kludges and hacks that are hard to maintain or understand.
>
> Kevin> Well, mail routing is the only mechanism I can think of
> Kevin> which has its own record type in DNS apart from a generic
> Kevin> name-to-address or address-to-name mapping, and about which
> Kevin> one might conceivably want to "lie" in an internal-root
> Kevin> context.
>
> The issue here is names and naming, not record types. How many "lies"
> have to be put in your root zone and how easy is it to control and
> maintain that conspiracy? [How much of the outside world are you
> prepared or obliged to replicate in the internal root?]
Only TLD MX wildcards, until someone can demonstrate to me that there are
tangible benefits -- like failover and load-balancing options -- to
adding any other kind of records.
> Eventually this approach will break down.
Not if you set the proper pain-vs.-gain threshold. Our wildcards right
now benefit us much more than they cost in maintenance and/or complexity
costs. I'm not going to add anything else just because J. Random User or
even J. Random Manager thinks it would be a neat idea. I can articulate
the value of MX-based routing in management-speak that gets heard,
understood and accepted. And likewise, I can articulate the value of
NOT adding other kinds of data to the internal root zone. The cruft stops
here.
> If it works for you at present, then
> that's fine. It's your net and your name space after all. It wouldn't
> be my choice, but then again I'm not running your net.
>
> >> These might also be interdependent in subtle and weird
> >> ways. The wildcarding could even break. Suppose you then have
> >> to add an A record for an external web site - say ibm.com - to
> >> your root zone because of some other broken application or
> >> stupid misconfiguration. Now the idiot mailers can't send mail
> >> to ibm.com because the A record for ibm.com will take
> >> precedence over the *.com MX wilcard. The more cruft that goes
> >> into the root zone, the worse that problem becomes.
>
> Kevin> Hmmm... Running an internal root zone pretty much assumes
> Kevin> you have no need to resolve external names in the first
> Kevin> place, doesn't it? I'd never need an A record for ibm.com
> Kevin> since there is no way anyone internal can connect to it
>
> I was using ibm.com as an example of what can go wrong if you start
> adding cruft to the existing situation. Just suppose the Big Boss
> demands you add such a name - he/he isn't interested in proxy servers
> and wants to get to some important web site on the Internet. Now. What
> do you say, "sorry, I can't because the company's email will break"?
If, hypothetically, such a thing were to transpire, I could always create
lower-level MX wildcards (*.ibm.com or whatever) to accommodate the
"intruding" A record. So it's an ugly problem, but not an intractable
one. Such a requirement is highly unlikely to arise, though, since we
have a strict security policy in place against direct connections to the
Internet, and, frankly, not a lot of infrastructure that could support
such a thing. Last I checked, our routers didn't even have default routes
pointing in that direction. So it wouldn't just be a DNS change; it'd be
a major infrastructure change.
> Kevin> (they'd have to go through an application proxy instead),
> Kevin> and therefore I never have these kinds of A-vs-MX
> Kevin> conflicts. If someone is polluting their internal root with
> Kevin> unnecessary A records, then I think they have a systemic
> Kevin> problem and MX records aren't the only things that are
> Kevin> going to suffer from it.
>
> Indeed. But where we differ is where we draw the line. IMHO, adding
> wildcard MX records for external names is already a step too far.
Well, if the only technical reason for not adding the wildcards is to
prevent any potential conflicts with fake Internet A records, aren't you
*inviting* a greater evil? I'd rather tell the Big Boss that his A record
is going to break email unless $XXX,XXX is paid to redo our
infrastructure than to admit that I've carefully paved the way for its
addition, and, oh yes, feel free to have me create others so I can
maintain that cruft for the rest of my life. Sometimes the best answer is
a negative answer, regardless of whom it pisses off. And, as every good
DNS admin knows, the TTL for a negative cache entry is almost always
shorter than for a positive one :-)
> Kevin> Well, as I said, I've made a special case for MX records,
> Kevin> because we happen to have software which can put them to a
> Kevin> good and valid use. I hold the line on everything else,
> Kevin> and so my root zone is relatively cruft-free.
>
> Fine. I hope it remains straightforward to keep the lid on this can of
> worms, sorry I mean "special case".
It has been so far. I guess some organizations are better at securing
worm-can-lids than others. Part of the secret is to ensure the worms
don't know anything exists outside of their can. :-)
- Kevin
Joseph S D Yao
> Joseph S D Yao wrote:
>
> > On Fri, Dec 10, 1999 at 11:16:40AM -0500, Robert Setterlund wrote:
> > > Are the below MX records supported in Bind 8.X?
> > >
> > > *.gov IN MX 10 firewallrelay.mayo.org
> > > *. IN MX 10 firewallrelay.mayo.org
> >
> > Yes. But this is probably not the right way of doing this. You should
> > really put a relay host into your sendmail.cf file, to send all
> > non-local e-mail to your firewall.
>
> than it is one master file on an internal root server? ...
This response assumes that in a network it is easier to configure DNS
properly all over than it is to configure sendmail all over. Mine
assumed the opposite. Different experiences.
Both have the same goal: to get the internal mail servers to send
"non-local" [for some definition of "non-local"] e-mail to the firewall
for relaying to the Big Bad Internet.
The "better" one would be whichever one better fits the "truth". It's
always easier to maintain a consistent story if you're telling the
truth. ;-) And, "Say What You Mean" is Joe's First Law of Software
Engineering. My first impression was that the MX trick, above, violated
this. But within its domain, as Kevin has pointed out, it does NOT. It
is true.
I will continue to use my sendmail configuration, since it suits my
needs better. [Everybody thinks they can meddle with DNS at their whim.
Everybody is afraid to touch sendmail.cf. ;-)] I do note that one
advantage to the MX solution is that one can specify failover firewalls
with that, but not with the sendmail relay.
Jim Reid
Joseph> The "better" one would be whichever one better fits the
Joseph> "truth". It's always easier to maintain a consistent
Joseph> story if you're telling the truth. ;-) And, "Say What You
Joseph> Mean" is Joe's First Law of Software Engineering. My
Joseph> first impression was that the MX trick, above, violated
Joseph> this. But within its domain, as Kevin has pointed out, it
Joseph> does NOT. It is true.
Not really. At best, it's a controlled lie.
The point is that an internal root implies there is no need to resolve
external names. (Save for things like firewalls and proxy servers at
the perimiter net.) So if someone has decided to implement this, why
should they re-introduce external names to the internal name space?
Joseph> I will continue to use my sendmail configuration, since it
Joseph> suits my needs better. [Everybody thinks they can meddle
Joseph> with DNS at their whim. Everybody is afraid to touch
Joseph> sendmail.cf. ;-)]
Hmmm. Maybe DNS zone files should have a more complex and obscure
syntax so that people don't meddle with them so readily either? :-)
Joseph> I do note that one advantage to the MX
Joseph> solution is that one can specify failover firewalls with
Joseph> that, but not with the sendmail relay.
Nope. Mail relays can have their own MX records too. And with smart
relays, much simpler configurations on "satellite" mail systems are
possible. "This mail is not local so punt it at smart-mail-relay which
has a bunch of MX records for load balancing, redundancy and all that."
Kevin Darcy
> On Wed, Dec 15, 1999 at 07:44:46PM -0500, Kevin Darcy wrote:
> > Joseph S D Yao wrote:
> >
> > > On Fri, Dec 10, 1999 at 11:16:40AM -0500, Robert Setterlund wrote:
> > > > Are the below MX records supported in Bind 8.X?
> > > >
> > > > *.org IN MX 10 firewallrelay.mayo.org
> > > > *.gov IN MX 10 firewallrelay.mayo.org
> > > > *. IN MX 10 firewallrelay.mayo.org
> > >
> > > Yes. But this is probably not the right way of doing this. You should
> > > really put a relay host into your sendmail.cf file, to send all
> > > non-local e-mail to your firewall.
> >
> > Why? Is it easier to custom-configure dozens or hundreds of sendmail.cf's
> > than it is one master file on an internal root server? ...
>
> This response assumes that in a network it is easier to configure DNS
> properly all over than it is to configure sendmail all over. Mine
> assumed the opposite. Different experiences.
>
> Both have the same goal: to get the internal mail servers to send
> "non-local" [for some definition of "non-local"] e-mail to the firewall
> for relaying to the Big Bad Internet.
>
> The "better" one would be whichever one better fits the "truth". It's
> always easier to maintain a consistent story if you're telling the
> truth. ;-) And, "Say What You Mean" is Joe's First Law of Software
> Engineering. My first impression was that the MX trick, above, violated
> this. But within its domain, as Kevin has pointed out, it does NOT. It
> is true.
>
> I will continue to use my sendmail configuration, since it suits my
> needs better. [Everybody thinks they can meddle with DNS at their whim.
> Everybody is afraid to touch sendmail.cf. ;-)] I do note that one
> advantage to the MX solution is that one can specify failover firewalls
> with that, but not with the sendmail relay.
Another advantage, mentioned briefly in the _DNS_and_BIND_ book, and which we
may wish to implement, is that you can more easily route outbound mail to
different gateways, depending on domain name, e.g. all *.de mail goes out the
German gateway.
- Kevin