Jfc,
Thank you for carrying the work!
Thank you for your feedback.
Sorry to be the unhappy one, but I feel we contributed with
many more cases?
I based the draft on the use cases collected earlier
(http://www.martin-stecher.de/opes/smtpusecases.html)
Some examples have been combined into a single use case in the draft and
some have been omitted if they are very similar to other use cases.
I see no content massaging applications?
Which example of the source list
(http://www.martin-stecher.de/opes/smtpusecases.html) are you missing in
particular?
I am not sure at all this has no security implication? Where
to you address the end to end issue: if rerouting is not
accepted by both end there is an obvious security leak?
There are many security considerations for OPES. We handled them in an
application agnostic form in RFC 3837 which this draft is referring to.
Describing use cases of existing and future email filtering use cases
that could potentially be implemented by OPES does not introduce new
security implications beyond the RFC 3837, see section 2.2 of that RFC
"OPES Flow Application Level Threats" in particular.
(And btw, it does not need both ends to accept the selected routing of
an email)
Regards
Martin