I think all of the use cases are good, but I'd
like to point out that there's already a significant problem with
SMTP "enhancements". The ISP that provides my IP connectivity
has severe email filters and they do not offer per user "customization".
Their implicit, unwritten, use policy is "by using our services
you agree to having us muck with your email in any way that pleases us."
Thus, I have to pay for a second ISP in order to get email services
without filtering. That ISP does, however, sometimes impose filtering
even on "no filter" accounts, simply because their techs don't realize
that such accounts exist. Recently the filtering caused me to be
suspended from almost all IETF mailing lists. Fortunately, they
lifted that particular filter when I talked to them about it;
they'd forgotten it was there.
My point in this anecdote is that because there is no required API
for per account customization *by the customer* for SMTP filtering
today, the overall utility of SMTP is, in my opinion, drastically
reduced. This is why I think that defining the protocol that lets
the user adjust the filtering rules is so important for SMTP.
When we began this work, I thought that the per account customization
for HTTP was very important, but not worth screaming about. In the
intervening years HTTP has become more important to daily life, and I
think the issue is as important as for SMTP. I would really like to
see some ideas on how to get this specified and set into standards
as we move forward with SMTP.
Hilarie