[dmarc-discuss] On making suggestions for changes

Douglas Otis dotis at mail-abuse.org
Mon Jun 25 14:14:02 PDT 2012

On 6/25/12 10:54 AM, Murray Kucherawy wrote:
> On 6/25/12 10:24 AM, "Dave Crocker" <dhc at dcrocker.net> 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

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

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.

Douglas Otis

More information about the dmarc-discuss mailing list