Subject: Re: sendmail inappropriately tries to externally relay local mail
To: Christian Hattemer <c.hattemer@arcor.de>
From: Chuck Swiger <cswiger@mac.com>
List: netbsd-users
Date: 09/01/2005 10:53:52
Christian Hattemer wrote:
> Hello Chuck,
Hi--
> On 31.08.05, you wrote:
>> Doesn't "dig localhost." and "dig localhost" and "dig
>> localhost.myisp.de" all return 127.0.0.1...?
>
> No. If I read the dig output correctly there are two NXDOMAIN and one
> valid external IP for the last variant.
>
> $ dig localhost.
>
> ; <<>> DiG 9.3.0 <<>> localhost.
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 49986
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
This is undesirable on the part of the nameserver you are using. You you are
running BIND locally, consider adding a localhost zone like this:
$TTL 604800
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Default TTL
;
@ IN NS localhost.
@ IN A 127.0.0.1
...otherwise, suggest it to your ISP or whoever.
>>Perhaps your sendmail is misconfigured. You should set the canonical
>>hostname to be a fully-qualified value, and you should ensure that
>>sendmail sees this.
>
>
> In /etc/rc.conf I have: hostname=lahksa.t-link.de
> The IP is static, I also have an entry in /etc/hosts with it.
OK. /etc/hosts also has a localhost entry, right?
>>Consider the output of:
>>
>> echo "3,0 user@localhost" | sendmail -d0.1 -bt
>
>
> $ echo "3,0 root@localhost" | sendmail -d0.1 -bt
> Version 8.13.3
> Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7
> NAMED_BIND NETINET NETINET6 NETISO NETUNIX NEWDB PIPELINING
> SCANF STARTTLS TCPWRAPPERS USERDB XDEBUG
>
> ============ SYSTEM IDENTITY (after readcf) ============
> (short domain name) $w = lahksa
> (canonical domain name) $j = lahksa.t-link.de
> (subdomain name) $m = t-link.de
> (node name) $k = lahksa.t-link.de
> ========================================================
>
> ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
> Enter <ruleset> <address>
>
>>canonify input: root @ localhost
>
> Canonify2 input: root < @ localhost >
> Canonify2 returns: root < @ lahksa . t-link . de . >
> canonify returns: root < @ lahksa . t-link . de . >
> parse input: root < @ lahksa . t-link . de . >
> Parse0 input: root < @ lahksa . t-link . de . >
> Parse0 returns: root < @ lahksa . t-link . de . >
> ParseLocal input: root < @ lahksa . t-link . de . >
> ParseLocal returns: root < @ lahksa . t-link . de . >
> Parse1 input: root < @ lahksa . t-link . de . >
> Parse1 returns: $# local $: root
> parse returns: $# local $: root
That appears to be looking and working fine. Mail sent to localhost gets
canonified with your FQDN, which is then recognized and passed off for local
delivery.
> I noticed another thing. IIRC, in older versions of NetBSD local mails had
> only one Received: header line. Since a while they have two.
Really old versions of sendmail would only have a single Received: header line.
Newer versions do a handoff between the MSA (the clientmqueue) and the MTA
(which does the /var/spool/mqueue).
> It seems the first one works Ok, while the problem occurs when it tries to
> forward the mail the second time. This is the upper header in this example,
> the last mail that got through correctly:
>
> From root@lahksa.t-link.de Fri Aug 19 03:15:45 2005
> Return-Path: <root@lahksa.t-link.de>
> Received: from lahksa.t-link.de (localhost [127.0.0.1])
> by lahksa.t-link.de (8.13.3/8.13.3) with ESMTP id j7J1FiDE017168
> for <root@lahksa.t-link.de>; Fri, 19 Aug 2005 03:15:45 +0200 (CEST)
> Received: (from root@localhost)
> by lahksa.t-link.de (8.13.3/8.13.3) id j7J1F0h6023665;
> Fri, 19 Aug 2005 03:15:01 +0200 (CEST)
> Date: Fri, 19 Aug 2005 03:15:01 +0200 (CEST)
> From: Charlie Root <root@lahksa.t-link.de>
> Message-Id: <200508190115.j7J1F0h6023665@lahksa.t-link.de>
> To: root@lahksa.t-link.de
> Subject: lahksa.t-link.de daily output for Fri Aug 19 03:15:00 CEST 2005
>
> The returned mails in clientmqueue have only the lower header.
Mails in clientmqueue haven't been delivered yet. You need to run a
clientmqueue runner or fire one off periodicly from cron. See the
sendmail/src/SECURITY document (path may vary slightly), especially the section
towards the end which states:
> Mail will end up in the client queue if the daemon doesn't accept
> connections or if an address is temporarily not resolvable. The
> latter problem can be minimized by using
>
> FEATURE(`nocanonify', `canonify_hosts')
> define(`confDIRECT_SUBMISSION_MODIFIERS', `C')
>
> which, however, may have undesired side effects. See cf/README for
> a discussion. In general it is necessary to clean the queue either
> via a cronjob or by running a daemon, e.g.,
>
> /PATH/TO/sendmail -L sm-msp-queue -Ac -q30m
Try running "sendmail -L clientmqueue -Ac -q30m" directly by hand and see
whether that helps.
--
-Chuck