jessea@dynasys.UUCP (Jesse W. Asher) (04/12/90)
I'm not sure what I'm asking, so I didn't know how to phrase the subject. :-)
But, I'm interested to know if a USENET site could handle the routing for
other USENET sites. Example: Let's say my site has a registered domain
and I have a site that I connect to that is on Internet and is my MX
forwarder. I also have 10 other sites that _want their own domain_ instead
of hiding behind mine. Now, here's the question. Is there a way that these
ten sites (after registering, of course) can list my domain name as their
MX forwarder? In other words, is there a way that they don't have to have
my Internet contact as the MX forwarder for them or do I just not know what
I'm talking about? I know that I can have machines use my domain -
my domain is foobar.com and can have those systems be whatever.foobar.com.
But that's not what I'd like to do. Thanx in advance for any ideas...
--
Jesse W. Asher - Dynasys - (901)382-1705 Evening: (901)382-1609
6196-1 Macon Rd., Suite 200, Memphis, TN 38134
UUCP: {fedeva,chromc,autoz}!dynasys!jesseaemv@math.lsa.umich.edu (Edward Vielmetti) (04/13/90)
In article <141@dynasys.UUCP> jessea@dynasys.UUCP (Jesse W. Asher) writes:
I'm not sure what I'm asking, so I didn't know how to phrase the subject. :-)
But, I'm interested to know if a USENET site could handle the routing for
other USENET sites. Example: Let's say my site has a registered domain
and I have a site that I connect to that is on Internet and is my MX
forwarder. I also have 10 other sites that _want their own domain_ instead
of hiding behind mine. Now, here's the question. Is there a way that these
ten sites (after registering, of course) can list my domain name as their
MX forwarder? In other words, is there a way that they don't have to have
my Internet contact as the MX forwarder for them or do I just not know what
I'm talking about? I know that I can have machines use my domain -
my domain is foobar.com and can have those systems be whatever.foobar.com.
But that's not what I'd like to do. Thanx in advance for any ideas...
In a word, no.
To be more specific, the mechanism that provide you with mail forwarding
is the MX record, which has to point to a machine which has
an A record, like so
foobar.com. MX 10 mailgw.forwarder.org. ;; OK
mailgw.forwarder.org. A 135.24.64.24 ;; needed
blurfl.com. MX 10 foobar.com. ;; nope
blurfl.com. MX 10 mailgw.forwarder.org. ;; OK
The first MX record won't work for blurfl.com because the MX record
doesn't point to a real A record.
It is possible to hack your way around this by having whoever
is doing name service for the foobar.com domain put in a false
A record for foobar.com which really is the address of 'mailgw'
in this case, i.e.
foobar.com. A 135.24.64.24 ;; a lie!
This is a bald-faced lie and asks for trouble, especially since things
like 'telnet' and 'ftp' to foobar.com will now work though not as you
might expect. As an instance of this compare the result when you
connect to "um.cc.umich.edu" and "ummts.cc.umich.edu".
Even so this will not work without cooperation from your friendly mail
gatewaying site, since they have to known (i.e. hard-wire in their
mail configuration) that "blurfl.com" should be delivered to
"foobar.com" via uucp or avian carrier or what have you, not in the
standard way of trusting the domain name system to resolve an address.
It would also be un-sociable to put this extra forwarding burden on
your mail relay without giving them the courtesy of rejecting this
extra load.
--Ed
Edward Vielmetti, U of Michigan math dept.
emv@math.lsa.umich.edumatt@group-w.uchicago.edu (Matt Crawford) (04/13/90)
Edward Vielmetti: ) foobar.com. A 135.24.64.24 ;; a lie! ) ) This is a bald-faced lie and asks for trouble, ... It sure does. Don't put lies into the DNS. Don't put lies into the DNS. Don't put lies into the DNS. Don't put lies into the DNS. Don't put lies into the DNS. Don't put lies into the DNS. Don't put lies into the DNS. Don't put lies into the DNS. Don't put lies into the DNS. Don't put lies into the DNS. Don't put lies into the DNS. Don't put lies into the DNS. Don't put lies into the DNS. Don't put lies into the DNS. I just spent hours and hours fighting the effects of a lie someone inserted into the DNS in Kaiserslautern, West Germany. These lies really get around. Matt Crawford "Have you considered a military solution?" - Sysadmin Ed Resnechenko
jeremy@cs.swarthmore.edu (Jeremy Brest) (04/13/90)
emv@math.lsa.umich.edu (Edward Vielmetti) writes: >In article <141@dynasys.UUCP> jessea@dynasys.UUCP (Jesse W. Asher) writes: >To be more specific, the mechanism that provide you with mail forwarding >is the MX record, which has to point to a machine which has >an A record, like so Maybe I'm entering this discussion a little late, but why is this so? It seems that when a mailer looks up a host and finds an MX record, it should then start at the top again and look up that host, again to see if it has an MX record. This couldn't be difficult to implement, so why doesn't the protocol allow for this? .. .. .. .. .. .. .. .. .. .. .. .. .. .. Jeremy Brest, Swarthmore College, Swarthmore, PA 19081 jeremy@cs.swarthmore.edu, jeremy@swatsun.uucp, jeremy@swarthmr.bitnet
kre@cs.mu.oz.au (Robert Elz) (04/13/90)
In article <HGKHXQM@xavier.swarthmore.edu>, jeremy@cs.swarthmore.edu (Jeremy Brest) writes: > It seems that when a mailer looks up a host and finds an MX record, it > should then start at the top again and look up that host, again to see > if it has an MX record. Several reasons .. for one, it would prevent A MX B B MX A from working (just in case someone actually finds a use for that...) Second, the final A record site has to know how to process the mail in any case (ie: if you had A MX B; B MX C; C A a.b.c.d, then C needs to know how to handle mail addressed to both A and B). It makes more sense to make that clear. Third, there are many more lookups than changes to the MX routing, why make each lookup more expensive (needing to do multiple MX checks) which could easily be done when the MX is installed in the first place (ie: in the above case, the end result is going to be that the mail is SMTP'd to C, so just install A MX C initially). Finally its not clear (to me at least) just what it would mean to have chained MX's when there are alternate MX's for a name, the complexity in understanding simply isn't worth the insignificant gain (which is entirely that if B was to change its MX, and you want A to go along with it, with chained MX's you wouldn't need to explicitly change A's MX, without them you do). kre
imp@dancer.Solbourne.COM (Warner Losh) (04/13/90)
In article <141@dynasys.UUCP> jessea@dynasys.UUCP (Jesse W. Asher) writes: >To be more specific, the mechanism that provide you with mail forwarding >is the MX record, which has to point to a machine which has >an A record, like so In article <HGKHXQM@xavier.swarthmore.edu> jeremy@cs.swarthmore.edu (Jeremy Brest) writes: >Maybe I'm entering this discussion a little late, but why is this so? >It seems that when a mailer looks up a host and finds an MX record, it >should then start at the top again and look up that host, again to see >if it has an MX record. This couldn't be difficult to implement, so >why doesn't the protocol allow for this? You can have multiple MX records for a given host. The defined algorithm for choosing the order to try these records is something like: 1) Get all MX records for host n 2) Sort all MX records 3) If your local host is in the list, remove it and all other hosts that have a higher MX value. 4) Try the MX hosts in order from lowest to highest until the mail succeeds. Now, if you have to go out and get MX record for MX records for MX records, this entire process falls apart. It would be very easy to get mail looping because you have A MXing for B MXing for A, etc. The purpose of MX records is to tell mailers a *HOST* they can send your mail to, not some domain name that will handle the mail for you. If you try to expand them beyond this limited functionality, you will be creating problems for old implementations, as well as making non-trivial to find mail loops easier to come into existence. *THAT* is why it is hard to implement. Just my two cents from a former VMS/SMTP/DECNET MAILER hacker..... -- M. Warner Losh Solbourne Computer imp@solbourne.com (formerly warner@twg.com and warner@hydrovax.nmt.edu)
emv@math.lsa.umich.edu (Edward Vielmetti) (04/13/90)
Here's a quote from RFC 974, "Mail Routing and the Domain System", by Craig Partridge in 1986: Implementors should understand that the query and interpretation of the query is only performed for REMOTE. It is not repeated for the MX RRs listed for REMOTE. You cannot try to support more extravagant mail routing by building a chain of MXs. (E.g. UNIX.BBN.COM is an MX for RELAY.CS.NET and RELAY.CS.NET is an MX for all the hosts in .IL, but this does not mean that UNIX.BBN.COM accepts any responsibility for mail for .IL). "when in doubt, quote an rfc" --Ed Edward Vielmetti, U of Michigan math dept. emv@math.lsa.umich.edu