|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Wietse Venema (wietse
porcupine.org)
Date: Thu Nov 01 2007 - 10:03:27 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
gordan
bobich.net:
> On Thu, 1 Nov 2007, Jorey Bump wrote:
>
> > gordan
bobich.net wrote, at 11/01/2007 09:56 AM:
> >
> >> The MTA should try the MX-es in the correct order, regardless of whether
> >> the Additional section contains the high priority MX information or not.
> >> If that takes a second look-up specifically for the high priority MX, so
> >> be it.
> >
> > You might want to explain what you're trying to accomplish with your multiple
> > MX records. This list is ridiculously long, and the TTLs are far to high for
> > an experiment. It's hard to look at the results of this query and jump to the
> > conclusion that Postfix is at fault:
>
> You're jumping to conclusions.
>
> 1) That's not the domain that's having problems.
> 2) It's MX-es are not running postfix (they are running courier)
> 3) The MX-es are there for a reason. Google "nolisting".
> 4) Lots of MX-es are no excuse whatsoever for not re-trying them in the
> correct order, whether their IPs get reported back in the additional
> section or not.
I have one suggestion.
Point Postfix to a DNS server that doesn't truncate replies, and
show evidence that Postfix behaves incorrectly. If so, we will
investigate and may even ask you to turn on debug logging.
Postfix doesn't cut corners; it takes the MX list and then does
separate A lookups for each of them. If something is cutting corners
here it is more likely that DNS server that is truncating your
replies, and that does who knows what with the partial information.
I am, however, not interested in adding code to Postfix to work
around mis-behaving DNS servers.
Wietse
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]