On Tue, 2006-09-05 at 03:26 +0200, Frank Ellermann wrote: > Douglas Otis wrote: > > > DNS encodes about 40 code points > > More like 230 octets if you treat US ASCII case insensitive.
This was in reference to scalar values of a character. DNS case insensitivity limits resolving an encoded local-part, especially when the local-part is not ASCII, or perhaps includes subaddress symbols. > IMO this SSP draft has more serious problems. RFC 2822 etc. > clearly allow PRA != From, a "policy" or "practises" trying > to "forbid" RFC 2822 just makes no sense. The current policy strategy is limited to a small segment of domains. This segment is willing to endure delivery failures to ensure their 2822.From address is always signed by the same domain. Some moderation of delivery failures might be achieved by indicating adherence has not been strict. > Let's build on RFC 4407 or drop SSP. What is the precise > Message-ID where one of the Chairs stated that it's the > consensus of this WG to rename "policy" to "practises" ? If I recall correctly, this took place before the chartering of the WG. Due to potential replay issues, do not expect policy based criteria to offer effective deterrents, except within an even smaller segment of domains. Working with large financial organizations, even the 2822.From address being within the signing domain is not enough, there is also a desire to further limit the resulting annotations. With ether the perspective of an annotation or a policy based acceptance standpoint, DKIM does not fully meet the needs of even a small segment of domains. Limiting annotations is not well accommodated by i= semantics. In addition, the i= parameter can not associate addresses above or outside the signing domain. Without policy associating signing domains with that of the SMTP client or the 2821.MAIL_FROM, handling replay issues may prove problematic. Ensuring DSNs, J.D. alluded to an expectation that the 2821.MAIL_FROM would be the same as that of the signing domain. This relationship is not expressed within any DKIM related policy however. By being able to associate the signing domain with that of other domains, the DKIM signature offers greater value. This association is fully independent of the DKIM signature verification. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
