Douglas Otis wrote:
On Feb 15, 2008, at 3:49 PM, Damon wrote:
Just in case we need a tie breaker... -1
To summarize, as a bunch of -1 says so little, ...
I know, don't you hate that. :-) I call it the "Follow the Chieftain
Syndrome" In my opinion, if "votes" came with some reason or
explanation for the position, it might help sway others.
.... the push back generated
by this concept had to do with DKIM policy being applicable to other
transport protocols that might be bridged into SMTP.
Doug, for the record, I was more against the MX lookup MUST in the SSP
record discovery setup. IMO, I prefer it to be a MAY or even a SHOULD
only because historically it was not a requirement and therefore highly
possible that the MX did not exist.
Keep in mind the steps in SSP is only a recommendation. As long as the
end result is the same, people don't have to follow those steps. It is
very possible the MX lookup was already been done in other places.
Look at this way, the way I view it, if we keep the MUST MX lookup
requirement for the SSP discovery steps, then +1, I would agree there
should also be a MUST for adding/having a MX record for any x822.From
domain used in a domain's new DKIM signing mail operations.
So I have less of a problem with the idea from a general DKIM deployment
recommendation for domains to consider and even possibly a SHOULD
recommendation for having an MX record for x822.From from the standpoint
of "DKIM/SSP protocol consistency" especially when it differs from the
return path or sender domains.
The ability to clearly indicate whether any message is fraudulent
without incurring additional transactions is also important from a
general domain protection standpoint. Jim is right. Policy can be made
to include scope, and that also offers a more flexible and workable
solution. Message abuse will demand negotiated changes accommodated to
some extent by policy assertions. Keeping a lid on the the added
overhead represents the remaining challenged.
+1, You're right. This is a very important part (for me) in the
implementation considerations.
But consider, before you can mandate an x822.From MX with a MUST, you
also have to, at the very least, allow for verifier policy based
handling and that has been removed in the current emasculated model.
Since policies allowed implementators to optimize and scale DKIM
processing, its removal reduces the MDA adoption incentive for DKIM
verification. Thus, with little to no payoff resulting from the
additional overhead, there is less reason to even bother with the
overhead.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html