On August 18, 2005 at 09:57, Douglas Otis wrote: > 1- Employs DKIM > 2- Employs DKIM universally > 3- Allows TP signing > 4- Allows sub-domain TP signing > 5- Disallows all TP signing > 6- Never sends email > > It would seem counter productive to for assertion 5 to be the default > taken as this would greatly discourage larger ISP from universally > signing all outbound mail.
Why sign messages when there will be no value in doing so? The OA is important here, and automatically signing messages without explicit permission from the OA is not playing nice. Except, if DKIM signatures were not limited to OA SSP binding, then an ISP could blindly sign messages, making the assertion, "this what I got before I sent it out." Now large ISPs (like Y!) control the domain of their users (the bulk of their users are under yahoo.com), so defining the proper SSP records (for 1st-party signing) is not more difficult than defining the signer public key entries. For ISPs servicing multiple domains, they should only sign if the domain owner allows it, creating a 1st-party signing relationship versus a TP one. Note, domain owner does not necessarily equal domain administrator. (Note, any first-party relationship will probably need to have a legal basis.) IMO, from the OA perspective, enabling TP signing is bad policy from a security perspective. OA will not care if other entities sign a message (for traceability purposes) as long as they are not claiming a 1st-party association. Side Note, I think it would be useful if the OA SSP allowed for an OA to designate a list of allowable signers. > For those where this would matter, then > making the assertion should be required. You are assuming that a domain owner is aware of DKIM. When DKIM is deployed, you cannot require all domain owners to set up SSP records immediately. > > Exactly. Are you suggesting that the default should be: > > (1) Treat any signature from the OA (example.org) with suspicion, or > > (2) Treat any signature on a message from the OA with suspicion ? > > > > If it's (2), it means that domains that haven't deployed DKIM that > > send through mailing lists to domains that are checking SSP would > > have those messages marked as suspicious. > > Here the trade-off is rather clear. The restrictions on TP > signatures is related to combating phishing exploits which affect > only a minority of domains. The majority of domains should be > willing to allow their messages to be "spoofed" (third-party > signatures) out of sheer convenience. There is no "willing" for domains that do not know of DKIM or have yet to adopt it. DKIM must not facilitate spoofing. > Another view would be for the mailing-list to leave all signed > messages intact. There would then be no added overhead groping for > SSPs. The mailing-list may adopt a convention where new headers > replace the technique of message modification. The List-* headers are well-defined, but many MUAs probably do not display them (by default). --ewh _______________________________________________ ietf-dkim mailing list http://dkim.org
