Re: [dmarc-ietf] Best Guess SPF is a dead hack from 18 years ago

[Scott Kitterman]

On Monday, December 6, 2021 4:22:16 PM EST Dave Crocker wrote:
> On 12/6/2021 1:18 PM, John Levine wrote:
> > Please can we all pretend it never existed, we never heard of it,
> > and we certainly are not going to say anything about it.
> 
> My best guess is that you are referencing something that has no business
> even being referenced in an IETF specification.

Agreed (on both of your points).  It was a mistake to put it in RFC 7498, but 
that's no IETF specification.

Scott K


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

Re: [dmarc-ietf] PSD Flag

[Tim Wicinski]

On Mon, Dec 6, 2021 at 8:57 AM Scott Kitterman  wrote:

>
>
> Unless there's a valid reason for someone to publish PSD=no, I don't think
> it should exist and I can't think of a reason.  If you give people a knob,
> someone will turn it [if we leave it in, I guarantee you there will be
> things written about how essential it is to have psd=no in your DMARC
> record].
>
>
What Scott says here. It can not be said enough.  People will attempt
anything and everything.  Make it simple, and precise.

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

Re: [dmarc-ietf] Best Guess SPF is a dead hack from 18 years ago

[Dave Crocker]

On 12/6/2021 1:18 PM, John Levine wrote:

Please can we all pretend it never existed, we never heard of it,
and we certainly are not going to say anything about it.



My best guess is that you are referencing something that has no business 
even being referenced in an IETF specification.



d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] Best Guess SPF is a dead hack from 18 years ago

[John Levine]

It appears that Scott Kitterman   said:
>No.  The so called best guess is no part of SPF.  

The "best guess" was a short term hack around 2003 when SPF was new
and not widely deployed.  It is now 18 years later, anyone who can
run a mail server can publish SPF and that hack is totally dead.

Please can we all pretend it never existed, we never heard of it,
and we certainly are not going to say anything about it.

R's,
John

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

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

[Scott Kitterman]

On Monday, December 6, 2021 3:04:37 PM EST Dave Crocker wrote:
> On 12/6/2021 11:56 AM, Scott Kitterman wrote:
> > Somewhere we need to explain about how ARC related to DMARC.  If it's
> > going to be in the protocol specification, this is the place.  Otherwise
> > it would go in the appendix I keep mentioning that we need which explains
> > options senders, intermediaries, and receivers can do to mitigate DMARC
> > interoperability challenges.
> > 
> > I think it's slightly better to do it in an appendix , as long as we
> > remember to write it.
> You want to comment on ARC in the DMARC specification?  Don't do that.
> 
> ARC currently has nothing to do with DMARC.  And DMARC currently has
> nothing to do with ARC.
> 
> To change this will require writing a specification, presumably as an
> enhancement to DMARC, to include consideration of ARC.
> 
> In technical terms, the ARC specification must not know about or care
> about DMARC, since ARC is attempting to augment DKIM, rather than an
> upper-level function that uses DKIM, which is what DMARC is.
> 
> If it helps, draw boxes with labels for different functions, like SPF,
> DKIM, and DMARC.  Draw arrows between them,to establish which provides
> functionality and which uses it.
> 
> A providing specification must not know or document anything about a
> consumer.  Otherwise it is, effectively, a layer violation.  It also
> invites messy complexity and out-of-date references, as specifications
> change.
> 
> To the extent that there is a strong benefit in having a document that
> discussion an aggregation of components, then it's a separate operations
> or architecture document.

That's fine.  I was thinking something conceptually similar to RFC 7208 
Appendix D, but I think there's nothing wrong with a separate document if 
that's what the group prefers.

Scott K


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

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

[Dave Crocker]

On 12/6/2021 11:56 AM, Scott Kitterman wrote:

Somewhere we need to explain about how ARC related to DMARC.  If it's going to 
be in the protocol specification, this is the place.  Otherwise it would go in 
the appendix I keep mentioning that we need which explains options senders, 
intermediaries, and receivers can do to mitigate DMARC interoperability 
challenges.

I think it's slightly better to do it in an appendix , as long as we remember 
to write it.



You want to comment on ARC in the DMARC specification?  Don't do that.

ARC currently has nothing to do with DMARC.  And DMARC currently has 
nothing to do with ARC.


To change this will require writing a specification, presumably as an 
enhancement to DMARC, to include consideration of ARC.


In technical terms, the ARC specification must not know about or care 
about DMARC, since ARC is attempting to augment DKIM, rather than an 
upper-level function that uses DKIM, which is what DMARC is.


If it helps, draw boxes with labels for different functions, like SPF, 
DKIM, and DMARC.  Draw arrows between them,to establish which provides 
functionality and which uses it.


A providing specification must not know or document anything about a 
consumer.  Otherwise it is, effectively, a layer violation.  It also 
invites messy complexity and out-of-date references, as specifications 
change.


To the extent that there is a strong benefit in having a document that 
discussion an aggregation of components, then it's a separate operations 
or architecture document.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org

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

[dmarc-ietf] Ticket #120 - Unique IDs

[Brotman, Alex]

Hello folks,

We received a ticket about the unique IDs that are included with reporting:

--
unique-id, msg-id, and report_id are loosely defined.

The spec needs to say that they are semantically the same thing and must have 
the same content.

In addition:

Message-ID should also be based on unique-id if possible (for example, 
msg-id@domain-name),
make optional the final part of the Subject:, [Report-ID: msg-id] (like the 
filename).
--

I agree, the references should be made to the point to the same identifying 
string definition.  Today, the msg-id is required via the Subject, report_id is 
required in the XSD, and the unique-id is optional in the filename of the 
attached report.  Proposed is adding a suggestion to use the same ID attached 
to the Message-Id header.  Thoughts about making all required or optional?


--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

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

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

[Scott Kitterman]

On December 6, 2021 7:16:06 PM UTC, Dave Crocker  wrote:
>On 12/6/2021 5:29 AM, Scott Kitterman wrote:
>> I think what better goes in this spot is a more general comment about local 
>> policy (it doesn't seem to be discussed elsewhere).
>
>
>"Local policy" is just another way of saying "doing something outside of 
>the specification".  People are always 'allowed' to do whatever they 
>want.  It has nothing to do with interoperability through the specification.
>
>Telling people that they can do things outside of the specification is 
>not helpful.  In fact, it often is counter-productive, because having 
>such language in a specification makes it seem to carry extra weight.  
>Which it doesn't.  For example, it often seems to be granting permission 
>or constraint, but it is doing that for something about which the 
>specification has no power or authority.

Agreed, in general.  Somewhere we need to explain about how ARC related to 
DMARC.  If it's going to be in the protocol specification, this is the place.  
Otherwise it would go in the appendix I keep mentioning that we need which 
explains options senders, intermediaries, and receivers can do to mitigate 
DMARC interoperability challenges.

I think it's slightly better to do it in an appendix , as long as we remember 
to write it.

Scott K

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

Re: [dmarc-ietf] dmarcbis-04, 5.7.1. Extract Author Domain

[John Levine]

It appears that Alessandro Vesely   said:
>Hi,
>
>The domain in the RFC5322.From header field is extracted as the
>domain to be evaluated by DMARC.  If the domain is encoded with UTF-
>8, the domain name must be converted to an A-label, as described in
>Section 2.3 of [RFC5890], for further processing.
>
>Why?  That paragraph is almost identical to its 7489 version.  However, since 
>then, RFC 8616 established that d= in DKIM signatures is a U-label.  In that 
>case, to check alignment, the domain name must be converted to U-label.  Of 
>course, to perform a DNS lookup names must be converted to A-label.  To use 
>the 
>PSL, for those who do, names must be converted to U-label.  In one sentence, a 
>verifier must be prepared to convert domain names as needed.
>
>I'd just strike that paragraph.

If you have EAI mail, which you do if you have a UTF-8 domain in a From header, 
the U-label form is preferred.

It'd be better to say that in an EAI environment, A-labels and U-labels are 
equivalent,
and per RFC 8616 you should use the U-label in A-R headers.  Don't have a 
strong opinion
about what goes into the reports but in aggregate reports, A-labels would 
likely surprise
fewer people.

R's,
John

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

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

[Dave Crocker]

On 12/6/2021 5:29 AM, Scott Kitterman wrote:

I think what better goes in this spot is a more general comment about local 
policy (it doesn't seem to be discussed elsewhere).



"Local policy" is just another way of saying "doing something outside of 
the specification".  People are always 'allowed' to do whatever they 
want.  It has nothing to do with interoperability through the specification.


Telling people that they can do things outside of the specification is 
not helpful.  In fact, it often is counter-productive, because having 
such language in a specification makes it seem to carry extra weight.  
Which it doesn't.  For example, it often seems to be granting permission 
or constraint, but it is doing that for something about which the 
specification has no power or authority.



d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] dmarcbis-04, 5.5. Domain Owner Actions

[Scott Kitterman]

On Monday, December 6, 2021 1:59:19 PM EST Dave Crocker wrote:
> On 12/6/2021 10:48 AM, Scott Kitterman wrote:
> > I understand you don't like what's there, but not how you think it should
> > be changed.  The proposed revision addresses the concern I had raised.
> If a sentence or a paragraph is not providing necessary specification
> and is not providing necessary clarification and is not providing useful
> guidance, then drop that text.

Thanks.  I think that's fine too.

Scott K


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

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

[Scott Kitterman]

On Monday, December 6, 2021 2:01:10 PM EST Alessandro Vesely wrote:
> On Mon 06/Dec/2021 14:29:02 +0100 Scott Kitterman wrote:
> > On December 6, 2021 1:04:44 PM UTC, Todd Herr  
wrote:
> >>On Sat, Dec 4, 2021 at 5:35 PM Douglas Foster 
 wrote:
> >>> I have multiple objections to this paragraph in section 5.7.2
> >>> 
> >>> "Heuristics applied in the absence of use by a Domain Owner of either
> >>> SPF
> >>> or DKIM (e.g., [Best-Guess-SPF
> >>>  >>> -Guess-SPF> ]) SHOULD NOT be used, as it may be the case that the Domain
> >>> Owner wishes a Message Receiver not to consider the results of that
> >>> underlying
> >>> authentication protocol at all."
> >>> 
> >>> [snip]
> >>> 
> >>> 
> >>> I think this text was inserted because of an open ticket when discussion
> >>> was going nowhere and a new draft was created.  Perhaps the originator
> >>> of
> >>> that ticket can elaborate on his thinking.
> >>
> >>To be clear, the text at issue is present in RFC 7489, Section 6.6.2.
> >>
> >>That doesn't make it immutable, of course...
> >>
> > Thanks for the clarification.  I'd forgotten that was there.  I definitely
> > think it should be removed, regardless of the origin.
> I assume you said one can locally evaluate Best-Guess-SPF, but should not
> taint DMARC results by considering its outcome.  That paragraph should then
> be left there, no?

No.  The so called best guess is no part of SPF.  The document says use the 
SPF result.  It's not an SPF result.  There's nothing we can do to stop people 
from doing non-standard things.  We already say what they should do for 
interoperability and protocol consistency.  It's not feasible nor is it a good 
idea to attempt to enumerate the things people shouldn't do.  I struggle to 
understand why this should be called out and not, to pick an example, Sender 
ID.  I'd prefer we don't act as publicity for bad practices.


Scott K


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

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

[Alessandro Vesely]

On Mon 06/Dec/2021 14:29:02 +0100 Scott Kitterman wrote:

On December 6, 2021 1:04:44 PM UTC, Todd Herr  wrote:

On Sat, Dec 4, 2021 at 5:35 PM Douglas Foster 
 wrote:


I have multiple objections to this paragraph in section 5.7.2

"Heuristics applied in the absence of use by a Domain Owner of either SPF
or DKIM (e.g., [Best-Guess-SPF 

]) SHOULD NOT be used, as it may be the case that the Domain Owner wishes
a Message Receiver not to consider the results of that underlying
authentication protocol at all."

[snip]


I think this text was inserted because of an open ticket when discussion
was going nowhere and a new draft was created.  Perhaps the originator of
that ticket can elaborate on his thinking.



To be clear, the text at issue is present in RFC 7489, Section 6.6.2.

That doesn't make it immutable, of course...


Thanks for the clarification.  I'd forgotten that was there.  I definitely 
think it should be removed, regardless of the origin.



I assume you said one can locally evaluate Best-Guess-SPF, but should not taint 
DMARC results by considering its outcome.  That paragraph should then be left 
there, no?




In addition to my comments about leaving SPF best guess out, I think the DKIM part is 
problematic too.  There really aren't any DKIM heuristics to use "in the absence of 
use by a domain owner".  The only DKIM related heuristics that might apply to this 
section are the ones we've discussed about recovering signatures that failed due to in 
transit modification.  Those are a good thing, even if they aren't broadly applicable 
enough to warrant standardization.



Agreed.

However, I wonder if there are heuristics for DMARC itself.  Step 2 seems to 
suggest to skip any SPF or DKIM verification if no policy is found.  By the 
same logic, it could even suggest to skip verifications if p=none and no rua/ 
ruf were found.  Instead, IMHO, there's some value in carrying out 
verifications nonetheless.




I think what better goes in this spot is a more general comment about local 
policy (it doesn't seem to be discussed elsewhere).  That would include 
mentioning ARC as an input to local policy.  I have also suggested an appendix 
or possibly a separate document on things mail senders, intermediaries, and 
receivers can do to improve the reliability of DMARC through indirect mail 
flows.  This would be one place that should be referenced.

I'll provide text if people like the concept.


IMHO that'd be interesting.


Best
Ale
--







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

Re: [dmarc-ietf] dmarcbis-04, 5.5. Domain Owner Actions

[Dave Crocker]

On 12/6/2021 10:48 AM, Scott Kitterman wrote:

I understand you don't like what's there, but not how you think it should be 
changed.  The proposed revision addresses the concern I had raised.


If a sentence or a paragraph is not providing necessary specification 
and is not providing necessary clarification and is not providing useful 
guidance, then drop that text.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] Experiments

[Scott Kitterman]

On Monday, December 6, 2021 1:53:13 PM EST Murray S. Kucherawy wrote:
> To those who said they're collecting data and hope to have some stuff to
> share soon, is there anything interesting to report?
> 
> The topic of ARC's efficacy came up in another IETF context today (tools)
> and I'm wondering if we have anything new here.

Nothing new to report on PSD.

Scott K


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

Re: [dmarc-ietf] Experiments

[Murray S. Kucherawy]

To those who said they're collecting data and hope to have some stuff to
share soon, is there anything interesting to report?

The topic of ARC's efficacy came up in another IETF context today (tools)
and I'm wondering if we have anything new here.

-MSK

On Thu, Sep 23, 2021 at 2:08 PM Brotman, Alex 
wrote:

> Murray,
>
>
>
> We’ve started (relatively recently, in volume) logging ARC data so we can
> try to make some informed decisions going forward.  We’re not yet acting on
> anything as a result, nor writing into the message. We’re also not doing
> anything when mail is being forwarded.  We’ll hopefully have more
> information/data available to share in the future (may not be the very near
> future given other projects going on).   This isn’t a guarantee that we’ll
> fully adopt ARC in the future, but enough to say we’re logging/analyzing
> things.
>
> Random thing while looking at some data just now .. At least one message
> apparently came through with seven ARC sets.
>
>
>
> Let me know if there’s anything I can answer at this point.
>
>
>
> --
>
> Alex Brotman
>
> Sr. Engineer, Anti-Abuse & Messaging Policy
>
> Comcast
>
>
>
> *From:* dmarc  *On Behalf Of * Murray S. Kucherawy
> *Sent:* Wednesday, September 22, 2021 4:30 PM
> *To:* IETF DMARC WG 
> *Subject:* [dmarc-ietf] Experiments
>
>
>
> Is anyone in a position to comment on the ARC and PSD experiments and how
> they're progressing?  Deployment status?  Data acquired thus far?
>
>
>
> -MSK
>
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] dmarcbis-04, 5.5. Domain Owner Actions

[Scott Kitterman]

On December 6, 2021 6:39:17 PM UTC, Dave Crocker  wrote:
>On 12/6/2021 10:06 AM, Scott Kitterman wrote:
>> OK.  What's your recommendation then?
>
>Scott,
>
>I think my note contained a series of very basic recommendations.  I'm 
>not sure what else you are looking for.

What text (if any) would you suggest there?

I understand you don't like what's there, but not how you think it should be 
changed.  The proposed revision addresses the concern I had raised.

Scott K

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

Re: [dmarc-ietf] dmarcbis-04, 5.5. Domain Owner Actions

[Dave Crocker]

On 12/6/2021 10:06 AM, Scott Kitterman wrote:

OK.  What's your recommendation then?


Scott,

I think my note contained a series of very basic recommendations.  I'm 
not sure what else you are looking for.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] dmarcbis-04, 5.5. Domain Owner Actions

[Scott Kitterman]

On Monday, December 6, 2021 1:01:51 PM EST Dave Crocker wrote:
> On 12/6/2021 9:38 AM, Scott Kitterman wrote:
> >> In the interests of future-proofing, should there ever be additional
> >> underlying authentication protocols, I propose this:
> >> 
> >> Should any authentication failures for systems
> >> under the Domain Owner's control be found in the reports, in cases
> >> where the failures are caused by local misconfiguration or omission
> >> the Domain Owner can take steps to address such failures.
> > 
> > I think that's good.
> 
> Sorry, but I think it's not.
> 
> 1.  A specification should specify.  It should specify things that are
> concrete, precise, reliably actionable, and generally produce the same
> understanding across widely differing readers. Specification language
> that does not satisfy the list in the preceding sentence is not a
> specification.  Rather it is commentary.
> 
> 2. When a specifications says that something vague and operational is
> allowed or not allowed, consider whether it would be meaningful to
> switch the bit.  The above text is saying that local problems are
> allowed to be fixed by taking local action. Could it make sense here to
> prohibit taking that action?  I sure hope not.  So this text is, really,
> entirely gratuitous.  It purports to be saying something useful, but it
> isn't.
> 
> 3. IETF specification culture is quite nice in also allowing commentary
> about background or use or 'issues' with the specification.  The
> downside is that this often produces text that is, really, none of the
> things listed in the preceding sentence. Rather, it is language that
> might feel comfortable to the authors but has no practical utility.
> 
> On 12/6/2021 5:35 AM, Todd Herr wrote:
> > SPF normally fails on forwarding.  Should we mention that?
> > 
> > I don't know if it's necessary. SPF breaking due to forwarding is a
> > well-known condition, and I don't think it has to be documented in
> > every text that mentions SPF.
> 
> Kudos for that point.
> 
> 4. Duplication of specification details or commentary text invites
> divergence and/or misunderstanding. Sometimes a caution is helpful, not
> not when it is long-standing issue with another specification and is
> already well-understood.  To the extent that there is a continuing
> concern about the reader's understanding the fact of the caution, there
> should be a basic pointer, early in the specification, to material that
> discusses this (other) specification.
> 
> 
> The problems here come from good intentions, but from the problematic
> view that adding bits of vague or redundant text will provide meaningful
> protection against the points of concern.  They won't.
> 
> d/

OK.  What's your recommendation then?

Scott K



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

Re: [dmarc-ietf] dmarcbis-04, 5.5. Domain Owner Actions

[Dave Crocker]

On 12/6/2021 9:38 AM, Scott Kitterman wrote:

In the interests of future-proofing, should there ever be additional
underlying authentication protocols, I propose this:

Should any authentication failures for systems
under the Domain Owner's control be found in the reports, in cases
where the failures are caused by local misconfiguration or omission
the Domain Owner can take steps to address such failures.

I think that's good.


Sorry, but I think it's not.

1.  A specification should specify.  It should specify things that are 
concrete, precise, reliably actionable, and generally produce the same 
understanding across widely differing readers. Specification language 
that does not satisfy the list in the preceding sentence is not a 
specification.  Rather it is commentary.


2. When a specifications says that something vague and operational is 
allowed or not allowed, consider whether it would be meaningful to 
switch the bit.  The above text is saying that local problems are 
allowed to be fixed by taking local action. Could it make sense here to 
prohibit taking that action?  I sure hope not.  So this text is, really, 
entirely gratuitous.  It purports to be saying something useful, but it 
isn't.


3. IETF specification culture is quite nice in also allowing commentary 
about background or use or 'issues' with the specification.  The 
downside is that this often produces text that is, really, none of the 
things listed in the preceding sentence. Rather, it is language that 
might feel comfortable to the authors but has no practical utility.



On 12/6/2021 5:35 AM, Todd Herr wrote:


SPF normally fails on forwarding.  Should we mention that?


I don't know if it's necessary. SPF breaking due to forwarding is a 
well-known condition, and I don't think it has to be documented in 
every text that mentions SPF.


Kudos for that point.

4. Duplication of specification details or commentary text invites 
divergence and/or misunderstanding. Sometimes a caution is helpful, not 
not when it is long-standing issue with another specification and is 
already well-understood.  To the extent that there is a continuing 
concern about the reader's understanding the fact of the caution, there 
should be a basic pointer, early in the specification, to material that 
discusses this (other) specification.



The problems here come from good intentions, but from the problematic 
view that adding bits of vague or redundant text will provide meaningful 
protection against the points of concern.  They won't.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] dmarcbis-04, 5.5. Domain Owner Actions

[Scott Kitterman]

On Monday, December 6, 2021 11:40:47 AM EST Todd Herr wrote:
> On Mon, Dec 6, 2021 at 9:08 AM Scott Kitterman  wrote:
> > On December 6, 2021 1:35:10 PM UTC, Todd Herr  > 
> > 40valimail@dmarc.ietf.org> wrote:
> > >On Mon, Dec 6, 2021 at 7:45 AM Alessandro Vesely  wrote:
> > ...
> > 
> > >>Should any overlooked systems be found in
> > >>the
> > >> 
> > >> reports, the Domain Owner can adjust the SPF record and/or
> > >> configure
> > >> DKIM signing for those systems.
> > >> 
> > >> I'd s/overlooked systems/failures/, since surprises can also arise from
> > >> systems
> > >> that the Domain Owner considered to have been set up well.
> > >
> > >How about:
> > >
> > >"Should any authentication failures for systems under the Domain Owner's
> > >control be found in the reports, the Domain Owner can adjust the SPF
> > 
> > record
> > 
> > >and/or configure DKIM signing for those systems."
> > 
> > Have mercy for the poor admins whose bosses will waive this at them and
> > demand they "fix" all the issues in their failure reports.  Most cases of
> > DMARC failure are outside the control of the sending domain and this
> > doesn't seem to acknowledge that at all.  Yes, maybe the DNS group decided
> > one day to prettify their zone files by lower casing everything and now
> > everything is getting a DKIM fail, but usually it's a problem elsewhere.
> > 
> > Maybe add "caused by local misconfiguration or omission" after
> > authentication failures?
> 
> In the interests of future-proofing, should there ever be additional
> underlying authentication protocols, I propose this:
> 
> Should any authentication failures for systems
> under the Domain Owner's control be found in the reports, in cases
> where the failures are caused by local misconfiguration or omission
> the Domain Owner can take steps to address such failures.

I think that's good.

Scott K



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

Re: [dmarc-ietf] dmarcbis-04, 5.5. Domain Owner Actions

[Alessandro Vesely]

On Mon 06/Dec/2021 17:40:47 +0100 Todd Herr wrote:

On Mon, Dec 6, 2021 at 9:08 AM Scott Kitterman  wrote:

On December 6, 2021 1:35:10 PM UTC, Todd Herr wrote:

On Mon, Dec 6, 2021 at 7:45 AM Alessandro Vesely  wrote:

...

   Should any overlooked systems be found in the
reports, the Domain Owner can adjust the SPF record and/or configure
DKIM signing for those systems.

I'd s/overlooked systems/failures/, since surprises can also arise
from systems that the Domain Owner considered to have been set up
well. >>>

How about:

"Should any authentication failures for systems under the Domain
Owner's control be found in the reports, the Domain Owner can adjust the
SPF record and/or configure DKIM signing for those systems." >>>

Have mercy for the poor admins whose bosses will waive this at them and
demand they "fix" all the issues in their failure reports.  Most cases of
DMARC failure are outside the control of the sending domain and this
doesn't seem to acknowledge that at all.  Yes, maybe the DNS group decided
one day to prettify their zone files by lower casing everything and now
everything is getting a DKIM fail, but usually it's a problem elsewhere.

Maybe add "caused by local misconfiguration or omission" after
authentication failures?


In the interests of future-proofing, should there ever be additional
underlying authentication protocols, I propose this:

   Should any authentication failures for systems under the Domain Owner's
   control be found in the reports, in cases where the failures are caused by
   local misconfiguration or omission the Domain Owner can take steps to
   address such failures.


That's very generic and almost works.  Could we add "peculiarity" (or a better 
word) for cases where there's nothing wrong but amendments are possible?  That is:


Should any authentication failures for systems under the Domain Owner's
control be found in the reports, in cases where the failures are caused by
local peculiarity, misconfiguration or omission the Domain Owner can
take steps to address such failures.

For example, DKIM signing with strict/strict canonicalization is not a 
misconfiguration, but switching to relaxed/strict can survive a forwarder which 
reflows header fields.



Best
Ale
--





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

Re: [dmarc-ietf] dmarcbis-04, 5.5. Domain Owner Actions

[Todd Herr]

On Mon, Dec 6, 2021 at 9:08 AM Scott Kitterman  wrote:

>
>
> On December 6, 2021 1:35:10 PM UTC, Todd Herr  40valimail@dmarc.ietf.org> wrote:
> >On Mon, Dec 6, 2021 at 7:45 AM Alessandro Vesely  wrote:
> ...
> >>Should any overlooked systems be found in the
> >> reports, the Domain Owner can adjust the SPF record and/or configure
> >> DKIM signing for those systems.
> >>
> >> I'd s/overlooked systems/failures/, since surprises can also arise from
> >> systems
> >> that the Domain Owner considered to have been set up well.
> >>
> >
> >How about:
> >
> >"Should any authentication failures for systems under the Domain Owner's
> >control be found in the reports, the Domain Owner can adjust the SPF
> record
> >and/or configure DKIM signing for those systems."
> >
> Have mercy for the poor admins whose bosses will waive this at them and
> demand they "fix" all the issues in their failure reports.  Most cases of
> DMARC failure are outside the control of the sending domain and this
> doesn't seem to acknowledge that at all.  Yes, maybe the DNS group decided
> one day to prettify their zone files by lower casing everything and now
> everything is getting a DKIM fail, but usually it's a problem elsewhere.
>
> Maybe add "caused by local misconfiguration or omission" after
> authentication failures?
>
>
In the interests of future-proofing, should there ever be additional
underlying authentication protocols, I propose this:

Should any authentication failures for systems

under the Domain Owner's control be found in the reports, in cases

where the failures are caused by local misconfiguration or omission

the Domain Owner can take steps to address such failures.


-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*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] 3.2.6. Non-existent Domains

[Scott Kitterman]

On Sunday, December 5, 2021 9:35:15 PM EST John Levine wrote:
> It appears that Scott Kitterman   said:
> >> For your #2 you seem to be saying that if I send no-reply transactional
> >> mail, my DNS would look like this:
> >> 
> >> notifiy.bigcorp.com. IN MX 0 .   /* we don't receive replies /*
> >> 
> >>IN A 0.0.0.0  /* make the domain exist */
> >> 
> >> _dmarc.notify.bigcorp.com. IN TXT "v=DMARC1; p=reject; ..." /* it's all
> >> aligned */ s._domainkey.notify.bigcorp.com. IN TXT "v=DKIM1; h=sha256;
> >> p=MIIBIjANB..." /* it's signed */
> >
> >In the current definition one of MX, A, or  needs to return something
> >other than NODATA or NXDOMAIN. ...
> >
> >This is  about if the sp= or np= policy should apply (if defined).  I think
> >it's reasonable to apply np= if the only thing that makes the domain exists
> >in our terms in the null mx (#1).  For #2, I think the sp= policy should
> >apply.
> The question appears to be whether we believe that null MX means that a
> domain never sends mail, as opposed to never receivess mail.  As we said in
> RFC 7505 sec 4.2, sending mail from a null MX domain is not a great idea,
> but it is a SHOULD NOT, not a MUST NOT.  If you want to say you never send
> mail, that's SPF -all.
> 
> I don't think this is the place to change the semantics.

I agree it's not the place to change the semantics, but I don't think we are.

The np/sp question is about domain existence, not does it send mail.  Where 
published so far the np tags tend to be a stricter policy than the sp tags.  
For example the current record for .mil:

v=DMARC1; p=reject; sp=none; np=reject; rua=mailto:dmarc_repo...@mail.mil

The difference then would be that currently mail purportedly sent from 
example.mil would use the reject policy from the np= tag vice the none from 
sp=.  If someone were to publish a null mx record for that domain, should that 
change?

I think not.  My simplistic view of SHOULD NOT is that anyone who does owns 
the results if they do.  In this case if you really did send mail from 
example.mil with just the null mx record you SHOULD NOT have done that and if 
that gets a message rejected, well, you SHOULD NOT have done it that way and 
it's on you.

Scott K


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

Re: [dmarc-ietf] dmarcbis-04, 5.5. Domain Owner Actions

[Scott Kitterman]

On December 6, 2021 1:35:10 PM UTC, Todd Herr 
 wrote:
>On Mon, Dec 6, 2021 at 7:45 AM Alessandro Vesely  wrote:
...
>>Should any overlooked systems be found in the
>> reports, the Domain Owner can adjust the SPF record and/or configure
>> DKIM signing for those systems.
>>
>> I'd s/overlooked systems/failures/, since surprises can also arise from
>> systems
>> that the Domain Owner considered to have been set up well.
>>
>
>How about:
>
>"Should any authentication failures for systems under the Domain Owner's
>control be found in the reports, the Domain Owner can adjust the SPF record
>and/or configure DKIM signing for those systems."
>
Have mercy for the poor admins whose bosses will waive this at them and demand 
they "fix" all the issues in their failure reports.  Most cases of DMARC 
failure are outside the control of the sending domain and this doesn't seem to 
acknowledge that at all.  Yes, maybe the DNS group decided one day to prettify 
their zone files by lower casing everything and now everything is getting a 
DKIM fail, but usually it's a problem elsewhere.

Maybe add "caused by local misconfiguration or omission" after authentication 
failures?

Scott K

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

Re: [dmarc-ietf] PSD Flag

[Scott Kitterman]

On December 6, 2021 1:10:02 PM UTC, Todd Herr 
 wrote:
>On Sat, Dec 4, 2021 at 11:28 PM Scott Kitterman 
>wrote:
>
>> I think the addition of the PSD flag to support organizational domain
>> determination is a good change.  I have some quibbles about the exact
>> definition though:
>>
>> >   psd:  A flag indicating whether the domain is a PSD. (plain-text;
>> > OPTIONAL; default is 'n').  Possible values are:
>> >
>> > y:  Domains on the PSL that publish DMARC policy records
>> SHOULD
>> >include this tag with a value of 'y' to indicate that the
>> >domain is a PSD.  This information will be used during
>> policy
>> >discovery to determine how to apply any DMARC policy
>> records
>> >that are discovered during the tree walk.
>> >
>> > n:  The default, indicating that the DMARC policy record is
>> >published for a domain that is not a PSD.
>>
>> Why does this need a value at all?  Why can't the flag just be psd?
>>
>> [snip]
>>
>> All that's needed is to strike "with a value of 'y'" from the second
>> sentence.
>>
>> I think this is simpler and clearer.
>>
>>
>I don't disagree that it's simpler and clearer. However, expressing it as
>psd=(y|n) was chosen to be consistent with the expression of every other
>tag currently defined for DMARC records, all of which "follow the
>extensible "tag-value" syntax for DNS-based key records defined in DKIM" as
>declared in section 5.3, General Record Format.
>
>This doesn't mean we can't break new ground here, but doing so would
>require rewriting the beginning of section 5.3, as well.

Unless there's a valid reason for someone to publish PSD=no, I don't think it 
should exist and I can't think of a reason.  If you give people a knob, someone 
will turn it [if we leave it in, I guarantee you there will be things written 
about how essential it is to have psd=no in your DMARC record].

Good point about section 5.3.  The ABNF would need changing too.  I can provide 
a patch for the change if you would like.

Scott K

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

Re: [dmarc-ietf] dmarcbis-04, 5.5. Domain Owner Actions

[Todd Herr]

On Mon, Dec 6, 2021 at 7:45 AM Alessandro Vesely  wrote:

> Hi,
>
> I have a few nits about this section:
>
> This section describes Domain Owner actions to fully implement the
> DMARC mechanism.
>
> Actually, the section doesn't mention DMARC checking, adhering to policies
> found in DMARC records, and sending feedback reports.  Hence I'd strike
> "fully".  It describes sender side actions.
>
>
"fully" was left over from a previous attempt to address
https://trac.ietf.org/trac/dmarc/ticket/66

It will be stricken from the next rev.

>
> While it is possible to secure a DMARC pass verdict based on only SPF
> or DKIM, it is commonly accepted best practice to ensure that both
> authentication mechanisms are in place in order to guard against
> failure of just one of them.
>
> SPF normally fails on forwarding.  Should we mention that?
>

I don't know if it's necessary. SPF breaking due to forwarding is a
well-known condition, and I don't think it has to be documented in every
text that mentions SPF.

For what it's worth, the introductory text to section 5 and the text in
Appendix B.3.1 both hint at forwarding causing authentication problems.

>
>
>   The Domain Owner SHOULD choose a DKIM-
> Signing domain (i.e., the d= domain in the DKIM-Signature header)
> that aligns with the Author Domain and configure its system to sign
> using that domain, to include publishing a corresponding DKIM public
> key in DNS.
>
> Maybe it's me, but I cannot understand "to include" in the last phrase of
> that
> sentence.
>
>
This was a ham-fisted attempt on my part to mimic text from the preceding
paragraph on SPF.

Section 5.5.1, Publish an SPF Policy for an Aligned Domain, includes this
sentence:

"As a first step the Domain Owner SHOULD choose a domain to use as the
RFC5321.MailFrom domain (i.e., the Return-Path domain) for its mail, one
that aligns with the Author Domain, and then publish an SPF policy in DNS
for that domain."


So, in Section 5.5.2, Configure Sending System for DKIM Signing Using an
Aligned Domain, I was going for similar phrasing to express the idea "Do
the authentication stuff, and publish something in DNS to make it work."

I'll have to think about how to word that better.


>Should any overlooked systems be found in the
> reports, the Domain Owner can adjust the SPF record and/or configure
> DKIM signing for those systems.
>
> I'd s/overlooked systems/failures/, since surprises can also arise from
> systems
> that the Domain Owner considered to have been set up well.
>

How about:

"Should any authentication failures for systems under the Domain Owner's
control be found in the reports, the Domain Owner can adjust the SPF record
and/or configure DKIM signing for those systems."

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*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] Best Guess SPF should not be deprecated.

[Todd Herr]

On Sat, Dec 4, 2021 at 5:35 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I have multiple objections to this paragraph in section 5.7.2
>
> "Heuristics applied in the absence of use by a Domain Owner of either SPF
> or DKIM (e.g., [Best-Guess-SPF
> 
> ]) SHOULD NOT be used, as it may be the case that the Domain Owner wishes
> a Message Receiver not to consider the results of that underlying
> authentication protocol at all."
>
> [snip]
>
>
> I think this text was inserted because of an open ticket when discussion
> was going nowhere and a new draft was created.  Perhaps the originator of
> that ticket can elaborate on his thinking.
>
>
To be clear, the text at issue is present in RFC 7489, Section 6.6.2.

That doesn't make it immutable, of course...
-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*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

[dmarc-ietf] dmarcbis-04, 5.5. Domain Owner Actions

[Alessandro Vesely]

Hi,

I have a few nits about this section:

   This section describes Domain Owner actions to fully implement the
   DMARC mechanism.

Actually, the section doesn't mention DMARC checking, adhering to policies 
found in DMARC records, and sending feedback reports.  Hence I'd strike 
"fully".  It describes sender side actions.



   While it is possible to secure a DMARC pass verdict based on only SPF
   or DKIM, it is commonly accepted best practice to ensure that both
   authentication mechanisms are in place in order to guard against
   failure of just one of them.

SPF normally fails on forwarding.  Should we mention that?


 The Domain Owner SHOULD choose a DKIM-
   Signing domain (i.e., the d= domain in the DKIM-Signature header)
   that aligns with the Author Domain and configure its system to sign
   using that domain, to include publishing a corresponding DKIM public
   key in DNS.

Maybe it's me, but I cannot understand "to include" in the last phrase of that 
sentence.



  Should any overlooked systems be found in the
   reports, the Domain Owner can adjust the SPF record and/or configure
   DKIM signing for those systems.

I'd s/overlooked systems/failures/, since surprises can also arise from systems 
that the Domain Owner considered to have been set up well.



Best
Ale
--








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

Re: [dmarc-ietf] 3.2.6. Non-existent Domains

[Douglas Foster]

Scot raises a valid concern, which calls for a counterproposal, not an end
to discussion.I can propose one, but I wonder what the group thinks.

Building on other comments, the strict needs this additional logic:

DMARC Policy and the NP test
--
Existence of an exact-match DMARC record is definitely evidence that the
domain name exists for purposes of the NP test.   This is not an extra DNS
lookup, since the tree walk has to occur every time anyway.   The evaluator
simply needs to remember whether an exact-match policy was found.

A domain-level DMARC policy can solve my concern about domain names that
are currently not in DNS but are used for mass mailings.   The domain owner
who wishes to enable the NP test must create a domain-level DMARC policy
for any name that cannot satisfy the "existence" test by some other
method.

DKIM Public Keys and the NP test
--
A domain also exists if a message has an unverified DKIM signature that (a)
has a key published for the scope ID, and (b) is an exact-match for the
mail domain name.   Of course, If the signature verifies, the result will
be DMARC PASS and the NP test will be ignored.

If the signature does not have a public key, then the failed signature may
be spoofed so it is ignored for purposes of the NP test.The name may
still be non-existent

I don't think there is any way to answer the more general question, "Does
this domain have at least one DKIM public key?"

Invalid Names
---
A PSD name is always invalid, with or without a DMARC policy found.
A name where any segment starts with an underscore is always invalid, with
or without a DMARC policy found.

Doug Foster


On Sun, Dec 5, 2021 at 7:01 PM Scott Kitterman  wrote:

>
>
> On December 5, 2021 9:54:42 PM UTC, Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
> >It is a relief to finally have this topic open for discussion.  The issues
> >go deeper than null MX.
> >
> >The goal is to domain names that the domain owner never uses for
> >RFC5321.From addresses.   No direct test exists, so there are two
> candidate
> >substitutes:
> >- (Relaxed:)  A name is rejected if it does not exist in DNS, so a lookup
> >returns NXDOMAIN.   An example would be "u...@junk.junk.ietf.org"
> >- (Strict:)  The name is not used for SPF mail.An example would be "
> >u...@www.ietf.org"
> >
> >There are problems with either of these, so a domain which intends to
> >publish an np=reject policy will need to take measures to ensure
> compliance
> >before publishing an NP=REJECT policy.
> >
> >The MX/A/ test is a version of the strict test, so it needs to be
> >addressed first.  The most  obvious problem is the omission of SPF.
> >There have been some assertions that SPF can be omitted because any domain
> >which sends mail must be configured to also receive it.This is an
> >assertion which is difficult to defend.  A mail message can obtain both
> SPF
> >PASS and DMARC PASS based on SPF alignment, without having a valid MX
> >record.  We are all receiving no-reply messages, so we should not be
> >surprised at the existence of no-reply domains.   Therefore the existence
> >of a valid SPF record must be evidence that the domain exists for purposes
> >of the Strict test.
> >
> >The second problem is the inclusion of A/ as a test of SMTP usage.   I
> >suspect that there are relatively few DNS names which do not contain a
> host
> >record, so including A/AAA in the strict version of an existence test is
> >essentially reducing it to a relaxed test.But this is not necessary.
> > We can assume that a domain which wants to use NP=REJECT is willing to
> >exert some effort to make this test useful.  Requiring domain owners to
> >complete the migration from Implicit MX to Explicit MX is a very small ask
> >with a very big payback.   Therefore, A/ should be dropped from the
> >Strict test.   Domains that do not wish to migrate to explicit MX can
> >choose not to publish NP=REJECT.
> >
> >A third problem is the one that Scott introduced:   If a domain has one or
> >more MX records, but none of them can be resolved to a public IP address,
> >then the existence of the MX record indicates that the name is NOT used
> for
> >receiving mail.   Similarly, an SPF record of "-ALL" indicates that the
> >name is not used for sending mail.   For purposes of the Strict test,
> >invalid MX is equivalent to no MX, and SPF "-ALL" is equivalent to no SPF.
> >
> >The fourth problem involves domain names that are only used for mass
> >mailings from service providers, where the service provider domain is used
> >for SMTP.  The FROM address domains on such mailings have no need to exist
> >in DNS, and we have had no difficulty finding examples of this occurring.
> >  This problem affects both relaxed and strict tests.For domain owners
> >with subdomains that fit this situation, we need to provide a way to
> create
> 

Re: [dmarc-ietf] Reversing modifications from mailing lists

[Alessandro Vesely]

On Sun 05/Dec/2021 20:55:30 +0100 Wei Chuang wrote:

On Wed, Dec 1, 2021 at 3:45 AM Alessandro Vesely  wrote:

On Tue 30/Nov/2021 18:30:39 +0100 John R Levine wrote:

On Tue, 30 Nov 2021, Wei Chuang wrote:

What about adding a footer to some html mime part is poorly handled when
using "l="?  Multipart bodies could be handled by other techniques.


See section 8.2 in the DKIM spec which says if you use l= you need to
be careful with your MIME boundaries so naughty people can't add another
part that overlays the real message. >

Agreed there's risk in HTML hiding content and showing malicious things but
that risk has existed before.  An updated DKIM authenticator could help us
understand who did those malicious updates along some forwarding path.



ARC can do better for such kind of forensic analysis.



[...]  Hence I retract what I said in my previous message[*], that l=
works well with a wide range of mailing lists. >

Could a way of dealing with "l=" is extending the list-canon
 ideas
of identifying signatures by mime-parts into identifying length as well?
In other words, with list-canon each part generates a hash, and similarly
each part can have a length of the content in that part that is claimed.
It also records the content-type for each part.  I'm going to guess that
this is to help identify changes like what I believe you are concerned
with.



Those ideas have been ruminated for a while.  See also
https://datatracker.ietf.org/doc/html/draft-crocker-dkim-doseta-00
https://datatracker.ietf.org/doc/html/draft-vesely-smooth-canon-00

In fact, at this point DKIM is what it is, for the good and the bad of it.


Anyway, I wouldn't want to authenticate a message that underwent an HTML 
footer addition, because it can completely replace the original content in

the end recipient's eyes.  My draft requires footers to be plain text.


I was looking at the footers that Googlegroups puts in, and it seems to add
them to both the text/plain and text/html parts.  At least one IETF mailing
list adds a new mime-part with text/plain.  BTW has someone cataloged all
these possible mailing list changes?



Wikipedia has a list of ten software packages, dunno if it's complete:
https://en.wikipedia.org/wiki/List_of_mailing_list_software
It doesn't dig into their peculiarities.

Mailing lists existed before computers, and are not regulated by strict rules, 
so trying to harness their behavior holds little water.  For example, it is 
customary these days to have discussion fora backed by mailing lists, where 
messages arrive with a From: display name referring to a user while the address 
part points to the forum server.  In that case, the user most likely typed the 
text in a web page, so the From: is not /re/-written, it's written that way 
from the start.  Although those messages have parts that were not written by 
the user, it is not possible to catalogue the changes.  And not even ARC can 
handle such messages in a way that would results in a From: address pointing to 
the real author.



Best
Ale
--





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

Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5

[Alessandro Vesely]

On Sat 04/Dec/2021 22:30:30 +0100 Murray S. Kucherawy wrote:

On Fri, Dec 3, 2021 at 10:38 AM Todd Herr 
The sentence should read something like this:

Percentage of messages using the Domain Owner's domain and failing DMARC
authentication checks to which the DMARC policy is to be applied.


I'd be happy with either of these two definitions:

(a) All messages are subjected to DMARC checking, and "pct" identifies the
percentage of messages failing the check that should be subjected to the
policy;

(b) "pct" identifies the percentage of messages subjected to the DMARC
check, irrespective of the outcome.



I implemented (a), and don't understand how (b) can make sense given:

   However,
  this MUST NOT be applied to the DMARC-generated reports, all of
  which must be sent and received unhindered.

In order to compile DMARC result into the report one must first evaluate it.

Besides, after checking SPF and DKIM, the cost of evaluating DMARC boils down 
to compare two strings for alignment.



Best
Ale
--








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

Re: [dmarc-ietf] Reversing modifications from mailing lists

[Murray S. Kucherawy]

On Sun, Dec 5, 2021 at 12:24 PM John R Levine  wrote:

> I'm pretty sure that changing DKIM is very out of scope for this working
> group.
>

As I read the charter, I don't agree.  It says in at least two places that
this could be in scope.

Whether the chairs want the WG to engage in such work right now is another
matter.

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