From owner-freebsd-advocacy Fri Jun 26 16:26:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA26198 for freebsd-advocacy-outgoing; Fri, 26 Jun 1998 16:26:44 -0700 (PDT) (envelope-from owner-freebsd-advocacy@FreeBSD.ORG) Received: from smtp04.primenet.com (daemon@smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA26052; Fri, 26 Jun 1998 16:26:13 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id QAA01964; Fri, 26 Jun 1998 16:26:11 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp04.primenet.com, id smtpd001897; Fri Jun 26 16:26:08 1998 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id QAA23161; Fri, 26 Jun 1998 16:26:03 -0700 (MST) From: Terry Lambert Message-Id: <199806262326.QAA23161@usr01.primenet.com> Subject: Re: Packet Engines - FreeBSD To: freelist@webweaver.net (Nicole Harrington) Date: Fri, 26 Jun 1998 23:26:02 +0000 (GMT) Cc: opsys@mail.webspan.net, freebsd-advocacy@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG In-Reply-To: from "Nicole Harrington" at Jun 25, 98 10:42:57 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-advocacy@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Well I just bought 10 of them for my project at work. > One problem though, is that they are comming out with a new/better > card soon but the driver will not work with it yet. > > If anyone wants to see what I am working on, go to > http://www.webweaver.net/work > > I had been wanting to put togther a write up on them, but have been > too dman busy at work :< It says "ISPCHANNEL DESIGN". If this is a design for an ISP, I would *seriously* recommend including *seperate* internal and external DNS. This is because "best known practice" for SMTP mail delivery with a dynamic IP assignment to customers whose domains you are hosting *requires* this: Mail in: client | ISP | Internet | | | External DNS | mail to bob@client.com | | MX for client.com? | x.x.x.x MX client.com | <--------------- | | send it to x.x.x.x | | ----------------> | SMTP Server | here's the mail! | IP=x.x.x.x | <--------------- Mail retrieval: client | ISP | Internet | | | | connection... | | ----------------> | Livingston Portmaster | Your IP is y.y.y.y... | | ^ | <--------------- | v | | | Radius Server | | | | | y.y.y.y MX client.com | | v | | Internal DNS | | ^ | ETRN client.com | | | ----------------> | SMTP server | | IP=x.x.x.x | | | | connect to y.y.y.y | SMTP server | <--------------- | | here's mail, buddy! | | <--------------- | Thanks, buddy! | | ----------------> | | This allows an ISP to assign dynamic IP's (preserving the prescious static IP address assignments for his own machines and for clients who pay him (or her) lots of money and want to host their own servers (these are usually full time connections, anyway). You have to have a seperate internal server to allow you to prevent cached information from damaging your ability to correctly deliver the mail (ie: if someone cached that client.com's MX was y.y.y.y, and another customer dialed in and the IP was reassinged, that would be bad). Since sendmail does not cache DNS information, the act of the radiusd removeing the DDNS (Dynamic DNS) created MX in the internal DNS server is sufficient to resolve the "do ETRN and hang up, letting someone else get the IP address instead" problem that would result from cached data (I don't know what vmailer does, but qmail also does the right thing). A secondary advantage is that the link to the larger net can become damaged or go down, and many essential services can continue functioning transparently. POP3 retrieval is not sufficient, since envelope information is destroyed (unless you hack you smtp server to either ensure that the "Received:" timestamp always includes a "for" -- remove "m" from the local mailer falgs line -- or you add an "X-Envelope-To:" header). Even if the envelope information is not lost, the most popular program for doing this, "fetchmail" (from the paper "The Bizarre Cathedral") is too stupid to assign priority other than by order of occurrrance, and it always insists that the machine you are POPping from be treated as one of your MX's -- ie: you get bogus delivery if the SMTP server and the POP3 server are not the same machine, and the virtual domain to maildrop translation is done on the SMTP server. This is because the "Received:" timestamps "by hostname" portion matches, and the for is "for isp.maildrop" instead of the correct "for user@client.com". Much better to use ETRN (and save the maildrop and POP3 processing overhead at the same time) -- and with DDNS, it's possible to do this with dynamic IP assignment to your customers. (I'd just hate for such a large setup, like that depicted in youe diagram, to get mail wrong -- even though almost every ISP on the Internet tends to get mail wrong. Hell, *my* ISP's SMTP server stamps the wrong "by servername" on it; the "servername" is *supposed* to match my MX records, not their internal mythical name for their mail server on DNS rotor that happens to anser the SMTP port!) Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message