sendmail SMARTHOST

[Paul Lussier]

"Michael ODonnell" <michael.odonnell at comcast.net> writes:

> I'm glad to see this thread as I've also puzzled
> over this issue on and off since forever as a ComCast
> customer with multiple Linux boxes behind a NAT box.

This is the same basic scenario of many small companies.  Mine
included.  And, IIRC, MCL also had "multiple Linux boxes behind a NAT
box" :)

The way to think of this isn't as "a Comcast customer with multiple
Linux boxes behind a NAT box".  Rather, it's as "a domain behind a
firewall which happens to use Comcast as it's connection to the
internet."  Comcast is nothing but a service provider, and the service
they provide is a wire to your house which allows you to transport
bits between your systems and others on the internet.

> The more general question in my case is: Given
> that ComCast only knows me by the single interface
> associated with my cable modem and that interface is
> in the comcast.net TLD, how should I configure all
> the systems behind that interface?

The short answer:  however you want.

The long answer: It completely depends upon what you're trying to accomplish.

If you want to run your own domain, completely separate from the
comcast.net TLD, it's a little more complicated than if you want to
pretend to just be part of that same TLD.

> I can't tell my email software (let's say it's running on a host
> named "waldo" that's behind my firewall) that it's running on a host
> in the comcast.net domain because it ain't;

Sure you can, and yes it is, but that's largely irrellevent.  What you
do is tell your MTA to masquerade as part of the comcast.net TLD, hide
your hostnames, and re-write your envelope headers as just being from
comcast.net.  That way, all reply e-mail comes back to
michael.odonnell at comcast.net rather thay michael.odonnell at waldo.comcast.net.

> ComCast has no idea that waldo exists and can't route to waldo.

They shouldn't need to.  It you're hiding hostnames and masquerading
as comcast.net, then the outgoing mail appears to come from
michael.odonnell at comcast.net.  Return mail to that address is
perfectly valid, and therefore, should reach you via their POP3
server.

> But I also can't tell waldo that it's in some other domain (either
> real or fictitious) because that ain't true, either.  So, where's
> waldo?

This is where it gets hairy.  You can do this, but it's a whole lot
easier if the domain you make waldo part of, does in fact exist.  It
also depends upon your motivation for having a different domain behind
your firewall.

Case A:
If you're just fooling around, and want to have a little network
behind your firewall and have e-mail to/from family members on that
network appear to be from some pseudo/make-believe domain which you
haven't registered, yet you want mail outbound to the world to still
work, it's a little complicated.

Case B:
If you really want to run a legitimate domain behind your firewall
that can really route e-mail to/from the internet and have that e-mail
appear to recipients as being from that domain, it's slightly easier.


Let's take A first, since, if you can figure that out, Case B is a lot
easier to understand.  Suppose you have 3 systems behind your
firewall, and, for argument's sake, let's make one of them a
non-UNIX-like, supposedly user-friendly system.

What you need to run this domain is some way to do hostname<->IP
address resolution[1] and a way to send mail.  For simplicity, we'll
just use host tables on each system[2] and assume all the other
network parameters are correctly and statically assigned[3].

Designate one of the 2 UNIX-like systems as your mail gateway.
Make sure you configure it to strip hostnames from the envelope headers[4],
ensuring all mail apprears to be from user at foo.tld vs. user at waldo.foo.tld.

Next, make sure the mail gateway knows where to deliver mail for all
recipients in the domain.  The easiest thing to also have your
designated mail gateway be a POP3 or IMAP server for your internal
network, and configure mail clients on other systems appropriately[5].

At this point, your almost done, mail to/from anyone internal to this
domain can now send/receive mail.  But, they can't send mail to the
internet, and no one can send them mail.  Since this domain doesn't
really exist, what we have to do is tell the MTA that any mail
destined for an address outside out this tld should have all the
headers re-written to something that does exist.  I don't remember off
hand how to do this with sendmail, but with postfix, I think it's in
the canonical maps.  Essentially, your masquerading outbound e-mail as
being from comcast, while leaving local e-mail alone.

Next, you probably want to set the MTA up to use a SMARTHOST relay.
You don't have to, but it makes your life somewhat simpler.  Doing
this ensures that recipients using providers such as AOL will
definitely get your e-mail, but you can choose to, if you want, have
your MTA connect directly with the MTA of the recipient, just don't
specify a relay[6].  

Case B is really not much more than a slight deviation from Case A.
In this case, you have a legitimate domain behind your firewall that
you want to send mail from and receive mail to all the while
maintaining that domain name you've just paid so dearly for.

The first thing that's required is DNS.  Since you're technically on
an IP address owned by someone else, you can't map that entire address
space onto your domain.  You need to use something like DynDNS.org[7]
to map your domain name to a specific IP address (that of your cable
modem) and also specify the MX record for that domain, which will also
be the addresss of the cable modem.

Now, from out on the internet, you should be able to connect to your
domain.  Configure your firewall to allow ssh traffic to a specific
box internally, and make sure that system can receive ssh traffic.
Try ssh'ing to your new domain.  If this works, then you only need to
set up your firewall to now allow inbound SMTP connections to the
system you designated as a mail gateway.  Now try sending mail from
the internet to your internal e-mail address.

FWIW, this is exactly what I do all the time.  I use a domain from
DynDNS, and run an MTA on my Linux box.  I don't actually advertise my
domain to anyone, I just use it because it's easier for me to remember
than the IP, which may change.  I ssh to my box from work (which is
how I'm actually composing this e-mail), and occassionally send my
self e-mail, either from work, or from my cell-phone.  It works rather
well[8] :)

I hoped this helped somewhat.  I left out many of the exact specifics,
since they differ between sendmail and postfix, and I'm too lazy to
look them up :)

Seeya,
Paul

Footnotes: 
[1]  DNS is probably over-kill for this scenario, but once you start
     adding hosts to the network, maintaining DNS and DHCP becomes a lot
     easier.  If running your own domain, and laptops are involved, DHCP
     also helps in auto-configuration of all these things too.  But again,
     this is left as an exercise to the reader.

[2]  It is left as a reader to figure out how to do this on the
     non-UNIX-like, supposedly user-friendly system.

[3]  This is where DHCP comes in really handy!

[4]  This is just a good idea, though not really necessary in this
     case.  but if you want to progress to Case B, then it's not too far of
     a jump, since this is required for that scenario.

[5]  You could, if you wanted to get really fancy, have the MTA deliver
     mail to the appropriate machine, but that requires running an MTA on
     those machines which recieve mail, and you now need a way for the MTAs
     to determine the MX record of each machine, which, AFAIK, requires
     DNS.

[6]  You may also want to use a fetchmail/procmail combination on your
     mail gateway.  This will allow you to fetch mail from the comcast POP3
     servers on behalf of everyone on your network, then filter it
     appropriately into the each user's account.  You could probably do
     some header re-writing in there if you really wanted to in order to
     make it appear that the sender sent it to the internal recipient's
     fake e-mail address, but I think this is largely asking for trouble.

[7]  I know there's another service out there that does the same thing,
     but actually allows you to use your own domain rather than choosing
     one of theirs, but I can't remember the name of it.  DynDNS will allow
     you to do this as well, but it becomes a paid-for service.

[8]  If you investigate the headers of this e-mail, you'll probably see
     evidence of this.  Though I don't advertise my domain, I don't hide it
     either :)