[
https://issues.apache.org/jira/browse/JAMES-913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805556#action_12805556
]
Norman Maurer commented on JAMES-913:
-------------------------------------
Anyone has some idea howto fix this ?
> Incorrect MX record orderering
> ------------------------------
>
> Key: JAMES-913
> URL: https://issues.apache.org/jira/browse/JAMES-913
> Project: JAMES Server
> Issue Type: Bug
> Components: DNSServer
> Affects Versions: 2.3.1
> Reporter: Amichai Rothman
> Assignee: Norman Maurer
> Priority: Minor
>
> The SMTP RFC states that given multiple MX record, they must be ordered such
> that lower priority records come first, and equal priority records are
> randomized for load balancing. The JAMES implementation uses Arrays.sort()
> along with an MXRecordComparator, which compares the priorities, and 'flips a
> coin' if they are equal.
> This precariously breaks the Comparator contract, which can theoretically
> cause a sort implementation to loop forever, for example if it is implemented
> using a trivial bubble sort which stop when no more swaps are performed. In
> practice, it causes a different bug: the Sun implementation of Arrays.sort()
> uses insertion sort for N <= 7. So for example, if you have 5 MX records with
> equal priority, the last element is compared only in the last iteration of
> the loop, with a 1/2 probability of remaining last. On the other hand, it has
> a 1/16 probability of being swapped 4 times to become first on the list.
> So while there is randomness involved, equal-priority records will tend to
> stay near their original (relative) position, and not be shuffled with the
> uniform probability which the RFC implied for load balancing...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
