I would have the following "worries": - performance of pulling / update object on images individualized by recipient, if there are really many recipients (which is in general the case for an "Announce")
Yes, I had realized that and expect to use it for associations with less than 100 intended recipients.
- what if recipients are distribution lists or generic emails ? (that's also often the case of "Announces"). I don't think there's any easy way to know what are the "real" recipients behind ...
As good as email can be; this is true. Although I do not know how to implement it, I would favour to use user-names and resort to individual emails separately. This also supports better the read-witnessing (avatar, user-name, ... no cryptic emails).
You could also have a look at return receipt [1] though it's a pretty uncertain mechanism.
It seems to have gone away from most email clients nowadays. I am not sure why.
Though quite different use-case, the most similar I know may be the Newsletter Application. Ideally, I suppose some "Distribution List Application" may be a nice addition, to be (re)used both by the NewsLetter application and your proposed app ;-) So you could create DLs inside the wiki, then send an Announce or a Newsletter to a particular DL (instead of relying on DLs managed by various email or mailing lists servers - but on another side, that's encroaching on those servers' territory :) ).
[1] - http://en.wikipedia.org/wiki/Return_receipt [2] - http://extensions.xwiki.org/xwiki/bin/view/Extension/Newsletter+Application
Where I found the idea of announce nice is that the content of the announce is visible as one page and its "reads" are displayed there as well. People can refer to it and show it to each other. Compared to a newsletter distribution list, a facet of an association with local activity is that the names and faces of others are almost all known so that displaying the recipients name is a good idea. I do not seem to see this there. The template approach might be useful indeed but it seems a bit "profesional oriented". Also, I strongly refuse to send PDF files instead of email bodies as this encourages weight in the mailboxes, left-around-files in the attachments' temporary directories, and almost encourages the people to print. paul