Pleased to see someone else bring this up; I've just been writing
some documentation on our new S/MIME 3 toolkit, from a position of
relative unfamiliarity with the ESS services, and this really stuck
out like a sore thumb for me. I think it may have been an error to
put the automatic generation of receipts as a MUST without addressing
this problem. It may be worth raising on the list, despite the late
stage we're at in the proceedings.
Sending receipts in an automatic way is a strange implemenation.
The problem is at 15 years old, and lot's of text has been
written about it.
In the model that was borrowed from X.420, nothiing is said about
when a receipt is generated. In any case, a receipt notification
is just a specially formatted message. people have fortunalety
given up to specify requirement about when these things should be
generated.
The common misunderstanding is that people talk about
'read notification' and an analogy of the postal service with
registered letters with receipt.
It is understandable that such a kind of service may be desirable,
but then the underlying model is wrong. The postal service just gives
the originator an indication that some letter has been received
but nothing about the contents.
IMHO a receipt is a conscious act from a user who wants to indicate
the reception/refusal of a message; the creation of a receipt is by no
means related to the action of reading a message for the first time.
At any time a user should be able to generate or not a receipt.
Whether the receipt has just informational character or more
depends on the context.
If one reads carefully the ess text, a lot is about about 'validation'
of the receipt request. This validation includes what? At least, the
validation of the 'signatures' on the receipt request, thus all kinds
of certificate path handling etc; a local policy can decide, we don't
accept signatures from anyone on these types of messages.
Validation of a signature does not necessarily occur at reading time.
This should also be a conscious act of the user, since it may
involve network interactions (OCSP calls or others).
And also: SPAM, SPAM, SPAM.
If I had to use a tool kit that generates such a stuff,
the first thing would be to stop my outgoing mail, and delete the
stuff before it gets sent.
Inside a closed environment that uses a mail based application, the
situation may be different, but in this case it should still be
the application that decides when and how to create a receipt, and
never whatever an underlying mail tool kit as an automatic result
of a transfer of the message to the application.
Of course, some may have a another philosophy. :-)
The type of certificate used is still another question.
Peter