Sendmail problem

[Tim]

Tim:
>> Are you using domain names that you own?  Is there a DNS entry that
>> points to someone else's IPs?

Kevin Cummings:
> My domain is dynamic DNS, owned by Dyn DNS, but "allocated to me".  In
> that regard, I own kjchome.homeip.net (I pay for its use).  If you do a
> DNS lookup on it, you will find the IP address allocated to me (via
> DHCP) by my ISP.

It has no MX record, so I'd expect sendmail to just use the IPs
associated with the hostnames (mailing directly between machines).  On
the other hand, if they had a MX record pointing to one of their own
mail servers, sendmail would be trying to pipe your mail through it, and
fun and games would ensue.


>> Email can be rather painful when you're using host files, I use a local
>> DNS server which has a configuration set into it for all local machines
>> in the same manner as is traditional for setting up real public IPs
>> (e.g. forward and reverse look-ups, A names for machines, CNAMES for any
>> aliases, MX records).

> I could not get the files to flush until I added
> localhost.localdomain.kjchome.homeip.net to my /etc/hosts file under
> 127.0.0.1.  After I added this alias, "sendmail -q" now sends those
> emails out.  My question was 2 fold:
> 
> 	1)  why the ridiculous looking combined FQDN

First answer to a DNS query becomes the answer, so make your first
answer the one you want.  Usually, you want a machine hostname to point
to a network IP (whether an internal one, such as 192.168.0.1 or a real
public IP).  127.0.0.1 only works within a machine, itself, and it
becomes problematic to test mail between different things on your
network when hostnames resolve to the localhost address.

Various servers go through a series of queries to work out what
addresses to use, such as:

Find the numerical IP for the hostname it wants to know about.  For
instance, this sort of thing can happen:

Find the IP for mail.example.com and be told that its 192.168.1.2

Double-check the hostname for that IP, and be told that its
www.example.com (that IP could have several hostnames attached, and this
one was the first response).

Triple-check, and find the IP for www.example.com is 192.168.1.2

Work with those last two numerical IPs and named addresses...

If there's a switch in names somewhere along the way, like that example,
you can get unexpected responses, if *you* weren't prepared for it.

If something goes into localhost that needs to actually leave the
machine, things can end up going around in circles in the localhost.

e.g. You're trying to use mail with example.com, some hostfile
associates that hostname with 127.0.0.1, and now everything backfires to
the localhost address, instead of where you want it.

My hosts file, and my DNS servers, only associate the localhost and
localhost.localdomain addresses with 127.0.0.1.  All my internal machine
hostnames resolve to their network addresses (192.168.1.xyz), none of
them double up back to the localhost address.

This is my entire hosts file:
127.0.0.1  localhost.localdomain  localhost
::1  localhost6.localdomain6  localhost6

> 	2)  why won't sendmail send these out without the explicit
>             "sendmail -q"

The million dollar question, but may be related to working out the right
address to use.  And localhost can only deliver mail to itself.


>>> And why is localhost.localdomain being prepended to my local domain
>>> name in the mqueue?

>> When there are multiple answers for domain names (host files, or DNS),
>> it's typically the first one that becomes the answer.

> My /etc/host.conf file contains 1 line:
> 
> multi on
> 
> My /etc/resolv.conf contains 3 nameserver lines:
> 
> nameserver 192.168.6.94			; My server
> nameserver 192.168.6.1			; My router
> nameserver 8.8.8.8			; Google

That's a different kettle of fish.  I was referring to something like
either your hosts file, or a DNS server, providing multiple answers
about the same query.

The host.conf multi on wouldn't appear to be a problem, see this for a
one page explanation:  http://www.linfo.org/etc_host_conf.html

The resolv.conf series of nameservers refer to which ones will be asked
to provide answers.  The first one will be asked, and only if it doesn't
respond, will the next one be asked.  Likewise for subsequent listed
name server addresses.  And I do mean "if it doesn't respond.," quite
precisely.  If it does respond, but cannot supply the answer, it has
responded, the other servers will not be asked.

So, unless the first name server is disconnected, the second will not be
queried.  And if the first and second ones aren't available, then the
third one will be used.  There'll usually be a seriously annoying delay
before things timeout waiting for a non-responsive name server, so all
queries will slow, one after another.  I don't think that Linux
remembers that the first (and/or next) servers hasn't responded, for the
next query, and skip trying to ask them on each name server query.


>> e.g. with the following in /etc/hosts
>> 
>> 127.0.0.1  localhost  localhost.localdomain something.example.com
>> 127.0.0.1  blah.example.com
>> 
>> All those domain names and hostnames have the 127.0.0.1 IP.  But if
>> something asks what's the name for 127.0.0.1, the answer will be just
>> "localhost".
 

> Interesting, localhost.localdomain is the first name on that line....
> 
> Should I change it such that localhost is first?

If you want to...  Whatever you want as your answer, put it first.  It
seems the norm, nowadays, that Linux has the dotted name first.  In the
past, some services insisted that they needed an address with at least
one dot in them, but I haven't encountered that for quite some time.
Hence the Linux peculiarity of having a localhost.localdomain address,
where everyone else just uses localhost.

> Why is this only broken recently?  What changed on or about July 30????

Hosts files can be dynamically changed by things such as NetworkManager.
You can look through your yum history to see if any packages changed
around that date.

> I may go back to having my iPhone just use my ISP's email server
> directly instead of using my own server (which of course send all of its
> outgoing mail to my ISP).

If you're trying to send mail out to the outside world directly through
your own mailserver, you're going to strike a plethora of problems.

      * You're trying to send from a "localhost" address.
      * You're trying to send from a user IP, not an acknowledged ISP
        address, so many, if not most, anti-spam systems will block you.
        However, having your local mailserver just act as a proxy to
        your ISP's mail server, so the ISP does the delivery, will
        usually mitigate that issue.
      * If your mail's "from" address doesn't use a publicly resolvable
        domain name (if something outside of your own network can't find
        a real usable IP for the entire hostname), mail is going to be
        rejected.


-- 
[tim at localhost ~]$ uname -rsvp
Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64

All mail to my mailbox is automatically deleted, there is no point
trying to privately email me, I will only read messages posted to the
public lists.

George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.