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