Without wanting to dispute the other point david makes I do want to disagree
with a point made at the meeting.
A mailing list is not the same as a person resending mail. On a mailing list
we now have an assumption that the user consented to receive the message
from that source.
Its the only time we really have prior consent in the mail system.
-----Original Message-----
From: Dave Crocker [mailto:dhc(_at_)dcrocker(_dot_)net]
Sent: Thu Oct 28 14:54:19 2004
To: Michael Thomas
Cc: IETF MAILSIG WG
Subject: Re: simplicity, focus and adoption; what problem are we
trying to solve?
On Thu, 28 Oct 2004 08:39:24 -0700, Michael Thomas wrote:
Dave Crocker writes:
We are not trying to replicate pgp or s/mime. We are trying to
serve an entirely different purpose. We are trying to say who
is responsible for injecting this message into the message
transfer service.
This is a red herring. Nobody's talking about replacing PGP or
S/MIME. We're talking about domain based assertions.
My point was about the purpose of the assertion, not the scope for
which it is applied.
PGP and S/Mime make assertions about content authorship. Note that
the responsibility I described, above, is quite different.
Much of the problem in the current discussion is with a focus on
validating the "author", rather than for establishing a validated,
accountable agent concerned with the message transfer.
I completely disagree. Mailing lists are nothing more than special
types of forwarders.
Please review draft-crocker-email-arch. It is not formally published,
but it has now had enough open review and revision to make me think it
reflects a fair degree of consensus among the email technical
community. The role of a mailing list is fundamentally different from
an MTA.
I went for a couple of decades thinking that a mailing list could be
seen either as a special MTA or else as a special user agent. The
recent round of architectural discussions -- and especially the impact
of trying to accommodate mailing lists as if they were MTAs -- has
convinced me that they can only be viewed as user agents.
Mailing lists can and do do an arbitrary set of transformations on a
message. That's not an MTA. MTA's simply relay a message. The
changes that a real MTA is allowed to make to a message are highly
constrained to envelope information.
When an MTA does more than that, it is not simply an MTA. At the
least, it is some sort of translating gateway.
To try to say that the
original sending domain has no
responsibility for injecting the message simply because it
traverses a mailing list is ludicrous. To whit: I have a very
strong suspicion that as you read this message that you're not
thinking that imc.org is responsible for the content of this
You are confusing a higher-level human communication role, performed
by one class of mailing lists, for the architectural role performed by
mailing lists in general. In general, the rather narrow range of
current practice for email is tending to cause folks to view the
overall service rather narrowly.
We need to be careful that we do not make changes that *require* only
that narrow usage.
message, but instead... mike(_at_)mtcc(_dot_)com is actually responsible for
this message. Imc.org is merely facilitating its transmission.
The mailing list is doing far more than "facilitating". It is
creating a place for messaging exchange among a defined set of
participants. The policies for the operation of that mailing list are
actually rather rich.
If you want an example of ludicrous, then consider comparing the
architectural role of a group communication service, like a mailing
list, to the limited store-and-forward functions of an MTA.
The ability to preserve end to end semantics is something that is
a huge strength of MASS. If you want hopwise
semantics -- which is what you're advocating even if a hop is not
limited to a transport hop
So, you want this signature to work across some decades of storage and
re-postings by a sequence of recipients?
On Thu, 28 Oct 2004 08:39:04 -0700, Jim Fenton wrote:
What I meant was, that in the absence of mailing list support for
signing messages, there's only one signature available anyway:
the one associated with the original sender.
As sympathetic as I'm sure we all are for the desire to find some
entity to put onto the accountability hook for a message, this does
not justify misplacing our focus.
We need a mechanism that is as simple and direct as possible
This starts with being extremely clear about the problem we are trying
to solve, as I've noted at the beginning of this message.
Otherwise we will have adoption barriers and unintended consequences
making successful deployment and use problematic. And there is
plenty of experience trying to field Internet security services to
make that concern highly warranted.
On Thu, 28 Oct 2004 11:06:27 -0600, Robert Barclay wrote:
... I disagree though
with the statement below about what the problem is, and I think
without resolving that issue first it is probably not possible to
decide how significant a problem forwarders and mailing lists are
we agree on the importance of agreeding on our goal...
Provides an assertion that the domain of the message author
(2822.From) authorized the sending of a specific message.
As appealing as the 2822.From field is, it really does not focus on
the particular problem we are trying to solve, I think. What is the
kind of entity that is going to use the signature, and for what
purpose?
The signature is used at the time of message filtering, as part of
an
assessment about the "safety" of the message. This is strictly a
transit-time (receipt-time) decision, although it can be performed at
several different places of "receipt".
The assertion should remain verifiable regardless of original
transmission source (2822.Sender regardless of who that is if they
are in fact authorized), and (this is the most slippery part) as
long as the author of the message remains the same.
I don't think I fully understand what you are saying, and so will ask
you to restate it.
As you do, please try to anticipate the question: why is each aspect
of the goal present? How does it pertain to the problem we are trying
to solve?
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
www.brandenburg.com