On Sat, 2004-12-04 at 12:51, Dave Crocker wrote:
Checking to see whether I understand your point:
A message may have at most one mass signature in effect at any one time.
However there may be multiple headers documenting validation of the
signature, such as by a receive-side border MTA and by the MDA.
As mail is received by the MDA, an mda-verification header is generated,
There are a number of places along the way, on the receive side, that
could legitimately be the source of the header. Not just the MDA.
That is why I listed the incoming border MTA and the MUA, as examples.
but this header is not allowed to exist within a message passed through
the Internet.
The verification header is valid only within the administrative trust
domain that creates it.
I would extend that by saying it is not allowed to enter this "trust"
domain. If this is not introduced by the MDA, it could be sent
out-of-band or some other means equivalent to having this introduced by
the MDA.
This scheme would normally result in a single verification header. For
mail forwarded, the source of the initial verification should be
documented, and this involves a verification header that is intended to
be passed through the Internet and included within the resigning.
If the validation header is only valid within the trust domain that
created it, then it does not make sense to discuss scenarios that use
the header across the open Internet. That's what you seem to be doing
here.
While the locally generated mda-verification header (for the want of a
better description) is not signed, passing this information along when
forwarding would be signed with no additional administrative overhead.
This information may be removed if submitted via the MUA. The concept
is that should this header remain within the MDA environment and is
being reissued and signed, then trusting this information is still
trusting the MDA, but if there is a problem, this information would be
useful.
The validation header is a local annotation.
It especially does not make sense to talk about validation that
survives "forwarding" (that is, after re-posting) unless you meant
relaying.
I meant specifically when reissued by an automated process such as a
list server that resigns.
(Swapping a header name should be all that is needed.) The MSA would
simply rename the existing mda-verification header as a
pass-through-verification header. (This process should over-write an
existing pass-through-verification header.) Without over-writing, it
could become a mess otherwise.
What is the point in doing this?
There is information lost that may be contained within the signature
that indicates the accountable entity. This information may become lost
otherwise.
This approach should work well for a majority of situations where a
message is modified and reissued, as example within a list server. This
pass-through-verification header documents the accountable element of
the verification used when the message was accepted into the mail
channel. If there is a problem, having this information would be useful
for resolution.
So you are trying to create an audit trail of validations? Why not
simply add this to a Received header? That's where we put audit
information.
This information can not be relayed safely in the Received headers. As
the verification headers must receive special consideration, why attempt
to retro-fit this information? Renaming the header would provide a
consistent presentation of this new entity irrespective of the
information being forwarded.
-Doug