Doug,
>>>
A few of us hope to be publishing a draft aimed at safely extending third-party
authorizations in a highly scalable fashion that answers these questions.
Replace the l= with tpa=(yes, no); The tpa entry can then apply additional
restrictions in the hashed-accessed resource record used to authorize a
third-party domain. This might involve list-id header alignment, etc. Since
this scheme can be generalized, it seems the "{hash-label}._tpa" resource
should include related protocols as well
<<<
How would this work in real life? Would Yahoo need to publish in DNS a list of
all the mailing lists their users subscribe to?
-- Terry
-----Original Message-----
From: Douglas Otis [mailto:doug.mtv...@gmail.com]
Sent: Tuesday, May 6, 2014 6:00 PM
To: Terry Zink
Cc: J. Gomez; dmarc-discuss@dmarc.org
Subject: Re: [dmarc-discuss] DMARC woes - forwarding signed / encrypted e-mail
On May 6, 2014, at 5:30 PM, Terry Zink <tz...@exchange.microsoft.com> wrote:
>> What do you think about this proposal to extend DMARC to
>> account for the failure case of DMARC with mailing lists:
>> http://www.ietf.org/mail-archive/web/dmarc/current/
>> msg00167.html
>
> I remember this thread from a year ago and that it didn't get a lot of
> support. I suppose an example record is the following:
>
> _dmarc.example.com "v=DMARC1; p=reject; pct=100; rua=...; ruf=...; l=yes"
>
> The idea is for mailing lists to avoid getting filtered by DMARC (since it
> does spoof the From but legitimately) but it needs to be thought out
> end-to-end. I have a couple of questions:
>
> 1. The tag value for l=no isn't required. This means "I don't participate in
> mailing lists and therefore you should enforce my p=reject action." But this
> is the same as l=dunno (empty) which is the same as today's behavior. So, you
> would only need l=yes.
>
> 2. How would a receiver know that the email comes from a mailing list? Would
> it just look for something like a List-Unsubscribe or List-Subscribe header?
> Or something similar?
>
> 3. Would the expected behavior be that if the email comes from a mailing list
> yet fails DMARC, do not enforce DMARC's p=reject action nor the p=quarantine
> action?
>
> 4. What about a large domain prone to spoofing? Yahoo publishes a p=reject,
> and plenty of its users use mailing lists. What is stopping a spammer from
> putting the same mailing list tags into the message and spoofing From: Yahoo?
> That seems like a very easy workaround for the spammer. A counter argument is
> to not blindly trust what appears to be a mailing list but also apply some
> other heuristic to it (e.g., domain or IP reputation). But if you're going to
> apply IP or domain reputation to suppress the DMARC action, then you don't
> need to pay attention to the l=yes tag at all.
>
> That is, if condition X can let you know whether or not to do p=reject, then
> there's no reason to do condition X and condition Y, making condition Y
> redundant. Right?
Dear Terry,
A few of us hope to be publishing a draft aimed at safely extending third-party
authorizations in a highly scalable fashion that answers these questions.
Replace the l= with tpa=(yes, no); The tpa entry can then apply additional
restrictions in the hashed-accessed resource record used to authorize a
third-party domain. This might involve list-id header alignment, etc. Since
this scheme can be generalized, it seems the "{hash-label}._tpa" resource
should include related protocols as well. In this way, if there is any abuse,
the Author-Domain from DMARC's perspective will not enable just any message
with a list-id header or those purporting to be from a mailing-list. This also
removes replay concerns, since the Author-Domain is able to delist any
third-party domain failing to respond to reports of abuse.
There would be an additional benefit beyond restoring use of third-party
services. When requested policies are used in conjunction with user accounts,
the fact that their account has been disabled to prevent delisting would act as
a type of notification that the user's account or system has become
compromised. Just as your organization does, we also offer free cleanup tools
to assist when their system is affected. Otherwise users should be able to
simply change their account passwords and security information. Perhaps we
could even standardize the forwarding of cleanup results to help facilitate
service restorations.
Regards,
Douglas Otis
_______________________________________________
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)
