Re: [dmarc-ietf] Jumping the Gun

[Mark Alley]

On Wed, Oct 25, 2023, 8:25 PM Jesse Thompson  wrote:

> On Wed, Oct 25, 2023, at 4:06 PM, Todd Herr wrote:
>
> Someone posting at Security Boulevard has decreed that DMARCbis (at least
> the t= tag parts of it) are now codified:
>
> https://securityboulevard.com/2023/10/dmarc-t-tag-replaces-pct-in-dmarcbis/
>
> This person did a fantastic job of cutting and pasting from DMARCbis to
> "create" their "content".
>
>
> It's a good summary IMO
>

The article was created using plagiarized non-IETF/RFC credited text from
the DMARCbis appendix A.7, which is a point I think Todd was trying to make.


> Is it advisable to use "t=y pct=0" for backwards compatibility?
>

I'm curious about this as well.

I imagine implementation experience with this will vary widely because
there's unfortunately no shortage of receivers rolling non-standard DMARC
evaluation logic with liberal interpretations of expected syntax and tags,
even though the ABNF and section 5.3 are explicit with instruction on how
to proceed in those cases.


- Mark Alley
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Jumping the Gun

[Jesse Thompson]

On Wed, Oct 25, 2023, at 4:06 PM, Todd Herr wrote:
> Someone posting at Security Boulevard has decreed that DMARCbis (at least the 
> t= tag parts of it) are now codified:
> 
> https://securityboulevard.com/2023/10/dmarc-t-tag-replaces-pct-in-dmarcbis/
> 
> This person did a fantastic job of cutting and pasting from DMARCbis to 
> "create" their "content".

It's a good summary IMO

Is it advisable to use "t=y pct=0" for backwards compatibility?

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

[dmarc-ietf] Jumping the Gun

[Todd Herr]

Someone posting at Security Boulevard has decreed that DMARCbis (at least
the t= tag parts of it) are now codified:

https://securityboulevard.com/2023/10/dmarc-t-tag-replaces-pct-in-dmarcbis/

This person did a fantastic job of cutting and pasting from DMARCbis to
"create" their "content".

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Murray S. Kucherawy]

On Wed, Oct 25, 2023 at 9:33 AM Richard Clayton 
wrote:

> >The operator is making the decision to publish or enforce, not the
> >user.
>
> Looking at $DAYJOB$ logs for this week I see a shade under 300 people
> who are participating in IETF working groups using p=reject addresses.
>
> I believe they have made an informed decision as to what email address
> they will use and have not "blundered" at all (in fact a couple look as
> if they have set up the email address specially in order to participate.
>
> (that was easy to count and it seemed relevant to do so, counting other
> mailing lists is complex)
>
> There are 5 or so in this group...
>
> Surely you are not going to ask them to leave.
>

IETF users are not the source of my concern.  It's the less savvy ones, who
tend to just want what they want and not have to concern themselves with
what they consider to be the operational minutiae of email, that I'm
highlighting here.

Even if you clearly present such information, I have doubts about how many
will read it, much less understand it.

When's the last time any of us actually read a EULA?

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Richard Clayton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message , Murray S. Kucherawy 
writes

>Do you really want to be pushing that information and decision 
>burden onto users?  How many of them will understand versus 
>ignoring it and just blundering ahead?

I think that depends how clearly the information is presented

>The operator is making the decision to publish or enforce, not the 
>user.

Looking at $DAYJOB$ logs for this week I see a shade under 300 people
who are participating in IETF working groups using p=reject addresses.

I believe they have made an informed decision as to what email address
they will use and have not "blundered" at all (in fact a couple look as
if they have set up the email address specially in order to participate.

(that was easy to count and it seemed relevant to do so, counting other
mailing lists is complex)

There are 5 or so in this group...

Surely you are not going to ask them to leave.

- -- 
richard  Richard Clayton

Those who would give up essential Liberty, to purchase aBenjamin
little temporary Safety, deserve neither Liberty nor Safety.Franklin

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZTlDEd2nQQHFxEViEQLOowCg0paP4kt9wbajuJ4tKO+uY/G6BoYAoJry
+RxYXsHtHSMV+KgNQP87805W
=zUUT
-END PGP SIGNATURE-

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

Re: [dmarc-ietf] Dmarcbis way forward

[Murray S. Kucherawy]

On Wed, Oct 25, 2023 at 8:17 AM Richard Clayton 
wrote:

> So might I suggest a wording that captures what will actually happen in
> the real world
>
>   Domains that choose to publish p=reject SHOULD inform the people
>   using those domains of the issues that may arise if theu post to
>   Internet mailing lists.
>
> I'd even live with a MUST for that second sentence :-)
>

-1.

Do you really want to be pushing that information and decision burden onto
users?  How many of them will understand versus ignoring it and just
blundering ahead?

The operator is making the decision to publish or enforce, not the user.

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Richard Clayton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message , Brotman, Alex  writes

>+1 SHOULD NOT

If there is not going to be a consensus for just a discussion of the
issue (which I would prefer) then my view, obviously is that SHOULD NOT
is to be preferred to MUST NOT

The relevant bit of Barry's text is I believe:

  It is therefore critical that domains that host users who might
  post messages to mailing lists SHOULD NOT publish p=reject.
  Domains that choose to publish p=reject SHOULD implement
  policies that their users not post to Internet mailing lists.

but I am concerned about the second sentence.

It would be perfectly possible at $DAYJOB$ (where I help look after a
number of domains with p=reject and a large number of users) to meet
that SHOULD by blocking those users from sending to mailing lists.  This
would (a) be somewhat unpopular and (b) for many mailing lists which
have implemented workarounds of various kinds completely unnecessary.

So might I suggest a wording that captures what will actually happen in
the real world

  Domains that choose to publish p=reject SHOULD inform the people
  using those domains of the issues that may arise if theu post to
  Internet mailing lists.

I'd even live with a MUST for that second sentence :-)

- -- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZTkxF92nQQHFxEViEQK63QCgyXe3+giXO9UlDA9jAC2T4E6kGeQAn3NC
WoNnAF7y6HrECK9Y1kcdE1nd
=iSip
-END PGP SIGNATURE-

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

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

[Murray S. Kucherawy]

On Tue, Oct 24, 2023 at 11:11 PM Steven M Jones  wrote:

> On 10/20/23 12:35 PM, Murray S. Kucherawy wrote:
>
> (1) As written, the text says (to me) that the handling of a message might
> change depending on this mapping of a broken value to "none", but only if
> "rua" is present; absent "rua", the record is treated as junk and DMARC
> doesn't apply.
>
> It's not so much changing the handling as changing the reporting.
>

Yes, I think that was probably the intent of the logic branch here, but
that's not how it reads.


>
> So then, maybe we wind up with something like this:
>
> PROPOSED versus draft 28 section 4.7:
>
> 
>If a retrieved policy record does not contain a valid "p" tag, or
>contains an "sp" or "np" tag that is not valid, then:
>
>*  The Mail Receiver MUST act as if a record containing "p=none" was
>   retrieved and continue processing;
>
>*  The Mail Receiver MAY note the invalid "p", "sp", or "np" tag
>   in the optional "error" field of the informative section of the
>   DMARC aggregate report [I-D.ietf-dmarc-aggregate-reporting];
>
>*  If there is no "rua" tag, or if it does not contain at least one
>   syntactically valid reporting URI, the Mail Receiver effectively
>   applies no DMARC processing to this message.
> 
>
> And if somebody wants to argue against including the third point, I would
> offer that it may be better to be explicit that to repeat this exercise in
> a future WG.
>

I think the first bullet should include the word "only", otherwise it looks
like you're replacing a faulty "p" tag but not the others.

I think the MAY in the second bullet should be a lowercase "should".

I think the third bullet after the comma should read more like "the Mail
Receiver does not include this message in reporting in any way", because
the current language ties it back to handling which, as you said, is
already decided.

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On Wednesday, October 25, 2023 11:01:27 AM EDT Richard Clayton wrote:
> In message , Scott
> Kitterman  writes
> 
> >>> My reading of the discussion is:
> >>> 
> >>> 1. We did not have rough consensus to eliminate the use of SPF in DMARC.
> 
> sadly so, it would have been the right thing to do
> 
> >>> 2. We did not have rough consensus to complicate DMARC by having the
> >
> >publishing domain specify authentication methods.
> 
> hmm...  it does seem to be the best way of addressing #1
> 
> >The purported use case is "my SPF is so awful you can't trust it and at the
> >same time, so critical I still have to publish the record".  I don't think
> >that's a real thing.
> 
> there appear to be receivers who use SPF as a filtering mechanism to
> reject patently obvious forgeries -- and if SPF passes they then apply
> other mechanisms because they don't want to bother with DKIM  (I've seen
> posts to this effect -- their customers, their funeral)
> 
> not having an SPF record at all would mean that these receivers would
> not be able to do that filtering (and the lack of SPF might adversely
> affect various heuristics for determining how email should be treated)
> 
> viz: there is an edge case for senders to continue to publish SPF even
> when it almost useless (it stops people forging mail from a different
> cloud, but not from the one that they use)
> 
> if that is so, then senders need to be able to tell all the receivers
> who do believe in the value of DKIM (and there are a lot of those) "take
> no notice of my SPF record" ... so DMARCbis should support that
> 
> Note that if BIMI is involved the SPF will be ignored anyway (and the
> documentation might even say that RSN)
> 
> >If your SPF is unreliable, fix it or delete it.  Not a DMARC problem.
> 
> senders using clouds to spin up and spin down resources depending on
> demand will struggle to "fix it"  ...  that's why it was so widely drawn
> in the first place. Senders using shared IPs at ESPs are also not in a
> position to "fix it" -- they can only hope that the ESP correctly
> polices what is being sent by each particular customer.

Modifying their SPF record to include '?' for the suspect mechanisms is the 
exact technical solution to this problem.  It has no impact on rejecting 
messages that fail SPF and keeps such mail from passing DMARC.

The solution to bad SPF deployments is fixing them.

Scott K



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

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On Wednesday, October 25, 2023 10:46:09 AM EDT Emanuel Schorsch wrote:
> > >There's the counterargument "so don't publish SPF" but it's on so many
> > 
> > checklists
> > 
> > >that even though that would be a fine idea, it's not practical.
> > 
> > Diving into the SPF angle, if someone has a 'legitimate' mail source that
> > also sends spoofed mail for them, they can prefix the relevant mechanism
> > with '?' so it produces a neutral rather than a pass result.  DMARC will
> > ignore it then.  Still solvable in SPF with no protocol change.
> > 
> > These sources are effectively open relays (not literally, but
> > practically).  This isn't a problem that should be solved by a protocol
> > change in DMARC.
> 
> I too had thought there was consensus on this issue. I think in this case
> it is appropriate for a protocol change. Senders today do not currently
> have a way to express "ignore my SPF when evaluating DMARC". Adding that to
> the protocol is necessary to give them that choice. We have seen hundreds
> of senders affected by this issue and it is not acceptable for them to turn
> off SPF because there are a variety of receivers out there with varying
> requirements and turning off SPF entirely might have a negative impact. It
> is more than acceptable for them to say: ignore SPF from the perspective of
> DMARC.

And then where's DMARC when the demand comes up to ignore DKIM because of the 
impacts of DKIM replay attacks?

To me this is similar to the multiple suggestions over the years to add an "I 
really mean it" flag to SPF for records that end in -all and it's an equally 
'good' idea.  This is entirely fixable within SPF as the message you are 
replying to describes.

Scott K



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

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Richard Clayton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message , Scott
Kitterman  writes

>>> My reading of the discussion is:
>>> 
>>> 1. We did not have rough consensus to eliminate the use of SPF in DMARC.

sadly so, it would have been the right thing to do

>>> 2. We did not have rough consensus to complicate DMARC by having the 
>publishing domain specify authentication methods.

hmm...  it does seem to be the best way of addressing #1

>The purported use case is "my SPF is so awful you can't trust it and at the 
>same 
>time, so critical I still have to publish the record".  I don't think that's a 
>real thing.

there appear to be receivers who use SPF as a filtering mechanism to
reject patently obvious forgeries -- and if SPF passes they then apply
other mechanisms because they don't want to bother with DKIM  (I've seen
posts to this effect -- their customers, their funeral)

not having an SPF record at all would mean that these receivers would
not be able to do that filtering (and the lack of SPF might adversely
affect various heuristics for determining how email should be treated)

viz: there is an edge case for senders to continue to publish SPF even
when it almost useless (it stops people forging mail from a different
cloud, but not from the one that they use)

if that is so, then senders need to be able to tell all the receivers
who do believe in the value of DKIM (and there are a lot of those) "take
no notice of my SPF record" ... so DMARCbis should support that

Note that if BIMI is involved the SPF will be ignored anyway (and the
documentation might even say that RSN) 

>If your SPF is unreliable, fix it or delete it.  Not a DMARC problem.

senders using clouds to spin up and spin down resources depending on
demand will struggle to "fix it"  ...  that's why it was so widely drawn
in the first place. Senders using shared IPs at ESPs are also not in a
position to "fix it" -- they can only hope that the ESP correctly
polices what is being sent by each particular customer.

- -- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZTktx92nQQHFxEViEQLZfwCgrWwC2PLCvHV8I9aHLE5XVZLZGTQAnjar
ThGQVjdL/8CrteVWGe3KaNTO
=BqvR
-END PGP SIGNATURE-

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

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Emanuel Schorsch]

>
> >There's the counterargument "so don't publish SPF" but it's on so many
> checklists
> >that even though that would be a fine idea, it's not practical.
>
> Diving into the SPF angle, if someone has a 'legitimate' mail source that
> also sends spoofed mail for them, they can prefix the relevant mechanism
> with '?' so it produces a neutral rather than a pass result.  DMARC will
> ignore it then.  Still solvable in SPF with no protocol change.
>
> These sources are effectively open relays (not literally, but
> practically).  This isn't a problem that should be solved by a protocol
> change in DMARC.
>

I too had thought there was consensus on this issue. I think in this case
it is appropriate for a protocol change. Senders today do not currently
have a way to express "ignore my SPF when evaluating DMARC". Adding that to
the protocol is necessary to give them that choice. We have seen hundreds
of senders affected by this issue and it is not acceptable for them to turn
off SPF because there are a variety of receivers out there with varying
requirements and turning off SPF entirely might have a negative impact. It
is more than acceptable for them to say: ignore SPF from the perspective of
DMARC.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] DMARCbis rev 29 (was: Re: DMARCbis way forward: Do we need our session at IETF 118)

[Todd Herr]

On Tue, Oct 24, 2023 at 2:15 PM Barry Leiba  wrote:

> Now that we have a consensus call on the main issue that has remained open:
>
> 1. Do we need to retain our session at IETF 118 and discuss this (or
> something else) further?
>
> ...or...
>
> 2. Do we have what we need to finish up the DMARCbis document, and
> should the chairs cancel the session at 118?
>
> Oh, and...
>
> 3. Is there something else (such as the reporting documents) that we
> should use the time at 118 to discuss?  Or can we continue with those
> on the mailing list for now?  My sense is that aggregate reporting, at
> least, is just about ready to go and doesn't need the face-to-face
> time.
>
>
I think canceling the session at 118 is the way to go.

I further think that the best way to produce the next rev of DMARCbis is
for the chairs and the editors (and perhaps the ADs) to huddle together and
create/update issues in the Github repository for the sections of text for
which changes have been proposed. At a minimum, the outcome of this meeting
would be several bullet points all following this pattern:

   - Create/update GitHub issue with $TITLE using text from
   $MAILING_LIST_THREAD

Todd, as editor whose mail client isn't one that lends itself well to
piecing together multiple threads into a coherent list...

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On October 25, 2023 1:37:55 PM UTC, John Levine  wrote:
>It appears that Scott Kitterman   said:
>>>* Is there consensus on moving ahead with the idea of a way to indicate
>>>which authentication method(s) the Domain Owner wants Receivers to use?  If
>>>so, it doesn't seem to be in the document yet.
>>
>>I haven't seen any valid case for it yet.  It adds complexity to little or no 
>>benefit. 
>
>Normally I am in favor of keeping stuff simple, but I think in this case the
>argument for "DKIM only" is quite strong.  People whose opinion I trust tell
>me that so many SPF records include so many large clouds that in practice
>an SPF pass no longer tells you anything useful.
>
>There's the counterargument "so don't publish SPF" but it's on so many 
>checklists
>that even though that would be a fine idea, it's not practical.

Diving into the SPF angle, if someone has a 'legitimate' mail source that also 
sends spoofed mail for them, they can prefix the relevant mechanism with '?' so 
it produces a neutral rather than a pass result.  DMARC will ignore it then.  
Still solvable in SPF with no protocol change.

These sources are effectively open relays (not literally, but practically).  
This isn't a problem that should be solved by a protocol change in DMARC.

Scott K

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

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[John Levine]

It appears that Scott Kitterman   said:
>>* Is there consensus on moving ahead with the idea of a way to indicate
>>which authentication method(s) the Domain Owner wants Receivers to use?  If
>>so, it doesn't seem to be in the document yet.
>
>I haven't seen any valid case for it yet.  It adds complexity to little or no 
>benefit. 

Normally I am in favor of keeping stuff simple, but I think in this case the
argument for "DKIM only" is quite strong.  People whose opinion I trust tell
me that so many SPF records include so many large clouds that in practice
an SPF pass no longer tells you anything useful.

There's the counterargument "so don't publish SPF" but it's on so many 
checklists
that even though that would be a fine idea, it's not practical.

>>* Given some of the stuff we're hearing in the wings about the utility of
>>ARC, do we want to talk about it in -bis at all? 

>ARC solves nothing on its own.  ARC plus a list of senders I trust not to lie 
>to me is quite useful.  I don't
>think it can be raised to a more formal part of DMARC since its utility if 
>entirely dependent on
>non-standardized (and almost certainly non-standardizable) special sauce.

Agreed.

R's,
John

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

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Dotzero]

On Wed, Oct 25, 2023 at 8:56 AM Scott Kitterman 
wrote:

>
>
> On October 25, 2023 11:56:25 AM UTC, Alessandro Vesely 
> wrote:
> >On Wed 25/Oct/2023 13:12:32 +0200 Barry Leiba wrote:
>  * Is there consensus on moving ahead with the idea of a way to
> indicate which authentication method(s) the Domain Owner wants Receivers to
> use?  If so, it doesn't seem to be in the document yet.
> >>>
> >>> My recall is that we want to limit DMARC evaluation to DKIM only, for
> the edge cases of domains with over-wide SPF policies, since they proved to
> be vulnerable to false DMARC pass.  The WG discussed the possibility to
> also require both methods to limit replay, and concluded that the idea was
> a foot gun.  Hence the WG agreed on the comma syntax.
> >>
> >> My reading of the discussion is:
> >>
> >> 1. We did not have rough consensus to eliminate the use of SPF in DMARC.
> >
> >
> >Yes.
> >
> >
> >> 2. We did not have rough consensus to complicate DMARC by having the
> publishing domain specify authentication methods.
> >
> >
> >One thread started here:
> >https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukLDgDqlp6NEGw/
> >
> >It ends up with Wei recapitulating the thread and summarizing the changes
> to the draft.  No objections.  I expected those changes to be carried out.
> >
> >
> >> Ale, you're saying that my reading on (2) is wrong, yes?  Can you
> provide support for that?
> >
> >
> >I had only seen Scott's reading, which surprised me.  After you and
> Michael hold that no agreement was reached, I begin to doubt of my reading
> myself.
> >
> >In particular, since there is a paper[*] showing how a "spoofed email
> >purporting to be b...@state.gov is delivered to a Gmail user’s inbox
> with no warning indicators", Wei's argument seemed to be fully reasonable.
> >
> >What outstanding objections were there?
>
> The purported use case is "my SPF is so awful you can't trust it and at
> the same time, so critical I still have to publish the record".  I don't
> think that's a real thing.
>
> If your SPF is unreliable, fix it or delete it.  Not a DMARC problem.
>

+1

We need to stop confusing operational/implementation issues on the part of
some with issues that reflect poor logic in a standard.

Michael Hammer
___
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: Do we need our session at IETF 118

[Scott Kitterman]

On October 25, 2023 11:56:25 AM UTC, Alessandro Vesely  wrote:
>On Wed 25/Oct/2023 13:12:32 +0200 Barry Leiba wrote:
 * Is there consensus on moving ahead with the idea of a way to indicate 
 which authentication method(s) the Domain Owner wants Receivers to use?  
 If so, it doesn't seem to be in the document yet.
>>> 
>>> My recall is that we want to limit DMARC evaluation to DKIM only, for the 
>>> edge cases of domains with over-wide SPF policies, since they proved to be 
>>> vulnerable to false DMARC pass.  The WG discussed the possibility to also 
>>> require both methods to limit replay, and concluded that the idea was a 
>>> foot gun.  Hence the WG agreed on the comma syntax.
>> 
>> My reading of the discussion is:
>> 
>> 1. We did not have rough consensus to eliminate the use of SPF in DMARC.
>
>
>Yes.
>
>
>> 2. We did not have rough consensus to complicate DMARC by having the 
>> publishing domain specify authentication methods.
>
>
>One thread started here:
>https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukLDgDqlp6NEGw/
>
>It ends up with Wei recapitulating the thread and summarizing the changes to 
>the draft.  No objections.  I expected those changes to be carried out.
>
>
>> Ale, you're saying that my reading on (2) is wrong, yes?  Can you provide 
>> support for that?
>
>
>I had only seen Scott's reading, which surprised me.  After you and Michael 
>hold that no agreement was reached, I begin to doubt of my reading myself.
>
>In particular, since there is a paper[*] showing how a "spoofed email
>purporting to be b...@state.gov is delivered to a Gmail user’s inbox with no 
>warning indicators", Wei's argument seemed to be fully reasonable.
>
>What outstanding objections were there?

The purported use case is "my SPF is so awful you can't trust it and at the 
same time, so critical I still have to publish the record".  I don't think 
that's a real thing.

If your SPF is unreliable, fix it or delete it.  Not a DMARC problem.

Scott K

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

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Alessandro Vesely]

On Wed 25/Oct/2023 13:12:32 +0200 Barry Leiba wrote:
* Is there consensus on moving ahead with the idea of a way to indicate 
which authentication method(s) the Domain Owner wants Receivers to use?  If 
so, it doesn't seem to be in the document yet.


My recall is that we want to limit DMARC evaluation to DKIM only, for the edge 
cases of domains with over-wide SPF policies, since they proved to be 
vulnerable to false DMARC pass.  The WG discussed the possibility to also 
require both methods to limit replay, and concluded that the idea was a foot 
gun.  Hence the WG agreed on the comma syntax.


My reading of the discussion is:

1. We did not have rough consensus to eliminate the use of SPF in DMARC.



Yes.


2. We did not have rough consensus to complicate DMARC by having the 
publishing domain specify authentication methods.



One thread started here:
https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukLDgDqlp6NEGw/

It ends up with Wei recapitulating the thread and summarizing the changes to 
the draft.  No objections.  I expected those changes to be carried out.



Ale, you're saying that my reading on (2) is wrong, yes?  Can you 
provide support for that?



I had only seen Scott's reading, which surprised me.  After you and Michael 
hold that no agreement was reached, I begin to doubt of my reading myself.


In particular, since there is a paper[*] showing how a "spoofed email
purporting to be b...@state.gov is delivered to a Gmail user’s inbox with no 
warning indicators", Wei's argument seemed to be fully reasonable.


What outstanding objections were there?


Best
Ale
--

[*] Enze Liu et al.  "Forward Pass: On the Security Implications of
Email Forwarding Mechanism and Policy", https://arxiv.org/abs/2302.07287




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

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

[Olivier Hureau]

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

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

[Matthäus Wander]

Olivier Hureau wrote on 2023-10-25 12:56:
What about using the error report of RFC 7489 for this purpose instead 
of aggregate report? ( 
https://datatracker.ietf.org/doc/html/rfc7489#section-7.2.2 )


I have never seen any error report but I think that error reports were a 
great ideas because they can advertise the domain owner (through the 
valid URI) for any failing external destination verification
We could also use the error reports for  to reports any syntactic errors 
in the record could be also useful, in my opinion.


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.


However, it needs to be well defined to avoid sending to much 
unsolicited  message (Usenix 2023 : You've Got Report: Measurement and 
Security Implications of DMARC Reporting 
.)
Sending error reports only to domains under authority of the Domain 
Owner would solve the issue.


I believe aggregate reports have already addressed this issue (Verifying 
External Destinations).


Regards,
Matt

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

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Dotzero]

On Wed, Oct 25, 2023 at 7:12 AM Barry Leiba  wrote:

> > > * Is there consensus on moving ahead with the idea of a way to indicate
> > > which authentication method(s) the Domain Owner wants Receivers to
> use?  If
> > > so, it doesn't seem to be in the document yet.
> >
> > My recall is that we want to limit DMARC evaluation to DKIM only, for
> the edge
> > cases of domains with over-wide SPF policies, since they proved to be
> > vulnerable to false DMARC pass.  The WG discussed the possibility to also
> > require both methods to limit replay, and concluded that the idea was a
> foot
> > gun.  Hence the WG agreed on the comma syntax.
>
> My reading of the discussion is:
>
> 1. We did not have rough consensus to eliminate the use of SPF in DMARC.
>

+1


> 2. We did not have rough consensus to complicate DMARC by having the
> publishing domain specify authentication methods.
>

+1


> Ale, you're saying that my reading on (2) is wrong, yes?  Can you
> provide support for that?
>
>
Mi chael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Barry Leiba]

> > * Is there consensus on moving ahead with the idea of a way to indicate
> > which authentication method(s) the Domain Owner wants Receivers to use?  If
> > so, it doesn't seem to be in the document yet.
>
> My recall is that we want to limit DMARC evaluation to DKIM only, for the edge
> cases of domains with over-wide SPF policies, since they proved to be
> vulnerable to false DMARC pass.  The WG discussed the possibility to also
> require both methods to limit replay, and concluded that the idea was a foot
> gun.  Hence the WG agreed on the comma syntax.

My reading of the discussion is:

1. We did not have rough consensus to eliminate the use of SPF in DMARC.

2. We did not have rough consensus to complicate DMARC by having the
publishing domain specify authentication methods.

Ale, you're saying that my reading on (2) is wrong, yes?  Can you
provide support for that?

Barry

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

Re: [dmarc-ietf] Best of all possible documents?

[Barry Leiba]

DMARC is a protocol that uses a published DNS record to advertise a
sending domain's policy.  It's described in RFC 7489 and the DMARCbis
draft.

What anyone does in the absence of a published DMARC record is *not*
part of DMARC, in the same way that use of FTP to deliver email is not
part of SMTP.

The DMARCbis document is *only* describing the use of DMARC.
Describing [not DMARC] in the DMARCbis document is out of scope.
Please stop insisting that it be in scope.

Barry, as chair

On Wed, Oct 25, 2023 at 12:32 PM Douglas Foster
 wrote:
>
> More specifically to the asserted charter problem:
>
> RFC 7489 provided a universally applicable rule for determining 
> organizational boundaries: the PSL.
> Then it provided a universally applicable rule for determining 
> authentication:   relaxed alignment, same organization for the verified 
> identifier and the FROM domain.
>
> Despite starting from that point, RFC 7489 arbitrarily limited applicability 
> to messages with DMARC policies, which is its core design failure.   
> Reversing that mistake is part of what DMARCbis needs to do.
>
> Doug
>
> On Tue, Oct 24, 2023 at 11:30 PM Murray S. Kucherawy  
> wrote:
>>
>> On Tue, Oct 24, 2023 at 5:34 PM Douglas Foster 
>>  wrote:
>>>
>>> In short, I am not part of the presumed consensus on this document. I will 
>>> vigorously oppose any document which does not discuss malicious 
>>> impersonation defenses for every domain.
>>
>>
>> Doug,
>>
>> A working group charter is a sort of contract with the IESG that stipulates 
>> what the working group will produce and how it will operate.  This is meant 
>> to keep the working group on track and eschew distractions and scope creep.  
>> The charter for this particular working group is visible in the IETF 
>> datatracker.
>>
>> If you read it, you'll see that this working group is not chartered to do 
>> anything as broad as what I believe you are demanding here.  Put another 
>> way: Were it to produce the document that you appear to expect, it likely 
>> would be sent back as exceeding the working group's charter.  A full 
>> treatment of sender authentication and malicious impersonation far exceeds 
>> what DMARC by itself is capable of addressing, and we here are only dealing 
>> with DMARC.  We are chartered here to revise RFC 7489 based on operational 
>> experience acquired since DMARC was first deployed, and in this and other 
>> ways prepare it for publication on the Standards Track, and possibly produce 
>> ancillary documents.  We are not chartered to produce an broad treatment of 
>> the sort you seek.
>>
>> The sentiment of your first sentence is noted.  The sentiment of your 
>> second, however, seems like a threat that you intend to make yourself 
>> vexatious to the progress of the document, and I truly hope you don't mean 
>> that.
>>
>> -MSK, ART AD

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

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

[Olivier Hureau]

On 25/10/2023 08:10, Steven M Jones wrote:


It's not so much changing the handling as changing the reporting.

* The policy to apply is "none," because the p/sp/np value was faulty. 
Done.
* Next step, if there's no "rua" target you can't report - which is 
now equivalent to bailing out of DMARC processing for this message.



I am not fan of this exceptions, it breaks the ABNF ... 'A DMARC policy 
recordMUSTcomply with the formal specification found inSection 5.4 
' 

The record 'v=DMARC1; p=foobar; rua=mailto:r...@example.com' does not 
comply with the formal specification (ABNF rule dmarc-request)
Furthemore, 'mailto://example.com' is a valid URI according to RFC3986. 
If we take into consideration the record 'v=DMARC1; p=foobar; 
rua=mailto://example.com' : a 'rua' tag is present and contains at least 
one syntactically valid reporting URI (no need to have a mailto). Who 
are we going to send the reports specifying the errors?


What about using the error report of RFC 7489 for this purpose instead 
of aggregate report? ( 
https://datatracker.ietf.org/doc/html/rfc7489#section-7.2.2 )


I have never seen any error report but I think that error reports were a 
great ideas because they can advertise the domain owner (through the 
valid URI) for any failing external destination verification
We could also use the error reports for  to reports any syntactic errors 
in the record could be also useful, in my opinion.


However, it needs to be well defined to avoid sending to much 
unsolicited  message (Usenix 2023 : You've Got Report: Measurement and 
Security Implications of DMARC Reporting 
.)
Sending error reports only to domains under authority of the Domain 
Owner would solve the issue.


Regards,
Olivier



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Alessandro Vesely]

On Wed 25/Oct/2023 05:38:01 +0200 Murray S. Kucherawy wrote:

On Tue, Oct 24, 2023 at 11:15 AM Barry Leiba  wrote:


2. Do we have what we need to finish up the DMARCbis document, and
should the chairs cancel the session at 118?


A few questions, but they don't demand in-person time if we want to just 
deal with them on the list:


* Is there consensus on moving ahead with the idea of a way to indicate 
which authentication method(s) the Domain Owner wants Receivers to use?  If 
so, it doesn't seem to be in the document yet.



My recall is that we want to limit DMARC evaluation to DKIM only, for the edge 
cases of domains with over-wide SPF policies, since they proved to be 
vulnerable to false DMARC pass.  The WG discussed the possibility to also 
require both methods to limit replay, and concluded that the idea was a foot 
gun.  Hence the WG agreed on the comma syntax.



* Given some of the stuff we're hearing in the wings about the utility of 
ARC, do we want to talk about it in -bis at all?  The original plan (I 
thought) was that if it turned out to be high signal, we could add it as a 
third supported method.  I'm hearing positive value from a couple of 
operators, but nothing of the form "Yes, this solves the DMARC problem with 
lists."



ARC was barely specified.  A protocol to regulate in which cases it overrides 
DMARC was not specified.  A reporting mechanism was not specified.  These 
issues belong to the charter and I hope the WG will tackle them, after DMARCbis 
last call.  To merge an ARC applicability statement into DMARCbis would distort 
it into an experimental thing, thereby failing to standardize it.



Best
Ale
--




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

Re: [dmarc-ietf] Best of all possible documents?

[Douglas Foster]

More specifically to the asserted charter problem:

RFC 7489 provided a universally applicable rule for determining
organizational boundaries: the PSL.
Then it provided a universally applicable rule for determining
authentication:   relaxed alignment, same organization for the verified
identifier and the FROM domain.

Despite starting from that point, RFC 7489 arbitrarily limited
applicability to messages with DMARC policies, which is its core design
failure.   Reversing that mistake is part of what DMARCbis needs to do.

Doug

On Tue, Oct 24, 2023 at 11:30 PM Murray S. Kucherawy 
wrote:

> On Tue, Oct 24, 2023 at 5:34 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> In short, I am not part of the presumed consensus on this document. I
>> will vigorously oppose any document which does not discuss malicious
>> impersonation defenses for every domain.
>>
>
> Doug,
>
> A working group charter is a sort of contract with the IESG that
> stipulates what the working group will produce and how it will operate.
> This is meant to keep the working group on track and eschew distractions
> and scope creep.  The charter for this particular working group is visible
> in the IETF datatracker.
>
> If you read it, you'll see that this working group is not chartered to do
> anything as broad as what I believe you are demanding here.  Put another
> way: Were it to produce the document that you appear to expect, it likely
> would be sent back as exceeding the working group's charter.  A full
> treatment of sender authentication and malicious impersonation far exceeds
> what DMARC by itself is capable of addressing, and we here are only dealing
> with DMARC.  We are chartered here to revise RFC 7489 based on operational
> experience acquired since DMARC was first deployed, and in this and other
> ways prepare it for publication on the Standards Track, and possibly
> produce ancillary documents.  We are not chartered to produce an broad
> treatment of the sort you seek.
>
> The sentiment of your first sentence is noted.  The sentiment of your
> second, however, seems like a threat that you intend to make yourself
> vexatious to the progress of the document, and I truly hope you don't mean
> that.
>
> -MSK, ART AD
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Best of all possible documents?

[Douglas Foster]

The solution then should be to fix the charter.   Everything depends on
your definition of DMARC.   Here is mine:

"DMARC is the use of proxy authentication to provide verification of the
FROM address and mitigate malicious impersonation of that address, combined
with supporting mechanisms to maximize the accuracy of that evaluation."

I reject this definition:

"DMARC is the use of proxy authentication to provide verification of some
FROM addresses to  mitigate malicious impersonation on a subset of those
addresses."

or this one:

"DMARC is the use of proxy authentication to protect brand identity of the
FROM address domain owner."

But to the mailing list problem, try this:

Messages fall naturally into three groups:
1) Messages which demonstrate domain owner authorization using SPF PASS or
DKIM PASS.
2) Messages which cannot demonstrate domain owner authorization but are
based on an established relationship with an individual domain member and
sent for benevolent purposes.
3) Messages which are not based on any relationship with the domain and are
consequently malicious in purpose.

The distinction between the second and third group is a matter of intent,
and intent can only be determined by the evaluator when messages are
presented for evaluation.   Domain owner use of "p=reject" is a request to
usurp the evaluator role by asserting that there is no possibility that any
message from any source could be received for any benevolent reason without
presenting evidence of domain owner authorization.In limited cases,
domain owners are in a position to make this assertion correctly, but
operating experience has shown that this is rare.   Evaluators SHOULD treat
"p=reject" as equivalent to  "p=quarantine", and make their own
determination of intent, blocking messages with malicious intent and
allowing acceptable messages.

Doug Foster



On Tue, Oct 24, 2023 at 11:30 PM Murray S. Kucherawy 
wrote:

> On Tue, Oct 24, 2023 at 5:34 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> In short, I am not part of the presumed consensus on this document. I
>> will vigorously oppose any document which does not discuss malicious
>> impersonation defenses for every domain.
>>
>
> Doug,
>
> A working group charter is a sort of contract with the IESG that
> stipulates what the working group will produce and how it will operate.
> This is meant to keep the working group on track and eschew distractions
> and scope creep.  The charter for this particular working group is visible
> in the IETF datatracker.
>
> If you read it, you'll see that this working group is not chartered to do
> anything as broad as what I believe you are demanding here.  Put another
> way: Were it to produce the document that you appear to expect, it likely
> would be sent back as exceeding the working group's charter.  A full
> treatment of sender authentication and malicious impersonation far exceeds
> what DMARC by itself is capable of addressing, and we here are only dealing
> with DMARC.  We are chartered here to revise RFC 7489 based on operational
> experience acquired since DMARC was first deployed, and in this and other
> ways prepare it for publication on the Standards Track, and possibly
> produce ancillary documents.  We are not chartered to produce an broad
> treatment of the sort you seek.
>
> The sentiment of your first sentence is noted.  The sentiment of your
> second, however, seems like a threat that you intend to make yourself
> vexatious to the progress of the document, and I truly hope you don't mean
> that.
>
> -MSK, ART AD
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Alessandro Vesely]

On Tue 24/Oct/2023 20:15:22 +0200 Barry Leiba wrote:


2. Do we have what we need to finish up the DMARCbis document, and
should the chairs cancel the session at 118?



IMHO this one.


Best
Ale
--




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

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

[Alessandro Vesely]

On Wed 25/Oct/2023 08:10:33 +0200 Steven M Jones wrote:


PROPOSED versus draft 28 section 4.7:


If a retrieved policy record does not contain a valid "p" tag, or
contains an "sp" or "np" tag that is not valid, then:

*  The Mail Receiver MUST act as if a record containing "p=none" was
   retrieved and continue processing;



If it were not for the appositive condition bringing about "sp" and "np", these 
two clauses would have a sound meaning.  Acting as if p=none after an invalid 
sp= clashes.  Let me try a different wording:


If, in a retrieved policy record, the policy to be applied, "p", "sp",
or "np", is specified with an invalid value, then:

*   The Mail Receiver MUST act as if said policy had the value "none";



*  The Mail Receiver MAY note the invalid "p", "sp", or "np" tag
   in the optional "error" field of the informative section of the
   DMARC aggregate report [I-D.ietf-dmarc-aggregate-reporting];
  
*  If there is no "rua" tag, or if it does not contain at least one

   syntactically valid reporting URI, the Mail Receiver effectively
   applies no DMARC processing to this message.



I agree to mention the error field here.  Yet, in such event, it is not 
possible to report the value of the policy, so minOccurs should be 0.


The order of the last two bullets is beter reversed.


Best
Ale
--



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

Re: [dmarc-ietf] Dmarcbis way forward

[Alessandro Vesely]

On Tue 24/Oct/2023 15:20:02 +0200 Baptiste Carvello wrote:

Le 23/10/2023 à 19:59, Alessandro Vesely a écrit :
My opinion is that Barry's text is good as is.  As far as delimiting a SHOULD 
NOT with another SHOULD is legit, this sentence sounds clear to me:


  It is therefore critical that domains that host users who might
  post messages to mailing lists SHOULD NOT publish p=reject. Domains
  that choose to publish p=reject SHOULD implement policies that
  their users not post to Internet mailing lists.

The exceptions to the latter SHOULD are rather obvious.  Do we really need to 
formally specify domain policing?


I for one would be interested in hearing what you believe those exceptions are. 
When reading your aggressive next paragraph, I'm lead to think that in your 
view, "technologies dating from the 80s deserve no respect" is reason enough to 
break both SHOULDs.



I absolutely didn't mean to be disrespectful.  I'm sorry that interpretation 
came up.  What I wanted to say is that our persistent attention toward this 
topic is probably not met by average readers, and any outcome will likely be 
unattended.  IOW, I perceive our continuing this discussion as a waste of time, 
not because I don't respect the value of interoperability, but because the 
discussion doesn't seem to be productive.  Getting back to addressing the 
issues with indirect mail flows, for example, would be more fruitful than 
philosophizing on who is permitted to use DMARC.


As for domain policing exceptions, let me mention internal mailing lists which 
can manage to be fully interoperable notwithstanding DMARC.  I also believe 
that it is possible to automate per-user whitelisting of all forwarded traffic, 
relying on ARC, so as to avoid the much abhorred From: munging.  Domains within 
such an environment can certainly deploy p=reject without worries.  In general, 
people should balance interoperation needs and security requirements.



There may be rough consensus for a good faith SHOULD, but definitely not for 
overt disrespect of interoperability in the name of some brave new "today's 
reality".



If there is rough consensus, we can just move on, without further polishing 
Section 8.6.  There is no disrespect, just clearance.



Best
Ale
--



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

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

[Steven M Jones]

On 10/20/23 12:35 PM, Murray S. Kucherawy wrote:
(1) As written, the text says (to me) that the handling of a message 
might change depending on this mapping of a broken value to "none", 
but only if "rua" is present; absent "rua", the record is treated as 
junk and DMARC doesn't apply.


It's not so much changing the handling as changing the reporting.

* The policy to apply is "none," because the p/sp/np value was faulty. Done.

* Next step, if there's no "rua" target you can't report - which is now 
equivalent to bailing out of DMARC processing for this message.


Olivier's language comes close to this. But then Matt and Ale have 
continued with reporting...



Matt Wander wrote:

In the above case, the already existing (but not prominently known) 
optional  field in the  section can be used to 
include an error message, e.g., "syntax error in sp tag".


Text suggestion:
The Mail Receiver MAY utilize the optional "error" field in aggregate 
reports to announce syntax errors identified in the DMARC policy record.


+1


So then, maybe we wind up with something like this:

PROPOSED versus draft 28 section 4.7:


   If a retrieved policy record does not contain a valid "p" tag, or
   contains an "sp" or "np" tag that is not valid, then:

   *  The Mail Receiver MUST act as if a record containing "p=none" was
  retrieved and continue processing;

   *  The Mail Receiver MAY note the invalid "p", "sp", or "np" tag
  in the optional "error" field of the informative section of the
  DMARC aggregate report [I-D.ietf-dmarc-aggregate-reporting];
 
   *  If there is no "rua" tag, or if it does not contain at least one

  syntactically valid reporting URI, the Mail Receiver effectively
  applies no DMARC processing to this message.


And if somebody wants to argue against including the third point, I 
would offer that it may be better to be explicit that to repeat this 
exercise in a future WG.



--S.

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