FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 04-12-2008, 10:10 AM
"Bernhard R. Link"
 
Default exim, local resolver, host name lookups and IPv6

* Marc Haber <mh+debian-devel@zugschlus.de> [080412 10:42]:
> [...] Thankfully, gethostbyname2 is
> used in exim's source code only twice (with one of the occurrences
> being inside an if( primary_hostname == NULL ) which doesn't apply if
> primary_hostname is set in configuration, which is the case if exim is
> configured with the minimaldns option. So, the AAAA lookup must be
> triggered by the gethostbyname2 call in host.c line 1969, which I not
> yet have fully understood. Can some more experienced C programmer
> comment on this part of the code?

That simply seems to be exim's host_find_byname function to encapsulate
the different ways on different systems to do host lookups. So this
lookup can origin from almost everywhere. (this early one possible
cause might be resolving the name showing up in another config option).

Hochachtungsvoll,
Bernhard R. Link


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-12-2008, 11:06 AM
Tollef Fog Heen
 
Default exim, local resolver, host name lookups and IPv6

* "Bernhard R. Link"

| * Marc Haber <mh+debian-devel@zugschlus.de> [080412 10:30]:
| > >I think the main problem is that Debian is by default setting up those
| > >ipv6 stuff into the interface even when you are in an pure ipv4
| > >environment. That way exim4 cannot do anything to avoid ipv6 stuff
| > >and evil things like this can happen.
| >
| > Another process on the local system might actually use IPv6 on the
| > local links, so I'd vouch for tweaking the system (or exim) to not
| > break if IPv6 is enabled but not fully connected.
|
| Yes, that might even be better. Sadly while getaddrinfo(3) has
| AI_ADDRCONFIG, it says "IPv6 addresses are only returned if the local
| system has at least one IPv6 address configured". (Dunno if something
| like "has a working ipv6 setup" instead would be properly detectable
| by libc).

If «has a working ipv6 setup» means «has a address with scope better
than $value», then yes, that's easy. See my other post to this
thread. I think «has at least one IPv6 address configured» should
mean «has at least one IPv6 address which may be in DNS configured».
Yes, this probably breaks NAT-PT, this probably also breaks for people
who want to talk to services on localhost using IPv6 (and doesn't
otherwise have IPv6 configured) as well as people who put link-local
addresses into DNS. Don't do that, then. IMNSHO.

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
 
Old 04-12-2008, 02:58 PM
The Fungi
 
Default exim, local resolver, host name lookups and IPv6

On Sat, Apr 12, 2008 at 10:41:54AM +0200, Marc Haber wrote:
[...]
> Where can I obtain the FQDN of the system instead?
[...]

You can't, necessarily. Especially if the MTA is running on RFC 1918
addresses behind a NAT and relying on external DNS (which I expect
is becoming quite common these days). Is there any way to simply
*insist* the FQDN be present in the config (provided by the
administrator via debconf or by manual editing after installation)
and just be done with all the guessing? Maybe even refuse to start
the daemon until this is provided, with a clear error message to
that effect?
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fungi@yuggoth.org); IRC(fungi@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fungi@yuggoth.org);
MUD(fungi@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-12-2008, 04:51 PM
Marc Haber
 
Default exim, local resolver, host name lookups and IPv6

On Sat, 12 Apr 2008 11:32:32 +0200, "Bernhard R. Link"
<brlink@debian.org> wrote:
>* Marc Haber <mh+debian-devel@zugschlus.de> [080412 10:30]:
>> >I don't think that is only limited to additional lookups. I think I've
>> >also seen a message not being sent on etch, because the target host
>> >also had a AAAA record. (At least I think that is the reason, after
>> >disabling ipv6 in exim4.conf it was sent).
>>
>> I'd call that a bug, since exim should have a "destination
>> unreachable" error upon trying to open the IPv6 connection in absence
>> of a IPv6 default route.
>
>I'd consider that a bug, too. What it should do is use the IPv4 address
>of the target host instead.

It'll do that after not reaching the IPv6 address.

>> The only lookup that is still visible on the network (and only in some
>> cases that I haven't yet fully nailed down) is an AAAA lookup for the
>> local host name on exim startup.
>
>Yes, "localhost" requests are not visible on the network, as long as there
>is a localhost ipv6 address in /etc/hosts. What I cannot recall is how good
>Debian is/was in also adding those items on upgrade. Perhaps not having
>that line in there was a user error.

An example /etc/hosts file created by d-i is in the message that
started this thread. We create 127.0.0.1 for localhost and
localhost.localdomain, 127.0.1.1 for the host name and FQDN given on
installation, but not analogous entry for ipv6.

Greetings
Marc

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
 
Old 04-12-2008, 04:53 PM
Marc Haber
 
Default exim, local resolver, host name lookups and IPv6

On Sat, 12 Apr 2008 14:58:24 +0000, The Fungi <fungi@yuggoth.org>
wrote:
>On Sat, Apr 12, 2008 at 10:41:54AM +0200, Marc Haber wrote:
>[...]
>> Where can I obtain the FQDN of the system instead?
>[...]
>
>You can't, necessarily.

So it needs to be in /etc/hosts.

>Is there any way to simply
>*insist* the FQDN be present in the config (provided by the
>administrator via debconf or by manual editing after installation)
>and just be done with all the guessing?

I'd rather avoid this and guess the name from a central point created
during installation.

> Maybe even refuse to start
>the daemon until this is provided, with a clear error message to
>that effect?

Nosireebob, people do not read error messages but post bug reports
instead. I am not prepared to handle these.

Greetings
Marc

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
 
Old 04-13-2008, 12:50 PM
"Alexander E. Patrakov"
 
Default exim, local resolver, host name lookups and IPv6

Steve Langasek wrote:

On Sat, Apr 12, 2008 at 12:13:36PM +0600, Alexander E. Patrakov wrote:

Marc Haber wrote:

In some cases, exim still looks up its IP address when a listening
daemon starts up. This is why the Debian installer configures
127.0.1.1 (not 127.0.0.1) for the local hostname on installation,
yielding /etc/hosts files like


127.0.0.1 localhost
127.0.1.1 myfoo.localdomain myfoo



<snip>



This being said, I consider the entire 127.0.1.1 business a horrible
hack which is one of the most ugly things I have ever seen. Do we have
a chance to implement this in a more cleaner way, or is it still the
way to go for the distribution, where we don't know zilch about the
environment where an installed system is going to be used?



I second this request.


Oh yes, by all means, let's flip-flop the /etc/hosts implementation back and
forth because people /second/ it, without ever bothering to understand the
reasons that made this necessary.


I don't understand this Debian-specific _hack_ because the unusual and
Debian-specific 127.0.1.1 entry has no comment referring to a problem that it
fixes ("see bug #xxxxxx" would be enough). Honestly, I even considered it my own
typo first when I encountered the vde2 breakage.



Just a data point: this 127.0.1.1 setup breaks the "vde2" package (namely,
its slirp-based part) if a local DNS server that listens on 127.0.0.1 only
(e.g., pdnsd) is used.


Then vde2 has broken assumptions and should be fixed.


I will file a bug against both pdnsd and vde2.

--
Alexander E. Patrakov


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-14-2008, 08:39 AM
Vincent Danjean
 
Default exim, local resolver, host name lookups and IPv6

Marc Haber wrote:
> On Sat, 12 Apr 2008 14:58:24 +0000, The Fungi <fungi@yuggoth.org>
> wrote:
>> On Sat, Apr 12, 2008 at 10:41:54AM +0200, Marc Haber wrote:
>> [...]
>>> Where can I obtain the FQDN of the system instead?
>> [...]
>>
>> You can't, necessarily.
>
> So it needs to be in /etc/hosts.

This would lead to broken config for a lots of *DSL box.
When the machine is running on RFC 1918 addresses behind a NAT (made by
the router), what you need is the external FQDN hostname of the router
(which must be configured to forward the port 25) to answer to the EHLO
greating.
And adding the router fqdn in the machine /etc/hosts seems really wrong
to me in that case: the machine is not the router and must not be reached
when trying to reach the router.

>> Is there any way to simply
>> *insist* the FQDN be present in the config (provided by the
>> administrator via debconf or by manual editing after installation)
>> and just be done with all the guessing?

This seems a good tip. The FQDN for mail must be in a config file.

> I'd rather avoid this and guess the name from a central point created
> during installation.

This value can, indeed, be guested at installation time with any heuristic
(/etc/mailname, gethostby*(), debconf, ...)

>> Maybe even refuse to start
>> the daemon until this is provided, with a clear error message to
>> that effect?
>
> Nosireebob, people do not read error messages but post bug reports
> instead. I am not prepared to handle these.

So, in case the user REMOVE the config value, you can failback to these
guesses (with a warning in the logs ?). But the normal (enforced at
installation/upgrade time) way should be a documented value in a config
file.

Best regards,
Vincent
--
Vincent Danjean GPG key ID 0x9D025E87 vdanjean@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87
Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package
APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-14-2008, 11:42 AM
Gabor Gombas
 
Default exim, local resolver, host name lookups and IPv6

On Sat, Apr 12, 2008 at 10:41:54AM +0200, Marc Haber wrote:

> Where can I obtain the FQDN of the system instead?

_Which_ FQDN? A machine may have several IP addresses, in the DNS there
may be multiple A records for every IP address (and the reverse PTR
records may be completely meaningless placeholders).

Gabor

--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-14-2008, 11:50 AM
Stephen Gran
 
Default exim, local resolver, host name lookups and IPv6

This one time, at band camp, Gabor Gombas said:
> On Sat, Apr 12, 2008 at 10:41:54AM +0200, Marc Haber wrote:
>
> > Where can I obtain the FQDN of the system instead?
>
> _Which_ FQDN? A machine may have several IP addresses, in the DNS there
> may be multiple A records for every IP address (and the reverse PTR
> records may be completely meaningless placeholders).

Marc,

I suspect that this line of enquiry is just going to make Debian's
exim config setup even more baroque and less useful to people who
actually use exim the way it was designed to be used. Can't you just
document it, and close bugs as they come in with a note to the docs? I
know it's not perfect, but I'm not completely convinced that running an
MTA behind a dial on demand setup is so normal an endeavor that we
should bend over backwards to support it out of the box.
--
-----------------------------------------------------------------
| ,'`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
 
Old 04-14-2008, 09:24 PM
Robert Edmonds
 
Default exim, local resolver, host name lookups and IPv6

On 2008-04-12, Marc Haber <mh+debian-devel@zugschlus.de> wrote:
> On Fri, 11 Apr 2008 17:48:19 +0000 (UTC), Robert Edmonds
><edmonds@debian.org> wrote:
>>Yes, there is a much better way: do not perform name resolution to
>>determine the host's FQDN. It is wrong.
>
> This is what exim does to determine the local host name:
>|This variable contains the value set by primary_hostname in the
>| configuration file, or read by the uname() function. If uname() returns a
>| single-component name, Exim calls gethostbyname() (or getipnodebyname()
>| where available) in an attempt to acquire a fully qualified host name. See
>| also $smtp_active_hostname.
>
> Is this broken?

IMO, yes: the nodename returned by uname() may have nothing to do with
information in the DNS.

I haven't looked at the exact sequence of calls exim makes, but a common
one is:

1) obtain the hostname via uname() or gethostname()

2) obtain the IP address corresponding to this hostname by calling
gethostbyname()

3) obtain the "fully qualified" hostname by calling gethostbyaddr()
on this IP address

This is somewhat damaged especially if the gethost* calls result in DNS
lookups for some reason, because the information in DNS could be under a
completely separate administrative domain.

Another problem is insisting that a "single-component name" isn't fully
qualified is wrong, too. E.g., "ai" is a fully-qualified Internet mail
domain:

edmonds@chase{0}:~$ dig +short mx ai
10 mail.offshore.ai.

> But this documentation is kind of incorrect in the first place, since
> the AAAA lookup I see is caused by a call to gethostbyname_2_, which
> is not mentioned int he docs at all. Thankfully, gethostbyname2 is
> used in exim's source code only twice (with one of the occurrences
> being inside an if( primary_hostname == NULL ) which doesn't apply if
> primary_hostname is set in configuration, which is the case if exim is
> configured with the minimaldns option. So, the AAAA lookup must be
> triggered by the gethostbyname2 call in host.c line 1969, which I not
> yet have fully understood. Can some more experienced C programmer
> comment on this part of the code?
>
>> The MTA needs to know the
>>"mail name" or FQDN of the system, and it may need to know specific IPv4
>>or IPv6 addresses to bind to if it is running an SMTP server, but it
>>does not need to know any particular mapping between the two.
>
> Where can I obtain the FQDN of the system instead?

Perhaps by asking the user at installation/configuration time, and
storing this information in some sort of file that stores the, erm,
"mail name" of the system

> Don't I need the particular mapping between IP addresses and host
> names to generate a proper HELO? But I wouldn't expect these lookups
> to be made at startup, but only when an outgoing message is sent.

No.

>>It looks like there are functions in src/host.c for performing DNS-based
>>determination of the system's FQDN. I don't know exactly under which
>>circumstances these functions are invoked, but policy 11.6 implies that
>>they are superfluous in the presence of the /etc/mailname file.
>
> /etc/mailname is unfortunately unclearly defined in Policy, and IIRC
> the policy editors refused to clarify when asked years ago. The exim 4
> maintainers have then created http://wiki.debian.org/EtcMailName and
> asked all MTA maintainers to comment how they use /etc/mailname, but
> only a fraction of them bothered to comment.
>
> Exim 4 only uses /etc/mailname to qualify unqualified recipient
> addresses and for some rewriting tricks. This has been the cause of
> unspeakable grief in the past so I do prefer to avoid touching this
> particular part of the system.
>
>>I don't see how this issue is analogous to the 127.0.1.1 hack. From
>>reading the archived discussion[0], the problem is applications which
>>use a sequence of legacy gethostname(), gethostbyname(), etc. calls to
>>construct an FQDN, and avoiding accidentally using 'localhost' or
>>'localhost.localdomain' as the system hostname. If you're using the
>>newer getipnode* functions, it's possible that you'll get an AI_V4MAPPED
>>address even when asking for an AF_INET6 address.
>
> It looks to me that the getipnode* functions are not available in
> current Debian based on glibc 2.7.

Yes, sorry. I meant the getaddrinfo() function.

>>The analogous IPv6 hack, btw, would be something atrocious in /etc/hosts
>>like:
>>
>>::ffff:127.0.1.1 hostname.domainname
>
> I'll try that.

Is there a bug report open where this is being discussed?

>>> Any hints will be appreciated.
>>
>>IME, nullmailer and postfix seem to get along fine without generating
>>spurious DNS traffic, so
>>
>>#include <flame/default/mta.h>
>
> So please make postfix the default MTA for lenny and have exim
> removed. It obviously sucks as badly as its maintainer. I'm _soooo_
> sick of that.

Actually, I wonder if it's time for the semi-annual "do modern Linux
systems need MTAs installed by default" argument.

--
Robert Edmonds
edmonds@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 05:09 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org