Graham Murray wrote:
"Thomas A. Fine" <fine(_at_)head(_dot_)cfa(_dot_)harvard(_dot_)edu> writes:
So if the only way a domain can set a policy that permits* recipients
to drop unsigned or broken mail is to set a policy that it will
not use non-compliant mailing lists, then this is doomed to failure,
Maybe one solution to the mailing list problem would be to approach
from a different angle. Would it be possible, for verification etc
purposes, to consider mailing list traffic to have come from the
mailing list not the person who submitted to the list?
Ohhh boy.
In Tom's perfect world, there would be two separate mechanisms being
standardized. One would be an email-session layer mechanism that would
be based on vouching for the validity of the envelope-header and
verifying it at the destination. Headers would be strippable in cases
of forwarding, with the forwarder taking responsibility. It's primary
use would be for MTAs, although it could be extended a bit to provide
some utility to MUAs. Such a system is exactly what you are describing
above, and it would have no problems whatsoever with mailing lists or
other forwarders. It would be a policy-first system. This would be an
easy-to-implement upgrade to the parental filtering employed by most
sites right now, and in the long run would VASTLY reduce the cost
incurred by dealing with spam.
The second mechanism would be a presentation-layer mechanism that
would be based on vouching for the From: header, that would essentially
verify the identify of the originator to the recipient. This is
inherently a much more complicated problem to solve. There is the
problem of mailing lists and other formatters that want to make small
or wholesale changes to content along the way. There is the problem
of sites that want to generate mail on behalf of someone, and how
do they get the priveleges to do that. The point here though is
to offer something to the MUA that the user can use to guide their
security choices. If such a system wants to be robust with
respect to gateways that may alter content, then it has to fully
encapsulate the original message and separate it from the alterations,
and that by it's very nature must all happen in the body of the message.
So we would end up with something like PGP.
DKIM is trying to do both, while at the same time trying to do
neither. It wants to be useful to both the MTA and the MUA. It
doesn't want to authenticate either the envelope-from or the From:
lines. It wants things to work with mailing lists (or more generally
through content transormations), but it wants to keep the signature in
the header, and (up to this point) it isn't interested in real message
encapsulation. If anything, at this point the MTA-utility of DKIM
seems to be diminished, while at the same time, it is clinging to
header-only standards which it impossible for an MUA to present
anything useful to the user about altered messages.
tom
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html