Re: [dmarc-ietf] Organizational Domain

On Mon, Jan 31, 2022 at 3:51 PM Alessandro Vesely wrote: > (This message is not going to be accepted by the IETF today, so I CC John > too) > Why wouldn't your email be accepted? > > On Sun 30/Jan/2022 05:25:30 +0100 Dave Crocker wrote: > >>> 3. The role of the function that uses the PSD and th

Re: [dmarc-ietf] Tree walk is not a heuristic, was screwed up

On Tue, Jan 25, 2022 at 12:40 PM John Levine wrote: > It appears that Scott Kitterman said: > >My impression is that the group is generally okay with PSD=y. I prefer > it over your suggestion. My strongest preference is that we pick > something, stick with it, and move on. > > I think I see w

Re: [dmarc-ietf] Tree walk is screwed up

On Sat, Jan 22, 2022 at 11:02 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > If a.b.example.com is considered aligned with c.example.com under > RFC7489, but will be considered unaligned under DMARCbis, then we have a > pretty significant incompatibility and need to move to DMAR

Re: [dmarc-ietf] Tree walk is screwed up

On Sat, Jan 22, 2022 at 6:52 AM Alessandro Vesely wrote: > > No, the concept of Organizational Domain is foundational to DMARC. We > cannot > overthrow it to spare an extra lookup. When we talked about tree walk we > knew > that additional lookups might well have come out. > > To specify that

Re: [dmarc-ietf] Evaluator reference model

On Tue, Jan 18, 2022 at 11:58 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Why should the protocol provide a carve-out for non-participating domains? > I would think that "non-participating domains" would be self explanatory. Non-participating is a choice not to participate,

Re: [dmarc-ietf] Section 5 - DKIM-only authentication

On Wed, Jan 5, 2022 at 11:33 AM John R Levine wrote: > > I have one bigger example back from the days when I was working for an > > ESP. The Situation was that a financial Institution decided to sign all > > their messages with DKIM and deploy a DMARC reject policy and an active > > decision agai

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

On Thu, Dec 16, 2021 at 12:58 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Yes, this is important stuff. > > This is one of my problem scenarios: > > A record arrives at the first hop and obtains DMARC PASS, based on SPF > and/or DKIM interpreted by a DMARC policy. Based on D

Re: [dmarc-ietf] dmarcbis-04, 4.7.1 and 4.7.2 Relaxed Alignment and Domain Hierarchy

On Tue, Dec 7, 2021 at 5:12 PM Todd Herr wrote: > On Tue, Dec 7, 2021 at 4:14 PM Dotzero wrote: > >> >> >> On Tue, Dec 7, 2021 at 4:00 PM Todd Herr > 40valimail@dmarc.ietf.org> wrote: >> >>> >>> Why do aspf=s and adkim=s not mitigate t

Re: [dmarc-ietf] dmarcbis-04, 4.7.1 and 4.7.2 Relaxed Alignment and Domain Hierarchy

On Tue, Dec 7, 2021 at 4:00 PM Todd Herr wrote: > On Tue, Dec 7, 2021 at 3:54 PM Dotzero wrote: > >> >> Let us consider that DNS is hierarchical. A subdomain cannot exist unless >> those responsible for the parent/organizational domain create it through >> DNS.

Re: [dmarc-ietf] dmarcbis-04, 4.7.1 and 4.7.2 Relaxed Alignment and Domain Hierarchy

Interesting responses to your post.. On Tue, Dec 7, 2021 at 7:37 AM Todd Herr wrote: > Greetings. > > I've been engaged in a spirited off-list discussion regarding the topic of > relaxed alignment and the idea of a required relationship between two > domains in relaxed alignment. I won't reveal

Re: [dmarc-ietf] Minutes from IETF 112

On Thu, Nov 18, 2021 at 3:51 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Don't the alignment rules allow any DKIM signature for the organization to > validate any FROM address for the organization -- up, down, or sideways? > > To use the sideways example, this means that an R

Re: [dmarc-ietf] same old org domain, Topic for IETF 112 - Policy Discovery

On Mon, Nov 1, 2021 at 6:08 PM Tobias Herkula wrote: > Yes this is used in a significant way, dropping the mechanic of the > org-domain would make a lot of things in processing inbound mail streams a > lot more complicated. > > The PSL does not exists for DKIM or DMARC, it is a product of the CAB

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

On Sun, Oct 31, 2021 at 1:03 PM Scott Kitterman wrote: > Perhaps it's a pointless semantic distinction. I think of DMARC as a > mechanism for expressing policy about authentication, not an authentication > method. > > I still don't understand what you think is unprotected. > > Scott K > +1 DMA

[dmarc-ietf] Some DMARC data

Straight from the DMARC.org website: https://dmarc.org/2021/10/dmarc-policies-increase-28-through-june-2021/ (overall adoption/publishing of records) https://dmarc.org/stats/farsight/dmarc/ (breakout of records by policy) Michael Hammer ___ dmarc maili

Re: [dmarc-ietf] Experiments

On Mon, Sep 27, 2021 at 6:29 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > If a domain has an enforceable DMARC policy, and the message has no > signature, then the policy interpretation would be equivalent to a "DO NOT > FORWARD" order on postal mail. > > We expect that this a

Re: [dmarc-ietf] Proposing p=validate, another DMARC improvement to better support indirect mail flows

On Mon, Sep 20, 2021 at 2:32 PM Scott Kitterman wrote: > > That's not specified in RFC 7489, so it's an assumption that this is how > the > world works. At best it's undefined and I don't think we can engineer > interoperability based on assumptions about how current implementations > address un

Re: [dmarc-ietf] Round Two: Ticket #66 (Define What It Means to Have Implemented DMARC) and #62 (Reporting a MUST)

On Thu, Sep 9, 2021 at 11:56 PM Scott Kitterman wrote: > As I understand it, it is not typical IETF practice to do conformance > specifications. The IETF practice is to define requirements for > interoperability. > > I think that the whole section should just go. It's not the IETF's job to > s

Re: [dmarc-ietf] Ticket #66 (Define What It Means to Have Implemented DMARC) and #62 (Reporting a MUST)

I'm troubled by this whole section. Unless IETF is getting into the certification or enforcement business, documenting anything about "implementation claims" would seem to be a non-starter. Do we have any similar requirements for "claims" about implementing SMTP, DNS or other standards? We should s

Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion

On Mon, Aug 2, 2021 at 3:49 PM Todd Herr wrote: > > On Sat, Jul 31, 2021 at 4:38 PM John Levine wrote: > >> I'd make it a lot simpler: >> >>pct: (plain-text integer; OPTIONAL; default is 100). For the >> RFC5322.From domain to which the DMARC record applies, the "pct" >> tag de

Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99

On Tue, Jul 20, 2021 at 4:13 PM Barry Leiba wrote: > One of the points of "deprecation" is that we don't eliminate it > entirely, but say that it's no longer used. New implementations no > longer generate it, but implementations that are interested in > backward compatibility will still include

Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99

On Tue, Jul 20, 2021 at 12:39 PM Dave Crocker wrote: > On 7/20/2021 7:54 AM, Barry Leiba wrote: > > I would like to see us deprecate PCT entirely, > > +1 > > d/ > > -- > Dave Crocker > dcroc...@gmail.com > 408.329.0791 > +1 Michael Hammer ___ dmarc ma

Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language

On Wed, Jun 16, 2021 at 2:02 PM John Levine wrote: > It appears that Alessandro Vesely said: > >It might make sense to reject that ~30% which doesn't even have an > >organizational domain (dubbed totally astray in my previous post). But I > still > >receive From: on a mailing list. > Rejectin

Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language

On Sat, Jun 12, 2021 at 8:56 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Below is my proposed language for dealing with the problems that NP is > intended to address: > - unused DNS names > - non-existent DNS names > > It provides supporting rationale, and provides a more com

Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

On Thu, Jun 3, 2021 at 8:48 AM Brotman, Alex wrote: > Hello folks, > > During our interim call last week the topic of extensions within the DMARC > aggregate report came up. There was a discussion about how to best > introduce these, but also how they might be best used. I noted three cases > t

Re: [dmarc-ietf] Consensus Sought - Ticket #47 (Removal of "pct" tag) - With Interim Notes

On Thu, Jun 3, 2021 at 6:17 PM John Levine wrote: > It appears that Alessandro Vesely said: > >On Thu 03/Jun/2021 05:45:33 +0200 Murray S. Kucherawy wrote: > >> I don't understand what "demeaning a domain's policy" means. > > > >I meant to say that p=quarantine; pct=0 is to be considered a stri

Re: [dmarc-ietf] Consensus Sought - Ticket #50 (Remove ri= tag) - With Interim Notes

On Fri, May 28, 2021 at 1:59 PM John Levine wrote: > It appears that Tim Wicinski said: > >-=-=-=-=-=- > > > >All, > > > >This is the current text in Section 10.4 of dmarc-bis > > > > Names of DMARC tags must be registered with IANA in this new sub- > > registry. New entries are assigned o

Re: [dmarc-ietf] Consensus Sought - Ticket #82 (Deprecate rf= and maybe fo= tag) - With Interim Notes

On Fri, May 28, 2021 at 1:32 PM Alessandro Vesely wrote: > On Fri 28/May/2021 17:47:25 +0200 Todd Herr wrote: > > > > Consensus on Ticket #82 > (Deprecate > > rf= and maybe fo= tag) was reached during the May 27 DMARC Interim to > remove > > the "rf" t

Re: [dmarc-ietf] Consensus Sought - Ticket #54 (Limits on recipients per report) - With Interim Notes

On Fri, May 28, 2021 at 2:03 PM John Levine wrote: > It appears that Alessandro Vesely said: > >On Fri 28/May/2021 17:46:54 +0200 Todd Herr wrote: > >> Greetings. > >> > >> Consensus on Ticket #54 > (Remove or > >> expand limits on number of recipien

Re: [dmarc-ietf] Consensus Sought - Ticket #53 (Remove reporting message size chunking) - With Interim Notes

On Fri, May 28, 2021 at 2:01 PM John Levine wrote: > It appears that Alessandro Vesely said: > >On Fri 28/May/2021 17:46:20 +0200 Todd Herr wrote: > >> > >> Consensus on Ticket #53 > (Remove > >> reporting message size chunking) was reached during th

Re: [dmarc-ietf] Consensus Sought - Ticket #4 (Definition of "fo" parameter) - With Interim Notes

On Fri, May 28, 2021 at 1:41 PM John Levine wrote: > It appears that Alessandro Vesely said: > >On Fri 28/May/2021 17:43:09 +0200 Todd Herr wrote: > >> The value of this tag is either "0", "1", or a colon-separated list > of the > >> options represented by alphabetic characters. > > > >

Re: [dmarc-ietf] Ticket #113 - DMARCbis -01 Introduction Section

Overall I'm comfortable with the introduction verbiage. I do have one concern: "For a mail-receiving organization supporting DMARC, a message that passes validation is part of a message stream that is reliably associated with the Domain Owner and/or any, some, or all of the Authenticat

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

On Thu, May 6, 2021 at 12:27 AM Seth Blank wrote: > WG colleagues, > > We committed to holding an interim meeting after the DMARCbis documents > were delivered, and cancelled our IETF 110 meeting to make space for the > design team to work. > > We now have new documents from the design team, and

Re: [dmarc-ietf] Sender vs From Addresses

On Thu, Mar 25, 2021 at 5:53 PM John R Levine wrote: > >>> It is a problem when receiving servers use DMARC existence and > >>> pass/fail to increase/decrease deliverability rates. - And when > >>> Yahoo/AOL pretty much block everything you send - even with a 98 > >>> sender score, SPF, DKIM, and

Re: [dmarc-ietf] Announcement - DMARC bis Design Team

So I'm assuming there won't be anything to talk about at the next IETF meeting. Michael Hammer On Mon, Feb 22, 2021 at 12:59 PM Seth Blank wrote: > On 27 October 2020, in post > https://mailarchive.ietf.org/arch/msg/dmarc/qtCDyGbeDHz96G8FaCxJvhJKrvo/ > the chairs announced a split of RFC7489 in

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

I'm comfortable with the language. Michael Hammer On Thu, Feb 18, 2021 at 3:40 PM Brotman, Alex wrote: > Aggregated comments: > > -- > Aggregate feedback reports contain aggregated data relating to messages > purportedly originating from the Domain Owner. The data does n

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

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. Mihael Hammer ___

Re: [dmarc-ietf] Forensic report loops are a problem

On Mon, Feb 1, 2021 at 6:49 PM Michael Thomas wrote: > > > On 2/1/21 3:23 PM, Dave Crocker wrote: > > On 2/1/2021 3:21 PM, John Levine wrote: > >> I find it hard to believe that if you are going to enough effort to > >> maintain the data to create and send reports, you can't figure out how > >> t

Re: [dmarc-ietf] Report bombing is a prolem, Forensic report loops are not

On Sun, Jan 31, 2021 at 3:02 PM John Levine wrote: > In article <49b248dc-91a7-7f2d-ba28-72fe8d6d3...@tana.it> you write: > >Rate limiting usually implies a number of buckets. They are managed by > >imposing limits per time periods, which can be either server-global or > per > >bucket. Normally

Re: [dmarc-ietf] A policy weaker than quarantine, yet better than none

On Mon, Jan 18, 2021 at 2:14 PM Alessandro Vesely wrote: > > On Mon 18/Jan/2021 19:56:21 +0100 John Levine wrote: > > > > >> BTW, the current spec does not mean that an invalid p= implies the > >> DMARC record is broken. If it did, it wouldn't say to check rua= in > >> that case. > > > > I know.

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

On Wed, Jan 6, 2021 at 10:07 AM Michael Thomas wrote: > > On 1/6/21 6:59 AM, Dotzero wrote: > > > > On Wed, Jan 6, 2021 at 9:41 AM Michael Thomas wrote: > >> >> On 1/5/21 10:02 PM, Dotzero wrote: >> >> >> >> On Tue, Jan 5, 2021 at 8:19 P

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

On Wed, Jan 6, 2021 at 9:41 AM Michael Thomas wrote: > > On 1/5/21 10:02 PM, Dotzero wrote: > > > > On Tue, Jan 5, 2021 at 8:19 PM Michael Thomas wrote: > > >> No it was an unalloyed good that you brought that up. We can use a much >> more data-driven approac

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

On Tue, Jan 5, 2021 at 8:19 PM Michael Thomas wrote: > No it was an unalloyed good that you brought that up. We can use a much > more data-driven approach rather than opinion and conjecture. It would > be good for it to be required reading for everybody on this working > group, and not snarled a

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

On Wed, Dec 30, 2020 at 11:30 AM Michael Thomas wrote: > > On 12/30/20 8:22 AM, Dotzero wrote: > > > DMARC != Auth-res. Auth-res provides all kinds of useful information than >> just pass/fail. For DMARC Auth-res should provide what the policy was at a >> bare minimum

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

On Wed, Dec 30, 2020 at 10:41 AM Michael Thomas wrote: > > On 12/30/20 7:35 AM, Todd Herr wrote: > > On Wed, Dec 30, 2020 at 9:01 AM Michael Thomas wrote: > >> >> On 12/30/20 5:48 AM, Todd Herr wrote: >> >> >> I propose to add two new result name codes, named after the policy >>> requests: >>> >

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

Absolutely agree with Todd's analysis and comments. +1 Michael Hammer On Wed, Dec 30, 2020 at 8:48 AM Todd Herr wrote: > On Wed, Dec 30, 2020 at 4:42 AM Alessandro Vesely wrote: > >> On Tue 29/Dec/2020 22:02:20 +0100 Michael Thomas wrote: >> > On 12/29/20 12:47 PM, Todd Herr wrote: >> >>> Unle

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

On Mon, Dec 28, 2020 at 8:30 AM Todd Herr wrote: > On Thu, Dec 24, 2020 at 1:55 PM John R Levine wrote: > >> >> Security considerations >> >> Failure reports provide detailed information about the failure of a >> single message or a group of similar messages failing for the same >> reason. They

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

On Wed, Dec 23, 2020 at 4:52 PM Murray S. Kucherawy wrote: > On Wed, Dec 23, 2020 at 12:08 PM John R Levine wrote: > >> > Failing that, I have another proposal to consider that might aid us in >> > shipping a standards track DMARC sooner: Remove any and all mention of >> > failure reports, and d

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

On Tue, Dec 22, 2020 at 11:39 AM John R Levine wrote: > I think that text is way too long and overspecific but we've already spent > too much time on this so I'll stop and see if there are other opinions. > > > On Tue, 22 Dec 2020, Alessandro Vesely wrote: > > OLD > > > > "Failure reports," or

Re: [dmarc-ietf] ARC vs p=quarantine

On Sat, Dec 19, 2020 at 2:50 PM John Levine wrote: > In article <1e61f7c4-c6d2-5dab-dfc7-f1fd740e1...@tana.it> you write: > >Now my tiny MX stores 115,225 domains total. And I have no idea how I > could > >add a trust-ARC-seals boolean field to each domain record. > > You wouldn't. Only a small

Re: [dmarc-ietf] p=quarantine

On Mon, Dec 14, 2020 at 10:26 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Sorry about the confusion caused by my typing failures. > What I meant: > First party - From address aligns with SMTP address. Can be validated > with SPF or DKIM. > Third party - From address and SMTP

Re: [dmarc-ietf] p=quarantine

On Sun, Dec 13, 2020 at 4:45 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Based on this discussion, it seems evident that p=reject should include > language about in-transit modifications which are outside the control of > the source domain, and consequently outside the abilit

Re: [dmarc-ietf] p=quarantine

On Fri, Dec 11, 2020 at 11:11 AM Hector Santos wrote: > We are not doing reporting at this > time. Not the main focus. That can come later as an augmented > feature, in fact, we might consider it as a paid service to be sending > thousands report out to domains. > That's good community spirit.

Re: [dmarc-ietf] p=quarantine

On Tue, Dec 8, 2020 at 2:42 PM Dave Crocker wrote: > On 12/8/2020 10:50 AM, Dotzero wrote: > > And here we get to some of the crucial unresolved questions involving > > email: "Does the wishes of a user of an account at a domain supercede > > the policies of the domai

Re: [dmarc-ietf] p=quarantine

On Tue, Dec 8, 2020 at 12:42 PM Michael Thomas wrote: > > If you take the literal meaning of quarantine, that means that every > piece of email from this and every other mailing list would end up in a > quarantine folder, or some such. I'm fairly certain that is not what > people want, and I'm do

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

On Mon, Dec 7, 2020 at 4:41 PM John Levine wrote: > >I don't understand the security or GDPR references. > > Well this is amusing. I wondered if anyone had ever implemented some > version of the http reporting in early DMARC drafts, so I set up a new > domain > with a server that will accept POST

Re: [dmarc-ietf] ARC vs reject

On Mon, Dec 7, 2020 at 12:30 AM Murray S. Kucherawy wrote: > On Sun, Dec 6, 2020 at 9:24 PM Michael Thomas wrote: > >> An idea that i've been rolling around in my head is that the MLM could >> give a sed-like script to rollback the changes. since they know their >> modifications, they can obviou

Re: [dmarc-ietf] DMARC and ARC

On Mon, Dec 7, 2020 at 12:15 AM Murray S. Kucherawy wrote: > On Fri, Dec 4, 2020 at 7:58 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> First, lets begin with the obvious: malicious messages come from >> enterprises that are in the malicious message business. They rare

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

On Mon, Dec 7, 2020 at 2:18 AM Murray S. Kucherawy wrote: > On Tue, Dec 1, 2020 at 2:22 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 https reporting. Early drafts of the DMA

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

On Mon, Dec 7, 2020 at 2:13 AM 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 refere

Re: [dmarc-ietf] is DMARC informational?

On Sun, Dec 6, 2020 at 8:58 AM Murray S. Kucherawy wrote: > On Sun, Dec 6, 2020 at 5:09 AM Alessandro Vesely wrote: > >> On chartering the WG in 2013, the decision was made to publish DMARC as >> independent submission, even though it was going to be discussed and >> reach >> consensus of a IETF

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

On Wed, Dec 2, 2020 at 5:35 PM Benny Lyne Amorsen wrote: > Dotzero writes: > > > p= DID NOT mistakenly choose to use the language of receiver > > actions. p= represents the domain-owner request to the receiver as to > > the disposition of messages which fail to

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

On Wed, Dec 2, 2020 at 9:29 AM Benny Lyne Amorsen wrote: > Dave Crocker writes: > > > p: Domain Owner Assessment Policy (plain-text; REQUIRED for policy > > records). Indicates the severity of concern the domain owner has, for > > mail using its domain but not passing DMARC validation. Policy

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

You are absolutely correct. It also doesn't prevent direct domain abuse when someone uses snail mail. Michael Hammer On Tue, Dec 1, 2020 at 10:09 PM Dave Crocker wrote: > On 12/1/2020 7:01 PM, Dotzero wrote: > > DMARC does one thing and one thing only - It mitigates direct do

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

On Tue, Dec 1, 2020 at 8:43 PM Steven M Jones wrote: > On 12/1/20 4:16 PM, Douglas Foster wrote: > > > > I have always assumed that p=quarantine and pct<>100 were included to > > provide political cover for "Nervous Nellies" who were afraid to > > enable p=reject. > > p=none, p=quarantine, and th

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

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/20

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

On Fri, Nov 13, 2020 at 9:46 AM Joseph Brennan wrote: > > >>> As another case, would people be surprised that email for the medical >>> center cumc.columbia.edu is a separate system managed by a separate IT >>> group from columbia.edu, and that any authentication for one should not >>> be applied

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

On Thu, Nov 12, 2020 at 9:24 AM Joseph Brennan wrote: > > > On Wed, Nov 11, 2020 at 4:21 PM Dave Crocker wrote: > >> >> Just to invoke a bit of ancient history, here, you are saying that if >> there was the domain name: >> >> engineering.sun.com >> >> people would be surprised that the organ

Re: [dmarc-ietf] On splitting documents

On Tue, Nov 10, 2020 at 8:06 PM Murray S. Kucherawy wrote: > Not to lob monkey wrenches around, but at one point we were talking about > putting the determination of the Organizational Domain into a separate > document. I think it was Dave who suggested it. This would allow for > simple augment

Re: [dmarc-ietf] Optional p= makes no sense

On Mon, Nov 9, 2020 at 9:05 AM Dave Crocker wrote: > On 11/9/2020 4:15 AM, Alessandro Vesely wrote: > > Invalid or repeated p= tags are a problem, but possibly they don't > > completely disqualify a record. > > > The concept of 'partial' disqualification points to the problem of > trying to be su

Re: [dmarc-ietf] Optional p= makes no sense

.. > > p=none probably means "I am trying to get my administrative controls in > place, but I am not there yet", which still supports my earlier comment > that "I don't know how to advise you on whether to accept or reject this > message". > p=none simply means "This domain is not asserting polic

Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports

On Wed, Oct 14, 2020 at 2:17 PM Brotman, Alex wrote: > During a session at M3AAWG50, one of the other participants proposed an > idea where a sender could optionally send reports to a domain holder when > they send messages on behalf of that domain. > > Let's consider the idea that example.com ha

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

On Tue, Sep 29, 2020 at 1:26 PM Dave Crocker wrote: > On 9/29/2020 6:40 AM, Hector Santos wrote: > > On 9/27/2020 11:44 PM, Dave Crocker wrote: > > DKIM has a single signature binding requirement, the 5322.From > >> DMARC establishes the relationship. > > I don't read it that way. > > > > DKIM bi

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

On Tue, Sep 29, 2020 at 6:15 AM Alessandro Vesely wrote: > On Tue 29/Sep/2020 05:40:13 +0200 Seth Blank wrote: > > I'm hearing consensus that an aggregate report should retain a > disposition > > of "none" when the dmarc policy is "none", but when the policy is > > quarantine or reject, "pass" sh

Re: [dmarc-ietf] Can we consider some process changes to speed attainment of conclusions?

+1 I'd also like to see calls for consensus rather than a declaration of consensus by the chairs based on posts from a very small minority of the members of the list. Michael Hammer. On Fri, Sep 25, 2020 at 2:01 PM Kurt Andersen (IETF) wrote: > It seems like the chairs have been relatively _la

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

On Thu, Sep 24, 2020 at 12:52 PM John Levine wrote: > Personally, I have no interest in defining this stuff but in practice, > there are a lot of places where people are instructed to "implement > DMARC", and it would be nice to encourage them to do more than publish > a lame SPF record and p=rej

Re: [dmarc-ietf] Issue submission - Mailing list security and potential solutions using DMARC

On Tue, Sep 15, 2020 at 12:02 PM Joseph Brennan wrote: > > > On Tue, Sep 15, 2020 at 11:55 AM John Levine wrote: > >> In article > bnk2_ckmn...@mail.gmail.com>, >> Joseph Brennan wrote: >> >"Domain administrators must not apply dmarc authentication to domains >> >from which end users send mail

Re: [dmarc-ietf] Issue submission - Mailing list security and potential solutions using DMARC

This proposal is way outside the scope of DMARC and the scope of the effort for this group. Let's not try to boil the ocean. Michael Hammer On Thu, Sep 10, 2020 at 6:51 PM Douglas E. Foster wrote: > Recently, I have become worried about the risks associated with using my > regular email on this

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

> -- > *From*: Jim Fenton > *Sent*: 8/26/20 5:01 PM > *To*: Dotzero > *Cc*: IETF DMARC WG > *Subject*: Re: [dmarc-ietf] third party authorization, not, was > non-mailing list > On 8/26/20 10:54 AM, Dotzero wrote: > > > > On Wed, Aug 2

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

On Wed, Aug 26, 2020 at 5:00 PM Jim Fenton wrote: > On 8/26/20 10:54 AM, Dotzero wrote: > > > > On Wed, Aug 26, 2020 at 1:32 PM Doug Foster 40bayviewphysicians@dmarc.ietf.org> wrote: > >> Are the weak signatures vulnerable to a replay attack?I thought that

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

On Wed, Aug 26, 2020 at 1:32 PM Doug Foster wrote: > Are the weak signatures vulnerable to a replay attack?I thought that > one of the reasons that DKIM signatures included the whole body was to > prevent the signature from being reused. > > > > DF > Not particularly vulnerable. The requirem

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

On Tue, Aug 25, 2020 at 2:13 PM John R Levine wrote: > On Tue, 25 Aug 2020, Dotzero wrote: > >>> I would expect there to be multiple potential approaches to identifying > >>> acceptable intermediaries. > >> > >> The harder part is to decide which in

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

On Tue, Aug 25, 2020 at 12:22 PM John R Levine wrote: > On Tue, 25 Aug 2020, Dotzero wrote: > >> https://tools.ietf.org/html/draft-levine-dkim-conditional-00? > > > Under my concept, all mail would still be signed in full. The weak > > signature would be in addition to

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

On Tue, Aug 25, 2020 at 5:48 AM Laura Atkins wrote: > > > On 24 Aug 2020, at 23:34, Douglas E. Foster < > fosterd=40bayviewphysicians@dmarc.ietf.org> wrote: > > Something seems inconsistent: > > - The people who have implemented DMARC do not see any significant > problems, and as a result the

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

On Tue, Aug 25, 2020 at 5:03 AM Alessandro Vesely wrote: > On Mon 24/Aug/2020 19:24:03 +0200 John Levine wrote: > > In article 8qgy3wky...@mail.gmail.com> you write: > >>> If the intermediary DKIM signs the modified message with their own > >>> signature, that provides some assurance to the rece

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

On Mon, Aug 24, 2020 at 6:34 PM Douglas E. Foster wrote: > Something seems inconsistent: > > - The people who have implemented DMARC do not see any significant > problems, and as a result they are not interested in a third-party > authorization scheme. > > - Yet adoption is very slow, especially

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

On Thursday, August 20, 2020, Jesse Thompson wrote: > On 8/20/20 4:00 PM, blong=40google@dmarc.ietf.org wrote: > > Neither atps or spf include are really designed for large scale usage > > That's my conclusion, as well. I don't want to authorize every potential > MLM to use all addresses in

Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01

On Wednesday, August 19, 2020, John R Levine wrote: > On Wed, 19 Aug 2020, Dotzero wrote: > >> Then Ericcson as an organization has made a decision regardless of the >> objections of those employees. The correct thing for Ericcson as an >> organization to do is to publish

Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01

On Wednesday, August 19, 2020, John R Levine wrote: > On Wed, 19 Aug 2020, Dotzero wrote: > >> If the people you claim don't want the outcome they have as a result of >> the >> DMARC policy that they published then maybe they should publish a >> diffe

Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01

On Tuesday, August 18, 2020, John Levine wrote: > In article mail.gmail.com> you write: > >This is just wrong. While I appreciate the enthusiasm for using the Sender > >field, unless there is a mechanism for establishing a relationship between > >the From domain and the Sender domain then we hav

Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01

On Tuesday, August 18, 2020, Dave Crocker wrote: > On 8/18/2020 12:48 PM, Todd Herr wrote: > >> The race condition here is in item 5, "Emails that fail the DMARC >> mechanism check are disposed of in accordance with the discovered DMARC >> policy of the Domain Owner", specifically when both the S

Re: [dmarc-ietf] DMARC failure scenarios

On Tue, Aug 18, 2020 at 6:49 AM Douglas E. Foster wrote: > You cannot make sense of it, John. I understand the difference between > submssion and SMTP. > > The asserted increase in complexity is not from adding a single signature, > it is the requirement to apply a different signature to every

Re: [dmarc-ietf] Time for a change

On Mon, Aug 17, 2020 at 9:09 PM Dave Crocker wrote: > > DKIM was a synthesis within the IETF of two things (DomainKeys and IIM) > that started outside. It underwent significant evolution in the IETF -- > not once, but twice. > > Actually, it wasn't. > > The constituent parts were separately pro

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

On Mon, Aug 17, 2020 at 2:28 PM Dave Crocker wrote: > On 8/17/2020 11:26 AM, Rolf E. Sonneveld wrote: > >> Michael Hammer (Inaccurately referred to by you as Herr Hammer) > > > > Talking about precise language, Dave, I think you owe Michael an apology > ;-) > > > to mix languages, au contraire.

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

On Mon, Aug 17, 2020 at 10:37 AM Dave Crocker wrote: > On 8/17/2020 7:33 AM, Dotzero wrote: > > DMARC fixes one thing and one thing only, direct domain abuse. > > > It does no such thing. Domains can still be 'directly' abused in all > sorts of ways that DMARC doe

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

On Mon, Aug 17, 2020 at 10:27 AM Dave Crocker wrote: > On 8/17/2020 7:00 AM, Laura Atkins wrote: > > I think the most > useful thing we can say about the FTC workshops is that they were a > forcing mechanism that instigated a lot of effort and innovation in the > space. Some of those efforts fel

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

On Mon, Aug 17, 2020 at 10:01 AM Laura Atkins wrote: > > > On 17 Aug 2020, at 14:18, Dotzero wrote: > >> >> And, 17 years on, we know that domain level authentication doesn’t >> actually help filter spam nor does it provide law enforcement with a potent >&g

Re: [dmarc-ietf] Time for a change

On Sun, Aug 16, 2020 at 3:09 PM Douglas E. Foster wrote: > > The reality is that IETF has mostly provided followership, not leadership, > on matters of security. This forum is replicating history. As has been > mentioned in the historical review, SPF, DKIM, and DMARC were independently > succe

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

On Mon, Aug 17, 2020 at 8:22 AM Laura Atkins wrote: > > > On 17 Aug 2020, at 12:25, Alessandro Vesely wrote: > > On Mon 17/Aug/2020 11:46:55 +0200 Laura Atkins wrote: > > > The forum page is off the FTC website, but the document links are > still accessible: > > > > A copy is here: > > https://w

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

On Mon, Aug 17, 2020 at 5:58 AM Alessandro Vesely wrote: > On Sun 16/Aug/2020 20:16:17 +0200 Dave Crocker wrote: > > > > If I put my gmail address into the from field, there is no > > pretending, no matter what platform I am using. > > > That conflicts with the coarse-grain

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

On Sun, Aug 16, 2020 at 2:17 PM John R Levine wrote: > > No, it was just some political theatre. We were already working on SPF > and DKIM. > DKIM didn't exist until that approximate time frame. There was Domain Keys (DK) and there was Internet Identified Mail (IIM) > > > DMARC took that stra

<    1   2   3   >