On Sun, 2006-07-30 at 16:13 -0700, Michael Thomas wrote: > Dave Crocker wrote: > > > What proposed SSP flags, configuration and usage will enable a > > receiver to know that a particular (rfc2822.From?) domain's messages > > must be signed by a particular ISP? > > I don't think it's hard to envision such a protocol element, where > I get stuck is how you do so in a way that doesn't blow out all kinds > of other requirements. It's tempting to put this sort of requirement > in, but if the end result is that it can't be done without violating > other more fundamental requirements then it should be eliminated. I've > been tentatively calling these sort of things "provisional" > requirements in that they need to > > a) demonstrate a constituency > b) demonstrate that they can be done without violating other > requirements.
It is difficult to discuss requirements without also considering requisite underlying mechanisms. If a mechanism becomes too cumbersome, then that requirement should be reconsidered. Several have lent support to the general concept of a list of designated signing domains. The mechanism might be as simple as a list and a flag that indicates whether non-designated domains are used. A means to designate a domain overcomes the dynamic issues related to sharing private keys/selectors/domains/settings, delegating domain zones, or directly handling DKIM. There are techniques that ensure a mechanism for publishing a domain list never involves more than one query and that always provides a small answer suitable for DNS/UDP. A desire and a means seems to satisfy both a & b requirements. The list and flag offer a means to indicate: - no domain is designated for the OA. (no mail) - specific domains are designated for the OA. - non-designated domains are used. A designated signing domain should always employ DKIM. A non-designated domain might not employ DKIM. When DKIM signs OAs of a different domain, the OA may still desire a means to limit their exposure to spoofing and to improve the delivery of their messages. The list approach allows this without also incurring the need to deal with multiple signatures, weaknesses with MUA signing, or making special arrangements with a DKIM provider. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
