On 5/7/2014 1:01 AM, ned+ietf@xxxxxxxxxxxxxxxxx wrote:
I can't speak to what was in the minds of the developers, but I view the fact
that the specification is noticeably lacking in describing these limitations
as problematic.
I haven't had time to do a careful review of the DMARC specification, but I do
note one obvious omission: Wouldn't it have been helpful to define an enhanced
status code for a p=reject failure which mailing lists could detect and take
appropriate action, i.e. counting this as a failure of the sender, not the
recipient?
That was part of the discussions. But for backward compatibility, a
ACCEPT and DISCARD could be a deployment optional alternative to a
reject action.
But YAHOO and others could of had a more graceful migration to
p=reject. It could of quarantined and/or just prepared a special
notification to the recipient:
Dear Yahoo user,
It appears you are subscribed to a mailing list {LIST-ID} which is
signing the message with the domain {LIST-ID.DOMAIN}.
YAHOO can decide on path #1
You will need to switch to a different to a different account.
Within one month, this mail from the list to you will be rejected.
YAHOO can decide on path #2
Please click the following link if you wish to WHITELIST this list:
{URL}?list-id={LIST-ID}?hash={SOME-UNIQUE-USER-ACTION-HASH}
But you know, it is probably just easier to reject and not worry about
it. Just like our system when we reject for SPF. Its not prepared to
do something like the above. Honestly, the DMARC whining has died down
on our end just like it happen for SPF back in the early days of
rejection. DKIM+POLICY using DMARC is doing what it suppose to do
when followed.
--
HLS