From: Tony Finch
Sent: Friday, October 08, 2004 5:01 AM
On Thu, 7 Oct 2004, Seth Goodman wrote:
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? Remember that recipient sites which do not implement this protocol
will leave the signatures in the message.
This suggestion is all based on the notion that the signature life is
limited, unlike traditional PK signatures. The problem this is meant to
avoid is a signature available at the MTA that will validate for a short
time, and then fail to validate. That kind of end-user experience might
lead people to feel the authentication was unreliable. To avoid this, I
suggest that either the signatures should be long-term, which has its own
set of difficulties, or they should be kept away from end-users, wherever
possible.
Since all sites will not do this protocol, it is obviously impossible to
require people to remove the signatures. Removing them whenever at least
mitigates the problem.
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.
That implies that many sites will have to implement the protocol in two
(or more) places instead of one -- in their border MTA and in all their
MDAs.
If they allow their MDA's to do forwarding, they have built a distributed
architecture so they have signed up to do a number of things in more than
one place. In the architecture you mention, the MDA does not have to
validate any signatures because the Internet-facing MTA already took care of
that. Similarly, the MTA does not have to remove any of the signatures
since it never talks to any end-user machines. Distributed architecture =>
distributed implementation.
It also prevents users from implementing forwarding on their own
systems, e.g. after fetching messages via POP.
Once a user has taken final delivery of a message, I think we would all
agree that particular message instance has reached the end of its path (or
would we?). What the user decides to do with it at that point is their
business, but it has completed its path through the mail stream. If the
user wants to forward it, they have no choice but to submit it via the MSA
(in their choice of formats) and it is a completely new message, with a new
message ID, being injected into the Internet message stream. The user is
free to use re-mailing (encapsulation) forwarding, where they pre-pend a
Resent-* header and use their own return-path. Since they are taking
responsibility for the message, as evidenced by their providing their own
bounce address and Resent-* header, I think it appropriate that the MTA
signs the outgoing message with _their_ key. This is fundamentally
different from alias forwarding where the message never leaves the MTA/MDA
environment and the end-user has no opportunity to alter the message.
Unless the ultimate protocol that we come up with supports multiple
signatures, it seems dubious to me to allow an end-user to re-submit a
message with someone else's signature back into the message stream once they
have touched it. Perhaps this is arbitrary, but I see delivery to the
end-user machine as defining the end of the time we have been calling
"in-transit".
Is it perhaps important to all agree, whether or not it goes in the charter,
as to what we mean when we say "in-transit", "transit time" and "limited
lifetime signatures"? It seems that we don't all agree on what these terms
mean for the purposes of MASS. I'll take a crack at it:
1) Transit time for a message instance:
The time from when a message is accepted by the MSA to the time that a
particular instance of that message either leaves the MDA for delivery to a
destination mailbox or a NDN leaves the MDA for delivery to the bounce
address.
2) Transit time for a message:
The time from when a message is accepted by the MSA to the time that all
instances of the message have completed their transit time.
3) Limited lifetime or transit time signatures:
A signature that is valid for at least the expected transit time of a
message instance or the expected transit time of a message, depending on the
signature usage. It MAY be valid for a longer period of time, but
implementations SHOULD NOT rely on this.
--
Seth Goodman