-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 03 Feb 2007 10:14:08 -0600, Robert C Wittig <wittig.robert@xxxxxxxxxxxxx> wrote: > Is dragonfly.bonivet.net the actual machine on which you host your > website, or what? I tried accessing http://dragonfly.bonivet.net and > http://www.bonivet.net and got a 'Forbidden', so I am guessing, 'not'. No. It's the name of my workstation which is behind the NAT box. However, since I sometimes communicate with MTAs outside of my LAN (I bypass them on occasion), "dragonfly.bonivet.net" still has to resolve to the *public* IP address from which the inbound connection is perceived to be coming by the remote MTA. That is why, seen from the outside, dragonfly.bonivet.net = 81.56.185.133. Seen from *inside* my LAN (on which I'm running my own nameserver), dragonfly.bonivet.net is 192.168.1.254. > So, what I don't understand, is how should a strictly Desktop > machine, that does not have a web server running on it, and has only > localhost sendmail running, and which share a single static IP > address on the DSL modem/router with any an all other non-server > Desktop machines (through the magic of NAT)... be named? Think outside the box. Put yourself in the place of the remote server receiving your mail in order to deliver it elsewhere. As far as *that* machine is concerned, the mail is coming from your 'Net-facing machine even if that 'Net-facing machine is merely forwarding packets from your workstation: +-------------+ +---------+ +------------------+ | workstation |------>| NAT box |------>|remote mail server| | 'foo' | | 'bar' | | SBC/Yahoo | +-------------+ +---------+ +------------------+ 'foo' wants to send mail out through the SBC/Yahoo mail server. Its gateway is 'bar', who does all the necessary NAT. As far as the remote server is concerned, it's 'bar' trying to send it mail, not 'foo'. In fact, that is precisely the purpose of NAT, to mask the real source of the IP traffic so that it looks like it's originating on the NAT box's public IP address. So, the SBC/Yahoo mail server sees inbound mail and it thinks it's coming from 'bar' on IP address 70.142.248.62. The software running on 'foo' has to take this into account when connecting to the remote mail server *through* 'bar'. You have two possibilities here. You can: 1) Get 'foo' to "lie" about its identity and try and pass itself off as 'bar'. The remote server will see inbound mail from 'bar' coming from software identifying itself as 'bar' and everyone will be happy. or 2) Add 'foo' to the DNS for your domain but make it point to the same address as 'bar'. That way, the remote server will see inbound mail from 'bar' and coming from a machine identifying itself as 'foo'. However, 'foo' has the same IP address as 'bar' so the domain name and the IP address match anyway. > I put a lot of various machines temporarily on my LAN, because I > build and repair for clients... mostly Windows boxes, running XP, > which have, as far as I know, no FQDN whatsoever. When those Windows > boxes go back to their owners, being generic Windows XP Desktop > machines, how will their email headers look? It depends on the mailer software. If they're equipped with Outleak Suxpress or Outleak then they will identify themselves using the machine's NetBIOS name, which goes against the standards (par for the course with Microsoft). - -- G. Stewart gstewart@xxxxxxxxxxx -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFxMTk3wTrO25YzEURAiFFAJ9YL7CU8KyMki6A2BXA7i2ysDsuOACeIJeP 5Fd0TkTatSLdqxsCJbB296U= =qLAF -----END PGP SIGNATURE----- -- You are receiving this message as part of your subscription to the "ringzero" mailing list at freelists.org. To unsubscribe, send an e-mail to ringzero-request@xxxxxxxxxxxxx?subject=unsubscribe