[dmarc-ietf] Re: PSOs sending mail from their PSD

It appears that Scott Kitterman said: > >>instead, it could say: >> >>Report generators MUST NOT consider ruf= tags in records having >>a "psd=y" tag, unless the domain is the RFC5322.From domain and/ >>or there are specific agreements between the interested parties. No. You can

[dmarc-ietf] Messages from the dmarc list for the week ending Sun May 12 06:00:03 2024

Count| Bytes | Who ++--- 12 ( 100%) | 137391 ( 100%) | Total 2 (16.7%) | 25581 (18.6%) | Mark Alley 2 (16.7%) | 17646 (12.8%) | Dotzero 2 (16.7%) | 11084 ( 8.1%) | John Levine 1 ( 8.3%) | 27325 (19.9%) | Hector Santos 1 ( 8.3

[dmarc-ietf] Re: New attack leveraging DMARC None

require getting the customer to understand that they're causing the problem and to spend money fixing it, rather than saying "your mail is broken." Good luck with that. Also remember that until DMARC came along, this all worked just fine. R's, John -- Regards, John Levine, jo...@taugh

[dmarc-ietf] Re: New attack leveraging DMARC None

It appears that Scott Kitterman said: >> Addressing this issue - perusing Section 5.5.6, is there anything else >> we could add that would be acceptable language in an Standards track >> document to encourage urgency behind a transitory state of p=none use by >> domain owners? Would that even

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Apr 28 06:00:04 2024

. Levine 1 ( 8.3%) | 10551 ( 8.7%) | Douglas Foster 1 ( 8.3%) | 10072 ( 8.3%) | Murray S. Kucherawy 1 ( 8.3%) | 5050 ( 4.2%) | RFC Errata System 1 ( 8.3%) | 3163 ( 2.6%) | John Levine 1 ( 8.3%) | 2754 ( 2.3%) | ___ dmarc mailing

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Apr 21 06:00:04 2024

Count| Bytes | Who ++--- 33 ( 100%) | 296336 ( 100%) | Total 9 (27.3%) | 59633 (20.1%) | Scott Kitterman 6 (18.2%) | 36555 (12.3%) | John Levine 5 (15.2%) | 71162 (24.0%) | Todd Herr 4 (12.1%) | 53314 (18.0%) | Douglas Foster 3

Re: [dmarc-ietf] Thoughts on choosing N

It appears that Scott Kitterman said: >> Or I suppose say if there's more than 8 components in the name, just stop >> because no domain actually used for mail is that deep. Take out the skip >> stuff. > >I am not entirely unsympathetic, but I think what we have is reasonable and >based on

Re: [dmarc-ietf] Thoughts on choosing N

It appears that Todd Herr said: >When DMARC was first developed, there was concern about DNS load and >needing to minimize DNS lookups. Operational expertise now shows that this >is no longer cause for concern. > >Short circuiting a tree walk has led to many issues, like a reliance on the >PSL,

Re: [dmarc-ietf] Thoughts on choosing N

It appears that Scott Kitterman said: >>I'm with Scott, pick a number, 5, 8, whatever, and be done with it. >> >Modulo we do need to explain why 8. Related, I think we also need to explain >why the reporting address thing is important for DMARCbis since having an >intermediate level record

Re: [dmarc-ietf] Thoughts on choosing N

It appears that Alessandro Vesely said: >8 is not needed and not justified. A mail site using 8 labels would have >troubles with the RFC 7489 version, which uses the PSL. They'd have to ask >for >PSL upgrades, right? No, they would not. They might ask to have their pseudo-TLDs added to the

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Apr 14 06:00:04 2024

Count| Bytes | Who ++--- 21 ( 100%) | 150727 ( 100%) | Total 9 (42.9%) | 62034 (41.2%) | Neil Anuskiewicz 4 (19.0%) | 19770 (13.1%) | John Levine 2 ( 9.5%) | 21019 (13.9%) | Douglas Foster 2 ( 9.5%) | 12465 ( 8.3%) | Scott Kitterman

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-failure-reporting-10.txt

It appears that Neil Anuskiewicz said: >Do you all think we should mention the decline and fall of the failure report? >I think that Yahoo! is the only major MBP that still sends >failure reports. I think the others may have stopped over PII concerns. I still get a dozen a day. They're not

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Apr 7 06:00:04 2024

Kitterman 7 ( 6.8%) | 62365 ( 6.6%) | Todd Herr 7 ( 6.8%) | 35765 ( 3.8%) | John Levine 5 ( 4.9%) | 75347 ( 8.0%) | Douglas Foster 5 ( 4.9%) | 39532 ( 4.2%) | Jim Fenton 5 ( 4.9%) | 27791 ( 2.9%) | John R. Levine 3 ( 2.9%) | 38637 ( 4.1%) | Tim Wicinski 3 ( 2.9%) | 31423

Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all

It appears that Scott Kitterman said: >I hear you. Your operational issue is my system working as designed. DMARC >works on top of SPF, it doesn't change it. > >Anything like this belongs in an operational guidance document, not in the >protocol description. I have no problem describing

Re: [dmarc-ietf] ARC, DMARCbis WGLC - Issue 144 Mention of ARC in DMARCbis

It appears that Murray S. Kucherawy said: >Can you give an example, even if only a hypothetical one? I'm not Emmanuel but people at large mail systems have told me that the biggest value of ARC is to deal with mailing lists that do lousy spam filtering. Lists often let anything through that has

Re: [dmarc-ietf] DMARCbis WGLC - Issue 144 Mention of ARC in DMARCbis

It appears that Todd Herr said: >Issue 144 has been opened for the question of what to say about ARC (RFC >8617) in the context of indirect mail flows, a la Murray's example text >from this post >: > >"One possible

Re: [dmarc-ietf] WGLC contentious topics (I'm in the rough and I know it) in draft-ietf-dmarc-dmarcbis-30

It appears that Seth Blank said: >More accurate language that alleviates the concern would be "It is >therefore critical that domains that host users who wish for their messages >to be modified and spoofed by downstream intermediaries, such as alumni >forwarders or mailing lists, SHOULD NOT

Re: [dmarc-ietf] SPF follies, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

It appears that Tim Wicinski said: >-=-=-=-=-=- > >I have to agree with Seth's comments that "security teams believe an SPF >hard fail is more secure". >I've been on the receiving end of that discussion more than once. I believe you, but if you reject on SPF fail you're going to lose a lot of

Re: [dmarc-ietf] SPF follies, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

It appears that Mark Alley said: >>   People who publish -all know what they do. > >I posit that there is a non-insignificant amount of domain owners that >don't know what the consequences of -all are other than that they've >been instructed to use "-all" by a guide online, ... I'm with you.

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Mar 31 06:00:04 2024

Count| Bytes | Who ++--- 33 ( 100%) | 260931 ( 100%) | Total 11 (33.3%) | 59746 (22.9%) | Alessandro Vesely 7 (21.2%) | 37255 (14.3%) | John Levine 4 (12.1%) | 51406 (19.7%) | Jim Fenton 4 (12.1%) | 26151 (10.0%) | Matthäus Wander

Re: [dmarc-ietf] WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

I mostly agree but here's a few comments. It appears that Seth Blank said: >Section 4:2: Use of RFC5322.From: > >Is it also worth it to call out that time and operational impact have >proven this to be the right choice? Since we never tried anything else, we don't know. I suppose we might note

Re: [dmarc-ietf] Errata for Aggregate Reporting

It appears that Alessandro Vesely said: >On Sun 24/Mar/2024 18:06:53 +0100 John Levine wrote: >> It appears that Brotman, Alex said: >> >>>https://www.rfc-editor.org/errata/eid5774 :: There were a number of edits >>>for clarification to this portion of the do

Re: [dmarc-ietf] Errata for Aggregate Reporting

It appears that Brotman, Alex said: >There were a few errata for the aggregate reporting. I wanted to confirm with >the list that these are still valid. > >https://www.rfc-editor.org/errata/eid5440 :: I thought it had been determined >the ";" was not necessary. It was required in 7489 but not

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Mar 24 06:00:04 2024

Count| Bytes | Who ++--- 56 ( 100%) | 437345 ( 100%) | Total 9 (16.1%) | 63038 (14.4%) | Scott Kitterman 9 (16.1%) | 54473 (12.5%) | Alessandro Vesely 9 (16.1%) | 50879 (11.6%) | John Levine 8 (14.3%) | 54502 (12.5%) | Matthäus

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

It appears that Murray S. Kucherawy said: >-=-=-=-=-=- > >This seems like it's probably legitimate. Does it need to be fixed in the >-bis document? It's already fixed in the current markdown. FYI, the XML pattern is silly. It forbids harmless stuff like leading zeros in 01.02.03.04 and

Re: [dmarc-ietf] no DMARC result for DKIM testing and policy

and finish up. R's, John -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC result for DKIM testing and policy

It appears that Todd Herr said: > 2. That part of 6376 might be better written as "Should the signature > fail to verify, verifiers MUST NOT treat messages from Signers in testing > mode differently from unsigned email." as I see no reason to penalize a > Domain Owner who successfully

Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?

Tightened up a little, reworded in view of the fact that your own mail provider (M*r*s*ft) may let people spoof you through shared IP ranges. >11.X External Mail Sender Cross-Domain Forgery Add this to 11.1 Authentication Methods Both of the email authentication methods that underlie DMARC

Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?

It appears that Scott Kitterman said: >1. Bad mail gets DMARC pass and so DMARC policy is not applied (avoid >consequences of DMARC fail). > >2. Bad mail gets DMARC pass and something else (e.g. BIMI) does a wrong thing >(gets benefits of DMARC pass). I agree these are the two main points.

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Mar 17 06:00:05 2024

7 ( 6.4%) | 96182 ( 8.6%) | Douglas Foster 7 ( 6.4%) | 34125 ( 3.1%) | John Levine 6 ( 5.5%) | 50080 ( 4.5%) | Murray S. Kucherawy 5 ( 4.6%) | 64726 ( 5.8%) | Hector Santos 5 ( 4.6%) | 61477 ( 5.5%) | Mark Alley 2 ( 1.8%) | 45081 ( 4.0%) | Tobias Herkula 2 ( 1.8

Re: [dmarc-ietf] Problem with multiple policies, different alignment

It appears that Murray S. Kucherawy said: >It's alarming to hear that NXDOMAIN replies are never issued or (perhaps >more likely) are dropped by some software or firewalls. It completely >prevents any benefits of negative caching. I wonder what the DNS community >might have to say about this

Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

It appears that Todd Herr said: >I agree that clarifying it can't hurt, obviously, ... I disagree, it does hurt. If we say you're allowed to use CNAMEs to point to DMARC records, people are to say uh oh, is there something special here? What about DKIM records? what about SPF records? how

Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

It appears that Todd Herr said: >The reasons given were: > > 1. https://www.rfc-editor.org/rfc/rfc5863#section-4.1 I am reasonably sure it was referring to DNS crudware that wouldn't let you put an underscore in the name, or that limited TXT records to a single 255 byte string, not CNAMEs. >

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

It appears that Scott Kitterman said: >> SPF it treated in multiple places. We cannot warn against a bad practice in >> one place (135) and recommend it unconditionally in another (132). > >That is exactly how one handles Security Considerations. So 132 says do SPF. >Security Considerations

Re: [dmarc-ietf] DMARCbis WGLC Issue 134 - What To Do With Appendix A.5?

It appears that Todd Herr said: >-=-=-=-=-=- > >Colleagues, > >Two people have spoken up on list asking for removal of this section >(thread subject is "A.5 Issues with ADSP in Operation") while one person >has registered opposition to the idea. I don't believe this is anywhere >close to

Re: [dmarc-ietf] Fwd: The sad state of SPF: research just presented at NDSS

It appears that Scott Kitterman said: >Or, as RFC 4408 and RFC 7208 warn against, ESPs don't allow customers to send >mail for anything other than their own domains. ESP customers, don't use ESPs >that do this. It's not just ESPs. There's a widely reported bug that lets anyone whose mail is

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Mar 10 06:00:04 2024

Pedersen 1 ( 1.8%) | 3780 ( 0.8%) | John Levine ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Mar 3 06:00:04 2024

Count| Bytes | Who ++--- 53 ( 100%) |1524027 ( 100%) | Total 12 (22.6%) | 165485 (10.9%) | Todd Herr 8 (15.1%) | 59210 ( 3.9%) | Scott Kitterman 5 ( 9.4%) | 90332 ( 5.9%) | Seth Blank 5 ( 9.4%) | 2 ( 1.9%) | John Levine 3 ( 5.7

Re: [dmarc-ietf] DMARCbis WGLC Issue - Description of rua and ruf Tags

It appears that Todd Herr said: >Below please find the current text (rev -30) and my proposed replacement >text. It seems OK but I would say that at this point that mailto: URI are the only ones currently defined. >PROPOSED REPLACEMENT TEXT: >= cut here

Re: [dmarc-ietf] DMARCbis WGLC Issue - Section 11.3

It appears that Todd Herr said: >p=none by default." This seems inconsistent with the text in 5.7.2 >("Continue if one is found, or terminate DMARC evaluation otherwise") and >4.7 ("Handling of DNS errors when querying for the DMARC policy record is >left to the discretion of the Mail Receiver")

Re: [dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6

It appears that Scott Kitterman said: >In what way is this a new issue that has not already been argued to death in >the WG? I think for WGLC, we've already done this. We will, no doubt get to >have this conversation during the IETF >last call, but for the working group, this strikes me as

Re: [dmarc-ietf] The sad state of SPF: research just presented at NDSS

It appears that Barry Leiba said: >-=-=-=-=-=- > >A paper was presented this morning at NDSS about the state of SPF, which is >worth a read by this group: > >https://www.ndss-symposium.org/ndss-paper/breakspf-how-shared-infrastructures-magnify-spf-vulnerabilities-across-the-internet/ I was

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Feb 11 06:00:04 2024

Massar 2 ( 7.4%) | 23984 (10.8%) | Todd Herr 2 ( 7.4%) | 10340 ( 4.7%) | John Levine 2 ( 7.4%) | 9397 ( 4.2%) | Jim Fenton 1 ( 3.7%) | 8739 ( 3.9%) | Hector Santos 1 ( 3.7%) | 6413 ( 2.9%) | Scott Kitterman 1 ( 3.7%) | 5183 ( 2.3%) | John R. Levine 1 ( 3.7%) | 4900

Re: [dmarc-ietf] dmarc-dmarcbis: add "req=dkim"

It appears that Jeroen Massar said: >Hi Folks, > >As DMARCbis is being updated, I would like to suggest a new tag `required` >shorted to `req`. > >``` >`req=dkim`: requires DKIM, messages not properly signed are then to be >rejected/quarantined based on 'p' policy. > >The tag should allow

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

It appears that Murray S. Kucherawy said: >-=-=-=-=-=- > >On Sun, Feb 4, 2024 at 5:25 AM Alessandro Vesely wrote: > >> > What do we think has changed since then that warrants reconsidering that >> > position? Have we started to see multi-value From attacks? >> >> A DMARC filter has to do

Re: [dmarc-ietf] Non-technician's idea for DMARC improvement

It appears that Ted Wham said: >-=-=-=-=-=- > >DMARC allows a policy ("p") value of none, quarantine, or reject. According to >DMARC.org, as of Q2 >2022 just under 20% of all DMARC implementations chose the reject policy >(source: >https://dmarc.org/stats/dmarc/). However, for that subset of

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Jan 21 06:00:04 2024

( 2.9%) | John Levine ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

It appears that Scott Kitterman said: >I don't think that's sensible at all. It's not the place of a signing filter >to modify the message. I think it would be reasonable to either add a >signature for >each from domain or to decline to sign it at all, but since DKIM doesn't care >about

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Nov 26 06:00:04 2023

( 7.1%) | 11779 ( 8.6%) | Dotzero 1 ( 7.1%) | 4008 ( 2.9%) | Jim Fenton 1 ( 7.1%) | 3381 ( 2.5%) | John Levine ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Nov 19 06:00:04 2023

HUREAU 2 (10.5%) | 9417 ( 5.7%) | John Levine 1 ( 5.3%) | 12175 ( 7.3%) | Seth Blank 1 ( 5.3%) | 8750 ( 5.3%) | Neil Anuskiewicz 1 ( 5.3%) | 7966 ( 4.8%) | Steven M Jones 1 ( 5.3%) | 7329 ( 4.4%) | Murray S. Kucherawy 1 ( 5.3%) | 5585 ( 3.4%) | Jim Fenton

Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML Schema

Thanks for doing this work. It cleans up a messy corner of DMARC. It appears that OLIVIER HUREAU said: >I was personally thinking about the following options: > >1) Specify Version "2" ... > >2) Explore a JSON Format for Aggregated Reports: ... > >3) Create an Extended XML Schema for

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Nov 12 06:00:04 2023

Count| Bytes | Who ++--- 43 ( 100%) | 331482 ( 100%) | Total 15 (34.9%) | 129432 (39.0%) | Neil Anuskiewicz 5 (11.6%) | 24679 ( 7.4%) | John Levine 3 ( 7.0%) | 30894 ( 9.3%) | Dotzero 3 ( 7.0%) | 17105 ( 5.2%) | Steven M Jones 3

Re: [dmarc-ietf] Codifying "Apex Domain"?

It appears that Todd Herr said: >-=-=-=-=-=- > >Colleagues, > >I note that lately in various email fora that the term "apex domain" has >found some favor, said term being used interchangeably with "organizational >domain", and having the same contextual meaning as "organizational domain". They

Re: [dmarc-ietf] Well, that was amusing

It appears that Damian Lukowski said: >> Low budget spam to the DMARC list that happened to fake my name and address >> on the From: line. >> >> If this happened more than once every five years, I might consider >> publishing a DMARC policy. > >How is iecc.com affiliated with this mailing

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Nov 5 06:00:03 2023

Clayton 3 (11.1%) | 14611 ( 6.4%) | John Levine 2 ( 7.4%) | 33293 (14.6%) | Mark Alley 1 ( 3.7%) | 8157 ( 3.6%) | Murray S. Kucherawy 1 ( 3.7%) | 7638 ( 3.4%) | Tero Kivinen 1 ( 3.7%) | 7229 ( 3.2%) | Dotzero 1 ( 3.7%) | 6550 ( 2.9%) | Barry Leiba 1 ( 3.7%) | 6191

Re: [dmarc-ietf] DMARC session at IETF 118

It appears that OLIVIER HUREAU said: >-=-=-=-=-=- > >I was personally planning to go to the IETF-118 specifically for the DMARC >meeting. In the end, many other >activities caught my eye. >However, if any of you are going to the IETF, I'd be happy to share a few >words about DMARC and put a

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

It appears that Steven M Jones said: >> As error reports have never gotten any traction, it would be a big >> effort to make this work. Reusing the existing ecosystem of aggregate >> reports is a lower hanging fruit. > >Failure reports were actually sent for many years, and not just by small

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Oct 29 06:00:04 2023

( 4.8%) | Olivier Hureau 3 ( 3.4%) | 14132 ( 1.7%) | John Levine 2 ( 2.2%) | 27371 ( 3.3%) | Matt V 2 ( 2.2%) | 19356 ( 2.3%) | Todd Herr 2 ( 2.2%) | 18662 ( 2.2%) | Hector Santos 2 ( 2.2%) | 18208 ( 2.2%) | Emanuel Schorsch 2 ( 2.2%) | 12123 ( 1.4%) | Matthäus Wander 1 ( 1.1

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

It appears that Scott Kitterman said: >>That is unfortunately true, but if we could decouple the DMARC from >>SPF, then at least we could fix the situation at some point... > >I propose that we not repeat this discussion and instead, try to focus on >finishing. If there isn't a consensus to

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

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

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Oct 22 06:00:04 2023

Foster 4 ( 9.3%) | 41704 ( 9.9%) | Dotzero 4 ( 9.3%) | 27970 ( 6.6%) | Scott Kitterman 3 ( 7.0%) | 42689 (10.1%) | Seth Blank 2 ( 4.7%) | 21313 ( 5.0%) | Murray S. Kucherawy 2 ( 4.7%) | 8955 ( 2.1%) | John Levine 1 ( 2.3%) | 13155 ( 3.1%) | Jesse Thompson 1 ( 2.3

Re: [dmarc-ietf] DBOUND

It appears that Neil Anuskiewicz said: >-=-=-=-=-=- >See section V Enaging with DBOUND is not the same thing as advocating that DBOUND do anything specific. Everyone agrees the PSL is awful, including the people who maintain it. But there's no agreement at all about what would be better.

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Oct 15 06:00:04 2023

Kitterman 1 ( 5.3%) | 13116 ( 6.6%) | Brotman, Alex 1 ( 5.3%) | 11866 ( 6.0%) | Todd Herr 1 ( 5.3%) | 3048 ( 1.5%) | John Levine 1 ( 5.3%) | 2694 ( 1.4%) | "IETF Secretariat" ___ dmarc mailing list dmarc@ietf.org https://ww

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Oct 8 06:00:04 2023

1 ( 8.3%) | 6835 ( 6.2%) | Jan Dušátko 1 ( 8.3%) | 5960 ( 5.4%) | Richard Clayton 1 ( 8.3%) | 4835 ( 4.4%) | John Levine 1 ( 8.3%) | 2753 ( 2.5%) | ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

It appears that Richard Clayton said: >I do wonder if this is the PSL raising its ugly head again. A remarkable >number of the people who have added entries have not understood how they >now need to publish rather more DNS records than previously ... Definitely. In the few cases we've found

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Sep 24 06:00:04 2023

Santos 2 (10.0%) | 12835 ( 6.8%) | Barry Leiba 2 (10.0%) | 9512 ( 5.0%) | John Levine 1 ( 5.0%) | 12329 ( 6.5%) | Brotman, Alex 1 ( 5.0%) | 11619 ( 6.1%) | Dotzero 1 ( 5.0%) | 6963 ( 3.7%) | Scott Kitterman 1 ( 5.0%) | 5805 ( 3.1%) | A. Schulze

Re: [dmarc-ietf] not demunging yet, Some Gmail comments on DMARCbis version 28

It appears that Scott Kitterman said: >Thanks. That's helpful. > >I interpret that as confirming my view that there is not currently a >reasonable >technical solution available. While these may be promising for the future, >it's not like any of those solutions are things that are currently

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Sep 17 06:00:03 2023

Count| Bytes | Who ++--- 31 ( 100%) | 306769 ( 100%) | Total 6 (19.4%) | 87916 (28.7%) | Douglas Foster 5 (16.1%) | 70425 (23.0%) | Dotzero 4 (12.9%) | 41026 (13.4%) | Hector Santos 3 ( 9.7%) | 18069 ( 5.9%) | Alessandro Vesely 2

Re: [dmarc-ietf] pct flag, Some Gmail comments on DMARCbis version 28

It appears that Murray S. Kucherawy said: >The definition of "pct" doesn't talk about sources, it talks about >individual messages, evaluated independently. It's meant to be applied in >aggregate across all messages purporting to be from that domain, >independently and irrespective of source.

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Aug 27 06:00:04 2023

Count| Bytes | Who ++--- 10 ( 100%) | 71281 ( 100%) | Total 3 (30.0%) | 13409 (18.8%) | John Levine 2 (20.0%) | 20533 (28.8%) | Jesse Thompson 1 (10.0%) | 14208 (19.9%) | Douglas Foster 1 (10.0%) | 9389 (13.2%) | Hector Santos

Re: [dmarc-ietf] p=interoperability p=compliance p=orgname:policyname

It appears that Jesse Thompson said: >I'm beginning to think that a solution to this problem is "other channels" > >Let's discuss p=interoperability, p=compliance, or p=orgname:policyname Please, no. This WG has already run a year past its sell-by date. Stuff like this will just tell the

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Aug 20 06:00:04 2023

Count| Bytes | Who ++--- 10 ( 100%) | 108558 ( 100%) | Total 3 (30.0%) | 54410 (50.1%) | Wei Chuang 2 (20.0%) | 13456 (12.4%) | Hector Santos 2 (20.0%) | 8893 ( 8.2%) | John Levine 1 (10.0%) | 13314 (12.3%) | Mark Alley 1 (10.0

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Aug 13 06:00:03 2023

Count| Bytes | Who ++--- 24 ( 100%) | 187014 ( 100%) | Total 4 (16.7%) | 45854 (24.5%) | Wei Chuang 4 (16.7%) | 27867 (14.9%) | Scott Kitterman 4 (16.7%) | 23388 (12.5%) | Alessandro Vesely 3 (12.5%) | 15572 ( 8.3%) | John Levine

Re: [dmarc-ietf] Another p=reject text proposal

It appears that Jesse Thompson said: >> This of course requires that the recipient SMTP server can't simply >> reject the incoming email after the MAIL FROM because SPF checks do >> not match, they actually need to receive the email so they can check >> ARC and DKIM headers... > >During my 19

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Aug 6 06:00:05 2023

. Kucherawy 5 ( 8.9%) | 23590 ( 4.6%) | John Levine 4 ( 7.1%) | 60280 (11.6%) | Hector Santos 4 ( 7.1%) | 36381 ( 7.0%) | Barry Leiba 3 ( 5.4%) | 39883 ( 7.7%) | Douglas Foster 3 ( 5.4%) | 29507 ( 5.7%) | Jesse Thompson 3 ( 5.4%) | 25517 ( 4.9%) | Wei Chuang 3 ( 5.4%) | 25426

Re: [dmarc-ietf] Proposal for auth policy tag in draft-ietf-dmarc-dmarcbis

h large clear text saying that if any of the listed methods pass, it's aligned. R's, John -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly

Re: [dmarc-ietf] Proposal for additional Security Considerations for SPF Upgrade in draft-ietf-dmarc-dmarcbis

It appears that Tim Wicinski said: >A malicious sender needs two properties to perform such a SPF upgrade >attack: > >1) a receiver that will forward quarantined messages, and do so without changing the bounce address. Solution: Don't Do That. >> Finally, I don't think this is

Re: [dmarc-ietf] Proposal for additional Security Considerations for SPF Upgrade in draft-ietf-dmarc-dmarcbis

It appears that Scott Kitterman said: >>When receivers apply the "MUST NOT reject" in Section 8.6 to accept >>unauthenticated messages as quarantined messages, receivers SHOULD >>carefully review how they forward mail traffic to prevent additional >>security risk. That is, this downgrade can

Re: [dmarc-ietf] No submitters, Reflections on IETF 117 Conference and DMARC Meeting

It appears that Dotzero said: >Nope. A real big NOPE! There is a reason that SUBMITTER/PRA and SENDER-ID >are deprecated. I agree. They're dead, even Microsoft abandoned them years ago. Even if they were useful, which they are not, there is no chance of getting people to use them again.

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Jul 30 06:00:04 2023

%) | 5872 ( 1.6%) | Richard Clayton 1 ( 2.6%) | 3559 ( 1.0%) | John Levine ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Jul 23 06:00:04 2023

. Kucherawy 4 ( 8.0%) | 27631 ( 4.7%) | Scott Kitterman 4 ( 8.0%) | 19667 ( 3.3%) | John Levine 3 ( 6.0%) | 15678 ( 2.7%) | Baptiste Carvello 2 ( 4.0%) | 43790 ( 7.4%) | Dotzero 2 ( 4.0%) | 38595 ( 6.5%) | Mark Alley 2 ( 4.0%) | 16716 ( 2.8%) | Jan Dušátko 2 ( 4.0

Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?

It appears that Barry Leiba said: >> - An attacker sends 10 messages that maliciously impersonates a >> big bank. With help from DMARC p=reject, the evaluator blocks >> them all. The attacker follows up with 10 messages that >> maliciously impersonate a major university. The stupid >>

Re: [dmarc-ietf] Eliminating From Munging from this list

It appears that Scott Kitterman said: >>That assumes there are lists that don't munge From:. Is that real today? > >Most of my list mail is from lists that don't. > >Scott K Even for lists that do change the From: they do it in a zillion different ways that depend on the goals of the list and

Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?

It appears that OLIVIER HUREAU said: >-=-=-=-=-=- > >Hi, > >> The stupid evaluator says, "p=none means no problem here". > >And the non-stupid evaluator knows that p=none means that the domain owner >doesn't (yet) have the appropriate sending infrastructure to have >p=reject. Or it means

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Jul 16 06:00:03 2023

Vesely 3 ( 7.0%) | 30432 ( 7.3%) | Murray S. Kucherawy 3 ( 7.0%) | 14850 ( 3.6%) | John Levine 3 ( 7.0%) | 14639 ( 3.5%) | Baptiste Carvello 2 ( 4.7%) | 52978 (12.7%) | Wei Chuang 2 ( 4.7%) | 15148 ( 3.6%) | Jim Fenton 2 ( 4.7%) | 13405 ( 3.2%) | Tero Kivinen 1 ( 2.3

Re: [dmarc-ietf] Another p=reject text proposal

It appears that Barry Leiba said: >> Is “generally” true here? I think I have seen exceptions to DKIM signatures >> being valid on relayed >> messages, although I can’t dig up any examples right now. > >You seem to be answering the question you're asking. I know of none >of these relays that

Re: [dmarc-ietf] a detour into lists, Another p=reject text proposal

It appears that Murray S. Kucherawy said: >1) Are list operators and developers tolerating this situation, >temporarily, because they think this crew is going to come up with a less >disruptive permanent solution to which they expect to migrate one day? > >2) If not, have they resigned

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Jul 9 06:00:04 2023

Count| Bytes | Who ++--- 47 ( 100%) | 414179 ( 100%) | Total 9 (19.1%) | 70748 (17.1%) | Barry Leiba 6 (12.8%) | 75862 (18.3%) | Douglas Foster 6 (12.8%) | 31399 ( 7.6%) | John Levine 5 (10.6%) | 50719 (12.2%) | Scott Kitterman 5

Re: [dmarc-ietf] Another p=reject text proposal

It appears that Richard Clayton said: >They then moved on to just using random identities from the same domain >as the recipient. This led a great many Yahoo users to believe that a >great many other Yahoo users had been compromised, leading to a >significant loss of faith in the integrity of

Re: [dmarc-ietf] Questions regarding RFC 8617

It appears that Murray S. Kucherawy said: >This is intentional. DKIM also isn't specific about how a passing or >failing signature is to be interpreted, especially since DKIM can fail for >lots of otherwise legitimate reasons, for example. You are right that it says nothing about how to

Re: [dmarc-ietf] Another p=reject text proposal

It appears that Barry Leiba said: >I, too, prefer MUST to SHOULD there, but it was clear to me that we >will not reach rough consensus on MUST, but that we can reach rough >consensus on SHOULD. > >I do like your suggestion of silent discard rather than bounce, and I >would want to see that

Re: [dmarc-ietf] Another p=reject text proposal

It appears that Barry Leiba said: >This makes it explicitly clear that any MUST/SHOULD stuff with regard >to using and honoring p=reject is an issue of interoperating with >existing Internet email features. I can accept that mechanism also, >and so, below is my attempt at writing that proposal

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Jul 2 06:00:04 2023

Vesely 4 ( 9.5%) | 76566 (17.9%) | Douglas Foster 3 ( 7.1%) | 13885 ( 3.2%) | John Levine 2 ( 4.8%) | 29059 ( 6.8%) | Jan Dušátko 2 ( 4.8%) | 20127 ( 4.7%) | Scott Kitterman 2 ( 4.8%) | 19406 ( 4.5%) | Tero Kivinen 1 ( 2.4%) | 14050 ( 3.3%) | 1 ( 2.4%) | 12882 ( 3.0

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

It appears that Barry Leiba said: >I'm saying I don't want "and" to be an option, because I think it's >damaging to DMARC. There is no reason anyone should ever want to say >that, and providing the option asks for misconfigurations because >people think it's somehow "more secure". It's not

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Jun 25 06:00:04 2023

Count| Bytes | Who ++--- 67 ( 100%) | 701096 ( 100%) | Total 9 (13.4%) | 57264 ( 8.2%) | Alessandro Vesely 8 (11.9%) | 129198 (18.4%) | Douglas Foster 8 (11.9%) | 42002 ( 6.0%) | John Levine 7 (10.4%) | 67059 ( 9.6%) | Hector Santos

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

It appears that Emil Gustafsson said: >I don't know if there is a better way to encode that, but I'm supportive of >making a change that that would allow domains to tell us (gmail) that they >prefer us to require both dkim and spf for DMARC evaluation (or whatever >combination of DKIM and SPF

Re: [dmarc-ietf] The auth= tag, was DMARC2 & SPF Dependency Removal

It appears that Alessandro Vesely said: >After sleeping on it, I think the new tag could also specify DKIM /and/ SPF, >besides or and one only, ... I am reasonably sure that when DMARC was designed they considered that and rejected it. So, no, and certainly not at this late state in the WG.

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

It appears that Tobias Herkula said: >-=-=-=-=-=- >Sadly they can’t, there are Mailbox Providers that expect SPF Records, so to >maintain deliverability to those, you have to keep SPF >records in place and can’t switch to an DKIM only DMARC. Nobody's saying you can't publish SPF. We're just

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Jun 18 06:00:04 2023

4 (10.0%) | 40612 ( 5.1%) | Tero Kivinen 3 ( 7.5%) | 21602 ( 2.7%) | Murray S. Kucherawy 2 ( 5.0%) | 240188 (30.3%) | Steve Siirila 2 ( 5.0%) | 10727 ( 1.4%) | Sebastiaan de Vos 2 ( 5.0%) | 8356 ( 1.1%) | John Levine 1 ( 2.5%) | 29130 ( 3.7%) | Ken Simpson 1 ( 2.5

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

It appears that Hector Santos said: >> Can these senders not accomplish the same thing by removing the SPF record >> altogether? >> >> -MSK, participating > > >Isn’t SPF, DKIM and alignment are all required for DMARC1 passage? Failure if >any are missing? No, that has never been the case.

  1   2   3   4   5   6   7   8   9   10   >