Re: [dmarc-ietf] DMARC WG Interim meeting Proposal -- request for group feedback on timing and participation

[Kurt Andersen (b)]

Yes, I will participate and the proposed timing is fine.

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

Re: [dmarc-ietf] NXDOMAIN

[Kurt Andersen (b)]

On Thu, Apr 8, 2021 at 5:02 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

>
> "IETF is interested in attacks of the form
> 'otherdomain.nonexistentdomain.psd', but IETF is not interested in attacks
> of the form 'nonexistentdomain.otherdomain.psd'.
>

I don't understand your assertion here. Non-existent domains under existing
org domains are already covered by the org-level DMARC policy assertion.
5322.From domain of nosuchdomain.example.com would be treated in accord
with the policy for example.com.

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

Re: [dmarc-ietf] Sender vs From Addresses

[Kurt Andersen (b)]

On Wed, Mar 24, 2021 at 3:25 PM Charles Gregory 
wrote:

>
> Has anyone considered an option to add "affiliated domains" to a DNS
> entry?  That way at least you could specify legitimate alternate/authorized
> domains that could still pass DMARC.
>

Yes, but no technically and operationally sound solution has yet achieved
consensus.

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

Re: [dmarc-ietf] Sender vs From Addresses

[Kurt Andersen (b)]

On Wed, Mar 24, 2021 at 1:21 PM John Levine  wrote:

> It appears that Gren Elliot   said:
> >For better or worse, there is long established practice in the
> Calendaring community when implementing iMIP (rfc6047) when an
> >assistant is working on behalf of a manager for the manager’s email
> address to populate the “From:” header and the
> >assistant’s email address to populate the “Sender:” header.
>
> DMARC only looks at the domain part of the From header.  How often do the
> manager and assistant have e-mail addresses that
> are not in the same domain?
>

John,

This goes back to your Roman Empire scenario. It's not necessarily common,
but it isn't unheard of for domain mismatches especially in the case of
acquisitions or other corporate structuring changes.

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

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-11.txt

[Kurt Andersen (b)]

On Sun, Mar 21, 2021 at 3:04 PM Tim Wicinski  wrote:

>
> In Section 1.1 "Example"
>
> OLD
>
>Defensively registering all variants of "tax" is obviously not a
>scalable strategy.  The intent of this specification, therefore, is
>to enhance the DMARC algorithm by enabling an agent receiving such a
>message to be able to determine that a relevant policy is present at
>"gov.example", which is precluded by the current DMARC algorithm.
>
>
> NEW
>
>Defensively registering all variants of "tax" is obviously not a
>scalable strategy.  The intent of this specification, therefore, is
>to enhance the DMARC discovery method by enabling an agent receiving
>such a message to be able to determine that a relevant policy is
>present at "gov.example", which is precluded by the current DMARC
>specification.
>

Tim,

I still think that including the term "obviously" in the first sentence of
this snippet is a pejorative judgemental statement which is out of place in
a specification. Especially given that there are alternatives to
"registering" any such domains at all via the use of "trick" DNS servers at
the PSD level.

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

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-11.txt

[Kurt Andersen (b)]

Good work on the updated phrasing, I'd make just a couple of changes to the
"tax" suggestion:

On Fri, Mar 19, 2021 at 9:28 AM Alessandro Vesely  wrote:

>
> *Example*
>
> Since the algorithm (last word) hasn't been mentioned yet:
>
> OLD
> Defensively registering all variants of "tax" is obviously not a
> scalable strategy.  The intent of this specification, therefore, is
> to enhance the DMARC algorithm by enabling an agent receiving such a
> message to be able to determine that a relevant policy is present at
> "gov.example", which is precluded by the current DMARC algorithm.
>
>
> NEW
> Defensively registering all variants of "tax" is obviously not a
> scalable strategy.  The intent of this specification, therefore, is
> to enhance DMARC discovering method by enabling an agent receiving
> such a
> message to be able to determine that a relevant policy is present at
> "gov.example", which is precluded by the current DMARC specification.
>

1 - delete the word "obviously". I really don't think such a statement
belongs in a spec and can lead us down infinite rabbit trails.
2 - s/DMARC discovering/DMARC discovery/

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

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Kurt Andersen (b)]

This is getting much better - thanks for all the wordsmithing. I have one
nuance to add...

On Thu, Feb 25, 2021 at 6:13 AM Dave Crocker  wrote:

>
> The suggested revisions to Barry's suggested revisions, below, primarily
> serve to reference the PSD construct without needing to reference the
> PSL.  And, of course, there are various other suggested wording tweaks...
>
> EVEN NEWER
> Domain-based Message Authentication, Reporting, and
> Conformance (DMARC) permits a mail-originating
> organization to express domain-level policies and preferences for
> message validation, disposition, and reporting, which a mail-receiving
> organization can use to improve mail handling.
>

Especially in the case of the PSD policies, one should not expect that the
controlling organization would necessarily be "a mail-originating
organization". Generally the idea is to *disavow* being such :-)

Suggested alternate text:

Domain-based Message Authentication, Reporting, and Conformance (DMARC)
permits a domain-controlling
organization to express domain-level policies and preferences for message
validation, disposition, and reporting,
which a mail-receiving organization can use to improve mail handling.

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

Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns

[Kurt Andersen (b)]

On Thu, Feb 18, 2021 at 7:09 AM Ken O'Driscoll  wrote:

>
> . . . I'd propose something like the below, which I think gets across what
> we all want to say.
>
> ===
> Aggregate feedback reports contain anonymized data relating to messages
> purportedly originating from the Domain Owner. The data does not contain
> any identifying characteristics about individual senders or receivers. No
> personal information such as individual email addresses, IP addresses of
> individuals, or the content of any messages, is included in reports.
>
> Mail Receivers should have no concerns in sending reports as they do not
> contain personal information. In all cases, the data within the reports
> relates to the authentication information provided by mail servers sending
> messages on behalf of the Domain Owner. This information is necessary to
> assist Domain Owners in implementing and maintaining DMARC.
>
> Domain Owners should have no concerns in receiving reports as they do not
> contain personal information. The reports only contain aggregated
> anonymized data related to the authentication details of messages claiming
> to originate from their domain. This information is essential for the
> proper implementation and operation of DMARC. Domain Owners who are unable
> to receive reports for organizational reasons, can choose to exclusively
> direct the reports to an external processor.
> ===
>

With a s/anonymized/aggregated/g change, this seems like reasonable
language. In technical terms, there is no anonymization involved. The only
other issue might be some ambiguity in the intepretation of the term
"individual senders or receivers" because the IP addresses of the MTAs
involved in the email interchange are definitely in the report. As someone
has pointed out earlier in the thread, a compromised home computer which is
able to send out on port 25 would indeed be exposed in such a scenario,
though it is a rare case.

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

Re: [dmarc-ietf] Ticket #1 - SPF alignment

[Kurt Andersen (b)]

On Wed, Feb 10, 2021 at 6:43 AM Scott Kitterman 
wrote:

> No.  Sigh.  Let's try it again.
>
> Yes, one might actually use a HELO result for DMARC.  It gives you the
> same
> result as if mail from is null.  So what?
>
> No one has given us a case where an attacker could get a aligned SPF
> result
> based on HELO that they couldn't also get with mail from, so it doesn't
> matter.
>
> By problem, I mean an actual problem.  There aren't any.
>
> Scott K
>

The other issue that people who are continuing this thread are ignoring is
that changing 7208 is out of scope for this WG.

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

Re: [dmarc-ietf] Ticket #1 - SPF alignment

[Kurt Andersen (b)]

On Sat, Feb 6, 2021 at 11:53 AM Dotzero  wrote:

>
> On Thu, Feb 4, 2021 at 11:43 AM John R Levine  wrote:
>
>> I really do not see anything to change here, and we have a lot of other
>> tickets to work on.  Please, can we stop and close this one?
>>
>
> +1 Could we have a show of consensus on closing this.
>

+1 - now, if only we had a real voting system :-P

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

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

[Kurt Andersen (b)]

On Fri, Jan 29, 2021 at 6:52 AM Tim Wicinski  wrote:

>
> I suggest adding it to this paragraph:
>
>This document specifies experimental updates to the DMARC and PSL
>algorithm cited above, in an attempt to mitigate this abuse.
>

update to DMARC = yes; update to PSL = no


> On Fri, Jan 29, 2021 at 1:44 AM Murray S. Kucherawy 
> wrote:
>
>> On Fri, Jan 22, 2021 at 5:01 PM Tim Wicinski  wrote:
>>
>>> Since this is an experiment, Appendix A discusses the updates that
>>> happen.  we don't actually say explicitly "if the experiment is a success,
>>> the following changes will be made" and perhaps I should add some wording
>>> like that.
>>>
>>
>> Something like this, perhaps?
>>
>> "A standards track update to [RFC7489] will take into account the results
>> of this experiment."
>>
>> ... somewhere in Section 1.
>>
>
A normative dependency from an experimental spec imposed upon a standards
track spec seems like a bad idea to me. At the very least it would impose a
timing constraint that DMARCbis could not be "completed" until after the
PSD experiment is "completed", analyzed and consensus achieved.

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

Re: [dmarc-ietf] Ticket #55, closing

[Kurt Andersen (b)]

On Mon, Jan 25, 2021 at 10:05 AM John Levine  wrote:

> In article <63451726-124b-c24f-3be1-d6435e12c...@tana.it> you write:
> >OLDER:
> >These reports SHOULD include the "call-to-action" URI(s) from inside
> >messages that failed to authenticate.
>

The intent of calling out CTA links was to facilitate takedown efforts
against fraudulent domains rather than being strictly concerned about why
otherwise valid messages failed to authenticate.

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

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

[Kurt Andersen (b)]

On Fri, Jan 22, 2021 at 4:57 PM Murray S. Kucherawy 
wrote:

> On Fri, Jan 22, 2021 at 4:55 PM Kurt Andersen (b) 
> wrote:
>
>> On Fri, Jan 22, 2021 at 3:06 PM Tim Wicinski  wrote:
>>
>>>
>>> Here's the paragraph in question
>>>
>>>  To determine the organizational domain for a message under
>>> evaluation,
>>> and thus where to look for a policy statement, DMARC makes use
>>> of a Public Suffix
>>> List. The process for doing this can be found in Section 3.2 of
>>> the DMARC
>>> specification.
>>>
>>
>> The concern that I have with this wording is that it is (potentially)
>> misleading. "How" DMARC determines the org domain does not matter at all to
>> this spec. The important point is that we go to "org-1" in the tree for
>> this extra lookup.
>>
>
> This is just establishing context for why we're doing what the rest of the
> document says (i.e., what problem we're solving).  Leaving this out seems
> to me to paint an incomplete picture; Section 3 basically describes a
> delta, but a delta to what?
>

And if DMARC changes how it determines the org domain, where does that
leave this spec?

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

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

[Kurt Andersen (b)]

On Fri, Jan 22, 2021 at 3:06 PM Tim Wicinski  wrote:

>
> Here's the paragraph in question
>
>  To determine the organizational domain for a message under
> evaluation,
> and thus where to look for a policy statement, DMARC makes use of
> a Public Suffix
> List. The process for doing this can be found in Section 3.2 of
> the DMARC
> specification.
>

The concern that I have with this wording is that it is (potentially)
misleading. "How" DMARC determines the org domain does not matter at all to
this spec. The important point is that we go to "org-1" in the tree for
this extra lookup.

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

Re: [dmarc-ietf] Forensic report loops

[Kurt Andersen (b)]

On Thu, Jan 14, 2021 at 7:28 AM Murray S. Kucherawy 
wrote:

> On Thu, Jan 14, 2021 at 3:12 AM Дилян Палаузов 
> wrote:
>
>> I have not read the thread “Ticket #28 - Failure report mail loops”.
>>
>
> Thanks, and apologies to the group; I should've checked for an open ticket
> on this topic first.
>
> This one recommends rate limiting rather than simpler "don't" type
> guidance.  I think we can table this until that ticket is open.
>
> A possible approach is not to send failure reports for messages
>> received on the address for accepting aggregate/forensic reports.
>> These messages shall just be excluded from all calculations.
>>
>
> That seems plausible, though less bulletproof than simply using the
> address already reserved by the email standard for administrative messages.
>

I thought that we discussed that ticket and decided that the incidence of
problems was low enough to warrant a "WONT FIX" determination.

https://mailarchive.ietf.org/arch/browse/dmarc/?gbt=1=W3uGPEpT3Yi5lqKntZXyL8jkNjk

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

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[Kurt Andersen (b)]

On Tue, Jan 5, 2021 at 10:18 AM Paypal security confirm your password now <
jo...@taugh.com> wrote:

> >> reputation for the domain. I have trouble imagining why anyone would
> >> think it's a good idea to get alignment by using third party domains
> >> that recipients don't know.
> >
> > Because recipients often can’t see (or don’t pay attention to) the
> domain
> > name and the reputation system you postulate doesn’t exist. OTOH,
> getting
> > alignment avoids a restrictive policy that might be associated with the
> > original domain.
>
> I think you're saying that I can always evade DMARC problems by putting an
> address I control on the From line and nobody will notice.  That would
> mean that DMARC is useless.
>
> If that's not what you're saying, could you clarify?
>

That is indeed the assertion - as long as you consider 97+% to be "always"
and interpret "nobody" in terms of real human actors (excluding the
automatons on this list) and discount the influence of receiver-level
reputation/filtering mechanisms. Personally, I think those levels of
rounding errors should not be ignored either for good or evil. The
formation of this working group and our initial deliverables provides some
level of concurrence with my personal perspective.

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

Re: [dmarc-ietf] auth-res vs. dmarc

[Kurt Andersen (b)]

On Tue, Dec 29, 2020 at 5:31 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

>
> DKIM, A-R, and ARC should all have a mandatory attribute indicating the
> HELO name of the server applying the header, the IP Address of the previous
> server which supplied the information being evaluated, or both.
>

With all due respect, it seems to me like this is something which should
have been pointed out before this WG came to final consensus on 8601 (aka
7601bis). A-R and AAR were not designed to be fed into a determinative
state machine.

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

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[Kurt Andersen (b)]

On Wed, Dec 23, 2020 at 10:10 AM John R Levine  wrote:

> On Wed, 23 Dec 2020, Ned Freed wrote:
> >  Failure reports provide detailed information about the failure of a
> single
> >  message or a group of similar messages failing for the same reason. They
> >  are meant to aid in cases where a domain owner is unable to detect why
> >  failures reported in aggregate form did occur. It is important to note
> >  these reports can contain either the header or the entire content of a
> >  failed message, which in turn may contain personally identifiable
> >  information, which should be considered when decoding whether or not to
> >  generate such reports.
>
> Ship it.
>

With one minor correction, I agree. The minor correction is in the last
sentence: s/decoding/deciding/

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

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[Kurt Andersen (b)]

On Tue, Dec 22, 2020 at 11:00 AM Alessandro Vesely  wrote:

>
> Making specifications that cannot be legally abided by is in IETF scope?
>

Sure - RFC 7258. Unless you want to play the semantic card of BCP vs.
specification.

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

Re: [dmarc-ietf] p=quarantine

[Kurt Andersen (b)]

On Thu, Dec 10, 2020 at 6:26 PM Dave Crocker  wrote:

> On 12/10/2020 6:01 PM, Kurt Andersen (b) wrote:
> > I think that is much closer to the right semantic but highlights a
> > problem that the mail coming from a particular domain probably doesn't
> > rate a single broad-brush characterization of seriousness.
>
> I've assumed the none, quarantine, reject choices are meant to indicate
> just how certain the domain owner is that the mail is problematic.
>
> Perhaps:
>
>  none: not certain at all
>
>  quarantine: I believe I've got control of all my sending, but am
> not 100% positive
>
>  reject: I have control of all my sending; if it doesn't pass DMARC,
> it's use of the domain is bogus.
>

But the problem case in our off-topic rabbit trail meanderings is that
people who "have control of all their sending" still don't necessarily send
mail of consistent seriousness nor do they have any control of the paths by
which that mail takes to get to the ultimate recipient. There is a
conflation of "control of emission" with "control of path".

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

Re: [dmarc-ietf] p=quarantine

[Kurt Andersen (b)]

On Thu, Dec 10, 2020 at 5:03 PM Dave Crocker  wrote:

> On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote:
>
> to quibble with the "*unauthorized use*"  situation. This situation
> devolves into use-as-imagined vs. use-as-really-used when one considers
> various intermediary scenarios.
>
> (to respond to the content...)
>
> So, the driving issue is that it's characterizing problematic usage; use
> that did not achieve a DMARC pass.
>
> And, yeah, that doesn't mean the use was unauthorized, given the other
> possible explanations for failure.
>
> So, without suggesting a label, I'd describe this factor as "how serious
> is a failure to get a DMARC pass"?  If that's the right semantic, what's a
> reasonable label to use?  If it's not the right semantic, what is?
>
I think that is much closer to the right semantic but highlights a problem
that the mail coming from a particular domain probably doesn't rate a
single broad-brush characterization of seriousness.

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

Re: [dmarc-ietf] p=quarantine

[Kurt Andersen (b)]

On Wed, Dec 9, 2020 at 10:09 AM Dave Crocker  wrote:

> It might be worth a bit of thinking about what, exactly, DMARC can
> reasonably do and how it should be summarized, for popular consumption:
>
> *Alignment - *DMARC defines a basis for authenticating use of the domain
> name in the rfc5322.From addr-spec.  (But nothing else in that header field
> or elsewhere in the message, neither header nor body.
>
> *Severity of unauthorized use - *DMARC provides a means of indicating to
> receivers how serious the domain owner considers unauthorized use of that
> domain name to be.
>
> *Reporting -* DMARC defines a mechanism for reporting DMARC-related
> activity by a receiver
>
> I've tried to state each of these precisely and accurately, in terms of
> real-world pragmatics.
>
These seem like a good starting point, but I'd have to quibble with
the "*unauthorized
use*"  situation. This situation devolves into use-as-imagined vs.
use-as-really-used when one considers various intermediary scenarios. Does
a domain owner really have the prerogative to define recipient behaviour as
"unauthorized"?

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

Re: [dmarc-ietf] dmarc - New Meeting Session Request for IETF 110

[Kurt Andersen (b)]

I'm wondering why we should wait for IETF110 rather than having an interim
meeting sooner. Interim meetings are also likely to garner greater
participation since they do not include participation fee. If there are
topics worthy of F2F discussion, why wait? If there are not, then why
charge people to join a pointless meeting?

--Kurt

On Tue, Dec 8, 2020 at 10:25 AM IETF Meeting Session Request Tool <
session-requ...@ietf.org> wrote:

>
>
> A new meeting session request has just been submitted by Alexey Melnikov,
> a Chair of the dmarc working group.
>
>
> -
> Working Group Name: Domain-based Message Authentication, Reporting 
> Conformance
> Area Name: Applications and Real-Time Area
> Session Requester: Alexey Melnikov
>
>
> Number of Sessions: 1
> Length of Session(s):  1 Hour
> Number of Attendees: 76
> Conflicts to Avoid:
>  Chair Conflict: dnsop dprive cfrg kitten emailcore
>  Technology Overlap: saag uta extra jmap cbor
>
>
>
>
>
>
> People who must be present:
>   Alexey Melnikov
>   Murray Kucherawy
>   Tim Wicinski
>   Seth Blank
>
> Resources Requested:
>
> Special Requests:
>
> -
>
>
> ___
> 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] ARC vs reject

[Kurt Andersen (b)]

On Sun, Dec 6, 2020 at 10:46 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

>
> I ask the chairs to formally endorse development of an alternative to ARC
> as an additional approach to the mailing list problem...
>

So you are asking the WG to go back to our second milestone and put the
current work on milestone 3 on hold?

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

Re: [dmarc-ietf] ARC vs reject

[Kurt Andersen (b)]

On Sat, Dec 5, 2020 at 5:21 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> ...much of this is about AOL in particular, and the currently available
> information suggests that AOL is not on board with ARC.
>

I would point you to
https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-22#section-12.2
(note that per normal IETF procedure, section 12 is removed in the
editorial conversion from an I-D to an RFC).

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

Re: [dmarc-ietf] Ticket #1 - SPF alignment

[Kurt Andersen (b)]

On Sun, Dec 6, 2020 at 11:13 PM Murray S. Kucherawy 
wrote:

> On Tue, Dec 1, 2020 at 2:17 PM John R Levine  wrote:
>
>> We would like to close this ticket by Dec 15, two weeks from now, so
>> short
>> trenchant comments are welcome.
>>
>> Ticket #1 is about SPF alignment.  We need to replace references to 4408
>> with 7408, ando clarify what if anything we do with SPF HELO checks if
>> the MAIL FROM is null.  One possibility is to say only MAIL FROM SPF
>> counts, if you want to align your bounces, sign them.  The other is to
>> explicitly say that HELO alignment is OK on bounces.
>>
>
> I have a slight preference for the first option.  HELO is too arbitrary in
> the protocol for me to put much value in using it in any of these systems.
>

There's a bit of an implementation detail though. If one is relying on an
encapsulated ck_host() function then you may not know whether it checked
the HELO or the MAIL FROM. Imposing a requirement like this from DMARC
seems like it verges on a layering violation.

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

Re: [dmarc-ietf] is DMARC informational?

[Kurt Andersen (b)]

On Fri, Dec 4, 2020 at 2:51 PM Michael Thomas  wrote:

>
> What changed in the bis version to change its intended status?
>

The entire point of this working group (and the bis version that is in
progress) is to move DMARC into the fully-recognized "standards" track.
Note that even the current email specs are not "standards" in IETF parlance
(there's another WG addressing that). It's mostly organizational semantic
slicing-and-dicing.

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

Re: [dmarc-ietf] ARC questions

[Kurt Andersen (b)]

As usual, John has pretty well nailed the response, but there was one other
part of your question (Mike) that I thought deserved explanation:

On Sat, Nov 21, 2020 at 7:14 PM John Levine  wrote:

> In article  you write:
> >If I'm a receiver who is going to be making some filtering decisions
> >based on ARC, I see that it passed by some authenticator along the way
> >which is fine, but my question is why I should trust that intermediary
> >in general?
>
> The short answer is that you shouldn't, any more than you should trust
> random DKIM signatures.
>
> This also means that ARC isn't useful if you don't have a reputation
> system to tell you where the lists and other forwarders that might add
> legit ARC signatures are.
>

On Sat, Nov 21, 2020 at 2:33 PM Michael Thomas  wrote:

>
> Or did I miss where ARC resigns the body? Or is there a tie in for ARC
> with the mailing list's resigned DKIM signature for the new message?
>

The ARC-Message-Signature (referred to as the AMS) includes a signature
over the newly modified message (headers & body) in a way very similar to a
DKIM-Signature. But this does not solve the problem of a malicious
forwarder that does a wholesale replacement of the (presumably) good
content with spam. That's were your own reputation and content analysis has
to come in.

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

Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

[Kurt Andersen (b)]

On Fri, Nov 20, 2020 at 5:57 AM Doug Foster  wrote:

>
> However, spoofing of non-existent subdomains is a potential problem for the
> RFC5321.MailFrom domain, which then becomes an attack vector for the
> RFC5322.From address as well.  The problem exists because because SPF has
> no
> organizational default.
>
> We need to think about intermediate nodes, non-mail leaf nodes, and
> non-existent subdomains.  Assume that a spammer tries to spoof a legitimate
> organization by using a non-mail  or non-existing node for both the SMTP
> MailFrom address and the message From Address.   The message will be
> evaluated as
> - SPF=None,
> - DomainAligned=True, and
> - (if checked by some unknown algorithm)  OrganizationReputation=good.
>
>

Presuming no DKIM signature is involved, SPF=None is not the required
"PASS" that DMARC enforces so I don't see the point of your argument.

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

Re: [dmarc-ietf] IETF 109 possible agenda/session discussion

[Kurt Andersen (b)]

+1 to being able to sleep through the night and deal with issues
asynchronously on the list.

--Kurt

On Tue, Nov 17, 2020 at 12:10 PM Dotzero  wrote:

> Considering that some of us have to be up in the wee hours to participate,
> it would be nice to know whether it is happening or cancelled. Just saying.
> If the agenda is that light weight I may skip it even if held.
>
> Michael Hammer.
>
> On Tue, Nov 17, 2020 at 2:35 PM Dave Crocker  wrote:
>
>> On 11/16/2020 10:46 PM, Murray S. Kucherawy wrote:
>> > I'm discussing this with the chairs and they or I will get back to you
>> > shortly.
>>
>>
>> Forgive me, but this is all a bit nuts.
>>
>> Very few days before the scheduled session, we get a query about
>> canceling it, though the query also included a fresh, 'lightweight'
>> agenda.
>>
>> A couple of responses are posted, stating a preference for cancellation,
>> with no immediate responses choosing having the meeting (though today,
>> some have).
>>
>> We are now less than 12 hours from the scheduled time and still have not
>> received a definitive decision by the chairs.
>>
>> d/
>>
>> --
>> Dave Crocker
>> Brandenburg InternetWorking
>> bbiw.net
>>
>> ___
>> 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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Sun, Nov 15, 2020 at 12:21 PM John Levine  wrote:

> In article  wm5wltcgib0jby0gubntop3qhzfr68yb2__r...@mail.gmail.com> you write:
> >
> https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08=draft-ietf-dmarc-psd-09
> >
> >Please review the changes and offer up comments to the working group.
>
> I looked at it, seems fine as an experiment.
>
> If we end up changing the way regular DMARC looks for Org domains, PSD
> might become redundant. Or not.


+1 on both counts.

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

Re: [dmarc-ietf] IETF 109 possible agenda/session discussion

[Kurt Andersen (b)]

On Fri, Nov 13, 2020 at 10:41 AM Tim Wicinski  wrote:

>
> All
>
> During the chairs call this morning we were discussing the upcoming
> meeting.  Now Seth has a conflict with the meeting time that can't be
> altered.   Since work items have been progressing rather well recently, and
> the editors are in positing, we discussed canceling the meeting.  We wanted
> to get some feedback from the working group.
>
> Here is a lightweight agenda Seth put together.  Should we 1) have a
> meeting around these topics;  2) discuss other topics or 3) cancel the
> meeting and keep moving along.
>

I'd vote for 3. I think that it would be better to discuss/hash out these
topics on the list. Perhaps we could start each one with a cogent summary
of the issues related to the topic.

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

Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND

[Kurt Andersen (b)]

On Thu, Nov 12, 2020 at 2:58 PM Jesse Thompson  wrote:

> On 11/12/20 3:23 PM, John Levine wrote:
> > You now can put a DMARC
> > record on a name below the org domain to shadow a subtree, but I don't
> > think that is a problem that needs to be solved.
>
> I'm confused by this statement.  Are you saying that you can "now" do
> subtree shadowing with sp?  as in the following language is being changed
> "now"?
>

I think that John was referring the potential future state where tree-walks
were being done, but even then I don't think it would work quite that
easily. A record at "a.b.example" would not shadow "x.y.a.b.example" if "x"
or "y" chose to express some policy.

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

Re: [dmarc-ietf] Announcing DMARCbis Editors

[Kurt Andersen (b)]

On Thu, Nov 5, 2020 at 9:31 AM Alessandro Vesely  wrote:

> The consensus of the working group is to remove the
> normative constraint about p= (ticket #49).  So now only v= is required.
>

I must have completely misunderstood the discussion and will have to go
back and look up the thread. I thought that the discussion was strictly
about whether the "p=" phrase had to be the second phrase in the record.

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

Re: [dmarc-ietf] Subject: Call for Adoption: DMARC-bis

[Kurt Andersen (b)]

On Mon, Oct 26, 2020 at 2:59 PM Tim Wicinski  wrote:

>
> This starts a Call for Adoption for: DMARC-bis
>
> We'll be starting with the text from the RFC 7489.
> This is available here:
> https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-dmarcbis/
>
> Changes made so far have been to include the current Errata.
>
> Please review this draft, and we are looking for *objections to adoption*,
> and send comments to the list stating your objections.  The working group
> can pick over the document after adoption.
>

No objection to adopting this draft.

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

Re: [dmarc-ietf] DMARC bis: ticket 51: disposition reporting in aggregate reports

[Kurt Andersen (b)]

On Tue, Sep 29, 2020 at 3:50 PM Dave Crocker  wrote:

> On 9/29/2020 3:08 PM, Seth Blank wrote:
> > I don't know of any receiver that checks DMARC, but then doesn't check
> > alignment
>
> It's not a matter of field statistics:
>
>   Since checking alignment is an obvious part of the DMARC
> procedure, if someone does not follow the specification, they are not
> doing DMARC.
>

Does that mean that "none" is not an appropriate verdict?

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

Re: [dmarc-ietf] DMARC bis: ticket 51: disposition reporting in aggregate reports

[Kurt Andersen (b)]

On Tue, Sep 29, 2020 at 3:15 AM Alessandro Vesely  wrote:

>
> +1.  The rationale, AIUI, is that if the receiver successfully evaluated
> alignment, then "pass" is fine.  If the receiver didn't evaluate anything
> after
> it saw p=none, then "none" is fine.   and  should agree.
>

If a receiver does not check alignment, then "none" would be the right
report, regardless of DMARC policy in the DNS record. (One could argue for "
¯\_(ツ)_/¯" instead of none, but I don't know how interoperable that would
be)

If DMARC is fully evaluated, including alignment, then "pass" would be
better.

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

Re: [dmarc-ietf] DMARC bis: revisiting ticket 66

[Kurt Andersen (b)]

On Mon, Sep 28, 2020 at 8:47 PM Seth Blank  wrote:

> At a minimum, per Dave's comments here:
> https://mailarchive.ietf.org/arch/msg/dmarc/XXE3r5FUozl6LVohv8rTkn5QG4E/
> I still believe there's some clear consistent language that needs to be
> agreed upon to drive the appropriate specificity in the document.
>

+1 about clarifying the terminology and I'd second Steve Jones's point
about defining the terms in the RFC for consistent usage throughout both
the RFC and any usage-related BCPs.

Functionally, I think that we need to break down the actions of a receiver
(whether ultimate or intermediary) a bit more clearly:

   - "validate" = go through the process of determining a DMARC pass
   verdict (or not)
   - "enforce" = take some sort of action on the basis of DMARC results +
   policy (published + local)
   - "report" = send RUA (and possibly RUF) reports

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Kurt Andersen (b)]

On Mon, Sep 28, 2020 at 10:46 AM Dave Crocker  wrote:

> . . .given that 'disposing of' the message is a domain owner goal,
> frequently, perhaps changing "disposed of" to "processed" would be less
> inviting of misunderstanding?
>

Yes, I think that, at least in American English usage, "disposal" tends to
have a bit of a pejorative connotation.  Consider that in the context of
people who have to deal with truckloads of UCE and other bulk email and the
negative association becomes even stronger.

+1 to adjusting the terminology to be less biased.

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Kurt Andersen (b)]

On Sun, Sep 27, 2020 at 11:23 AM Scott Kitterman 
wrote:

> On Sunday, September 27, 2020 1:16:11 PM EDT John Levine wrote:
>
> Agreed.  Maybe it would help if someone who takes the latter view would
> explain what they think RFC 7489, Section 6.6.2, Step 6 is for:
>
> >6.  Apply policy.  Emails that fail the DMARC mechanism check are
> >disposed of in accordance with the discovered DMARC policy of the
> >Domain Owner.  See Section 6.3 for details.
>
> I don't think that says "then toss the results into your classifier".
>

You completely ignored section 6.7 (Policy Enforcement Considerations)
which states:

> Final disposition of a message is always a matter of local policy.

Local policy could be considered "the output of some classifier" or other
mechanics left to the invention of the receiver.

This is a part of the documented DMARC spec, not a change.

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

Re: [dmarc-ietf] DMARC bis: ticket 38: reporting the proper DKIM key(s)

[Kurt Andersen (b)]

On Wed, Sep 23, 2020 at 2:56 PM Seth Blank  wrote:

> The original question in this thread had two parts:
>
> "Is it desirable to clarify this language, [1] such that it is clear which
> DKIM keys are required to include in a report, and [2] if so, how should
> the appropriate keys be determined?"
>
> I hear consensus on [1], that the domain and selector of the key used to
> evaluate the DMARC status MUST be included, but on [2] there is not yet
> clear consensus.
>
> Does anyone have thoughts on [2] beyond Ale's comments? Otherwise, we can
> separate the conversation on [2] and return to it later.
>

Sounds like a good approach - I'd suggest forking [2] into a separate TRAC
issue and closing this one out with a pointer to the new "subissue".

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

Re: [dmarc-ietf] DMARC bis: ticket 51: disposition reporting in aggregate reports

[Kurt Andersen (b)]

On Thu, Sep 24, 2020 at 1:39 AM Murray S. Kucherawy 
wrote:

> On Sun, Jun 7, 2020 at 2:23 PM Seth Blank  40valimail@dmarc.ietf.org> wrote:
>
>> https://trac.ietf.org/trac/dmarc/ticket/51
>>
>> In a DMARC aggregate report, a record with a disposition of "none" is
>> ambiguous, as a disposition of "none" at p=none means a different thing
>> (that no action was taken on the message) than a disposition of "none" if
>> the DMARC policy is reject or quarantine (the message passed an aligned
>> authentication check of either SPF or DKIM, and was therefore not subject
>> to policy).
>>
>> It is desirable to have logically distinct disposition responses, and if
>> so, what should be reported in the latter case? As a straw man, "pass"
>> instead of "none"?
>>
>
> Given the choices, I like "pass".
>

+1 to pass - but I'd go further than Ale and use pass whenever the DMARC
evaluation passes regardless of the policy setting in the DMARC record.

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

Re: [dmarc-ietf] DMARC and Gateways?

[Kurt Andersen (b)]

A scenario that you did not list, but which used to be common was a mail
transit path that went both in and out of a foreign protocol. Consider the
example of a message that starts with SMTP --> X.400 (with irreversible
changes) --> SMTP --> recipient. If the inbound and outbound gateways are
not the same, then there is no way for the outbound gateway to simulate the
inbound one.

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

Re: [dmarc-ietf] DMARC and Gateways?

[Kurt Andersen (b)]

The lack of universal DMARC verification and insufficient flexibility in
the application of enforcement and local policy overrides in the "filter
spam as a service" market (as well as the X.400, SMS, UUCP, Bitnet sort of
protocol gateways) were the problems that we were addressing within this
item in 7960.

--Kurt

On Tue, Sep 15, 2020 at 3:59 AM Douglas E. Foster  wrote:

> I was surprised to see email technology gateways included in RFC 7960.
>
> I would expect that a public gateway would use a from address within the
> gateway domain name, so that it can accept replies.   A gateway dedicated
> to a single organization would release messages into that organization on a
> trusted path, and anything forwarded out of that organization would be
> signed at the outbound mail gateway.
>
> Can anyone who was involved with RFC 7960 comment on whether the gateway
> problem still exists?
>
> DF
>
> ___
> 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] Revisiting the Race Condition in draft-crocker-dmarc-sender-01

[Kurt Andersen (b)]

On Wed, Aug 19, 2020 at 12:11 PM John R Levine  wrote:

>
> It is abundantly clear that Ericsson and AOL and Yahoo do not object to
> their users sending mail through discussion lists.  Ericsson doesn't want
> their execs to be phished, AOLhoo doesn't want complaints "why am I
> getting spam from people I know."  In each case we know from experience
> that their published p=reject doesn't describe their actual policy.
>

When domains have only three sizes of DMARC policy hammers, there aren't a
lot of options to handle loose screws...though I still haven't heard any
wormhole protocol suggestions which seem like viable mechanisms at scale or
which would allow the organizations you cite to express the nuances of
their presumptive "actual polic[ies]".

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Kurt Andersen (b)]

On Wed, Aug 19, 2020 at 1:34 AM Alessandro Vesely  wrote:

> On Tue 18/Aug/2020 01:21:33 +0200 Murray S. Kucherawy wrote:
> > The industry in general, and the IETF in particular, have chosen not
> > to pursue widespread use of any kind of standards-based third party
> > domain signature policy or reputation system. . .
>
> > Both ATPS (individual submission, experimental, February 2012) and the
> > REPUTE series of documents (working group, standards track, late 2013)
> > saw nearly zero adoption after publication even when free reference
> > implementations were provided.  They differ from basic DKIM in that
> > they require non-trivial upkeep, and that appears to be a step
> > function inhibiting adoption among operators.
>
> We can still try again.  In particular, the non-trivial upkeep seems
> to be a valid diagnosis.
>

Is there anything which has materially changed between 2012-13 and 2020
which would indicate that the anticipated results for such effort would be
any different?

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Kurt Andersen (b)]

On Fri, Aug 14, 2020 at 12:16 PM Jim Fenton  wrote:

> On 8/14/20 11:30 AM, Kurt Andersen (b) wrote:
>
> On Fri, Aug 14, 2020 at 9:23 AM Dotzero  wrote:
>
>>
>>  Is this an interoperability problem that is solved by IETF standards or
>> is it an organizational problem that requires an organizational solution?
>> Perhaps we need to generate an RFC entitled "Don't Do Stupid Things". ;-)
>>
>
> I think that it might be out of the DMARC-WG's charter, but such an RFC
> would be eminently quotable along with 2549 and other such work.
>
> We already have a number of such RFCs:
>
>
> https://datatracker.ietf.org/doc/search?name=considered+harmful==on=on=group=
>
> -Jim
>
Maybe we should write _Implementing Email Security Without Understanding
What You Are Doing Is Considered Harmful_ - that could fall within our
remit.

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Kurt Andersen (b)]

On Fri, Aug 14, 2020 at 9:23 AM Dotzero  wrote:

>
>  Is this an interoperability problem that is solved by IETF standards or
> is it an organizational problem that requires an organizational solution?
> Perhaps we need to generate an RFC entitled "Don't Do Stupid Things". ;-)
>

I think that it might be out of the DMARC-WG's charter, but such an RFC
would be eminently quotable along with 2549 and other such work.

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Kurt Andersen (b)]

On Fri, Aug 14, 2020 at 7:31 AM Dotzero  wrote:

>
> I've been involved in setting up DMARC with a policy of p=reject for
> somewhere North of 6,000 domains. As a sending domain, the heavy lifting is
> in getting buy-in across the organization that it is a worthwhile effort,
> getting control of your organization's mail flows and ensuring policies and
> procedures are communicated and followed. For complex environments there
> may need to be some automation required for creating and maintaining
> private/public key pairs and DNS records but that is much more
> straightforward than the aforementioned heavy lifting.
>

Also note that said "heavy lifting" is not a one time expenditure of
effort. Having hoisted the weight bar above your head, it requires
organizational will and ongoing knowledge to stick to the higher bar week
in and week out. Entropy is never your friend in an organizational security
context. Neither are acquisitions :-)

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

[dmarc-ietf] Good paper analyzing inter-component flaws in email security

[Kurt Andersen (b)]

It would be worthwhile for everyone in the group to read through
https://www.usenix.org/conference/usenixsecurity20/presentation/chen-jianjun
as they analyze implementation flaws that allow attacks against DMARC in
existing implementations.

The paper should be publicly accessible now since the conference is in
progress. There's also a slide deck with a summarized set of results from
their study.

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Kurt Andersen (b)]

On Thu, Aug 13, 2020 at 2:33 PM Doug Foster  wrote:

> The current DMARC architecture supports authorizing a vendor to mail on
> behalf of their clients if the client includes them in their SPF policy or
> delegates a DKIM scope to them and they use it.
>
>
>
> I agree that SPF is too limiting (including hard limits on complexity),
> and DKIM is too complex for an uncooperative vendor.
>
>
>
> In most cases, a solution would be a controlled third-party signature
> authorization along the lines of RFC 6541.
>
> The client would configure the authorization in his own DNS and the and
> the vendor would only need to sign with their own DKIM signature.
>

If "DKIM is too complex for [this] uncooperative vendor", why would having
the "vendor...sign with...DKIM" be workable?

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Kurt Andersen (b)]

On Thu, Aug 13, 2020 at 12:06 PM Neil Anuskiewicz 
wrote:

>
> Tunable! You said the magic word I have a client now getting spoofing.
>

Receiving spoofed mail or having their domain *being* spoofed?


> My point is that it sure would be nice to be able to tune so that BigCRM
> and BigCRM Marketing * mail would pass DMARC comfortably, and we could then
> turn the dial on policy to cut off the spoofers without breaking legit mail.
>

Passing DMARC is not a be-all-end-all. That's what local policy is for. I
fail to see why local policy would not solve your problem (as described).

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Kurt Andersen (b)]

On Mon, Aug 10, 2020 at 12:05 PM Tim Wicinski  wrote:

>
> During IETF 108, the chairs realized that there was interest in Dave's
> RFC5322.Sender draft.
>
> This starts a Call for Adoption for draft-crocker-dmarc-sender
>

+1 for adopting the document into the WG for continued discussion.

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Kurt Andersen (b)]

This is a known issue with many calendaring frameworks. Besides the issue
of delegates who are sending on behalf of someone in another domain, most
calendaring systems send "forwarded" invitations by trying to resend in the
name of the event originator.

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

Re: [dmarc-ietf] Agenda requests for Madrid IETF

[Kurt Andersen (b)]

On Mon, Jul 20, 2020 at 11:36 AM Seth Blank  wrote:

> We have a session on the books for IETF108, and would like suggestions
> from the group for the agenda, otherwise the chairs will choose relevant
> topics. Items in tickets or from the past month are all fair game.
>

Based on the recent discussions that have been happening, I think that
there are two key topics that should be hashed out in the F2F:

   1. Jim Fenton's ask to develop a threat model; along with this I think
   we need to more tightly defined the problem statement
   2. Is the goal of this WG to "get DMARC onto the standard track" or is
   it to "solve the spam problem"?

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Kurt Andersen (b)]

On Fri, Jun 19, 2020 at 12:41 AM Laura Atkins 
wrote:

> On 19 Jun 2020, at 07:59, Murray S. Kucherawy  wrote:
>
> So to those of you with access to such (e.g., M3AAWG regulars among
> us), is there evidence in the wild of spammers and phishers using
> discardable (ahem) domains to achieve alignment and improve their
> delivery success stories?
>
>
> There is certainly ample evidence that spammers are: sing disposable
> domains / rotating through domains and aligning authentication so that they
> will pass DMARC.
>

Here's an article citing exactly such an example from today's headlines:
https://threatpost.com/bofa-phish-gets-around-dmarc-other-email-protections/156688/
Sadly, the explanation of what DMARC is/does is botched. (related original
article:
https://www.armorblox.com/blog/blox-tales-7-bank-of-america-credential-phishing/
which details the specifics of the phishing attack - sent from Yahoo,
misleading display name, misleading newly registered domain and URL)

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Kurt Andersen (b)]

On Mon, Jun 15, 2020 at 11:30 AM Tim Wicinski  wrote:

>
> On Mon, Jun 15, 2020 at 2:27 PM Scott Kitterman 
> wrote:
>
>>
>> To follow-up on Brandon's note about Google's use of ARC, it's bigger
>> than
>> mailing lists and so is this problem.  It's any intermediary that
>> modifies a
>> message in such a manner that DKIM fails (SPF is only useful for direct
>> source
>> ADMD to destination ADMD tranmissions).
>>
>> I suspect that by hyper focusing on mailing lists, we're missing part of
>> the
>> problem.
>>
>> Scott K
>>
>>
> I think the mailing list issue looms so large as to block out everything
> else.  We (probably the chairs) should make sure we don't miss the the
> non-mailing list part of this problem.
>

That's what RFC 7960 (the first work product from this group) was all about.

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

Re: [dmarc-ietf] why ARC

[Kurt Andersen (b)]

On Fri, Jun 12, 2020 at 5:52 PM Dave Crocker  wrote:

>
> > ARC lets the recipient look back and retroactively do the filtering
> > the list didn't.
>
> The concern about the creator of an ARC chain spoofing the purported
> origin of a message is valid.
>

By "creator" do you mean "initiator" (aka, the source of the first ARC set,
i=1)?

In general ARC chains are the product of a series of co-creators through
the handling sequence for the message, so I think that "creator" in a
singular sense is a little misleading.

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Kurt Andersen (b)]

On Fri, Jun 12, 2020 at 5:06 PM Scott Kitterman 
wrote:

>
> On June 12, 2020 11:33:13 PM UTC, "Kurt Andersen (b)" 
> wrote:
> >I would like to understand what you mean by:
> >
> >On Fri, Jun 12, 2020 at 1:02 AM Alessandro Vesely 
> >wrote:
> >
> >> . . . ARC chains can be forged.
>
> Not sure what is confusing about that.  There's no requirement that
> signatures from previous hops still verify, so anyone can build an ARC
> chain that claims they got something from an arbitrary source.  ARC is only
> usable if you know you trust the source.
>

Perhaps we are debating semantics here, but a wholesale replacement of the
message content within the bounds of an ARC-chain-span is not what I would
call "forgery". One can not simply "build an ARC chain" because each
ARC-Seal header is cryptographically created by the entities which control
the respective private keys.

Trust matters, but really has nothing to do with the interoperability or
validity of the chain itself.

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Kurt Andersen (b)]

I would like to understand what you mean by:

On Fri, Jun 12, 2020 at 1:02 AM Alessandro Vesely  wrote:

> . . . ARC chains can be forged.
>

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

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

[Kurt Andersen (b)]

I'm sorry to pile on but could not restrain myself:
https://www.bmj.com/content/327/7429/1459?ijkey=c3677213eca83ff6599127794fc58c4e0f6de55a=tf_ipsecsha

I get Dave's point, but at the same time, it is well known that copy tweaks
can have significant effects on conversion rates. Whether the specific
tweak of the 5322.From header field's SMTP domain from  to
 has an effect separate from any
other subterfuges that might be being employed by the miscreant is probably
hard to disambiguate, especially since in the real world, it is rare to
have bare SMTP addresses in that header field.

--Kurt


On Tue, Jun 2, 2020 at 3:01 PM Dave Crocker  wrote:

> Wow. I'll ask folk to reread my text, here, carefully, since it specified
> something quite narrow and concrete, but is somehow being taken to have
> meant something broad and general:
>
> On Tue, Jun 2, 2020 at 1:46 PM Dave Crocker  wrote:
>
> However there appears to be no actual evidence that lying in the From
> field affects end user behaviors, and certainly none that lying in the From
> field about the domain name does.
>
> And again, there are all sorts of threats and all sorts of bad behaviors,
> but the question is whether a particular kind of bad actor behavior affects
> recipient end-user behavior.
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

[Kurt Andersen (b)]

On Fri, May 15, 2020 at 6:14 PM John Levine  wrote:

> In article  zmn0oxmgns0cspywu58hqlaw7wvvbh1442yu4e...@mail.gmail.com> you write:
> >-=-=-=-=-=-
> >Should we consider adding JSON formatting to DMARC?
>
> What Scott said, no. Report processors will always have to be able to
> decode the existing XML so adding more options just adds more
> complexity with no more function.
>

Agree 100%

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

Re: [dmarc-ietf] Composition Kills: A Case Study of Email Sender Authentication

[Kurt Andersen (b)]

Extracting from the abstract of a paper in process by Casey Deccio (now
researching SPF at BYU, formerly at Cisco):

Our techniques elicit SPF and DMARC validation activity of the servers,
> while minimizing spam and perceived abuse. We find that only 25% of mail
> servers and less than half of domains deploy SPF validation. Of domains
> that perform SPF validation, 7.6% exhibit inconsistent validation behavior
> across mail servers. We also find that 75% of organizations with mail
> servers for popular domains share DNS infrastructure with up to tens of
> thousands of others.


Most of his focus has been on SPF but it would be useful to loop him into
the DMARCbis discussions.

--Kurt

On Tue, Apr 21, 2020 at 9:11 AM Scott Kitterman  wrote:

> There is probably protocol improvement work that should be done based on:
>
> https://www.usenix.org/system/files/sec20fall_chen-jianjun_prepub_0.pdf
>
> Scott K
>
>
> ___
> 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] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

[Kurt Andersen (b)]

On Thu, Apr 16, 2020 at 7:29 AM John Levine  wrote:

> In article <4666d39f-85f5-4ad2-a754-11fed0a5c...@kitterman.com> you write:
> >Perhaps I'm too pessimistic, but I don't think it's possible to actually
> make this clear to anyone that isn't familiar
> >with RFC 7489 without essentially turning this into a proto 7489bis.
>
> I agree.  Hence my suggestion last week to tear out all of the TLD
> stuff or move it into an appendix and just say this is the name above
> the Organizational domain which you can find into RFC 7489.
>
> The reality is that any of the 8000 domains in the PSL could publish a
> PSD record, and I would not want to try to explain to anyone in the
> IESG why most of them are there.  So let's stay as far away from that
> as possible.  Policy Super Domain, remember?


 After an initial "that's too cutesy" reaction, I'm becoming more convinced
that John's suggestion ("policy super domain") might indeed be the right
sort of solution - along with clearly citing 7489 in the intro and abstract
("If you don't know what DMARC is, go read RFC 7489 before coming back
here." or similar).

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

Re: [dmarc-ietf] Genart last call review of draft-ietf-dmarc-psd-08

[Kurt Andersen (b)]

On Fri, Apr 10, 2020 at 9:34 AM John Levine  wrote:

> In article  skkohn-j+qiccser1rtg1anwpw...@mail.gmail.com> you write:
> >-=-=-=-=-=-
> >
> >Agree with John/Scott/Kurt on keeping this in 7489 and trying to weasel
> >word around it for now.
>
> So how about renaming it Policy Super Domain (PSD)?
>

Works for me.

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

Re: [dmarc-ietf] Genart last call review of draft-ietf-dmarc-psd-08

[Kurt Andersen (b)]

On Fri, Apr 10, 2020 at 6:49 AM Scott Kitterman 
wrote:

> On Friday, April 10, 2020 9:38:40 AM EDT Todd Herr wrote:
> >
> > I don't disagree, but what I was going for here was some level of
> > consistency with section 3.2 of RFC 7489. . .
>

And it needs to stay entirely in RFC7489 :-)


> > Dale twice in his comments expresses doubt that it's possible for anyone
> to
> > know all PSDs; the mention of a specific PSL in the abstract was an
> attempt
> > to answer those doubts.
>
> > But how to address Dale's concerns about how one knows all PSDs?
>
> To the extent this is a problem, it's RFC 7489's problem.  This document
> leverages it's existing definitions.  That's intentional.  While the
> current
> RFC 7489 definitions aren't ideal, as an extension to that work, I don't
> think
> it make sense to try and fix it here.  That's work for 7489bis.


Agreed. Dale's concern is a non sequitur. We can always invoke the ghost of
DBOUND-past :-D

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

Re: [dmarc-ietf] Genart last call review of draft-ietf-dmarc-psd-08

[Kurt Andersen (b)]

On Thu, Apr 9, 2020 at 1:36 PM Murray S. Kucherawy 
wrote:

>
> That seems like it paints a much clearer picture, which is what Dale was
> after.  A great start!
>
> On Thu, Apr 9, 2020 at 12:54 PM Todd Herr  wrote:
>
>> Having reviewed the comments, I'm wondering if perhaps the following
>> draft rewrite of the Abstract section might be a first step to address many
>> of the points raised?
>>
>> *AbstractDMARC (Domain-based Message Authentication, Reporting, and
>> Conformance) is a scalable mechanism by which a mail-originating
>> organization can express domain-level policies and preferences for message
>> validation, disposition, and reporting, that a mail-receiving organization
>> can use to improve mail handling.  *
>>
>> *The original design of DMARC applies only to domains that are registered
>> with a domain name registrar (called “Organizational Domains” in RFC 7489)
>> and nodes in the tree below Organizational Domains. Organizational Domains
>> are themselves nodes in the tree below domain names reserved for
>> registration, with the latter commonly referred to as “Top Level Domains”
>> (TLDs) (e.g., ‘.com’, ‘.co.uk ’, etc.), although in this
>> document they will be referred to as Public Suffix Domains (PSDs).*
>>
>> *Since its deployment in 2015, use of DMARC has shown a clear need for
>> the ability to express policy for PSDs. This document describes an
>> extension to DMARC to enable DMARC functionality for PSDs.*
>>
>> *RFC 7489 describes an algorithm for a mail-receiving organization to use
>> in determining the Organizational Domain of an inbound mail message, and
>> this algorithm recommends the use of a “public suffix list” (PSL), with the
>> most common one maintained by the Mozilla Foundation and made public at
>> >. Use of such a PSL by
>> a mail-receiving organization will be required in order to discover and
>> apply any DMARC policy declared by a PSD.*
>>
>> *This document also seeks to address implementations that consider a
>> domain on a public Suffix list to be ineligible for DMARC*
>>
>
I have two concerns with the proposed abstract:

   1. ".co.uk" is not a TLD. TLDs are single label domains - there are
   ccTLDs and gTLDs.
   2. The invocation of the PSL compounds the issue that was raised by Dave
   Crocker. How DMARC (RFC 7489) determines the organizational domain is
   orthogonal to this proposal which simply calls for a conditional additional
   check at the "org - 1" level. I recommend striking the penultimate
   paragraph in the proposal.

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

Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers

[Kurt Andersen (b)]

On Fri, Apr 3, 2020 at 1:09 PM John Levine  wrote:

> In article <
> caba8r6sbhlfkzhd4gapbxqbgny57j1elxt2spyafatyay3t...@mail.gmail.com> you
> write:
> >In practice, I don't know how common it is for clients to consume this
> >header.
>
> They have to if they're adding ARC seals on the way out.
>

Only if the ADMD's particular implementation to pass through the
information from incoming perimeter system to outgoing perimeter system
happens to utilize the A-R header(s) for the purpose of conveying that
information.

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

Re: [dmarc-ietf] Definition of "value" in RFC8601

[Kurt Andersen (b)]

On Tue, Mar 31, 2020 at 10:56 AM Damian Lukowski  wrote:

> > I don't see any reason to exclude them.  We could do this:
> >
> >   autbserv-id = sub-domain *("." sub-domain)
> >
> > Where sub-domain is imported from 5321 for ASCII mail and 6531 for EAI
> mail.
>
> Does this mean that a parser would need to know if the message has been
> sent with SMTPUTF8 in order to pass or refute U-labels?
>

You don't need SMTPUTF8 to handle IDNs.

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

Re: [dmarc-ietf] Definition of "value" in RFC8601

[Kurt Andersen (b)]

On Mon, Mar 30, 2020 at 10:43 PM Murray S. Kucherawy 
wrote:

> On Mon, Mar 30, 2020 at 4:21 PM John R Levine  wrote:
>
>> > Does someone have a fix in mind that could be submitted as an erratum?
>> The
>> > intent was indeed to make the authserv-id either a plain old ASCII
>> domain
>> > name or an A-label which doesn't need quoting.  I missed that RFC 6532
>> > didn't update "value", unfortunately.
>>
>> Unfortunately, 8601's defintion is a mess.  At the bottom of page 15 it
>> says this about authserv-id, which contradicts the ABNF:
>> [...]
>>
>
> OK, what does the WG think might be the best way to clean it up?
>

 I think that John's suggestion (ABNF: " authserv-id = domain-name ") makes
the most sense and the fewest contortions.

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

Re: [dmarc-ietf] Publication has been requested for draft-ietf-dmarc-psd-07

[Kurt Andersen (b)]

On Sat, Mar 7, 2020 at 7:15 AM Murray S. Kucherawy 
wrote:

>
>> Thanks to you and Murray for carrying out that writeup.  For a nit:
>>
>> There is one implementation already . . .
>>
>> Actually two.  Besides Scott's implementation, zdkimfilter 1.7 implemented
>> PSDDMARC  since Tue 24 Sep 2019.  https://www.tana.it/sw/zdkimfilter/.
>>
>
> Thanks; I'll correct the writeup if necessary, but I think the document
> itself includes that already in Appendix C.
>

 Since information about existing implementations gets removed as a doc
passes through the editor's hands, I'm not sure why it would matter to
update a section that will be removed.

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

Re: [dmarc-ietf] A tweak to draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Sat, Feb 29, 2020 at 11:16 AM Tim Wicinski  wrote:

>
> If we're going down the road of definitions, RFC8499 defines what a
> "Public suffix" is
> https://tools.ietf.org/html/rfc8499#page-28
>
> Which could assist in the Public Suffix Domain definition here.
> If this makes sense, I can offer some suggested text
>

No, that does not help. RFC8499 just refers back to RFC6265 section 5.3
which in turn invokes the PSL - that's Dave's problem with DMARC in the
first place.

I think that Murray's suggestion about importing definitions from DMARC
(RFC7489) makes much more sense than forking elsewhere since this is a riff
on DMARC.

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Thu, Feb 27, 2020 at 4:16 AM Alessandro Vesely  wrote:

> On Thu 27/Feb/2020 06:30:59 +0100 Murray S. Kucherawy wrote:
> >
> > With a completed (and now seven month old) Working Group Last Call on the
> > PSD document, and as far as I can see no sustained objection, we should
> > proceed toward publication.
>
> Great!
>

+1

> I will put this question to the working group: Can we solve this problem
> by
> > switching the document to Informational status, and can the working group
> > accept that outcome?
>
> If publishing as experimental would further delay publication, I'd accept
> informational.
>

Also agree.

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Tue, Feb 4, 2020 at 10:13 PM Scott Kitterman 
wrote:

>
> Assuming that's correct, please help me understand what PSD DMARC is
> affected at all.  All it does is consume the org domain however
> DMARC/DMARCbis choose to define it.  I don't see as it makes a difference
> from a PSD DMARC perspective.
>
> I get that you want to fix the architectural warts in DMARC and I don't
> disagree with you about working on that.  Where I get lost is how PSD DMARC
> has anything to do with it.  PSD DMARC could be done first, in parallel, or
> after the DMARC architectural work.  It would have no impact on that work.
>
> I would like to understand your position, but I don't, so please help me
> out here.
>

Scott,

Thank you for expressing this so clearly. This is exactly the issue that
I've been trying to understand in this series of conversations. It seems
like the PSD proposal has been being used as leverage to have an (almost)
entirely separate discussion about DMARCbis.

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Tue, Dec 10, 2019 at 2:13 PM Brandon Long  wrote:

>
> On Mon, Dec 9, 2019 at 6:27 PM Kurt Andersen (b)  wrote:
>
>> On Mon, Dec 9, 2019 at 4:54 PM Scott Kitterman 
>> wrote:
>>
>>> On Monday, December 9, 2019 7:41:27 PM EST Brandon Long wrote:
>>>
>>> > I'm sure I probably missed this, but couldn't we avoid this question
>>> by just mandating no reporting for non-existing organizational domains?  Is
>>> that a non-starter?
>>>
>>> It's one of the use cases we are trying to cover.  I don't know if that
>>> makes it a non-starter.
>>>
>>
>> Unless I'm misunderstanding Brandon's suggestion, it seems like you
>> (Brandon) are asking if doing no reporting on missing org domains solves
>> the scalability problem. *Getting* reports for missing org domains is the
>> main purpose of the PSD proposal so it would render the purpose moot.
>>
>
> Hmm, I guess I don't see it that way.
>
> Preventing phishing attacks from nonexistent.gov.uk, insomuch as DMARC
> can be used for such, seems way more important than the reporting.
> Obviously, getting to p=reject without reporting is more challenging.  You
> can certainly have policy without reporting.
>

While it is very true that receivers may implement validation and possibly
enforcement without reporting, we could solve the use case of phishing from
missing org-level domains by the same approach that we can solve it from
any missing domain - just don't accept mail from such bogus sources. That
does not help the overseers of a domain realm (org-1, aka LPSD) to tackle
takedowns or public awareness campaigns against such abuse though.

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Mon, Dec 9, 2019 at 4:54 PM Scott Kitterman  wrote:

> On Monday, December 9, 2019 7:41:27 PM EST Brandon Long wrote:
>
> > I'm sure I probably missed this, but couldn't we avoid this question by
> just mandating no reporting for non-existing organizational domains?  Is
> that a non-starter?
>
> It's one of the use cases we are trying to cover.  I don't know if that
> makes it a non-starter.
>

Unless I'm misunderstanding Brandon's suggestion, it seems like you
(Brandon) are asking if doing no reporting on missing org domains solves
the scalability problem. *Getting* reports for missing org domains is the
main purpose of the PSD proposal so it would render the purpose moot.

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Wed, Dec 4, 2019 at 2:39 AM Alessandro Vesely  wrote:

>
> > Rather, it's primed as a possibly useful data collection exercise.
>
> Kurt also talked about reporting some findings.  I'm embarrassed, I have no
> idea what I, as a receiver, should report.  What data should I, and other
> receivers collect?
>

I was thinking of something along the line of what was assembled for RFC
6686. In this case it would be something like the quantity of messages
which were assessed against the LPSD record and their disposition compared
to the number of messages dispositioned at the org level. Something to
answer Dave's concern about "too much additional work" for not enough
benefit.

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

Re: [dmarc-ietf] DMARCbis / Re: Collecting DMARC issues and nits for DMARC WG phase III - DMARC standardization

[Kurt Andersen (b)]

I'm willing to volunteer.

On Tue, Dec 3, 2019 at 12:42 PM Murray S. Kucherawy 
wrote:

> On Mon, Nov 18, 2019 at 7:49 AM Дилян Палаузов 
> wrote:
>
>> who is going to work on DMARCbis document and is it realistic to finish
>> it with a year?
>>
>
> We haven't started the process of selecting editor(s) for it, but if
> anyone wants to volunteer, please do.
>
> -MSK
> ___
> 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] Comment on draft-ietf-dmarc-psd

[Kurt Andersen (b)]

I think that if we could get a core set of receivers who would be willing
to test this and report on their findings in 3-6 months, that would be
great.

--Kurt

On Tue, Dec 3, 2019 at 12:40 PM Murray S. Kucherawy 
wrote:

> On Mon, Nov 11, 2019 at 2:21 PM Dave Crocker  wrote:
>
>> On 11/10/2019 11:34 PM, Murray S. Kucherawy wrote:
>>
>> * add text to the PSD draft making it clear that what it's describing is
>> an experiment whose outcome will be taken only as feedback to the revision
>> of the standard (i.e., this is not intended to be the final form of
>> anything), and it is not intended to be deployed outside of the
>> experiment's participants;
>>
>> Forgive me, but while everyone involved in this has extensive experience
>> and is trying to solve a real and serious issue, this is an astonishingly
>> naive view.
>>
>> The IETF does standards, not experiments.  Not /real/ experiments.  What
>> it calls an experiment mostly serves as market testing, with a smidgen of
>> engineering tuning later.  For the most part, IETF experiments produce an
>> accepted/failed/needs-small-revisions range of results.  What it does /not/
>> produce is results along the lines of "that was interesting, now let's
>> start fresh and do the real standard."
>>
>> Perhaps there are exampls of IETF experiments that have permitted
>> entirely starting over, but mostly those only happen when there is a
>> complete failure, and those typically are called experiments.
>>
> Should I take this as advocating for running the experiment without
> publishing an RFC about it?  Or do you have another suggestion?
>
> I don't think the idea of going back and fixing the DMARC-PSL separation
> issue first is tenable given how long it will take, compared to the urgent
> need to get some data here.
>
> -MSK
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] From: rewriting, was Email standard revision

[Kurt Andersen (b)]

On Mon, Dec 2, 2019 at 9:11 AM John C Klensin  wrote:

>
> --On Monday, December 2, 2019 08:29 -0800 Dave Crocker
>  wrote:
>
> > On 12/2/2019 7:56 AM, Kurt Andersen (b) wrote:
> >> There's also already RFC7960 which expands upon 5598 with
> >> specific  reference to DMARC's impact.
> >
> > ahh. thanks.
> >
> > It will help to have folk comment on the IETF mailing list, so
> > that Klensin's comments don't just get responses from me.
>
> Unfortunately, 7960 does not explicitly update 5598, so that
> relationship is difficult for anyone not heavily involved to
> discover (that neither Dave nor I was aware of the relationship
> is probably symptomatic).  This may eventually call for an
> update that replaces both documents or may further justify a
> more or less comprehensive Applicability Statement for the core
> email protocols.


In this regard I think that something like Hector's "practitioner's guide"
(probably as a BCP rather than a protocol standard) would be immensely
helpful and meet this need. Maybe we need to look for making a trilogy of
docs rather than just a duet: *21, *22, *23 :-)

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

Re: [dmarc-ietf] From: rewriting, was Email standard revision

[Kurt Andersen (b)]

There's also already RFC7960 which expands upon 5598 with specific
reference to DMARC's impact.

On Sat, Nov 30, 2019 at 7:37 AM Dave Crocker  wrote:

> On 11/30/2019 4:40 AM, Alessandro Vesely wrote:
>
> Let me quote this from the ietf-smtp mailing list:
>
> On Sat 30/Nov/2019 00:12:53 +0100 John C Klensin wrote:
>
> --On Friday, 29 November, 2019 11:16 -0600 Pete Resnick wrote:
> [...]
>
> Even the "From: rewriting" issue is
> a gatewaying issue, not a message format issue per se.
>
> That is less clear.  It fits into the gray area that has existed
> for years about just exactly what a mailing list exploder /
> redistribution system really is.
>
>
> This view is reasonable only if one re-defines accepted terminology and 
> ignores some basic technical facts.
>
> A user specifies a recipient address. The message is posted and then
> delivered to that address.
>
> That simple process describes basic email handling, and has been the
> accepted view for roughly 40 years.
>
> And it describes the /first/ leg of a message sent /through/ a mailing
> list.
>
> For the second leg, a bot at that address /re-/posts the message.  In
> simple, formal email technical terms, this is an entirely new email
> transaction.
>
> It isn't 'gatewaying' per se, since that term applies to transit between
> heterogeneous systems, but it /is/ a higher-level process.
>
> If only we had a document that discussed all this coherently, defined
> basic terminology, and had undergone IETF review and approval.  If only we
> had RFC 5598...
>
>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorkingbbiw.net
>
> ___
> 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] Comment on draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Mon, Nov 11, 2019 at 12:43 PM Alessandro Vesely  wrote:

>
> about the need for each OD to opt out by defining its own DMARC record,
> lest
> have reports delivered to the realm.  In the latter sense, Nominet solved
> the
> problem of what rights has gov.uk on domains below it.
>

Requiring "trick" authoritative name servers at the realm level is a/the
solution?!? If so, let's just drop all this I-D noise and get it all done.
That would also solve .bank's problem because they would not have to
"publish" any records contravening ICANN's requirements. They would only
have to "serve" them as responses.

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Mon, Nov 11, 2019 at 9:50 AM Alessandro Vesely  wrote:

> On Mon 11/Nov/2019 16:46:17 +0100 Kurt Andersen (b) wrote:
> >
> > I don't think that it is fair to say that anyone who refers to the org
> domain
> > concept as cited in the DMARC spec is necessarily invoking the PSL.
>
> Agreed.  The PSL just happens to be the only valid tool to do that.
>

Which was not what I thought Tim W was talking about...


> For various reasons, large organizations administer many apparently
> unrelated
> domains.  For example, _dmarc.youtube.com has a rua mailto ending in
> @google.com.  We cannot infer an OD from that, but I think the concept is
> clear.
>

I don't think this has anything to do with the PSD proposal either. Why do
you bring it up?


> > As to the proposed "let's run this as an experiment pending DMARCbis", I
> don't
> > see how that satisfies Dave's concern about creating new work for
> receivers in
> > order to help a small set of domain (realm) owners. I'm not opposed to
> it, but
> > I just don't see how this solves the issue.
>
> Isn't that an ICANN problem?  For the time being, dig _dmarc.bank txt
> returns
> an empty NOERROR response, while _dmarc.gov.uk returns a valid record.
> The
> latter is a Nominet, already solved problem, AFAICS.
>

If it was a solved problem, then we would not need a PSD (or realm) I-D and
this whole discussion would be moot. What ICANN does and does not allow is
out of scope for the IETF/protocol work (though I do acknowledge that ICANN
may consider protocol factors when making decisions - or I would hope that
they would).

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

Re: [dmarc-ietf] Call for rfc8601 erratum (smtp.remote-ip), was Do is need a new ptype?

[Kurt Andersen (b)]

On Mon, Nov 11, 2019 at 1:23 AM Alessandro Vesely  wrote:

>
> Does the WG agree to an erratum as follows:
>
> TYPE: technical
>
> SECTION: 2.3
>
> ORIGINAL TEXT:
>
>smtp:  Indicates information that was extracted from an SMTP command
>   that was used to relay the message.  The "property" indicates
>   which SMTP command included the extracted content as a parameter.
>
> CORRECTED TEXT:
>
>smtp:  Indicates information that was extracted from a parameter of
>   the SMTP session that was used to relay the message.  The
>   "property" indicates which parameter included the extracted content.
>
> NOTES
>
>This change makes the "smtp" type consistent with the definition of
>smtp.remote-ip given in rfc8617 Section 10.2.
>

This seems like a bit of a nit, but also seems to be an accurate
wordsmithing of the definition.

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Mon, Nov 11, 2019 at 1:58 AM Tim Wicinski  wrote:

> Scott
>
> PSD DMARC does talk about organizational domains which from the original
> DMARC spec (section 3.2)
> does say 'Acquire a "public suffix" list'
>
> The addition of the preamble text shouldn't move the document in either
> direction.
> I do feel anything which helps focus us on moving forward on DMARC-bis is
> a good thing.
> The WG should be able to start writing the PSL document right away.
>

Tim,

I think that you are being too liberal in applying transitive references.
The PSD document only refers to the PSL in

   - Informative References
   - Appendix A.1
   - Appendix B.3
   - Appendix C.2 (implementations)

I don't think that it is fair to say that anyone who refers to the org
domain concept as cited in the DMARC spec is necessarily invoking the PSL.

I do have a problem with the conflation of the org domain with a
super-organizational "realm" (?) that may impose conditions upon
organizations that fall within their jurisdictional purview. My main
concerns are with the potential usurpation of the org domain's policy
declaration rights. "Moving" the org domain up one level disenfranchises
the organizations and that is the wrong thing to do IMO.

As to the proposed "let's run this as an experiment pending DMARCbis", I
don't see how that satisfies Dave's concern about creating new work for
receivers in order to help a small set of domain (realm) owners. I'm not
opposed to it, but I just don't see how this solves the issue.

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Mon, Nov 11, 2019 at 1:58 AM Tim Wicinski  wrote:

> Scott
>
> PSD DMARC does talk about organizational domains which from the original
> DMARC spec (section 3.2)
> does say 'Acquire a "public suffix" list'
>
> The addition of the preamble text shouldn't move the document in either
> direction.
> I do feel anything which helps focus us on moving forward on DMARC-bis is
> a good thing.
> The WG should be able to start writing the PSL document right away.
>
> Murray and I will be in Singapore if anyone wishes to speak their mind.
>
> thanks
> Tim
>
>
>
>
> On Mon, Nov 11, 2019 at 3:29 AM Scott Kitterman 
> wrote:
>
>>
>>
>> On November 11, 2019 7:34:39 AM UTC, "Murray S. Kucherawy" <
>> superu...@gmail.com> wrote:
>> >On Thu, Sep 5, 2019 at 1:22 PM Dave Crocker  wrote:
>> >
>> >> > 1. The change to DMARC should be limited to permitting the query
>> >for the
>> >> > organization domain to be anywhere in the DNS tree, including a
>> >TLD.
>> >> > Within DMARC this would not look like 'extra' mechanism.
>> >> >
>> >> > 2. The mechanism that processes that query should be cast strictly
>> >as a
>> >> > PSL enhancement, independent of DMARC.
>> >>
>> >>
>> >> Trying to refine things further:
>> >>
>> >>
>> >> DMARC does not care about the PSL.
>> >>
>> >> What DMARC cares about is the Organizational Domain (OD), as a
>> >> fallback when no DMARC record is found at the desired domain name.
>> >>
>> >> That is, PSL is literally outside the scope of DMARC.
>> >>
>> >> At the least, therefore, the DMARC specification should define a
>> >> distinct interface to the outside functionality that tells DMARC
>> >where
>> >> the OD is, which will return what suffix of the full domain name is
>> >the
>> >> OD --  eg, getOrgDomain(full-domain) -> org-domain-suffix
>> >>
>> >> The PSL-related side of that interface should be a separate
>> >> specification, so that changes to its behavior -- such as has been
>> >> happening with the introduction of ODs that are TLDs or are otherwise
>> >> 'above' where DMARC has been guessing the OD to be -- are isolated
>> >from
>> >> DMARC.
>> >>
>> >> The current problems are that DMARC has embedded too much detail
>> >> about the PSL world, yet DMARC has no involvement in that world. The
>> >> current proposal embeds assumptions of PSL knowledge further, rather
>> >> than separating PSL knowledge out.
>> >>
>> >
>> >We (the chairs) fully agree with all of this.  What we -- I in
>> >particular
>> >-- have been struggling with is to find a path forward so the PSD
>> >experiment can still take place without being blocked by the need to
>> >first
>> >go back and overhaul RFC 7489 as you've described here, separating
>> >DMARC
>> >and the OD determination.  Because that'll take months.
>> >
>> >We are perhaps in the fortuitous position in our charter now that our
>> >very
>> >next work item is to take up the task of reopening DMARC itself, and
>> >the
>> >separation of function Dave is espousing could be made into a reality
>> >during that work.  Given this, we suggest that the PSD draft be allowed
>> >to
>> >proceed as Experimental, but with appropriate preamble text added to
>> >its
>> >Introduction explaining the deficiency Dave has identified.  So the
>> >order
>> >of operations becomes:
>> >
>> >* add text to the PSD draft making it clear that what it's describing
>> >is an
>> >experiment whose outcome will be taken only as feedback to the revision
>> >of
>> >the standard (i.e., this is not intended to be the final form of
>> >anything),
>> >and it is not intended to be deployed outside of the experiment's
>> >participants;
>> >* publish the experiment with those cautions and allow the experiment
>> >to
>> >begin
>> >* while the experiment is running, spin up the work on two new
>> >standards
>> >track documents, in line with our charter:
>> >a) DMARC, with PSL references replaced by the abstract notion of the OD
>> >that's determined in some non-specific way, as Dave suggests
>> >b) a PSL document that satisfies the abstract notion of OD in the DMARC
>> >document, also as Dave suggests
>> >* when the experiment completes, either augment (b) if it's still in
>> >development, or publish a revision to it, based on what the experiment
>> >has
>> >revealed
>> >
>> >Can this be made to work?
>> >
>> >Honestly, the experiment could start anyway without an RFC published,
>> >but a
>> >formal record of the experiment and its caveats doesn't strike me as a
>> >wrong thing to do.
>>
>> The current revision of the PSD DMARC draft makes no reference to the PSL
>> in the body of the draft (it only comes up in Appendix A and C).It
>> seems like an odd choice to continue to insist PSD DMARC is specifically
>> tied to the PSL when the text indicating so has been removed (Dave's email
>> was two months ago and things have changed in the interim).
>>
>> I don't think the proposed note says anything the status of experimental
>> shouldn't already communicate.  Given the current 

Re: [dmarc-ietf] Question regarding RFC 8617

[Kurt Andersen (b)]

Both of the cases you cited are entirely covered by ARC. If you are seeing
failures, I would be pointing the finger toward said "intermediary SMTP
system" which is modifying the message without properly affixing its own
ARC set.

--Kurt

On Thu, Nov 7, 2019 at 8:45 AM Weist, Bill  wrote:

> Thank you both for replying.  There are two instances where I have
> identified ARC signatures consistently failing:
>
>
>
> Case 1:  An intermediary SMTP system receives an email on behalf of a
> recipient system whereby the “from” field is required to be changed for the
> email to reply as desired by the recipient system.  (example:
> william.we...@gmail.com rewritten to william.we...@iqvia.com)
>
>
>
> Case 2: An Intermediary SMTP system receives an email on behalf of the
> recipient system whereby the “subject” field is required to by changed for
> the email to be categorized as desired by the recipient system. (example:
> “RE: [dmarc-ietf] Question regarding RFC 8617” modified to:  “RFC
> Correspondence: [dmarc-ietf] Question regarding RFC 8617”)
>
>
>
> As Kurt pointed out below, the ARC signature is NOT intended to be
> validated by hops >1 step away.  However, I did not think this was the case
> and that ARC was specifically supposed to validate each custodian where
> DKIM would be broken by the cases listed above.
>
>
>
> As differentiated from DKIM, the RFC reads as if ARC is designed to
> validate the “custodian” and NOT the “sender” therefore, “From” and
> “Subject” would not be as desirable as say “X-Received”,
> “X-Google-Smtp-Source”, and “X-Gm-Message-State” in the case of Brandon’s
> email to which I am replying.
>
>
>
> It is my suggestion that for ARC to be a valuable addition to DKIM, it
> needs to focus on the “custodian” and not the “sender”.
>
>
>
> Thank you both for your time and attention.
>
> -Bill
>
>
>
> *From:* Brandon Long 
> *Sent:* Wednesday, November 6, 2019 12:43 PM
> *To:* Kurt Andersen (b) 
> *Cc:* Weist, Bill ; dmarc@ietf.org
> *Subject:* Re: [dmarc-ietf] Question regarding RFC 8617
>
>
>
> This email originated from outside of the organization.
>
>
>
> What's more, the point of including Subject and other mutable headers is
> the same as it is for DKIM, those are the headers which are important to
> the receiver, so they should be validated.
>
> As Kurt points out, the point of ARC is to acknowledge these changes hop
> to hop, and the Arc Seal proves who did the change, the question becomes do
> you believe
>
> the person who changed it wasn't malicious.
>
>
>
> Brandon
>
>
>
> On Wed, Nov 6, 2019 at 7:37 AM Kurt Andersen (b)  wrote:
>
> The choice of which headers are included in the signed set is strictly up
> to the domain administrators who implement the signing practices. Also, the
> AMS is only relevant for the next receiver, it is not intended to be
> validated by hops >1 step away from the domain which adds that instance so
> I don't see how mutability would matter.
>
>
>
> --Kurt Andersen
>
>
>
> On Wed, Nov 6, 2019 at 7:30 AM Weist, Bill 
> wrote:
>
> DOI:  10.17487/RFC8617
>
>
>
> The inclusion of the address headers in the signature, and possibly the
> Subject, is an issue:
>
>
>
> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=
> microsoft.com
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmicrosoft.com=02%7C01%7CWilliam.Weist%40iqvia.com%7C3c6685ae55144287801808d762e0daa5%7C5989ece0f90e40bf9c791a7beccdb861%7C1%7C0%7C637086590191460908=KyZ7aC4X35IcojTOEbgeDFXnOPPSHvlt8RaqH8VtXpA%3D=0>;
> s=arcselector9901; 
> h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
> bh=;
>
>
>
> If a downstream server needs to modify either of these two values, the
> signature check fails.
>
>
>
> It is my understanding that the Authenticated Received Check signature is
> to validate the chain of possession.  As such, in my opinion, the signature
> should only include immutable references.
>
>
>
> In my opinion, there is value in NOT requiring headers to be stripped by
> downstream servers, thus maintaining the custody chain from origination to
> destination.
>
>
>
> Thank you for your time and attention,
>
>
>
> *William M. Weist*
>
> *Enterprise Architect I – Global Messaging – Mobile and Presence*
>
> CIO Team – End User Computing
>
> *[image: IQVIA logo_96dpi_100pxheight]*
>
> Learn more
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.iqvia.com%2F=02%7C01%7CWilliam.Weist%40iqvia.com%7C3c6685ae55144287801808d762e0daa5%7C5989ece0f90e40bf9c791a7b

Re: [dmarc-ietf] Question regarding RFC 8617

[Kurt Andersen (b)]

The choice of which headers are included in the signed set is strictly up
to the domain administrators who implement the signing practices. Also, the
AMS is only relevant for the next receiver, it is not intended to be
validated by hops >1 step away from the domain which adds that instance so
I don't see how mutability would matter.

--Kurt Andersen

On Wed, Nov 6, 2019 at 7:30 AM Weist, Bill  wrote:

> DOI:  10.17487/RFC8617
>
>
>
> The inclusion of the address headers in the signature, and possibly the
> Subject, is an issue:
>
>
>
> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=
> microsoft.com; s=arcselector9901; 
> h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
> bh=;
>
>
>
> If a downstream server needs to modify either of these two values, the
> signature check fails.
>
>
>
> It is my understanding that the Authenticated Received Check signature is
> to validate the chain of possession.  As such, in my opinion, the signature
> should only include immutable references.
>
>
>
> In my opinion, there is value in NOT requiring headers to be stripped by
> downstream servers, thus maintaining the custody chain from origination to
> destination.
>
>
>
> Thank you for your time and attention,
>
>
>
> *William M. Weist*
>
> *Enterprise Architect I – Global Messaging – Mobile and Presence*
>
> CIO Team – End User Computing
>
> *[image: IQVIA logo_96dpi_100pxheight]*
>
> Learn more  about IQVIA™
>
>
>
> 400 Campus Drive
>
> Collegeville, PA 19426
>
> USA
>
>
>
> O: +1 610 244 2646 | M: +1 484 904 8244
>
>
>
>
> 
> *IMPORTANT* - PLEASE READ: This electronic message, including its
> attachments, is CONFIDENTIAL and may contain PROPRIETARY or LEGALLY
> PRIVILEGED or PROTECTED information and is intended for the authorized
> recipient of the sender. If you are not the intended recipient, you are
> hereby notified that any use, disclosure, copying, or distribution of this
> message or any of the information included in it is unauthorized and
> strictly prohibited. If you have received this message in error, please
> immediately notify the sender by reply e-mail and permanently delete this
> message and its attachments, along with any copies thereof, from all
> locations received (e.g., computer, mobile device, etc.). To the extent
> permitted by law, we may monitor electronic communications for the purposes
> of ensuring compliance with our legal and regulatory obligations and
> internal policies. We may also collect email traffic headers for analyzing
> patterns of network traffic and managing client relationships. For further
> information see: https://www.iqvia.com/about-us/privacy/privacy-policy.
> Thank you.
>
> ___
> 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] Two new fields in aggregate reports

[Kurt Andersen (b)]

On Fri, Oct 25, 2019 at 3:52 AM Дилян Палаузов 
wrote:

>
> If it is a goal to reuse the dmarc-reporting mechanism to report also
> about perceived spam probability, then it can be
> discussed in more details how this can be achieved.  My experience is,
> that asking a provider, why an obviously non-spam
> mail was evaluated as spam, virtually never leads to a useful answer.  So
> nobody wants to reveal how its spam system
> weigths factors and if there is lack of such interest, extending the
> report format will not help, as nobody will be
> willing the report the data.
>

Especially when the answer more or less boils down to "lots of recipients
treated messages like this as spam". There are so many squishy terms there
that it is essentially meaningless.

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

Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL

[Kurt Andersen (b)]

On Fri, Aug 2, 2019 at 3:00 AM Alessandro Vesely  wrote:

>   To stick with A-R semantics, it should have been named
> tcp.ip, remote.ip or some such.
>

Note that  RFC8617 section 10.2 (
https://tools.ietf.org/html/rfc8617#section-10.2) does add in an
smtp.remote-ip method item.

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

Re: [dmarc-ietf] DMARC aggregate reports XML Schema inconsistencies

[Kurt Andersen (b)]

On Wed, Jul 31, 2019 at 2:47 AM Freddie Leeman  wrote:

> I’ve been processing millions of DMARC aggregate reports from a lot of
> different organizations, and have been trying to make sense of them for
> quite some time now. I’ve noticed that most of them, even those from large
> parties like Google and Yahoo!, fail to follow the DMARC RFC guidelines
> (Appendix C.  DMARC XML Schema). I’ve written a blog about this that can be
> found here:
> https://www.uriports.com/blog/dmarc-reports-ietf-rfc-compliance/
>
>
>
> The bottom line is that the RFC 7489 Appendix C is a mess and contradicts
> itself numerous times in both schema and comments. I think it’s important
> to be clearer and stricter about the xml elements and their values. Too
> much of this section is open to interpretation.
>

Freddie,

Thanks for your observations - would you mind proposing concrete language
to replace Appendix C? Speaking from experience, it can be helpful to be
able to do in-place comments/markup so I've posted
http://bit.ly/dmarc-rpt-schema - please make any adjustments in "Suggest"
mode or comments you feel appropriate. The invitation extends to all
members of this group.

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

Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Fri, Jul 19, 2019 at 8:30 AM Kurt Andersen (b)  wrote:

> On Thu, Jul 18, 2019 at 10:42 PM Scott Kitterman 
> wrote:
>
>>
>> If we want to take another run at this and put it in more standard DNS
>> terminology, then maybe:
>>
>>  a domain for which there is an NXDOMAIN or NODATA response for A,
>> ,
>> and MX records.
>>
>> I think that cures John's concern with my last proposal and addresses
>> yours as
>> well (the response to a CNAME/DNAME is not NODATA/NXDOMAIN, so they are
>> correctly followed).
>>
>
> Yes - I think that will fix my concerns (and John's too).
>

Thinking about this from a reporting POV, where would a receiver categorize
messages which ended up with SERVFAIL during the process of DMARC (regular
or PSD)? Would "sp" handling or "np" handling be invoked for SERVFAIL (such
as a broken DNSSEC implementation)?

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

Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Thu, Jul 18, 2019 at 10:42 PM Scott Kitterman 
wrote:

> On Thursday, July 18, 2019 11:42:36 AM EDT Kurt Andersen (b) wrote:
> > On Wed, Jul 17, 2019 at 7:35 PM Scott Kitterman 
> >
> > Most MTAs will also follow CNAMEs. Should they be included (along with
> > other things like DNAME records) within the scope of existence? I'm a
> > little concerned that we are making a special definition of
> "non-existence"
> > which differs from the standard DNS concepts of NODATA and NXDOMAIN
> without
> > having a correspondingly special name.
>
> OK.  I wish you'd jumped in earlier when we were discussing that exact
> topic.
>
> https://mailarchive.ietf.org/arch/msg/dmarc/44sVJzvPkXkdT7Np-0ANr9Wm2Zc
>
> If we want to take another run at this and put it in more standard DNS
> terminology, then maybe:
>
>  a domain for which there is an NXDOMAIN or NODATA response for A,
> ,
> and MX records.
>
> I think that cures John's concern with my last proposal and addresses
> yours as
> well (the response to a CNAME/DNAME is not NODATA/NXDOMAIN, so they are
> correctly followed).
>

Yes - I think that will fix my concerns (and John's too).


> > I'm also concerned
> > that a wildcard null MX record at the org level would end up having all
> > subdomains "exist", but the policy that should be applied would be the
> more
> > restrictive "np" policy, not the (possibly) more permissive "sp" policy.
>
> I think this is one of those "you must be this tall to ride on this ride"
> situations.  DNS comes equipped with multiple footguns and you have to
> know a
> bit about what you're doing to make sure you get the effects you're after.
>

Perhaps a reminder in the text related to "np" that wildcards may cause
undesired results and leave it as an exercise for the implementor to learn
from that warning.

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

Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Wed, Jul 17, 2019 at 7:35 PM Scott Kitterman 
wrote:

> > On July 17, 2019 8:14:54 PM UTC, "Kurt Andersen (b)" 
> > wrote:
> > >Firstly, I'm a little concerned with the sentence which says 'Note that
> > >"np" will be ignored for DMARC records published on subdomains of
> > >Organizational Domains and PSDs due to the effect of the DMARC policy
> > >discovery mechanism described in DMARC [RFC7489] Section 6.6.3.' I
> > >don't
> > >think that is an accurate portrayal. When DMARC evaluation libraries
> > >are
> > >updated to do both PSD lookups and handle the np tag, I would expect
> > >the
> > >presence of np tags below the PSD level would be processed exactly the
> > >way
> > >that any other tag in a DMARC record is processed. np will only be
> > >ignored
> > >(per the terms of the DMARC spec) when it is an "unrecognized" tag. I
> > >realized that this text is sort of picked up from the current
> > >description
> > >of "sp", but the inclusion of "and PSDs" makes it inaccurate. You can't
> > >publish an np record on a non-existent Org domain or any subdomain
> > >thereof
>
> At first, I thought Kurt was right, but after further thought, I don't
> think
> so.
>
> To review the 'sp' definition that I took this from:
>
> Imagine sub.sub.example.com where example.com is the org domain.  If
> sub.sub.example.com has no DMARC record, then the next lookup is for a
> DMARC
> record at the org domain (example.com).  If sub.example.com has a DMARC
> record
> with an 'sp' tag, it's never retrieved.
>
> The same thing would apply to 'np' when used in a non--PSD context.  No
> different.
>
> Keeping in mind that our definition of non-existent is a domain that has
> none
> of A, , or MX.  It could have other types.  It could also have
> subdomains
> called "_dmarc" that have TXT records.  Non-existent domains (in our
> context)
> can have DMARC records, so I think the description is correct, but
> narrowly
> focused.
>

Most MTAs will also follow CNAMEs. Should they be included (along with
other things like DNAME records) within the scope of existence? I'm a
little concerned that we are making a special definition of "non-existence"
which differs from the standard DNS concepts of NODATA and NXDOMAIN without
having a correspondingly special name.


> Modifying the example I used above slightly:
>
> Imagine sub2.sub1.org.example where example has a PSD DMARC record with
> 'np',
> org.example has no DMARC record, sub1.org.example also has a DMARC record
> with
> 'np', and sub2.sub1.org.example has no DMARC record.  In this case, the
> policy
> lookup is for sub2.sub1.org.example (exact domain), org.example (org
> domain),
> and then example (PSD).  Just as with 'sp' and regular DMARC, 'np' (or
> 'sp')
> in non-org subdomains of PSDs don't get discovered.
>

I was considering the case of a domain such as
subX.sub1.org.pub2.pub1.example:
* subX (and sub1) domains would only have direct lookup DMARC records
applied if they exist and would fall back to org
* org would be direct unless it doesn't have a record in which case if fall
back to LPD (pub2's record)
* pub2, pub1, and example would only have direct lookups since they are
already above the PSL line <-- this is where my concern with the "and PSDs"
phrase resides

I'm not sure how well this maps to what we describe. I'm also concerned
that a wildcard null MX record at the org level would end up having all
subdomains "exist", but the policy that should be applied would be the more
restrictive "np" policy, not the (possibly) more permissive "sp" policy.

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

Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Wed, Jul 17, 2019 at 2:40 PM John Levine  wrote:

> In article  zsdwzvr...@mail.gmail.com> you write:
> >Firstly, I'm a little concerned with the sentence which says 'Note that
> >"np" will be ignored for DMARC records published on subdomains of
> >Organizational Domains and PSDs due to the effect of the DMARC policy
> >discovery mechanism described in DMARC [RFC7489] Section 6.6.3.' I don't
> >think that is an accurate portrayal. ...
>
> I think what it means is that if there's a DMARC record on a
> subdomain, it won't see any np= in the org domain or the PSD.  I agree
> the wording could be better.  I also don't understand what possible
> meaning an np= on a subdomain record would have.


np on a subdomain doesn't make any sense; np on an org domain would. I
think that just omitting the "and PSDs" would solve my concern unless the
use case of concern has to do with PSD subdomains that are still in the
public space. It's a question of distinguishing between LPD (longest public
domain) and PSDs in general.

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

Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Tue, Jul 16, 2019 at 10:07 PM Scott Kitterman 
wrote:

>
> Updated rfcdiff attached.  The only change other than typos is to add
> mention
> of 'np' to Appendix A.
>

Having reviewed the thread and the diff insofar as it pertains to the "np"
tag, I'm in favor of the "np defaults to sp" approach.

Generally, I think that the proposed text works, but have two concerns:

Firstly, I'm a little concerned with the sentence which says 'Note that
"np" will be ignored for DMARC records published on subdomains of
Organizational Domains and PSDs due to the effect of the DMARC policy
discovery mechanism described in DMARC [RFC7489] Section 6.6.3.' I don't
think that is an accurate portrayal. When DMARC evaluation libraries are
updated to do both PSD lookups and handle the np tag, I would expect the
presence of np tags below the PSD level would be processed exactly the way
that any other tag in a DMARC record is processed. np will only be ignored
(per the terms of the DMARC spec) when it is an "unrecognized" tag. I
realized that this text is sort of picked up from the current description
of "sp", but the inclusion of "and PSDs" makes it inaccurate. You can't
publish an np record on a non-existent Org domain or any subdomain thereof
:-)

Secondly, I think that we need to update the "p" and "sp" descriptions in
both 7489 sections 6.3 & 11.4:

   - p --> 'Policy applies to the domain queried and to subdomains, unless
   subdomain policy is explicitly described using the "sp" tag.' change to
   'Policy applies to the domain queried and to subdomains, unless subdomain
   policy is explicitly described using the "sp" or "np" tags.'
   - sp --> 'Requested Mail Receiver policy for all subdomains
   (plain-text; OPTIONAL).  Indicates the policy to be enacted by the Receiver
   at the request of the Domain Owner.  It applies only to subdomains of the
   domain queried and not to the domain itself.' change to 'Requested Mail
   Receiver policy for all subdomains (plain-text; OPTIONAL).  Indicates the
   policy to be enacted by the Receiver at the request of the Domain Owner.
   It applies only to subdomains of the domain queried if they exist or if
   there is not an "np" tag published. "sp" does not apply to the domain
   itself."

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

[dmarc-ietf] LC feedback on draft-ietf-dmarc-psd-04

[Kurt Andersen (b)]

Please note that I did not review Tim's comments in detail so some of the
following points may have been covered by him previously.

*Page 2 contains the following paragraph:*

   This memo provides a simple extension to DMARC [RFC7489
] to allow
   operators of Public Suffix Domains (PSDs) to express policy for
   groups of subdomains, extends the DMARC [RFC7489
] policy query
   functionality to detect and process such a policy, describes receiver
   feedback for such policies, and provides controls to mitigate
   potential privacy considerations associated with this extension.

This extension does not really allow PSDs to express policy for
"groups of subdomains" unless you take the perspective that "all or
none" are groups. Perhaps altering the language to say "...to express
policy that would apply to subdomains..."?

*The very end of section 1 says:*

   DMARC [RFC7489 ], by design,
does not support usage by PSOs.  For PSDs
   that require use of DMARC [RFC7489
], an extension of DMARC
reporting
   and enforcement capability is needed for PSO to effectively manage
   and monitor implementation of PSD requirements.

I still fail to see how this proposal is necessary (or, potentially
even useful) for the PSO to perform enforcement of their policies. I'd
recommend either deleting the entire paragraph or refocusing the
second sentence around the brand protective role that this proposal
brings for abuse of non-existent subdomains below the PSD.

*Section 2.2* "PSD DMARC includes all public domains..." --> suggest
"PSD DMARC applies to all public domains..."

*Section 2.6* "...that a receiver is willing to accept" seems like it
opens up a wide area if one applies considerations like
DNSSEC/DANE/MTA-STS/etc. There is a separate conversation on this
topic so I'll defer to that thread.

*Section 3* should include the new "np" keyword as an update to the DMARC spec.

*Section 3.5* This call-out makes it seem like information about
non-existent domains is not desirable and useful for org-level DMARC.
Can we modify the language to remove that implication? Perhaps "...is
desirable and useful, just as it is for org-level DMARC operators."

*Section 4* Neglects the privacy implications of broken "receiver is
willing to accept" conditions that may lead to additional leakage.
Also in the third bullet point, "it's feedback" should not have an
apostrophe.

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

Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Fri, Jul 12, 2019 at 10:50 AM Scott Kitterman 
wrote:

> On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote:
>
> > 3. If an np= tag is needed to allow PSD functioning for only NXDOMAINs
>
> The limited feedback during WGLC has been favorable to this.
>
> This will require a rather larger change to the document than the other
> issues, but they are manageable and I believe I have most of the relevant
> text
> from earlier revisions.
>
> I think we should include this.
>

I am much more concerned with adding another tag that can only be used in a
PSD-DMARC record. I would be much more open to make a "normative" change to
the DMARC tag list (RFC 7489 section 11.4) to define np for any DMARC
record, than to make this a special case for PSD-DMARC records.

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

Re: [dmarc-ietf] Working Group Last Call: draft-ietf-dmarc-psd

[Kurt Andersen (b)]

I, for one, would *really* like to see the rumored "next version" from
Scott and prefer to comment on that one, rather than an at-best penultimate
version.

--Kurt

On Wed, Jul 10, 2019 at 1:21 PM Seth Blank  wrote:

> There is one week left before WGLC closes, and the below three items still
> need resolution. Please speak up!
>
> -- Seth, as Secretary
>
> On Wed, Jun 26, 2019 at 2:21 PM Seth Blank  wrote:
>
>> As Secretary, there are three items that have not yet reached consensus
>> that must be resolved during WGLC:
>>
>> 1. What further context is needed in the introduction
>> 2. If explicit call outs to ICANN/limited operator capacity to implement
>> are needed
>> 3. If an np= tag is needed to allow PSD functioning for only NXDOMAINs
>>
>> Seth
>>
>> On Wed, Jun 26, 2019 at 2:08 PM Murray S. Kucherawy 
>> wrote:
>>
>>> This message begins Working Group Last Call for draft-ietf-dmarc-psd,
>>> which is currently at version 04.  An 05 may appear shortly with some text
>>> changes that were previously discussed on the list; these do not include
>>> any technical changes (I believe) so the author is free to update with only
>>> those changes as planned.
>>>
>>> Please review the document and submit your feedback by Wednesday, July
>>> 17th.  We would ideally like to have enough responses to support our claim
>>> to the IESG that the document clearly has working group consensus.
>>>
>>> Note that we will be in pre-meeting draft embargo at that time so a new
>>> version dealing with any feeback cannot appear until IETF 105 begins on the
>>> 22nd.
>>>
>>> I'm planning to do my own review as the document shepherd with an eye
>>> toward consumption by readers with only a passing familiarity with DMARC.
>>> If anyone wants to join me in looking at it through that lens, you'd be
>>> welcome.
>>>
>>> -MSK, co-chairin'
>>> ___
>>> dmarc mailing list
>>> dmarc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dmarc
>>>
>>
>>
>> --
>
> *Seth Blank* | Director, Industry Initiatives
> *e:* s...@valimail.com
> *p:* 415.273.8818
>
>
>
> 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 mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication

[Kurt Andersen (b)]

On Wed, Jun 12, 2019 at 4:58 PM Alessandro Vesely  wrote:

>
> Well, I personally use it and sometimes find it useful.[†]  For a better
> statistics, I have a DKIM add-on whose purpose is just to display some
> authentication status.  With 10,107 users, it ranks 61st of 1,339 in
> Thunderbird's most popular extensions.
>
> [†] I tag _nopass_ messages not matching /^Authentication-Results:.*pass/
> and
> color them gray in the thread pane.  Many of them can be deleted w/o
> opening.
> (But then I have more pass'es than DMARC provides for.)
>

Are you suggesting that you are a good proxy for a "typical" user of any
random MUA?

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