Hi!

I found a small bug in the file rfc1035/rfc1035mxlist.c.

The bug is in the addrecord() function:

while ( *list && (*list)->priority < mxpreference ) list= &(*list)->next;

should get changed to:

while ( *list && (*list)->priority <= mxpreference ) list= &(*list)->next;

The reason for this is that the original code reverses the order of the address records for an MX preference level. When add_arecords first calls harvest_records for AAAA records and after that calls harvest_records for A records, this results in IPv4 addresses tried before IPv6 addresses which is incorrect according to RFC 3974 section 3.

And alternative solution to fix the problem would be to change the order of the harvest_records() calls for AAAA and A records within the add_arecords() function, but in that case also the code for processing the HARVEST_NODUPE flag would have to be modified, as this flag would have to be used with the AAAA record call in that case.

Without the patch "testmxlookup tthias.eu" shows the addresses in the incorrect order:

# testmxlookup tthias.eu Domain tthias.eu: Relay: mailin.amessage.eu, Priority: 10, Address: ::ffff:212.112.238.55 [ LOCAL ] Relay: mailin.amessage.eu, Priority: 10, Address: 2001:6f8:900:10d::2 [ LOCAL ]

After fixing the bug textmxlookup returns the addresses in the correct order:

# testmxlookup tthias.eu Domain tthias.eu: Relay: mailin.amessage.eu, Priority: 10, Address: 2001:6f8:900:10d::2 [ LOCAL ] Relay: mailin.amessage.eu, Priority: 10, Address: ::ffff:212.112.238.55 [ LOCAL ]

Matthias