[sf-lug] mail loop: problems with exim4 on ubuntu server 8.04.1

[Michael Paoli]

mail loop: problems with exim4 on ubuntu server 8.04.1

> Date: Thu, 18 Dec 2008 08:54:17 -0800
> From: jim <jim at well.com>
> Subject: [sf-lug] problems with exim4 on ubuntu server 8.04.1
> To: sf-lug at linuxmafia.com

> ------ This is a copy of the message, including all the headers. ------

> Received: from [192.168.1.1] (helo=ubuntu10)
>         by ubuntu10 with esmtp (Exim 4.69)
>         (envelope-from <jim at well.com>)
>         id 1LDM4v-0004ZR-JI
>         for jim at systemateka.com; Thu, 18 Dec 2008 08:50:25 -0800
<snipped 27 quite repetative Received: headers>
> Received: from [192.168.1.1] (helo=ubuntu10)
>         by ubuntu10 with esmtp (Exim 4.69)
>         (envelope-from <jim at well.com>)
>         id 1LDM4l-0004Y5-Qf
>         for jim at systemateka.com; Thu, 18 Dec 2008 08:50:15 -0800
> Received: from smtp.well.com ([208.17.81.207])
>         by ubuntu10 with esmtp (Exim 4.69)
>         (envelope-from <jim at well.com>)
>         id 1LDM4l-0004Y2-6l
>         for jim at systemateka.com; Thu, 18 Dec 2008 08:50:15 -0800

That (above) would be a mail loop.  When a mail item passes multiple
times through the same MTA on the same host or device, still targeted
to same recipient(s), and not otherwise substantially changed, we have
a mail loop.  Most typically MTAs will reject ("bounce") the email when
the Received: header count reaches some unusually high number - quite
typically 30 - as we see here in this case.  The presumptions being
that there's typically a Received: header added on each hop, and when
that count gets unusually high - e.g. >=30, it's much more likely
something has gone rather wrong (e.g. mail loop), rather than each hop
being legitimately appropriate for the email item to get from its
origin to its destination.

 From the above, we can quite readily see the looping.  [192.168.1.1]
(helo=ubuntu10) thinks that to get email to jim at systemateka.com, we
relay it to 192.168.1.1, and hence we have a loop - until the MTA
rejects and bounces the message, or the loop is otherwise broken.

In such a case, one typically needs to look at the mail routing
configuration (MTA configuration, DNS, etc.) and correct the bits that
need fixing (e.g. is the MTA supposed to be recognizing
@systemateka.com as itself, and processing as local, rather than
relaying?  Or if @systemateka.com isn't local, where (non-locally!)
should it be getting relayed to?)

$ dig -t MX systemateka.com. +short
20 mail.systemateka.com.
dig -t A mail.systemateka.com. +short
64.81.61.126

Looks like - from the Internet, anyway - it should go to 64.81.61.126.
After that is beyond Internet scope.  E.g 192.168.1.1 would be RFC 1918
- Address Allocation for Private Internets - likely behind or beyond NAT
device or system.