gordanbobich.net
Date: Thu Nov 01 2007 - 09:41:27 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Thu, 1 Nov 2007, Victor Duchovni wrote:

> On Thu, Nov 01, 2007 at 02:24:43PM +0000, gordanbobich.net wrote:
>
>> 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".
>
> Which requires just 3 MX hosts not 66.

To be effective you need more. 66 was for testing purposes, but proved to
work. In a production setup I wouldn't bother using more than 10-15.

Spammers go most for the top 1 and bottom 5 MX-es.

>> 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.
>
> The additional section is a red herring, please report some evidence.

I am actually inclined to agree here. I am not convinced that this is
what's causing it because there'd be more errors.

> How many MX hosts does the domain in question have?

17

> How big is the DNS response packet?

503 bytes, but not all MX IPs are listed in the additional section, only 4
(and they are not always the 4 with lowest priorities).

> 20050622
>
> Cleanup: the DNS lookup code now accommodates name server
> replies longer than 4 kbytes, with a hard upper limit of
> 32kbytes. For safety reasons, the number of MX host addresses
> that the SMTP client will try was reduced from unlimited
> to just 5, so that Postfix won't spend forever trying to
> connect to dozens and dozens of bogus MX hosts. Files:
> dns/dns_lookup.c, global/mail_params.h.
>
> The "5" in question are the best 5 obtained. If the results were
> truncated, and the MX records were shuffled, so that the truncated
> response omits the best MX hosts, don't create jumbo MX RRsets.

What defines "best" in this case? Lowest priority? Or something else? It's
not the MX list that gets truncated, it's the additional section that
gives the A records for the MXes in the list.

> Report "postconf mail_version mail_release_date" output.

# postconf mail_version mail_release_date
mail_version = 2.2.8
mail_release_date = 20060103

Still mining the logs for a nice conclusive example, that's why I haven't
posted them yet. Hopefully in the next half an hour or so.

Thanks.

Gordan

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]