Re: [ietf-dkim] Mailing lists as 2822-Sender
On Dec 3, 2007, at 8:58 AM, Dave Crocker wrote:
A mailing list is an original mail object that is comprised of
vetted submitted material much like a newspaper. It should take
submitted material, empty the accompanied envelope and remail using
a fresh clean envelope with new headers.
In the abstract, the model you describe is probably the best to
use. I think it is obviously true for a "digest" mode of mailing
out a collection of postings.
For the case that we are all most used to, it is probably still
true, but less obviously, since recipients perceive the message as
"from" the original author.
That difference between actual responsibility, versus reader-
perceived responsibility, is the issue.
When SSP makes a STRICT assertion, then From email-addresses not
signed by the same or parent domain are suspicious (and likely
rejected). The STRICT assertion is incompatible with the use of
mailing-lists. It is more likely that for a mailing-list the Sender,
and not the From, last modified (flattened) message content. With a
mailing list, it is also unlikely that the identity represented by the
From email-address had been authenticated.
Even when SSP makes a STRICT assertion, there is no assurance the
identity represented by the From email-address will have been
authenticated. Making a STRICT SSP assertions may necessitate the
DKIM signature to lie or remain ambiguous as to who's behalf the
message had been signed. Remaining ambiguous may be necessary simply
because there is _no_ means to achieve STRICT policy compliance for
other headers. The STRICT SSP assertion intentionally breaks many
normal use scenarios, and in doing so, places restrictions on the use
of the i= semantics.
Should DKIM reinforcing a perception that From field email-addresses
_always_ represents the responsible identity for message content?
DKIM is limited to the domain, and of course the domain _never_
creates message content. A STRICT SSP policy is domain-wide and
_breaks_ email. Tactics to overcome this breakage, along with the
dubious recognition of email-addresses creates more opportunities to
mislead recipients. Repair tactics using visible sub-domains email-
addresses having different policies will increase recipient
confusion. As internationalization becomes prevalent, identities
represented by email-addresses will become even more ambiguous.
Having said that, TPA-SSP can minimize breakage while also eliminate
some of the i= semantic restrictions. TPA-SSP also improves the
ability to obtain a higher granularity than just the domain, as well
as establish FULL "strict" compliance based upon Sender in addition to
just From headers. This is done by allowing policy compliance to
include more than just the From header, and by allowing transparent
use of signing sub-domains (which is considered a third-party
domain). Messages signed with authorized sub-domains can express
different policies and scope without recipients ever seeing this
complexity. TPA-SSP follows KISS from the recipient's perspective.
The complexity of TPA-SSP is well hidden and does not increase
overhead beyond that needed to implement a CNAME. : )
NOTE WELL: This list operates according to