On 6/25/12 10:54 AM, Murray Kucherawy wrote: > On 6/25/12 10:24 AM, "Dave Crocker" <[email protected]> wrote: > >> As such, any proposal should provide a basis for believing that >> the change will be highly useful AND a basis for making that >> assertion. > > I would add that such proposals need to include some threat > analysis of how the extension could be abused. The "hole" thus > created can't offset the utility of the proposal, or the idea is > not worth pursuing. > >> >> This sort of requirement is what distinguishes an engineering >> standards discussion from a more abstract intellectual/academic >> pursuit. The latter are entirely valid, but it's important not >> to confuse the two. > > +1
Dear Murray and Dave, How will DMARC overcome false positive rejections that caused prior "suggested email policy" schemes to be ignored? How will receivers in a geographic region that exchange messages in a different language than those used by a DMARC domain know which problematic source should be white-listed? Having DMARC policy ignored by various third-party providers represents a much deeper hole this protocol is likely to confront, based upon prior experience. DMARC continues to assume third-party providers will act on their behalf by compiling required exceptions and dealing with recipient complaints of "incorrectly" rejected messages. Should an Estonian mailing-list be white-listed by a receiver in China processing a DMARC service offered in English? Or must DMARC domains be prohibited from making exchanges with mailing-lists? Why not allow From domains to make these decisions? Some have suggested mailing-lists not alter messages even though such alteration keeps their source from being deceptive. A notification from a bank with a subject beginning with [dmarc-discuss] is less likely considered directly emitted by the bank when its signature is invalid and displays an odd subject line. A mailing-list that confirms subscriptions is also likely to have their messages placed in specific folders. SPF also suffers a high failure rate. A TLS scheme is less content sensitive and, when used in conjunction with third-party name based authorizations, can deal with known and current changes to email not anticipated by SPF. Why not avoid known problems before they become painfully apparent? Problems about to be caused by current and real changes to email infrastructure are not academic. Admittedly, such problems will be less apparent for English speaking users who have a high IPv4 address-to-user ratio and who are unlikely to benefit from UTF-8 local-parts properly conveying non-ASCII author's names. Even so, this should not offer solace. The transition for any such protocol change should not ignore other concurrent changes. The protocol should pragmatically consider its role while IPv6 and UTF-8 gains deployment. Regards, Douglas Otis _______________________________________________ dmarc-discuss mailing list [email protected] http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
