Hi all!
I believe that the algorithm specified in the latest SSP draft (section
4.4) is the best compromise possible and that it will cover the largest
percentage of use cases. However, I agree it's not perfect. Algorithm
steps #4 and #5 are the problem as there is no definitive list of TLDs
available and yet these steps call for the use of such. As an
implementor I'm worried about how I can comply with this part of the
algorithm. These steps suggest the use of a locally maintained or
implementation specific TLD list. But such lists would necessarily
differ from one deployment or implementation to another leading to
inconsistent application of SSP in the wild. This worries me greatly.
I'd like us to at least consider the possibility of removing the steps
associated with querying the immediate parent of the domain in question
(steps #4 and #5). Admittedly, this causes more administrative hassles
for certain classes of senders but no solution to this question will be
perfect in all cases.
I keep coming back to this: some of the brightest people I've ever meet
are members of this WG yet we are still grappling with this issue. I
think this points to the fact that maybe we can't solve this one and
that we should accept that and move forward with an even simpler
algorithm (by removing these two steps).
Anyway, I bow to the collective wisdom here of course but I'm hoping we
can at least discuss this some.
Arvel
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html