Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!accuvax.nwu.edu!tank!oddjob!matt From: matt@oddjob.uchicago.edu (Matt Crawford) Newsgroups: comp.mail.sendmail Subject: Re: Re^2: Short-circuiting a route Message-ID: <4147@tank.uchicago.edu> Date: 28 Jun 89 18:07:25 GMT References: <562@daitc.daitc.mil> <89Jun28.104844edt.10373@neat.ai.toronto.edu> <3569@ncar.ucar.edu> Sender: news@tank.uchicago.edu Reply-To: matt@oddjob.uchicago.edu (Matt Crawford) Organization: Chicago Superconductivity Center - "Resistance is useless!" Lines: 25 In-reply-to: woods@ncar.ucar.edu (Greg Woods) I still disagree with Greg, even though I gave in (for now) and altered my sendmail rules to accommodate fidonet.org and another domain that had the same problem. I think that if fidonet or anyone else wants to have mail from the internet enter their realm at a point chosen by them, then they should provide a person (or some automated tool) to keep up the MX records at the required level of detail. The domain's nameserver does not need to be on the same host as any of the MX records point to. In fact, in fidonet.org's case they aren't. They're at orst.edu. Some fidonet ruler ought to replace the single all-encompassing wildcard record with a more detailed set. Mail for each zone or subnet can then be handed directly to a willing internet- to-fidonet forwarder by any internet site, and each such forwarder can confidently inject all received fidonet mail at the nearest fidonet entry point. Side questions: Is fidonet not fully connected internally? If they are not, then how do they forward among disjoint components? Not over the internet, I hope! And if they are fully connected internally, why should the UUCP or internet world be expected move fidonet's mail around when fidonet is capable of, but not willing to, do so itself? ________________________________________________________ Matt Crawford matt@oddjob.uchicago.edu