Douglas Otis wrote:
On Jun 18, 2009, at 11:18 AM, hector wrote:
Douglas Otis wrote:
1) Why?
There is use in specifying an API here. Every other protocol
we've named so far as examples have an API, whether de facto from
lots of experience, or implicit from the spec that defines it the
protocol, or something actually explicit defining the API.
There's no evidence that this is a bad idea.
This has already been defined by RFC 4871 as the i= value, and
when that is not available, this defaults to @<d= value>.
This is why I as seeking an answer to why just d= and not anything
else. What it for a reputation system?
The response from a closed group of large email providers regarding
how they would like to have their reputation handled was to have their
entire domain's messages receive the _same_ reputation. This is not
surprising. Treating all of their messages en mass makes it
impractical to isolate abusive accounts or to retain delivery
integrity. :^(
This is also why they wish to ignore DKIM's potential for replay
abuse. DKIM suffers the problems found with any cryptographic
solution that can be replayed. Once all of the domain's signatures
are white-listed as suggested, this will invite massive levels of abuse.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html