Re: [dmarc-ietf] A.5 Issues with ADSP in Operation

[Matt V]

On Thu, Mar 14, 2024 at 10:55 AM Alessandro Vesely  wrote:

> On Thu 14/Mar/2024 15:47:14 +0100 Todd Herr wrote:
> > On Tue, Mar 12, 2024 at 5:19 AM Alessandro Vesely 
> wrote:
> >> On 12/03/2024 03:18, Neil Anuskiewicz wrote:
> >> > Please remove the pct tag from the spec.
> >>
> >> It has been removed already, which is incompatible with current records.
> >>
> >
> > I don't believe your assertion of incompatibility to be true, Ale.
> >
> > DMARCbis, like RFC 7489 before it, contains this sentence in the
> > description of DMARC records:
> >
> > Unknown tags MUST be ignored.
> >
> > Any site implementing the DMARCbis spec will see "pct" as an unknown and
> > ignore it.
>
>
> People having pct=n, n ≪ 100, will be in for a harsh surprise.
>
>
>From what I understand several big mailbox providers already ignore it if
it's not pct=0 or pct=100.

~

Matt
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.

[Matt V]

What if we were to look at re-writing this in a way that says something
like this:

In the case of optional DMARC flags (ex: sp, adkim, aspf, pct) that are
malformed, the processing system SHOULD ignore them as invalid inputs, and
MUST utilize the valid flags that are mandatory (ex: v, p) and properly
formatted. Where an RUA tag exists and the mandatory flags are invalid the
processor SHOULD default to p=none as the policy and indicate the change in
the RUA report.

Example:
"V=DMARC1; p=reject; sp=quarter; rua=mailto:t...@sample.com;";

The DMARC processor would evaluate that sp= is a bad value and ignore it
completely, defaulting to just the valid p= record, and treat it
accordingly under the DMARC process.

We could possibly suggest a notation for RUA reports as none
(assumed) or use the existing override reporting options to
indicate that this was the 'assumed/best guess' operation due to bad record
formatting.

Just a thought.

~
Matt

On Wed, Oct 25, 2023 at 7:32 AM Olivier Hureau <
olivier.hur...@univ-grenoble-alpes.fr> wrote:

>
> On 25/10/2023 13:25, Matthäus Wander wrote:
> >
> > As error reports have never gotten any traction, it would be a big
> > effort to make this work. Reusing the existing ecosystem of aggregate
> > reports is a lower hanging fruit. Tools and processes are established
> > and even the aggregate report format supports it already.
> >
> I totally understand..
> >
> > I believe aggregate reports have already addressed this issue
> > (Verifying External Destinations).
> >
> In current RFC 7489 EDV are a "SHOULD", it is upgraded to "MUST" in
> dmarcbis.
>
> However, the Usenix paper I have provided earlier have shown that it is
> not widely respected.
>
>
> --
> --
> Olivier HUREAU
> PhD Student
> Laboratoire Informatique Grenoble - UGA - Drakkar
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Matt V]

I also agree that "SHOULD NOT" would be my vote as the preferred language
going forward.

~
Matt

On Tue, Oct 24, 2023 at 12:41 PM Dotzero  wrote:

> I'd like to first thank Francesca for taking the time to review where the
> working group is as far as consensus.
>
> I fall into the "SHOULD NOT" consensus group with additional non-normative
> language.
>
> The short version of the non-normative language should be in the document
> itself but I believe the issues resulting from deviating from the normative
> "SHOULD NOT" deserve a fuller discussion in a separate document.
>
> Much of the discussion has been focused on the impact to mailing lists but
> the impacts can involve a wider range of issues depending on the nature of
> the domain/organization and users involved. A discussion of those wider
> impacts in the context of a "SHOULD NOT" would be useful in educating
> domain owners, administrators and (even) users. There are differences in
> control and impacts between a corporate/organizational domain, government
> domains, domains which offer free or paid accounts to the public and
> personal domains for example. Advice to one of these groupings may not
> reasonably address the concerns and impacts for domains or constituencies
> in other groupings.
>
> Michael Hammer
>
>
> On Mon, Oct 23, 2023 at 4:04 AM Francesca Palombini  40ericsson@dmarc.ietf.org> wrote:
>
>> I have been asked by Murray to assist with a consensus evaluation on the
>> discussion that has been going on for a while about the dmarcbis document
>> and how to move forward.
>>
>>
>>
>> I have made an attempt to evaluate consensus on the topic, trying to look
>> at it from a complete outsider’s point of view and trying not to let my
>> personal opinion bias my assessment. This is a summary of that evaluation.
>> It is based on several threads in the mailing list: [1], [2], [3] and
>> recordings of the IETF 117 wg meeting [4]. I also tried to pay attention to
>> chronology of comments, because some people have expressed different
>> support for different proposals, in which case I consider the latest
>> email I can find as the person’s latest opinion.
>>
>> Although that was mentioned, I believe there is no consensus to move the
>> document status to Informational. I believe there is a rough consensus that
>> a change needs to be made in the text to include stronger requirements
>> admonishing operators against deploying DMARC in a way that causes
>> disruption. The mails go in many directions, but the most contentious point
>> I could identify is if there ought to be some normative MUST NOT or SHOULD
>> NOT text. Many people have suggested text (thank you!). I believe the ones
>> with more tractions are Scott’s MUST NOT proposal [2] and Barry’s SHOULD
>> NOT proposal [3]. I believe most people who’d prefer just descriptive text
>> have stated that they can live with the SHOULD NOT text, but they have
>> stronger objections towards the MUST NOT text. There also a number of
>> people who strongly believe MUST NOT is the way to go, but these people
>> have not objected strongly to Barry’s latest proposed text in the mailing
>> list (although they have made their preference clear during the meeting
>> [4]). As a consequence, I believe there is a stronger (very rough)
>> consensus for going with Barry’s SHOULD NOT text. I also believe there is
>> consensus to add some non-normative explanatory text (be it in the
>> interoperability or security consideration sections, or both) around it.
>>
>> I suggest the authors and the working group start with Berry’s text and
>> fine-tune the details around it.
>>
>> In particular, as another AD that might have to ballot on this document,
>> I suggest that you pay particular attention to the text around the SHOULD
>> NOT, as also Murray suggested in [5]. I have often blocked documents with
>> the following text: “If SHOULD is used, then it must be accompanied by at
>> least one of: (1) A general description of the character of the exceptions
>> and/or in what areas exceptions are likely to arise.  Examples are fine
>> but, except in plausible and rare cases, not enumerated lists. (2) A
>> statement about what should be done, or what the considerations are, if the
>> "SHOULD" requirement is not met. (3) A statement about why it is not a
>> MUST.”.
>>
>> I appreciate everybody’s patience and constructive discussion.
>>
>> Francesca, ART AD
>>
>> [1]:
>> https://mailarchive.ietf.org/arch/msg/dmarc/Z2hoBQLfacWdxALzx4urhKv-Z-Y/
>>
>> [2]:
>> https://mailarchive.ietf.org/arch/msg/dmarc/wvuuggXnpT-8sMU49q3Xn9_BjHs/
>>
>> [3]:
>> https://mailarchive.ietf.org/arch/msg/dmarc/k6zxrKDepif26uWr0DeNdCK1xx4/
>>
>> [4]: https://www.youtube.com/watch?v=8O28ShKGRAU
>>
>> [5]:
>> https://mailarchive.ietf.org/arch/msg/dmarc/Ld-VObjtihm5uWd9liVzMouQ1sY/
>> ___
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
> __

Re: [dmarc-ietf] attack on reports

[Matt V]

On Tue, Jan 26, 2021 at 3:17 PM Michael Thomas  wrote:

> How do I know when I'm done though if I don't know the IP addresses who
> send on my behalf? Is it an actual forgery or is it Marsha in marketing
> using a outsourced email blaster?
>

This is solved with conversation with the relevant stakeholders in the
organization from IT, Marketing, PR, etc... along with security and brand
policies being enforced.

Ultimately only approved and official email sources will be authenticated -
random sales/marketing people don't get to make those types of decisions on
the day-to-day. You want an exemption for your support/marketing tools you
need to get it cleared, vetted and properly authenticated to play.

This is how most large companies resolve this issue.

~
*MATTHEW VERNHOUT*
Founder, Editor
EmailKarma.net 
It's not the size of your list, it's how you use it!

t: @emailkarma 
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc