From: Michael Thomas [mailto:mike(_at_)mtcc(_dot_)com]
Sent: Thursday, October 07, 2004 1:23 PM
Seth Goodman writes:
<...>
> I was overly restrictive when I said MTA. What I think is
> important is that the signature be removed before the
> message is delivered to the MUA.
Why? And should I assume that you mean that signatures must
be removed *always*? This seems like a local policy decision
that the receiving MTA and/or MTA can decide all on their
own whether they want to scrub the headers, but IMO, there
should be a pretty compelling reason to scrub them since
mail might get forwarded, etc, etc.
I am assuming that the signatures do not have a long life. Therefore, any
MUA that tries to validate a signature would get a result that depended on
when they did it. If you go on vacation and mail piles up in your inbox,
the signatures could easily have expired by time you get back. This
variability is a problem. The point of an end-to-end MTA protocol is that
the identity is validated at the time of reception and that's it.
> If
> forwarding can be done by the MDA, then the MDA should have the
> responsibility to remove the signature in the case of local
> delivery to an
> end-user. If an end-user system wants to automatically
> forward mail, it
> should use re-mailing rather than alias forwarding. The
> end-user system is now the new message originator.
The idea that there is exactly one "originator" seems
wrongheaded to me. Stripping the signatures to enforce that
point even worse. Why people seem intent with throwing away
interesting information is rather curious to me. What does
it buy you? Keeping them there, on the other hand, buys you
a lot: traceability, potential survival through bounces and
forwards, etc, etc. The flip side is that a robust receiver
MUST be able to deal with multiple signatures anyway (be
liberal in what you accept...). I just don't get it.
If you have no way of later validating the "interesting information", what's
the point of keeping it, especially if it is easy to forge after the fact?
The fact that your incoming MTA recorded that the signature validated is
good evidence for traceability. How can you force the sender to later
produce the correct public key? If they are denying accountability for the
message, it is in their interest to produce a bogus key so the signature
will appear invalid. Can you prove otherwise? If you can't, why keep the
actual signature?
As far as bounces and forwards go, I was arguing that the signature be kept
until final delivery to an end-user. The MDA should keep the signature
until that time so it can send it back with the DSN, as you suggest. In the
case of alias forwards, this is done by an MTA or MDA, so the signature
should be kept in that case as well. In the case of re-mailing forwards
(using Resent-* headers), the re-mailer becomes the new originator and is
taking responsibility for the message. The original signature may expire by
time the new recipients get the re-mailed message.
I think the concept of multiple signatures in a message is a really
interesting one. If it has to deal with the possibility of intermediate
signers adding content, I wonder if it is possible to solve it without major
changes to all MUA's? Also, the possibility of message with multiple
signatures arriving at an MTA does complicate matters greatly. How do you
express a policy that deals with the fact the forwarder's signature
validates but not the originator? How about the originator's and second
forwarder's signature validates but not the first forwarder? Finally,
validating multiple PK signatures by the recipient is starting to look like
a gratuitous DoS, or at least an unwanted load.
--
Seth Goodman