Noel Jones wrote:
> Schilling, Timo wrote:
>> Wietse Venema wrote:
>>> Schilling, Timo:
>>>> Postfix shouldn't negate the flag (from 1 to 0) so that the function
>>>> "res_search" doesn't append the known domain-informations.
>>>> But it is done in the above mentioned file, but why?
>>> Because it makes no sense to append MY OWN DOMAIN to the hostname
>>> from a REMOTE client.
>>>
>>> Wietse
>>
>> Yes thats true, if the postfix-server is connected to the internet. In
>> our case we use the server only for internal mail-communication, so that
>> the remote-domain matches MY OWN DOMAIN.
>>
>> Regards
>> Timo Schilling
>
> Why on earth would you check the HELO name of local clients?
> Many user mail programs will send junk HELO names; it's nearly universal
> practice to exclude local and/or authenticated clients from such checks.
>
mmhh....I think I should start from the beginning...
We have a central and internal mailserver, which uses postfix (v2.5.1).
Every host delivers it's mails to this host and expect that this hosts
routes the mail to the internet, to another host in the network or to
the central mailserver for our customers.
Now, we tried to decrease the junk mails while we use such options as
"reject_unknown_helo_hostname", "reject_non_fqdn_sender" and so on.
While this options are working, we recognized that internal hosts are
rejected because of an unknown helo-hostname. Some hosts started with an
"helo hostA", which isn't a full-qualified-hostname, why it should be
rejected, but we don't use the option "reject_non_fqdn_helo_hostname".
So we expect if "hostA" is known to our dns-server it will be accepted
anyway. But this wasn't right. The mails has been rejected, regardless
of an existing dns-entry or not. Postfix didn't ask our dns-server for
that hostname, he confirmed the hostname is unknown.
We wanted to know why postfix says it's unknown even though it's known
to our dns (with our default-domain).
As mentioned before, the one little line in the source code "says" the
system-c-function "res_search" not to append the default domain. While
there are no dots in the name res_search didn't try to reach a dns-server.
So we don't want to exclude the internal hosts, these are the hosts
which we want to control!
The only question left is, why this line negates the "saved_options"?
If it wouldn't, a postfix, which is used in the internet, have to ask
the dns-server more often, because of the own domain which is appended.
Than a system could accidentally permitted, because the given hostname
exists also in the local dns-server. But is this the reason why postfix
shouldn't request the dns-resolution or is there something else behind?
Here again the line out of "dns_lookup.c":
[...]
for (;;) {
_res.options &= ~saved_options; /* saved_options are negated
and merged with the global variable _res.options */
_res.options |= flags;
len = res_search((char *) name, C_IN, type, reply->buf,
reply->buf_len); /* call the system-function "res_search" */
_res.options &= ~flags; /* negate res.options back to
what it
was before system-call ... */
_res.options |= saved_options;
[...]
