Re: (DMARC) Why mailing lists are only sort of special

[Dave Cridland <[e-mail]>]

On 16 April 2014 21:01, Dave Cridland <[e-mail]> wrote:

> Unfortunately, the only option I thought was possibly available isn't
> permissible by the specification - therefore, the only solution involves
> alterations to the deployed base, which has been ruled impossible for over
> a year now.
>
>
Oh, I tell a lie, it's just not where I expected, and not quite as nice as
I'd hoped.

So I think what needs to happen is that a new policy of "sender-reject" or
something is allowed, which is essentially deferring to the sender, so
receivers would check:

1) The sender exists and is valid.

2) The mail has a valid DKIM signature from the sender and otherwise
complies with the published DMARC policy.

3) Any such policy is treated as p=reject

That is, if I have a mailing list at "[e-mail]", and a
p=forward-or-reject then my recipients would check for a _dmarc.ietf.org as
well, but ignore any p=, and treat as p=reject.

This means that mailing lists (and other forwarding cases) are enforced
into having DMARC records in order to forward DMARC originating messages,
which seems reasonable, and the Sender addresses must also be relatively
sensible, which they normally are already.

In fact, this case handles even people using gmail.com with their Yahoo
address sending messages to mailing lists, I think.

Note that the problem is that existing DMARC deployments which don't know
about sender-reject will either treat is as p=none - if there's a rua
listed - or "take no action", and I've not looked into this enough to
decide what that means.

So for Yahoo, should they implement this change, would effectively take a
backwards step to p=none until the DMARC deployments caught up, which would
be a little confusing to mailing list operators, but at least safe.

The alternative would be to add a new tag indicating this kind of deferral
to the sender; unknown tags are ignored, so this would behave like a reject
until software was updated. The problem with that is that it'd be very
unpredictable whether messages would pass or not; for mailing lists, which
typically drop subscribers after a certain number of failed deliveries, I
think it'd remain a huge problem.

In either case, there would be a knock-on to UAs, which would need to show
in the UI that the message had been forwarded - gmail does this with it's
"via", for example, so I don't think this is onerous.

I may be missing something.

Dave.