# Local Mail a Fail



## hruodr (May 21, 2018)

I intentionally write here and not under  "web and network services". ntentionally write without reading any documentation.  Why?

Just after installing, I expect that doing a traditional command "mail root" or "mail user" does send a mail to the user, independently on how the networking is configured. Not only I, but a lot of programs expect it, for example `vi` and the many daemons.

Well, this is not working, although I never touched `sendmail` configuration.

It should be irrelevant to say that I have in rc.conf:


```
hostname="fbsd"
local_unbound_enable="YES"
```

that I get with ping fbsd:


```
ping fbsd
ping: cannot resolve fbsd: Host name lookup failure
```

That if I have in /etc/hosts a line "127.0.0.1       localhost fbsd", then the ping works, but sendmail not even start  at boot and blocks it.

That `mailq` delivers:


```
% mailq
                /var/spool/mqueue (5 requests)
-----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient-----------
w4L6c4vI000807        2 Mon May 21 06:38 <root@fbsd>
                 (host map: lookup (fbsd): deferred)
                                         <root@fbsd>
```

*Why?!  WHY THIS HORROR?!!*


----------



## VladiBG (May 21, 2018)

The hostname string should be in fully qualified domain name (FQDN) for example fbsd.domain.local


----------



## hruodr (May 21, 2018)

That was not enough. I had edit /etc/hosts to have there "127.0.0.1  localhost fbsd.domain.local".

My machine do have a name: localhost. Why "mail root" is not interpreted as "mail root@localhost" and sent to root?

Or does every machine have to be an inernet or local area net machine? The last is not egough: Since we have cool TLDs, there is now place for local FQDNs. Also not ".local" is reserved for local machines.

And why is fbsd not a FQDN consisting of only the TLD fbsd? I think, this is conform with the definition.


----------



## VladiBG (May 21, 2018)

To be able to send and receive e-mails you need to have working DNS. The way that resolve work is configured in /etc/nsswitch.conf It first lookup for the local files like /etc/hosts then to DNS query if there's no match in the hosts.


----------



## hruodr (May 21, 2018)

With "fbsd.local" in /etc/hosts and /etc/rc.conf also works, but neither with "fbsd." nor with "fbsd". It seems, sendmail expects a name with at least two components, although one component should be a legal FQDN.

But it remains the original question. In `man mail` you read:



> HISTORY
> A mail command appeared in Version 1 AT&T UNIX. [...]



At that time, there were no internet, no LANs, no UUCP, just machines with many users. `mail` was used to send messages to people in the same machine.

`mail root` means mail to the root of the machine. For that is not be necessary `sendmail`, MTAs, TLDs, FQDNs, DNSs, GTDZKs, ZZTPPOIs, XYZTQs, etc.


----------



## zirias@ (May 21, 2018)

hruodr said:


> although one component should be a legal FQDN.


Well, then complain to the IETF?  It isn't, a FQDN always includes _at least_ a second-level domain name.


----------



## hruodr (May 21, 2018)

Can you quote a reliable source?

I suppose "localhost" is a FQDN. If I put "fbsd" or "fbsd." in /etc/hosts, it get resolved. The problem seems to lie in `sendmail`.

At the end of `man hosts` you read:



> Host names may contain any printable character other than a field delimiter, newline, or comment character.


----------



## zirias@ (May 21, 2018)

Although I'm not sure there's an explicit statement somewhere that a TLD cannot identify a host, it's implied in many documents, e.g. RFC 1032 -- you will find more... Just accept that fact.

Btw, *if* you want to try to make your system accept a single TLD as an _absolute domain name_ (which is the correct term for FQDN), you have to write it with a trailing dot, see RFC 1035, 5.1. Format. But don't be surprised if your implementation rejects this anyways.

About localhost, this is a TLD and at the same time expected to be queriable for A and AAAA records pointing to a local loopback interface, because it's special, as of RFC6761. It's not a FQDN as it isn't part of the global domain name tree.


----------



## hruodr (May 21, 2018)

I wrote above that sendmail does not treat "fbsd." (with a dot at the end) as a FQDN. I think, the following seems to be explicit:



> A domain name (or often just a "domain") consists of *one* or more
> components, separated by dots if more than one appears.  In the case
> of a *top-level domain used by itself in an email address, a single
> string is used without any dots.*
> ...



From 2.3.5 in https://tools.ietf.org/html/rfc5321#section-2.3.5

and



> The following syntax will result in fewer problems with many
> applications that use domain names (e.g., mail, TELNET).
> <domain> ::= <subdomain> | " "
> <subdomain> ::= <label> | <subdomain> "." <label>
> [...]



From 2.3.1 in https://tools.ietf.org/html/rfc1035


----------



## zirias@ (May 21, 2018)

A top-level domain used in an email address requires this TLD to have an MX record defining the actual host that handles mail for that TLD. And again, while "fbsd." is syntactically correct as an absolute domain name, it still isn't a semantically correct FQDN, as it neither is an existing TLD nor one of the reserved ones (like localhost, example, ...).

But keep insisting if you want, I'll just stop responding now.


----------



## VladiBG (May 21, 2018)

First there's nothing wrong with the sendmail.
The `mail` is mail user agent (MUA) that send e-mails using the mail transfer agent (MTA) in your case this is sendmail. When the MTA agent receive an email for user@domain it need to resolve the domain using the priority that is configured in /etc/nsswitch.conf  by default this is `hosts: files dns` the file is /etc/hosts then if there's no match there the DNS query is send to the DNS server specified in /etc/resolv.conf  nameserver
When you don't have your hostname registered in the DNS server or in the /etc/hosts file the MTA can't resolve the domain therefor the mails are hanging in the mail queue.


----------



## hruodr (May 21, 2018)

Zirias said:


> it still isn't a semantically correct FQDN, as it neither is an existing TLD nor one of the reserved ones (like localhost, example, ...).



Do you have a reliable source, that I cannot make a TLD in a local net exist, including running a DNS with a MX record to it?

And as I said: `sendmail` (in the default configuration in FreeBSD) does not treat localhost as FQDN.


----------



## hruodr (May 21, 2018)

*VladiBG*, this is not anymore a thema. My Domain is being resolved to 127.0.0.1 and sendmail is delivering local mails. But sendmail demands that the FQDN have two labels, and I find this strange.


----------



## VladiBG (May 21, 2018)

No there's no such demand by sendmail. The only requirement is to be resolved. You can add only fbsd in your hosts file and it will work.

```
::1          localhost fbsd localhost.my.domain
127.0.0.1    localhost fbsd localhost.my.domain
```


----------



## hruodr (May 21, 2018)

Did you try it? I tried again. I put fbsd in /etc/hosts and /etc/rc.conf again.

At every invocation of `sendmail`, even at boot (and indirectly by calling `mail`), I get the message:


```
fbsd sendmail[802]: My unqualified host name (localhost) unknown; sleeping for retry
```

But it continues after a while. And mails are delivered with the "localhost" domain. It ignores the "fbsd" FQDN and uses localhost, what I would even prefer.

This is only because of the messages and delay unusable. Perhaps it can be fixed configuring `sendmail` carefully, but for that one needs (at least I) a lot of time.


----------



## gkontos (May 21, 2018)

Sendmail looks for a fully qualified domain (FQDN) name and will use the localhost.localdomain if it does not find one.

For more information regarding FQDN --> https://en.wikipedia.org/wiki/Fully_qualified_domain_name

You might want to learn/read more on how MTA's work and the difference between a client and a server.


----------



## drhowarddrfine (May 21, 2018)

hruodr You come here looking for help, then put test questions at us as if we are the ones with a problem. I suggest you listen and learn first from people far more knowledgeable than you. Solve your problem. Then look for answers to your questions about sources.


----------



## hruodr (May 21, 2018)

*gkontos*, *drhowarddrfine,* I suppose that was the fully unqualified opinion of wannabe school teachers that want to say their oppinion without even reading the thread.


----------



## VladiBG (May 21, 2018)

Yes i tried in a vm and it's working as expected.. FQDN is not required.


----------



## zirias@ (May 21, 2018)

Lesson of this thread? You really should stop right here:



hruodr said:


> ntentionally write without reading any documentation.


Intentionally don't care...


----------



## gkontos (May 21, 2018)

VladiBG said:


> Yes i tried in a vm and it's working as expected.. FQDN is not required.


localhost.my.domain falls under the FQDN section. Check your logs.


----------



## hruodr (May 21, 2018)

At least you do not get the delay. But it seems that it takes localhost.my.domain as domain for email.

If I send myself a mail now, `mail root`, it appears as coming from <root@fbsd.local> and has Message-Id like <201805211201.w4LC1bpd001083@fbsd.local>.

It seems you will not get a mail from <root@btest>, perhaps also not from <root@localhost>, but from <root@localhost.my.domain>. I did manage to get it from <root@localhost>, but with the delays.

And it is strange why you get a different experience. We are using the same version of `sendmail`, and perhaps of FreeBSD (11.1).

Perhaps there is no way around than carefully configuring sendmail, but this is the tragedy: something so important like local mail should be in my opinion not so sensible to the configuration of things which are irrelevant to it (like DNS).


----------



## VladiBG (May 21, 2018)

*@gkontos*
Look at the top of the log from=<root@btest>
i've tested both configuration with and without local_unbound, both works.

ohh sorry my bad, the screenshot not include the past log here the above that.


----------



## hruodr (May 21, 2018)

*Zirias*, perhaps you did not get the message, perhaps you do not want to understand it: local mail should work out of the box, and not stop working due to things that are irrelevant to it.


----------



## Deleted member 30996 (May 21, 2018)

hruodr said:


> I ntentionally write without reading any documentation.  Why?



Sub-par reading comprehension skills?


----------



## ShelLuser (May 21, 2018)

hruodr said:


> *Zirias*, perhaps you did not get the message, perhaps you do not want to understand it: local mail should work out of the box, and not stop working due to things that are irrelevant to it.


Which is exactly how it works on FreeBSD.


----------



## ShelLuser (May 21, 2018)

So now the slightly longer version after having read (most) of the thread. If the OP can't be bothered to read documentation then I can't be bothered to spent too much time on this.

First things first, regarding my message above, please see the attached screenshot of this message. I recreated the whole setup; using a hostname without the FQDN, and local mail works just fine. When you truly use this 'out of the box' then this simply works as intended. Even if you make the mistake of not using a FQDN.

However, there is also a problem to address here, which is local unbound. I have used it myself a few times (or tried to) and my general opinion is that it's usually more trouble than it's worth. In most cases it doesn't work for me, let alone work 'out of the box'. I can get it to work by reconfiguring it (see /var/unbound), but one should also wonder why you'd want to use this in the first place? One way or the other you'll be using a DNS server, and those do their own caching as well. Why add even more to that?

And it's also noteworthy to mention that using Unbound has nothing to do with an "out of the box" kind of scenario:


```
peter@zefiris:/etc/defaults $ grep unbound rc.conf
local_unbound_enable="NO"       # local caching resolver
```
I realize that I'm playing the devils advocate a bit right now, but it doesn't change the fact that in a pristine 'out of the box' FreeBSD environment this service isn't used, as seen above.

Ergo: your problem isn't so much the local mail, but involves local unbound. Personally I'd recommend to turn it off, throw it into /dev/null and then forget all about it.

(edit)



Wozzeck.Live said:


> Please please please....
> CHECK /etc/hosts.allow
> 
> It seems there  is a TCP wrapped sendmail process (so inetd superserver is required), and localhost could be "blocked" according to the settings.


inetd isn't used out of the box by FreeBSD:


```
peter@zefiris:/etc/defaults $ grep inetd rc.conf
inetd_enable="NO"               # Run the network daemon dispatcher (YES/NO).
inetd_program="/usr/sbin/inetd" # path to inetd, if you want a different one.
inetd_flags="-wW -C 60"         # Optional flags to inetd
```
Another problem with your theory is that the default MTA (sendmail) gets started in localhost mode only, and none of the errors shared by the OP point in this direction.

What you're describing simply cannot happen on a freshly installed FreeBSD environment, which is what the OP was talking about.


----------



## VladiBG (May 21, 2018)

*ShelLuser*
if you don't have Network at all above won't work until you manually edit the hosts file. I also checked it on the vm without any network and the mail is trying to send it to root@hostname and it fail to resolve the hostname if it's not in /etc/hosts. In my network the DHCP is updating the local DNS server and it work without any modification to the hosts.


----------



## hruodr (May 21, 2018)

Well, the first time I started the cashing DNS, it made some changes in the system automatically, I mentioned it in this forum. Perhaps dns/unbound introduced the strange behaviour, but the correctly working /etc/hosts mechanism should be enough for mail/sendmail.

I had previously dns/bind as caching DNS. My experience is, that mail/sendmail is by far the most complicated daemon to configure, that it and not the DNS server normally makes troubles. In that sense Wozzeck.Live is right.


----------

