[dmarc-ietf] Messages from the dmarc list for the week ending Sun Feb 20 06:00:25 2022

Count| Bytes | Who ++--- 21 ( 100%) | 231492 ( 100%) | Total 8 (38.1%) | 46209 (20.0%) | John Levine 4 (19.0%) | 78177 (33.8%) | Todd Herr 3 (14.3%) | 19534 ( 8.4%) | Alessandro Vesely 2 ( 9.5%) | 37258 (16.1%) | Douglas Foster 2

Re: [dmarc-ietf] Let's Work on the Tree Walk Text

It appears that Alessandro Vesely said: >If they have MX and non-trivial SPF records, they probably are using the >domain >to send and receive mail. Yet, they also host independent subdomains. IMHO, >we should trait u...@us.com as a regular domain, without the limitations we >apply to

Re: [dmarc-ietf] Let's Work on the Tree Walk Text

It appears that Todd Herr said: >The process for a DNS Tree Walk will always start at the point in the DNS >hierarchy that matches the domain in the RFC5322.From header of the >message, and [will always end no later than the Public Suffix Domain that >terminates the RFC5322.From domain. ] I

Re: [dmarc-ietf] Figuring out the tree walk

It appears that Scott Kitterman quoted: >>- If there's evidence of intent, then the argument is "The >> definition of alignment needs to change, because the current >> definition isn't what the authors intended and it exposes domains to >> security/abuse risks." >>- If not, then the

Re: [dmarc-ietf] Figuring out the tree walk

It appears that Scott Kitterman said: >> b. walk up from both, stop at the first DMARC record. If they're at >> the same name and it's not a PSD, they are aligned and that's the org domain >> >> b+. walk up from both, if the DMARC records are at the same name, it has >> psd=y, and they have

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Feb 13 06:00:19 2022

Count| Bytes | Who ++--- 18 ( 100%) | 146682 ( 100%) | Total 6 (33.3%) | 57289 (39.1%) | Douglas Foster 3 (16.7%) | 13881 ( 9.5%) | John Levine 2 (11.1%) | 18697 (12.7%) | Dotzero 2 (11.1%) | 11724 ( 8.0%) | Alessandro Vesely 2

Re: [dmarc-ietf] 7.1 SPF -ALL

It appears that Dotzero said: >> I agree with Ale. Further, it is not as if we are considering this in a >vacuum. Since originally being made public, DMARC has been widely >implemented and it has not been identified that this (early reject on SPF >-all) has been a significant or even an

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Feb 6 06:00:57 2022

Crocker 2 (10.0%) | 9126 ( 6.0%) | John Levine 1 ( 5.0%) | 9480 ( 6.3%) | Dotzero 1 ( 5.0%) | 9320 ( 6.1%) | Todd Herr 1 ( 5.0%) | 5800 ( 3.8%) | Barry Leiba 1 ( 5.0%) | 2965 ( 2.0%) | ___ dmarc mailing list dmarc@ietf.org https

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Jan 30 06:00:08 2022

Count| Bytes | Who ++--- 63 ( 100%) | 492703 ( 100%) | Total 15 (23.8%) | 76536 (15.5%) | John Levine 13 (20.6%) | 132062 (26.8%) | Scott Kitterman 13 (20.6%) | 95551 (19.4%) | Dave Crocker 7 (11.1%) | 42852 ( 8.7%) | Alessandro Vesely

Re: [dmarc-ietf] Organizational Domain

It appears that Dave Crocker said: >Here is some alternative phrasing: > >For DMARC, an Organizational Domain can contain a DMARC record, to >be used as the default DMARC record for subordinate domains that do >not have a DMARC record of their own, and for subordinate domains >

Re: [dmarc-ietf] tree walk is experimental

It appears that Dave Crocker said: >-=-=-=-=-=- > >G'day. > >The method of finding the organizational domain should be specified >outside of the base DMARC specification.  I suggested this back during >the PSD discussion. That assumes that the org domain is useful on its own, rather than just

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

It appears that Steve Siirila said: >-=-=-=-=-=- > >After reading this thread, I couldn't help but wonder about how the >addition of a "PSD flag" specifically targeted to DMARC might be repurposed >for other non-DMARC applications since my understanding is that the PSL is >currently being used

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

It appears that Alessandro Vesely said: >As John said, the gap is that PSD domains are not going to publish >psd=y. No, that is not at all what I said. Most PSDs will publish no DMARC record at all. Based on what Scott has said, the handful that do publish a DMARC record will indeed include

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

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 where Ale's confusion is coming from. If we switch to a tree

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

It appears that Scott Kitterman said: >What I implemented is roughly: > >For policy determination, first check the From domain, if that has a DMARC >record, then that's the policy domain. Otherwise, tree walk up to the apex >looking for DMARC records. First domain you find with a record is

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Jan 23 06:00:07 2022

Count| Bytes | Who ++--- 58 ( 100%) | 559681 ( 100%) | Total 14 (24.1%) | 187601 (33.5%) | Douglas Foster 9 (15.5%) | 46823 ( 8.4%) | John Levine 8 (13.8%) | 109291 (19.5%) | Todd Herr 7 (12.1%) | 79928 (14.3%) | Scott Kitterman 7

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

It appears that Alessandro Vesely said: >On Wed 19/Jan/2022 19:38:15 +0100 John Levine wrote: >> What I always intended with the tree walk is that you walk up the tree and >> if you find >> a DMARC record that isn't a PSD, that's your org domain. To see if two &g

[dmarc-ietf] Tree walk is screwed up

I took a look at sections 4.5 and 4.6 of the draft, the part that describes the tree walk and PSD, and unfortunately what it currently says is seriously wrong. Apologies for not catching this sooner. It currently says you do a tree walk to find a PSD record, and the org domain is the one

Re: [dmarc-ietf] in praise of none, was Evaluator reference model

It appears that Alessandro Vesely said: >> I would agree except for the word "yet". For most of my domains I have no >> intention of ever publishing a policy other than p=none. >My understanding is that some users of your domain(s) use your MXes but, >occasionally or consistently, use a

Re: [dmarc-ietf] in praise of none, was Evaluator reference model

It appears that Todd Herr said: >A policy of "none" isn't useless to an evaluator; it's communicating to the >evaluator that the domain owner isn't yet confident that all mail sent >using its domain in the RFC5322.From header is properly authenticated, and >so messages that fail the DMARC

Re: [dmarc-ietf] What is a PSD for, was Evaluator reference model

It appears that Todd Herr said: >If the intent of the tree walk is, at least in part, to allow for >publishing of policy records at the PSD level and for those records to be >inherited by existing subdomains (e.g., _dmarc.tld is inherited by >domain.tld if domain.tld does not publish its own

Re: [dmarc-ietf] Evaluator reference model

It appears that Dave Crocker said: >-=-=-=-=-=- > >On 1/18/2022 5:51 AM, Todd Herr wrote: >> I don't agree with the goal statement here, because it implies to me >> that all messages that pass DMARC validation are safe and wanted, >> while all messages that do not pass DMARC validation are

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Jan 9 06:00:07 2022

Count| Bytes | Who ++--- 28 ( 100%) | 260018 ( 100%) | Total 8 (28.6%) | 92723 (35.7%) | Douglas Foster 5 (17.9%) | 24281 ( 9.3%) | John Levine 4 (14.3%) | 37247 (14.3%) | Murray S. Kucherawy 3 (10.7%) | 17599 ( 6.8%) | Dave Crocker

Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy

It appears that Alessandro Vesely said: >On Thu 06/Jan/2022 12:32:17 +0100 Douglas Foster wrote: >> The point of a specification like this is to understand each >> participant's best interest and channel that toward the common goal. >>  I perceive a false assumption that when a sender does

Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy

>> Consequently, the best way for senders to avoid delayed or blocked >> messages is to avoid getting close examination. This is facilitated by >> ensuring messages are both DKIM-verifiable and SPF-PASS, regardless of >> DMARC policy. P=NONE or T=Y or no policy are not valid substitutes. ...

Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy

It appears that Murray S. Kucherawy said: >I would argue that it's well understood by now that DKIM and SPF "pass" >results are the only things that convey usable information. I agree. I've never seen anyone have any trouble figuring out what SPF or DKIM inputs to feed into DMARC and don't see

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

It appears that Tobias Herkula said: >the often stated argument of simply not publishing SPF records if a Sender >wants DKIM-only >DMARC is not a viable solution in the real world. If your SPF record accurately describes the sources of your mail, can you explain why it would be a problem for

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Dec 26 06:00:16 2021

Count| Bytes | Who ++--- 33 ( 100%) | 295289 ( 100%) | Total 10 (30.3%) | 141051 (47.8%) | Douglas Foster 6 (18.2%) | 40155 (13.6%) | Scott Kitterman 6 (18.2%) | 28336 ( 9.6%) | John Levine 5 (15.2%) | 27604 ( 9.3%) | Alessandro

Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

It appears that Scott Kitterman said: >>> What definition are you wondering why we didn't stick to? >> >>Real non-existence. I'm not sure how to define it formally, ... The DNS has had a formal definition of non-existence for over 30 years. You look up a name, if it returns records or NOERROR

Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

It appears that Alessandro Vesely said: >On Sun 19/Dec/2021 21:42:16 +0100 Scott Kitterman wrote: >> If the domain owner has suggested that you reject mail from a sub-domain >> that has none of A, , or MX records, why would you not do that? >Then it turns out that one can also define DMARC

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence (Sample Data)

It appears that Alessandro Vesely said: >On Mon 20/Dec/2021 12:53:12 +0100 Douglas Foster wrote: >> I am not doing any root domain lookups.   If that is part of the proposed >> algorithm, somebody needs to document it.  I am simply looking for a >> resource >> record matching the FROM domain

Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

It appears that Scott Kitterman said: >If the domain owner has suggested that you reject mail from a sub-domain that >has none of A, , or MX records, why would you not do that? Just as with >any DMARC policy it's on >the sender to ensure authorized email conforms to the policy. My

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Dec 19 06:00:13 2021

Count| Bytes | Who ++--- 39 ( 100%) | 394785 ( 100%) | Total 8 (20.5%) | 129901 (32.9%) | Douglas Foster 7 (17.9%) | 51921 (13.2%) | Scott Kitterman 6 (15.4%) | 75074 (19.0%) | Tim Wicinski 4 (10.3%) | 18227 ( 4.6%) | John Levine

Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

It appears that Jeremy Harris said: >On 18/12/2021 03:47, Douglas Foster wrote: >> MX checks are a valid tool for assessing SMTP MailFrom addresses, since the >> sender is supposed to be ready to accept non-delivery reports and other >> automated messages. Of course, this has applicability if

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

It appears that Alessandro Vesely said: >Of course, if the From: domain doesn't exist at all, it cannot have a DMARC >record. However, according to the formal definition of Section 3.6.2, a >non-existing domain can pass all DMARC tests. ... DMARC lets a domain owner say "if mail with my name

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Dec 12 06:00:09 2021

Count| Bytes | Who ++--- 89 ( 100%) | 804017 ( 100%) | Total 24 (27.0%) | 156723 (19.5%) | Scott Kitterman 15 (16.9%) | 138377 (17.2%) | Alessandro Vesely 11 (12.4%) | 56788 ( 7.1%) | John Levine 10 (11.2%) | 144105 (17.9%) | Todd Herr 7

Re: [dmarc-ietf] 5.7.1 - Mulitple FROM

It appears that Scott Kitterman said: >>apply the DMARC check using each of those domains found in the >> >>RFC5322 .From field >> as the Author Domain and apply the most strict >>policy selected among the checks that fail. >> >> >>

Re: [dmarc-ietf] 5.7.1 - Mulitple FROM

It appears that Todd Herr said: >The entire paragraph from which that sentence was pulled reads: > >The case of a syntactically valid multi-valued RFC5322.From header field >presents a particular challenge. When a single RFC5322.From header field >contains multiple addresses, it is possible that

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

ing on your needs, >you may want to use another name when talking with clients, residents, >friends, and family." None of the users of these subdomains has a >relationship with each other besides purchasing services from a common >provider. John Levine and Scott Kitterman clea

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

It appears that Todd Herr said: >-=-=-=-=-=- >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 the other party in the >discussion, but I thought it best

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

It appears that Scott Kitterman said: >No. The so called best guess is no part of SPF. The "best guess" was a short term hack around 2003 when SPF was new and not widely deployed. It is now 18 years later, anyone who can run a mail server can publish SPF and that hack is totally dead.

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

It appears that Alessandro Vesely said: >Hi, > >The domain in the RFC5322.From header field is extracted as the >domain to be evaluated by DMARC. If the domain is encoded with UTF- >8, the domain name must be converted to an A-label, as described in >Section 2.3 of [RFC5890],

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

It appears that Scott Kitterman said: >> For your #2 you seem to be saying that if I send no-reply transactional >> mail, my DNS would look like this: >> >> notifiy.bigcorp.com. IN MX 0 . /* we don't receive replies /* >>IN A 0.0.0.0 /* make the domain exist */ >>

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

It appears that Scott Kitterman said: >> How about if it has a null MX and a DMARC record or DKIM keys? Remember >> that those records are at different names than the MX. ... >There's two ways we could go at this question: > >1. A domain that, except for the null mx, would fit the criteria for

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

It appears that Scott Kitterman said: >Should we modify the definition of non-existent domains so that a domain that >only has an RFC 7505 null mx record is still considered non-existent? How about if it has a null MX and a DMARC record or DKIM keys? Remember that those records are at

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Dec 5 06:00:12 2021

Count| Bytes | Who ++--- 63 ( 100%) | 457155 ( 100%) | Total 15 (23.8%) | 78033 (17.1%) | Alessandro Vesely 11 (17.5%) | 82509 (18.0%) | Murray S. Kucherawy 9 (14.3%) | 53122 (11.6%) | Scott Kitterman 8 (12.7%) | 41910 ( 9.2%) | John

Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (6729)

It appears that Murray S. Kucherawy said: >-=-=-=-=-=- > >This was reported but not sent to the WG. I believe the right disposition >is "Hold for Document Update". Does anyone want to argue for "Rejected" or >"Verified"? Reject it. Whether you choose to believe the non-ICANN part of the PSL

Re: [dmarc-ietf] Additions to introduction

It appears that Douglas Foster said: >-=-=-=-=-=- > >I propose that a paragraph along these lines be inserted into the >introduction: > >The DMARC test is characterized by a one-tailed error distribution: > Messages which pass verification have a low probability of being false >positives of

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

It appears that Alessandro Vesely said: >Hi, > >last message for today: the "t" tag instead of "pct". > >That's the only part which breaks existing records. According to the last >paragraph of this section, doing so requires v=DMARC2. Todd is right. We're deprecating the pct tag and adding

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

It appears that Alessandro Vesely said: >I'm not clear about the last but one paragraph of that section: > >An example of such an attack includes altering the MIME structure, >exploiting lax HTML parsing in the MUA, and defeating duplicate >message detection algorithms. > >I'm going

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

It appears that said: >> It appears that Wei Chuang said: >> > If the RFC2045 canonical representation at the final destination can be the >> > same as the canonical representation at the original sender, ... > >> When we were working on DKIM canonicalization we had lengthy discussions >>

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Nov 28 06:00:08 2021

Count| Bytes | Who ++--- 17 ( 100%) | 135792 ( 100%) | Total 5 (29.4%) | 31134 (22.9%) | Alessandro Vesely 5 (29.4%) | 26906 (19.8%) | John Levine 3 (17.6%) | 40468 (29.8%) | Wei Chuang 2 (11.8%) | 27847 (20.5%) | Douglas Foster

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

It appears that Wei Chuang said: >If the RFC2045 canonical representation at the final destination can be the >same as the canonical representation at the original sender, ... When we were working on DKIM canonicalization we had lengthy discussions about what to do about MIME and we decided not

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

It appears that Alessandro Vesely said: >Sure. Note that if the receiver trusts the MLM, simply recognizing it would >be >enough to pass DMARC per the "mailing_list" policy override. ARC additionally >provides the ability to learn the authentication status of the message when it >was

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

It appears that Alessandro Vesely said: >The GNU Compiler Collection includes front ends for C, C++, Objective-C, >Fortran, Ada, Go, and D. It doesn't cover all languages, but it's still alive. Sure and it's not an UNCOL. The front ends are mostly common from one machine to the next but

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

It appears that Wei Chuang said: >I saw Ale's draft draft-vesely-dmarc-mlm-transform > in >the ARC list, and wanted to discuss some of the ideas. ... Please humor me for a moment while I turn the clock way back to 1958.

Re: [dmarc-ietf] Minutes from IETF 112

It appears that Todd Herr said: >It seems to me that DMARC already provides the ability for >security.example.edu to ensure that no other part of example.edu can send >mail on their behalf. To accomplish this, security.example.edu can today: > > - Publish an SPF record listing only hosts under

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Nov 7 06:00:25 2021

Count| Bytes | Who ++--- 69 ( 100%) | 604304 ( 100%) | Total 21 (30.4%) | 147431 (24.4%) | Scott Kitterman 14 (20.3%) | 166827 (27.6%) | Douglas Foster 10 (14.5%) | 60816 (10.1%) | Alessandro Vesely 9 (13.0%) | 45287 ( 7.5%) | John

Re: [dmarc-ietf] Organizational Alignment Options

It appears that Tobias Herkula said: >I'm aware of that, to be more explicit about my meaning. At least I currently >believe (I don't know) that there is a difference in buying >the domain "mydomain.example" under the assumption that .example is a gTLD, >sTLD or ccTLD in comparison of buying a

Re: [dmarc-ietf] Organizational Alignment Options

It appears that Tobias Herkula said: >-=-=-=-=-=- >Threat risk: I totally agree the ORG begins with the first label that is not >considered to be a PSD, but at least I want to know if that >decision is based on contractual obligations from ICANN/IANA or only a >business decision by an entity

Re: [dmarc-ietf] a detour into public suffix publishing, was Organizational Alignment Options

It appears that Tobias Herkula said: >-=-=-=-=-=- >As an entity you want to be on the PSL to declare an organizational boundary, >and usage is now for Cookies, Certificates, Domain Reputation and most likely >a longer list of >more obscure individual use cases. So most of the time a DNS-RR on

Re: [dmarc-ietf] Organizational Alignment Options

It appears that Douglas Foster said: >-=-=-=-=-=- > >Correct, but you cannot query _dmarc.host1.domain because host1 is not a >DNS domain, even though it can be a mail sender and receiver Sorry, but I also have no idea what you're talking about. Any mail domain is a DNS domain because you have

Re: [dmarc-ietf] Organizational Alignment Options

It appears that Scott Kitterman said: >4. Common parent domain not marked PSD. We could add a new tag to the DMARC >records for PSDs to indicate it's a PSD, so it's record shouldn't be used for >alignment. Getting this added to the literal handful of PSD records that >exist and specifying

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

It appears that Joe Humphreys said: >We send tens of millions of such messages daily. These are messages where >the From address is nore...@application.organization.com, and the DKIM >signing domain is just organization.com. > >I suggest again that the simple answer is for the DMARC record

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

It appears that Alessandro Vesely said: The alternative I suggested is 100% compatible with the installed base. If a domain has published DMARC policy per RFC 7489, the proposed new approach will still find it. > >Yes, but would PSL-based DMARC filters have to be re-written,

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Oct 31 06:00:05 2021

Count| Bytes | Who ++--- 50 ( 100%) | 406868 ( 100%) | Total 15 (30.0%) | 81050 (19.9%) | John Levine 11 (22.0%) | 96610 (23.7%) | Scott Kitterman 6 (12.0%) | 81478 (20.0%) | Douglas Foster 4 ( 8.0%) | 31641 ( 7.8%) | Joe Humphreys

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

.com _dmarc.foo.com and you have a message from b...@y.x.foo.com, the current scheme will skip up to _dmarc.foo.com while a tree walk will find _dmarc.x.foo.com. I doubt that will make any difference in practice. If there really are any situations like that, who knows what they think it does

Re: [dmarc-ietf] let a hundred org domains blossom, not, was Topic for IETF 112 - Policy Discovery

It appears that Alessandro Vesely said: >IMHO, we shouldn't throw away the PSL. Most importantly, we should stick to >the concept of Organizational Domain. We can give an abstract definition of >the latter in terms of affiliation of some kind. Then the spec can leave it >to >developers to

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

I asked for some examples of bad things that the PSL would prevent or fix. Don’t think we’ve seen any. Please consider the environment before reading this message. John Levine, jo...@taugh.com > On Oct 29, 2021, at 22:08, Dave Crocker wrote: > > On 10/29/2021 6:40 PM, John Lev

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

It appears that Dave Crocker said: >Except that Alessandro's original reference was in the service of >explaining why a mechanism DMARC relies on, for establishing >organization authority, should not necessarily rely on everyone's being >a good actor. I take it you are agreeing that we

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

It appears that Scott Kitterman said: >Based on the longest true PSL entry being 4 labels, we could also just jump to >the 5th and walk up from there. It would give every domain that currently has >the ability to express a domain policy the ability to do so and bound the >total number of

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

It appears that Alessandro Vesely said: >Verisign is not new to abusive behavior. About 20 years ago they used to >reply >with one of their servers' IP addresses to any query like >www..com. ISC came out with the "root-delegation-only" hack >to counter that. Oh, please. That was the

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

It appears that Scott Kitterman said: >It's growing on me. Ooh, cool. >There are, however privacy and security concern differences between processing >a record for _dmarc.example.com and _dmarc.com. We can, and should explain >those differences in the security and privacy considerations

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

It appears that Joe Humphreys said: > >Why not allow the DMARC record to specify what domain root the identifier >must align with? Instead of adkim=r meaning "consult the PSL list", use >adkim=example.com to mean "use relaxed alignment, and the organizational >domain is example.com". Because

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

It appears that Scott Kitterman said: >On Tuesday, October 26, 2021 10:09:13 PM EDT John Levine wrote: >> The question remains what to do about the fake mail with 12 label domains. >> My perhaps radical suggestion is to say that if the author domain does not >> exist,

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

It appears that Scott Kitterman said: >For a 'normal' domain/sub-domain like eml.example.com where the domain has a >DMARC policy, every single implementation approach gives the >same answer, so it doesn't matter. The challenge is getting all the other >cases right. > >Until we understand

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

am on a few lists that are misconfigured to put the list's address on the From line with no hint about who wrote the message. My impression is about half the messages on such lists are "could you put your name in the body of the message so we know who it's from, please." -- Regards, John Levi

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Oct 17 06:00:13 2021

Count| Bytes | Who ++--- 27 ( 100%) | 312868 ( 100%) | Total 7 (25.9%) | 143774 (46.0%) | Douglas Foster 6 (22.2%) | 40530 (13.0%) | John, come on 4 (14.8%) | 16910 ( 5.4%) | John Levine 2 ( 7.4%) | 18156 ( 5.8%) | Scott Kitterman

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

It appears that Joseph Brennan said: > >Creating a DMARC record on your domain means (among other things) that you >expect no email sent from your domain to be a contribution to mailing >list discussions. Assuming you mean "a DMARC record with a policy other than p=none" that would be

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

It appears that Baptiste Carvello said: >Now, I'm skeptical of your solution. First, I don't think 100% >deliverability at all times is a hard requirement. ... Since 100% deliverability at all times does not and cannot exist, it's just as well. R's, John

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

It appears that Alessandro Vesely said: >IANAL, but I don't think that the addition of subject tags and footers >violates >author's copyright. Yet, adding a footer to state the right to add a footer >might look paradoxical. I can give you a long explanation about why copyright is not an

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Oct 10 06:00:40 2021

Vesely 8 (11.9%) | 40080 ( 7.8%) | John Levine 3 ( 4.5%) | 27614 ( 5.3%) | Baptiste Carvello 2 ( 3.0%) | 34088 ( 6.6%) | Laura Atkins 2 ( 3.0%) | 9621 ( 1.9%) | Barry Leiba 2 ( 3.0%) | 8697 ( 1.7%) | Benny Pedersen 1 ( 1.5%) | 11036 ( 2.1%) | Grant Taylor 1 ( 1.5%) | 6494

Re: [dmarc-ietf] Oh, the mail, it is a-changin', was DMARC-Compliant Mailing Lists

It appears that Dave Crocker said: >The purpose of the Author field is to retain some information that >presumably won't get modified. ... The problem for me is that this is just another entry in the list of things that are supposed to help peek back and see what the original message said.

Re: [dmarc-ietf] bad senders, was DMARC-Compliant Mailing Lists

It appears that Scott Kitterman said: >My vague recollection is that the reason not to use Sender (implicit or >explicit) as the key for ADSP and later DMARC was concern that some MUAs >didn't display the >explicit Sender (mostly Outlook Express, IIRC). The original Yahoo! >DomainKeys had

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

It appears that Murray S. Kucherawy said: >He didn't specify, but I took the suggestion to mean a new document, not >any of the current ones. You're welcome to start with the stuff in the ASRG wiki: https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail It's a real wiki, if

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

It appears that Alessandro Vesely said: >Doug's emphasis on aliases tends to give that impression. Otherwise it can >finally be a much needed attempt at formalizing the old, known From: rewriting. To point out what I would think is obvious, formalizing a bad idea doesn't make it any less bad

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

It appears that Alessandro Vesely said: >On Mon 04/Oct/2021 02:17:01 +0200 Douglas Foster wrote: >> As I hinted in a recent message, I believe that DMARC-compliant mailing >> lists >> are possible.   I have posted a draft which explicates how this can be done. I took a look, and this appears

Re: [dmarc-ietf] Experiments

It appears that Alessandro Vesely said: >There is a case (d) final receiver enforcea DMARC and ARC, but the >forwarder is not among its ARC-trusted senders. > >The simple solution if From: rewriting. I think you misspelled "ugly kludge" there. > Note that forwarders should always rewrite the

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Sep 26 06:00:16 2021

Count| Bytes | Who ++--- 16 ( 100%) | 173380 ( 100%) | Total 3 (18.8%) | 18693 (10.8%) | Scott Kitterman 2 (12.5%) | 25678 (14.8%) | Douglas Foster 2 (12.5%) | 9799 ( 5.7%) | Murray S. Kucherawy 2 (12.5%) | 9601 ( 5.5%) | John

Re: [dmarc-ietf] Experiments

;final destination. Without the signature, they should have been blocked >already. There are plenty of senders who only use SPF and publish a DMARC policy anyway. We all know why that's a bad idea, but that's what they do. R's, John -- Regards, John Levine, jo...@taugh.com, Primary Perpetr

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

It appears that Alessandro Vesely said: >TL;DR: p=validate: reject on fail, but only on first hop. New ticket: >https://trac.ietf.org/trac/dmarc/ticket/122 I'm with Scott and Mike. Let's not. In most cases MLMs can do strict DMARC enforcement on *incoming* mail with good results since it is

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

It appears that Tim Wicinski said: >I am not well ensconced in the Mail community, but are this disagreements >between vendors, software, etc over if one is "implementing DMARC"? Sure, but it's not our problem. People still have arguments about whether you've really implemented SMTP if you use

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-03.txt

It appears that Brotman, Alex said: >It feels like folks would prefer that the subject be required to be of a >specific format to better enable duplicate report processing. Do I >understand that correctly? > >So that would be: > > If a report generator needs to re-send a report, the system

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Aug 22 06:00:06 2021

%) | 41544 (14.1%) | Brotman, Alex 1 ( 4.2%) | 32030 (10.9%) | Dotzero 1 ( 4.2%) | 8838 ( 3.0%) | Douglas Foster 1 ( 4.2%) | 7140 ( 2.4%) | Barry Leiba 1 ( 4.2%) | 5125 ( 1.7%) | John Levine ___ dmarc mailing list dmarc@ietf.org https

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

It appears that Todd Herr said: > flows for the domain or sub-domains. It is not yet ready to commit > to conveying a severity of concern for unauthenticated email using > its domain. That's just wrong. I've looked at the numbers, and p=none perfectly communicates my level of concern.

Re: [dmarc-ietf] Trac #6 - Normative filename construction

It appears that Alessandro Vesely said: >I'd raise to MUST the media type, but leave the filename at SHOULD. >The MUST can be limited to the components, so that the same content >results in identical filenames. > >I'm not sure the filename is required for interoperability. Do report

Re: [dmarc-ietf] Trac #6 - Normative filename construction

It appears that Brotman, Alex said: >https://trac.ietf.org/trac/dmarc/ticket/6 > >Folks, > >I'd like to get a bit of feedback on this one. I realized I'd changed this to >a SHOULD, which doesn't really address the "fuzzy" >complaint. Seems like the proper thing to do is make this a MUST, though

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Aug 8 06:00:06 2021

Count| Bytes | Who ++--- 26 ( 100%) | 320536 ( 100%) | Total 6 (23.1%) | 114246 (35.6%) | Todd Herr 6 (23.1%) | 44361 (13.8%) | Alessandro Vesely 4 (15.4%) | 62050 (19.4%) | Douglas Foster 3 (11.5%) | 12819 ( 4.0%) | John Levine 2

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

It appears that Todd Herr said: >> I like simple, but I also like the idea of a separate section that >discusses the history of the pct tag and why the old values won't work any >longer. OK except: > remains the default, and "0". The value of "0" took on unintended > significance during

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Aug 1 06:00:10 2021

Count| Bytes | Who ++--- 15 ( 100%) | 122169 ( 100%) | Total 4 (26.7%) | 49661 (40.6%) | Douglas Foster 4 (26.7%) | 18123 (14.8%) | John Levine 3 (20.0%) | 15642 (12.8%) | Alessandro Vesely 1 ( 6.7%) | 19470 (15.9%) | Todd Herr 1

<    1   2   3   4   5   6   7   8   9   10   >