On Oct 13, 2005, at 11:27 AM, Jim Fenton wrote:
Frank Ellermann wrote:
Jim Fenton wrote:
By "envelope-based" I presume you mean SPF, Sender ID Framework,
and/or CSV.
JFTR, Sender ID minus PRA is SPF, and PRA isn't envelope based.
True; I mentioned it because I think SIDF could also be used to
address replay issues.
Path registration and DKIM? All the limitations of SPF/Sender-ID are
retained when making this claim. These records do not normally track
the signing-domain. SPF records are premised upon the PRA or the
MAILFROM where this claim will place such restriction on DKIM. Even
the OA of the SSP is not compatible. Neither the PRA, MAILFROM, or
the OA confront any threat satisfactorily. Will some large provider
declare PRA MUST be used with DKIM? Is this the reason the replay
attack has not been addressed? This restricts use of a mailbox-
address to that of a specific provider, otherwise the mailbox-domain
owner _MUST_ risk a perilous authorization that of course form the
basis of the SPF records. This will also form the basis for an
unfair reputation assessment already made upon the mailbox-domain
rather than the signing-domain. Ghastly.
Two modes of domain assertions would be useful against most threats.
One where conventional assessments of the originator is made to
ensure email is not disrupted, and another that disallows all other
domains in all such possible origination headers for exigent cases.
This approach should provide better results while offering the
greater freedoms. By dealing with the replay issue in a differ
manner, proper accountability is retained without shifting burdens
onto hapless mailbox-domain owners.
DKIM reliance upon Sender-ID could be used as justification for
coercing mailbox-domain owners into authorizing service providers
that are not be accounted in such a scheme. Nor would there be any
visibility of potential problems for the typical mailbox-domain
owner, as many of the MTA are within shared environments. Attempts
at using the mailbox-domain for authorization is generally a bad
idea, as this fails to consider rather commonly shared environments.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org