Hi there
On Sat, 17 Mar 2007, Martin Schulze wrote:
Please be more verbose.
Why should gethostname() not return the valid hostname of the host
it runs on?
If it doesn't return something useful, I'd expect /etc/hostname and
thus the hostname setting to be bogus and correction-requiring.
On Debian installations, the name in /etc/hostname and /etc/mailname and
/etc/hosts should be consistent. If this isn't the case, the local
admin has botched it, I'd say until proven otherwise.
First of all, a host is not the same thing as a domain;
You can not expect '[EMAIL PROTECTED]' to work when it really
should be '[EMAIL PROTECTED]'.
This is why Exim for instance, uses /etc/mailname for it's default domain.
And this still leaves you with the option of changing the qualify domain
in it's config.
Secondly, a lot of people use multi homed hosts. And often some of the
interfaces are in private (RFC 1918) address space. Often the domains used
on RFC 1918 lans have names like 'lan' or 'local'. Or use a subdomain
like lan.example.org or int.example.org
One is not allowed to publish private address space in public dns. So MX
records for hostnames in private address space are problematic. I solved
this with a wildcard MX record, but this is not an option for everyone.
Example;
In my case gethostname() returns the name of eth1, sput.int.sput.nl which
has address 192.168.1.1
If it returned the name of ppp0, ns.sput.nl (213.84.159.78) things would
be less problematic.
Still, 'sput.nl' is what it should use, which is in /etc/mailname.
If the mail from a form is forwarded to host which does callout
verification,
http://www.exim.org/exim-html-4.50/doc/html/spec_39.html#IX2587
the mail will be rejected if the Return-path doesn't contain a domain
(with a MX) one can actually connect to. Which was the problem I was faced
with.
Regards,
Rob
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
