Ricardo Signes:
> 
> So, every once in a while, this crops up:
> 
>   $ dig -t mx bollygroup.com
> 
>   ; <<>> DiG 9.4.2-P1 <<>> -t mx bollygroup.com
>   ;; global options:  printcmd
>   ;; Got answer:
>   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 996
>   ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
> 
>   ;; QUESTION SECTION:
>   ;bollygroup.com.                        IN      MX
> 
>   ;; ANSWER SECTION:
>   bollygroup.com.         3600    IN      MX      0 mail.
>   bollygroup.com.         3600    IN      MX      10 mail.vishalverma.com.
> 
> These guys have set up "mail." as their lowest distance MX, and Postfix tries
> to deliver there.  It looks up "mail" and finds it under the resolver's search
> prefix (even though, as far as I understand it, the DNS response is fully
> qualified to begin with and should not be qualified by the search prefix).

As of Postfix 2.8, the DNS client does not append domains by default.
It is an incompatible change, but it avoids the behavior as described
above, and other undesirable behavior.

http://www.postfix.org/postconf.5.html#smtp_dns_resolver_options

> This leads to the mail getting stuck in the queue, because the box handling
> this mail is "mail.prefix.com," and Postfix reports "mail for bollygroup.com
> loops back to myself"
> 
> ...but it only does this if you (a) use the bogus "mail." record and (b)
> qualify "mail." with the search prefix.
> 
> Is there a way to avoid this problem *without* special casing each domain that
> has it?  That is, to say "don't qualify MX names" or "the MX name 'mail.' is
> bogus and should be ignored" or anything else?

This requires source code change:

perl -pi -e 's/RES_DEFNAMES/0/' src/smtp/smtp_addr.c

and results in behavior that is the default as of Postfix 2.8.

        Wietse

Reply via email to