On Tue, 2004-11-30 at 10:52, Jim Fenton wrote:
Douglas Otis wrote:
Much of the spam today looks very much like the few lines added at
the end of the typical web mail service or the list server. Who
would be accountable for spam added at the end, when it must be
ignored by signature validation? What was once innocent and
heuristically ignored soon becomes the norm for spammers. Keeping
this behavior to a minimum does ensure greater protection from abuse.
There is no requirement that the recipient display the unsigned content
at the end of a message. A verifying MTA may remove the unsigned
content at its discretion. A suitably equipped MUA could do something
fancier, like Thunderbird does for embedded URLs (click here if you want
to see the embedded content). In other words, the decision to sign only
a portion of the message is made by the sender, but the recipient can
decide whether to accept that or not.
I would not be happy to see this information removed. I find it useful
at times. I would not expect to have an MUA able to highlight what
should be trusted any time soon. This is not a simple issue however.
Requiring those that make changes to resign the message does ensure
this process identifies those accountable. A header could be included
to allow signature validation to be cascaded.
I agree that it's desirable for those that make changes to re-sign the
message. But I think it's undesirable to say that signatures will just
fail for a large proportion of mailing lists unless that happens.
I hope that this valid problem can be bridged, as this seems to be a
major sticking point. Holding to the channel model as the nominal case,
and providing a "repair" header to accommodate a transition period of
half a decade or so could offer a solution that both satisfies a need
for simplicity, and the practical need for tools to safely get this off
the ground.
Then there's the other question you touch on, of whether a signature is
added or the original signature is replaced. I'm in the "added" camp
even though that means we have to define how messages are treated when
different signatures succeed and fail.
I do like the method used in IIM with respect to where the burden is
placed. This can be seen as a separate issue however.
Is an unprotected DNS server a reasonable approach for public key
distribution? Does DNSSEC offer a solution? IIM provides the public
key within the message and, for those that wish better protection,
perhaps could employ the use of HTTPS for the authorization step. The
IIM draft calls for HTTP. The question of establishing a public key
distribution system via DNS has the prospect of fostering other uses.
This raises the question, do we want to do this?
-Doug