Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 26 Jun 1998 23:26:02 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        freelist@webweaver.net (Nicole Harrington)
Cc:        opsys@mail.webspan.net, freebsd-advocacy@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG
Subject:   Re: Packet Engines - FreeBSD
Message-ID:  <199806262326.QAA23161@usr01.primenet.com>
In-Reply-To: <XFMail.980625224257.freelist@webweaver.net> from "Nicole Harrington" at Jun 25, 98 10:42:57 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806262326.QAA23161>