SSP desperately needs real life experience before we start
twiddling it.
I'd like to go with the current modest version and come back
after we've found out what's useful and what isn't.
The reporting address sounds like a fine idea, but as we've
already seen there's all sorts of questions that would benefit
from experience, like how much you redact, and to what extent
asking for reports would be an invitation to be mailbombed.
R's,
John
I agree with John about getting more real world experience and noit
holding up the current version.
I also believe reporting/feedback is critical to getting adoption of SSP
(and DKIM) moving forward. Even reporting in the aggregate (pass/fail)
is extremely useful. At ISOI4 I presented some very preliminary numbers
on DKIM fails that were based on feedback by a handful of receivers.
There was a very strong response from people and lots of interest.
Basically, senders that will take advantage of SSP with stronger
assertions have no way of knowing upfront what sort of breakage from
forwarding they might encounter.
Hopefully we will see some receivers providing feedback as part of their
whitelisting programs and/or feedback services like Return Path is
planning.
Just a few thoughts.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html