Douglas Otis wrote: > The mailing-list may wish to exclude the list-id email-address > from being allowed within the From header to prevent confusion > as to which header the message was signed "on-behalf-of".
A syntactically valid List-ID doesn't have the form of an email address or Message-Id, no "@". > While some domains may wish to prevent intra-domain spoofing > by employing email-address constraints, such constraints are > not typically, nor is this defined for use with DKIM. RFC 4409 6.1 and 8.1 won't help with "first author" constructs, and 8.1 arguably does not yet support PRA. But it's not an untypical request, compare op=auth for SPF proposed by Scott. > The "all" assertion DOES NOT imply an identity associated > with an email-addresses has been authenticated! It implies whatever the SSP spec. says. If it says something in the direction of op=auth it has to state what signers are supposed to do to enforce it. > Such an assertion violates DKIM's charter, where DKIM is not > sufficiently suited for such use. It mentions the issue as out of scope, yes, but I'm not sure if that also limits what an SSP can state. IMO intra-domain spoofing isn't an interesting problem, but if an MSA offers its sending and signing services to more than one domain then excluding "cross-user forgery" between them is relevant. RFC 4409 has options for SPF (6.1) and a part of PRA (8.1). Or is that beside the point ? Actually a service provider offering sending and signing for more than one domain has to do something about "cross-user forgery" for DKIM, no matter what SSP specifies. > The "all" assertion only indicates to receivers, they can > expect all messages originating from this domain to have > been signed. Kind of tough if they get a message signed by the MSA, but actually submitted by another domain (ab)using this MSA :-( Frank _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
