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

On 1/17/24 2:56 AM, Alessandro Vesely wrote: [ Discussion of  what to do with multi-valued From: in messages ] However, since DMARC bears the blame of banning multi-valued From:, it is appropriate for it to say something about the consequences and possible workarounds. DMARC doesn't ban

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

On 1/11/24 10:46 AM, Murray S. Kucherawy wrote: What I recall from when we wrote that was that the first paragraph really means "Most MTAs reject this anyway so it shouldn't even get to your DMARC filter" and the second means "If it does get to you, here's how you should probably react."

Re: [dmarc-ietf] DMARCbis rev 29

On 12/1/23 11:14 AM, Dotzero wrote: On Wed, Oct 25, 2023 at 10:04 AM Todd Herr wrote: I further think that the best way to produce the next rev of DMARCbis is for the chairs and the editors (and perhaps the ADs) to huddle together and create/update issues in the Github

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

On 11/15/23 02:12, OLIVIER HUREAU wrote: As mentioned here: https://mailarchive.ietf.org/arch/msg/dmarc/ouSBtpMhD5KJp2osPfUXJktuoMQ/ I have found out that the current reporting ecosystem uses two types of XML Schema

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

On Nov 12, 2023, at 1:02 PM, Neil Anuskiewicz wrote: > > Eventually, I’d reckon, Yahoo will stop sending failure reports, rendering > them worthless as nobody you’ve heard of will send them. Even if that were to happen, the standardized format may continue in use / continue to be useful. And

Re: [dmarc-ietf] Dmarcbis way forward

On 11/12/23 03:59, Neil Anuskiewicz wrote: What is the definition of rough consensus. That is if you took a vote, 100 people voted yes and 3 voted no, the three win? Id there’s a document that states these rules I’d be happy to dig into it. If there’s a rule we should have a vote. Who is

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

On 11/12/23 04:56, Dotzero wrote: Our original intent (I'm one of the folks behind DMARC) was that failure reports would be provided to senders just like aggregate reports. This was before GDPR and privacy concerns did a number on the practice. The companies that provide the service of

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

On 10/25/23 4:25 AM, Matthäus Wander wrote: Olivier Hureau wrote on 2023-10-25 12:56: What about using the error report of RFC 7489 for this purpose instead of aggregate report? ( https://datatracker.ietf.org/doc/html/rfc7489#section-7.2.2 ) I have never seen any error report but I think

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

On 10/20/23 12:35 PM, Murray S. Kucherawy wrote: (1) As written, the text says (to me) that the handling of a message might change depending on this mapping of a broken value to "none", but only if "rua" is present; absent "rua", the record is treated as junk and DMARC doesn't apply. It's

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

On 8/3/23 12:50 AM, Alessandro Vesely wrote: There is a push to avoid names that might recall racial prejudice, so blacklists are sometimes called blocklists...  The mentioned Appendix D talks about "whitelists of generally recognized forwarding services".  I support sticking to classic

Re: [dmarc-ietf] Signaling MLMs

On 4/12/23 11:15 AM, Murray S. Kucherawy wrote: The MLM can then decide if it is willing to pass the message unmodified to the list, or reject it with an error like "The policies of this list require modification of your message, which violates your domain's apparent policy.  Your submission

Re: [dmarc-ietf] ARC Dependency?

On 3/24/23 3:48 AM, Douglas Foster wrote: Do we know if any entity other than Google is successfully using ARC as an evaluation tool? FWIW: In late 2021 a "German company" reported that it was able to "recover" about 10% of messages that had failed other authentication checks by

Re: [dmarc-ietf] PSL vs. Tree Walk and Failure Reports, was Re: DMARC agenda for IETF 116 -- and do we need one?

On 3/14/23 13:18, Scott Kitterman wrote: My expectation is that if you were able to contact the people who made that decision, they'd say they did it because they want information on DMARC failures, which is not what DMARC failure reports give you. They provide details on messages which fail

Re: [dmarc-ietf] PSL vs. Tree Walk and Failure Reports, was Re: DMARC agenda for IETF 116 -- and do we need one?

On 3/12/23 07:50, John Levine wrote: It also occurs to me that anyone who sends failure reports also sends aggregate reports, so if you care, you have a way to find out. This made me wonder if everybody requesting failure reports also requests aggregate reports, so I took a look at the data

[dmarc-ietf] PSL vs. Tree Walk and Failure Reports, was Re: DMARC agenda for IETF 116 -- and do we need one?

On 3/10/23 3:08 AM, Alessandro Vesely wrote: although I'm back as an editor of the failure reporting I-D, that file is almost final and I can't think of anything to be discussed live about it.  I haven't registered for 116. Off the top of my head, and in light of the aggregate reports

Re: [dmarc-ietf] Version in aggregate report

On 3/9/23 11:45, Tomki Camp wrote: I think that's a good idea. Mike Jones from Fortra (ne Agari) also expressed concern during M3AAWG 57 about problems for data analysis to be able to determine how a specific receiver's result was achieved, with the discovery methodology doubling. An XML

Re: [dmarc-ietf] Missing participation from big tech members

On 11/19/22 19:13, Douglas Foster wrote: > I note that I have no feedback reports from: The best view of who participates in DMARC feedback reporting probably lies with the report processors. Some of them will tell you who they are getting reports from:    

Re: [dmarc-ietf] Weak signatures

On 10/27/22 16:04, John Levine wrote: It appears that Brotman, Alex said: How will we handle the ever-changing definition of "weak"? ... There is no reason for DMARC to say anything at all about either flavor of weak signature. +1. I was concerned we might be heading toward our own

Re: [dmarc-ietf] Weak signatures

On 10/26/22 16:45, Neil Anuskiewicz wrote: On Oct 26, 2022, at 3:48 AM, Douglas Foster wrote:  Murray first raised the issue of weak signatures. ... Weak results need to be part of the aggregate report so that domain owners understand the importance of moving from weak to strong

Re: [dmarc-ietf] Priming the Pump for Discussion - Ratchets

On 7/6/21 05:45, Todd Herr wrote: > > The theoretical goal of any domain owner that publishes a DMARC record > is to transition from an initial policy of p=none to a final one of > p=reject, because it is only at p=reject that DMARC's intended purpose > of preventing same-domain spoofing can be

Re: [dmarc-ietf] Sender-supplied decision matrix for passing DMARC

On 6/14/21 10:09, Brotman, Alex wrote: > Does this make everyone cringe, or perhaps worth a larger discussion? This was considered (repeatedly) during the original DMARC work, and I believe again while it was being put into RFC7489 form. It was rejected because it increased the likelihood of

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

On 5/31/21 15:49, Steven M Jones wrote: > I think we can get the input needed to resolve this by Todd's requested > deadline, and be able to show we did the due diligence to back up the > decision. I got three responses - unfortunately I discovered I don't have as many of these cont

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

I'm not philosophically or religiously opposed to removing the size limit but I would like to have some data, or at least informed feedback, to justify the decision. This feature was not in the original December 2011 specification, but was added in the March 2012 revision (both were pre-IETF).

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

On 5/28/21 08:46, Todd Herr wrote: > > Consensus on Ticket #54 > (Remove or expand limits on number of recipients per report) was > reached during the May 27 DMARC Interim to update the text in the > DMARC URIs section to read: > > The place such

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

On 5/28/21 08:47, 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" tag from the core spec and allow for the > possibility that it could potentially be

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

On 5/28/21 08:46, Todd Herr wrote: > > Consensus on Ticket #53 > (Remove reporting message size chunking) was reached during the May 27 > DMARC Interim to remove the feature and update the IANA registry and > ABNF grammar as necessary. I support the

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

On 5/28/21 08:43, Todd Herr wrote: > > Consensus on Ticket #50 > (Remove ri= tag) was reached during the May 27 DMARC Interim to remove > the tag and update the IANA registry to reflect its removal. I support removing the tag from the specification,

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

On 5/28/21 08:43, Todd Herr wrote: > > Consensus on Ticket #47 > (Removal of "pct" tag) was reached during the May 27 DMARC Interim to > keep the tag, but to rewrite its definition in whole or in part to > make its usage better understood. I support

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

On 5/28/21 08:43, Todd Herr wrote: > > Consensus on Ticket #4 > (Definition of "fo" > parameter) was reached during the May 27 DMARC Interim to update the > definition of the "fo" parameter with the following sentence, as shown > in dmarcbis-01: > >

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

On 5/5/21 21:26, Seth Blank wrote: > > The Chairs ask group participants to explicitly speak up if: > 1) they intend to participate in the interim > or 2) they wish to participate in the interim, but the timing does not > work 1) Intend to participate

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

On 2/21/21 08:49, Chudow, Eric B CIV NSA DSAW (USA) wrote: > I think it's getting better, but I wouldn't call them Internet Naming > Authorities. Should we just call them higher-level entities? There are proper names for these actors - there's no need to be even more vague ... > Also, while

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

On 1/27/21 19:08, John R Levine wrote: > On Wed, 27 Jan 2021, Murray S. Kucherawy wrote: >>> I still don't understand why failure reports about messages that >>> happen to be failure reports are in any way special. >> >> Loop detection in RFC 5321 is a normative MUST because of the obvious >>

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

On 1/27/21 12:47, Murray S. Kucherawy wrote: > On Wed, Jan 27, 2021 at 12:37 PM John Levine > wrote: > > I still don't understand why failure reports about messages that > happen to be failure reports are in any way special. > > > Loop detection in RFC 5321 is a

Re: [dmarc-ietf] attack on reports

On 1/26/21 11:24, Michael Thomas wrote: > > Here's a very basic question: if I do not know all of the IP addresses > that send on my behalf, are DMARC reports of any value? > No, an organization is not assumed to have perfect knowledge of all their authorized sending sources. If that were common,

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

On 1/25/21 12:18 PM, Michael Thomas wrote: On 1/25/21 12:08 PM, Todd Herr wrote: On Mon, Jan 25, 2021 at 2:56 PM Michael Thomas > wrote: Sounds like a bug to me and an issue should be opened. Just because it's a 10 year old bug doesn't mean it's not a bug.

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

On 1/20/21 15:10, Steven M Jones wrote: > > Duplicate reports to the same destination are not > the base case I may be an idiot, or at least too quick to hit Send. Since nobody implements https:// yet, what does the transition look like? Likely two URIs to the same report processor, u

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

On 1/19/21 06:02, Todd Herr wrote: > Picking up the thread on a ticket that was brought before the group > pre-holidays and has lain fallow since the end of 2020... Prompted me to read from the start of the thread through: On 1/20/21 11:19, John R Levine wrote: > On Wed, 20 Jan 2021, Alessandro

Re: [dmarc-ietf] Forensic report loops

On 1/13/21 20:29, Murray S. Kucherawy wrote: > > How are implementers dealing with forensic report loops? The question of whether such a thing is actually ever seen in the wild should be asked, if only to document that it was asked and answered. See prior "this is a vanishingly small number who

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

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 the pct= option were all included so that organizations could set

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

On 11/9/20 4:15 AM, Alessandro Vesely wrote: On Sat 07/Nov/2020 10:52:44 +0100 Steven M Jones wrote: I'm pretty sure both cases would be invalid as DMARC policy records, in which case they should be ignored. I don't think so.  The current draft says: [...] Oops - thank you

Re: [dmarc-ietf] Announcing DMARCbis Editors

On 11/7/20 8:20 PM, Dave Crocker wrote: On 11/7/2020 8:12 PM, Steven M Jones wrote: that's why the policy option of "p=none" exists. Perhaps the use of the string "none," meaning "no change in handling," is too readily confused with "none" meaning &

Re: [dmarc-ietf] Announcing DMARCbis Editors

On 11/7/20 5:00 PM, Dave Crocker wrote: On 11/7/2020 4:50 PM, Jim Fenton wrote: If that last sentence is the consensus of the working group (and I see that the charter could be interpreted that policy is required), then fine. But I consider the reporting aspect to be useful even in the

Re: [dmarc-ietf] Announcing DMARCbis Editors

On 11/7/20 4:50 PM, Jim Fenton wrote: On 5 Nov 2020, at 9:45, Seth Blank wrote: [...] To Todd's point, DMARC is a means of communicating policy between domain owner and mail receiver regarding how to handle unauthenticated mail. DMARC does not function without policy. [...] But I consider

[dmarc-ietf] Separate policy spec, was Re: Optional p= makes no sense

I wanted to bring this topic into a visibly different thread, as it's really about further splitting up of the base DMARC document. In digging through recent messages, I think I see what Ale meant. The topic was Jim Fenton's suggestion of splitting the policy section out into a separate

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

On 11/7/20 5:09 AM, Douglas E. Foster wrote: The report receiver verification step was referenced in the response.   This was the pointer: https://tools.ietf.org/html/rfc7489#section-7.1. It requires a DNS entry at: . _report._dmarc., type TXT, value "v=DMARC1"  (No other content is

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

On 11/7/20 1:11 AM, Alessandro Vesely wrote: On Fri 06/Nov/2020 14:57:46 +0100 Todd Herr wrote: On Fri, Nov 6, 2020 at 7:27 AM Douglas E. Foster wrote: It makes no sense to allow "p=" missing.   Why would we suggest that all existing implementations alter their code to tolerate additional

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

On 10/26/20 14:58, Tim Wicinski wrote: > > This starts a Call for Adoption for: DMARC-bis I support adoption of the DMARCbis draft as a working group document. (I realize you asked for objections, but you need some record of support to proceed, don't you?) --S.

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

On 9/23/20 2:49 PM, Seth Blank wrote: ... the Chairs strongly believe that having rough consensus on clear definitions is key to progressing the bis effort effectively. We strongly agree with Dave Crocker's position here:

Re: [dmarc-ietf] Meetecho at IETF 108

On 7/28/20 7:07 AM, Murray S. Kucherawy wrote: If any of those of you who participated in today's working group session via the Meetecho interface have any thoughts ...  You can email the list, the chairs, or me with your thoughts. Having to flip back and forth between the chat column and

[dmarc-ietf] MUAs showing From: address field, was Re: DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D

On 6/2/20 5:45 PM, Douglas E. Foster wrote: As to visibility: The business world still runs on Microsoft Outlook, and **Outlook presents the From Address** when a message is read. So it is odd to assert that no one ever sees that data. [Emphasis added] Regarding this and a subsequent

Re: [dmarc-ietf] More redacted RUF reports better than no RUF reports

On 6/11/20 5:22 PM, Scott Kitterman wrote: On June 11, 2020 6:28:13 PM UTC, Steven M Jones wrote: ... I also suggested that perhaps potential failure report generators would be encouraged if they could see examples of reports with different levels of redaction. I think it's entirely sensible

[dmarc-ietf] More redacted RUF reports better than no RUF reports

In the WG Interim Session, I had given a "+1" to Autumn Tyr-Salvia's comment about redacted failure reports being better than no failure reports. I also suggested that perhaps potential failure report generators would be encouraged if they could see examples of reports with different levels

Re: [dmarc-ietf] DMARC bis: ticket 49: remove normative requirement on policy tag placement

On 05/21/2020 14:11, Scott Kitterman wrote: Also, I don't see a problem with making the p= tag optional (with an inferred value of None if not present). This is consistent with an existing SHOULD in RFC 7489 and appears to be broadly supported in existing implementations. Wow, did I

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

On 05/15/2020 13:16, Scott Kitterman wrote: When there is only one report format, there's no need to discover a common format between report senders and report receivers. As soon as there are two, then to be interoperable, then either both report formats are required or there has to be some

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

On 05/15/2020 11:26, Seth Blank wrote: https://trac.ietf.org/trac/dmarc/ticket/69 Aggregate reports are only sent in XML format. There's been some discussion (that's also related to https://trac.ietf.org/trac/dmarc/ticket/42 about expanding reporting functionality beyond mailto:), of adding

[dmarc-ietf] draft-ietf-dmarc-arc-usage-08 published

This document is officially in "Parked WG Document" state while we focus on other matters, but it seemed worthwhile to keep it from expiring. One typo noticed after the last update in April was corrected. ___ dmarc mailing list dmarc@ietf.org

Re: [dmarc-ietf] Request to accept a new I-D into the WG work items

On 11/07/2018 11:41 PM, Scott Kitterman wrote: I'd suggest we adopt the draft/work item and then try to figure it out. +1. We should see where we can get with this topic. --S. ___ dmarc mailing list dmarc@ietf.org

[dmarc-ietf] New version of draft-ietf-dmarc-arc-usage posted

Greetings, I've submitted the changes to the "ARC Usage" I-D that I had on-hand, primarily because the previous version was going to expire on October 25th, and the I-D freeze for IETF103 was going to occur this evening. That deadline was extended by 24 hours, but I opted not to push it

Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-arc-protocol-16

It's been quite a while since my last full read-through of the spec, so apologies if I blunder into anything long-settled. And apologies if I'm repeating something from earlier commentary, I'm trying to get in under a very liberal interpretation of the deadline as is... ;) Love the way

Re: [dmarc-ietf] [Request] Presentation in IETF101

On 3/19/18 2:02 PM, Yasutaka, Genki | Dkim | OPS wrote: > > > You can download from the following link. > > https://datatracker.ietf.org/meeting/agenda.html > > - Virtual DMARC: DMARC verification without record definitions > > I will send you directly just in case. > Thank you, I found it -- I

Re: [dmarc-ietf] [Request] Presentation in IETF101

I want to thank Yasutaka san for presenting the Virtual DMARC proposal. I believe the situation he and his colleagues are addressing would benefit from more attention. The meeting materials at IETF do not seem to include Yasutaka san's slides. If I didn't just miss it, would it be possible to

Re: [dmarc-ietf] Agenda for IETF 101 DMARC session

On 3/15/18 10:19 AM, Kurt Andersen (b) wrote: > Two more items for discussion (coming from a chat that I had with some > of the NCSC folks today): Thanks for sharing their input. > * Creating a diagnostic report that would have some additional > information (such as sending address) and

Re: [dmarc-ietf] ARC Experimental goals

On 07/22/2017 12:36 AM, Tim Draegen wrote: > Why not pipe what is learned directly into a BCP.. you know.. in real time? Hmm, perhaps some kind of "feedback report" could be used... ;) ___ dmarc mailing list dmarc@ietf.org

Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC

On 07/18/2017 01:00 PM, Kurt Andersen wrote: > > We've suggested (during M3AAWG sessions) that smaller recipients can > build out a whitelist of "commonly seen" mediators, but might there be > value in having a mediator publish some sort of DNS record that would > indicate that they ARC seal

Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC

On 07/18/2017 01:00 PM, Kurt Andersen wrote: > > We've suggested (during M3AAWG sessions) that smaller recipients can > build out a whitelist of "commonly seen" mediators, but might there be > value in having a mediator publish some sort of DNS record that would > indicate that they ARC seal

Re: [dmarc-ietf] ARC RFC status to target

On 07/07/2017 12:12, Andrew Sullivan wrote: > On Fri, Jul 07, 2017 at 11:57:36AM -0700, Steven M Jones wrote: >> Would there be a proposed schedule for that evaluation to take place? > It's a good question, but I have two responses: > > 1. IETF timelines are worth approxima

Re: [dmarc-ietf] ARC RFC status to target

On 7/7/17 11:29 AM, Andrew Sullivan wrote: > On Fri, Jul 07, 2017 at 11:09:41AM -0700, Dave Crocker wrote: >> Experimental status is exactly for this purpose. > I always feel like experimental status ought to come with some > description of what success or failure would mean and how that would >

[dmarc-ietf] Anybody new for a possible interop in Lisbon, week of M3AAWG?

>From time to time we've organized interoperability testing sessions for ARC implementers. We have the opportunity to hold one the week of the M3AAWG meeting in Lisbon, Portugal in June. Is there anybody who hadn't previously raised their hand as an implementer, who has or is developing an

Re: [dmarc-ietf] ARC-Authentication-Results

On 04/03/2017 16:49, Murray S. Kucherawy wrote: > The latest ARC base document says this about the > ARC-Authentication-Results field: > >ARC-Authentication-Results is a direct copy of the Authentication- >Results header field [RFC7601 ] > created for

Re: [dmarc-ietf] Section [5.2.1] of the ARC draft

On 01/20/2017 11:23, Scott Kitterman wrote: > > I'm not on the ARC list, so I'll pile on this thread here... This is the right place for anything constructive regarding the specification, so no problem regarding any other lists. > I understand the minimum key size in the draft is 512 bits. I'm

Re: [dmarc-ietf] ARC Interoperability testing Friday, Dec 16th

On 12/29/2016 15:15, Barry Leiba wrote: > Steve, can you give us a brief report on how this went? A very brief report, yes - because it turned out that three of four implementations would have no representatives available at that time, so the testing did not in fact happen. My apologies for not

Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag

Hello Marco, Interesting proposal, from a five minute skim via cell phone. Have any mailbox providers or report generators shared their views on the incremental overhead of having to track this kind if interval timer for each sending domain that experiences an authentication failure, versus

Re: [dmarc-ietf] draft-kucherawy-dmarc-rcpts

On 11/12/2016 22:50, Murray S. Kucherawy wrote: > I've posted a draft that attempts to address an attack that's begun to > appear with DKIM. Interestingly, we called it out as a possible > attack in RFC6376 and even RFC4871, but now it's apparently happening > and being annoying enough that

[dmarc-ietf] ARC: Syntax for ARC-Authentication Results header

alue pair.) But I don't see any problem with the ARC "i=N" sequence tag/value being treated as a separate pre-pended clause, so long as it properly references RFC7601 in the spec. Any thoughts on this? Any other areas that need to be tightened up in the ARC draft spec?? Thanks, --Steve.

[dmarc-ietf] ARC Interoperability testing event this Friday, 9/23

in these events. Thanks, --Steve. Steven M Jones DMARC.org e: s...@dmarc.org, s...@crash.com ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Most common problems with DMARC records

ommon fault appears to involve using too many escape and quoting characters in the nameserver data, resulting in extraneous characters in the published record. It's known that many mail receiver implementations will strip out some quoting and escaping characters in DMARC records they retrieve, though the d

Re: [dmarc-ietf] [dmarc-discuss] exegesis: pass and fail together

On 07/07/2016 11:54, Elizabeth Zwicky wrote: > > Tomki [Camp] pointed out that I am completely wrong about selectors and > lots of people report them. I should have checked. And I didn't check - I do see provision for selectors in the aggregate report XML in RFC7489. Is the question of messages

Re: [dmarc-ietf] [dmarc-discuss] exegesis: pass and fail together

I'm quoting the following response in a thread from the dmarc-disc...@dmarc.org mailing list, because I think it identifies work items or at least questions this WG may want to address. If this is already captured somewhere, my apologies. Here's the original thread:

Re: [dmarc-ietf] [dmarc-discuss] ARC adoption

+ dmarc@ietf.org because Roland's responses should be considered/captured there too. Additional comment bottom-posted. On 6/29/16 12:09 AM, Roland Turner via dmarc-discuss wrote: Andreas Schulze wrote: 2) a general point I'm still unsure about:

Re: [dmarc-ietf] [dmarc-discuss] ARC adoption

+ dmarc@ietf.org list to capture for ARC discussion/archive On 06/28/2016 09:12, A. Schulze via dmarc-discuss wrote: > > Kurt just mention adoption in his last message. > Adoption is a good point, I've two questions: > > 1) > are there implementation available as open source? There is an

[dmarc-ietf] Overview slides for the ARC protocol available

. Direct download: https://dmarc.org/presentations/ARC-Overview-2016Q2-v03.pdf SlideShare: http://www.slideshare.net/SteveJones250/overview-of-the-arc-protocol-for-email Share and Enjoy, --Steve. -- Steven M Jones CRASH Computing e: s...@crash.com m: +1-254-220-4488 Skype: smjcrash, +1-415-799

Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone)

On 05/17/2016 13:14, MH Michael Hammer (5304) wrote: > > MK: Absent a desire to form a distinct working group to develop ARC, I think > we need to discuss rechartering before we can entertain this motion. > > MH: If we need to re-charter then I think we should re-charter. There > are already

Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone)

On 05/17/2016 12:53, Murray S. Kucherawy wrote: > > The charter enumerates three tracks, the first of which appears to allow > discussion of new protocols; in particular, one might argue that ARC is > a "form of DKIM signature that is better able to survive transit through > intermediaries".

Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone)

has great promise, but we're just completing and testing initial implementations. There are frequent discussions of specification changes (on arc-discuss and elsewhere), which shows that there's substantive work to be done - and that work can only benefit from the broader community that an IETF W

[dmarc-ietf] Semi-OT: Next ARC Interop Testing: April 1st

nother virtual interop session held on Friday, May 13th. So if you're just starting your implementation, that may serve as a useful deadline or integration/testing opportunity. Let me know, --Steve. -- Steven M Jones DMARC.org ___ dmarc mailing list dmarc@

[dmarc-ietf] Two ARC implementations tested at interoperability event

On February 19th AOL and Google successfully tested their implementations of ARC at the interoperability event held on February 19th. More details here: https://dmarc.org/2016/03/two-arc-implementations-tested-at-interoperability-event/ Many thanks to LinkedIn for hosting the event. I'm

[dmarc-ietf] ARC interoperability testing day: Friday, Feb 19th

With the chair's indulgence, I'd like to share a reminder with this list about an upcoming. related event. Follow-ups may be more appropriate on the arc-discuss list. See http://lists.dmarc.org/mailman/listinfo/arc-discuss for details of that list; see http://arc-spec.org for more information on

Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy

On 05/19/2015 13:01, Murray S. Kucherawy wrote: On Tue, May 19, 2015 at 12:00 PM, Terry Zink tz...@exchange.microsoft.com mailto:tz...@exchange.microsoft.com wrote: 6.What is the proposed t= time limit? Is 30 seconds enough? Too long? Too little? I would guess too little, but at this

[dmarc-ietf] DMARC panel at RSA, 4/22 @ 10:20AM

For anybody who will be attending the RSA Conference in San Francisco about a week and a half from today, there's at least one panel focused on DMARC: Curbing Email Threats Spearphishing– The Promise Results with DMARC Wednesday, April 22nd, 10:20 - 11:10AM, West, Room 2018

[dmarc-ietf] DMARC.org, was Re: Third Party Sender DMARC Adaptations

On 04/02/2015 12:42 PM, Rolf E. Sonneveld wrote: P.S. I only noticed today the significant organizational change of dmarc.org [3] and the fact that this 'new' dmarc.org has only two founding sponsors. While the change to the organization is significant - for instance, there is now a formal

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On 03/26/2015 04:22 PM, Franck Martin wrote: What I learn for all the combinations: It does not change much, people still ignore my posts :P Franck, that's wy outside the charter of this working group... ___ dmarc mailing list dmarc@ietf.org

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On 03/24/2015 01:38 PM, J. Gomez wrote: I do not agree. As long a major ESPs downgrade p=reject to p=quarantine or even p=none on reception of email which fails DMARC checks from domains whose Owner has published p=reject, DMARC is little more than a reporting protocol as Vlatko Salaj has

Re: [dmarc-ietf] Formal specification, URI

On 03/16/2015 12:22 PM, Murray S. Kucherawy wrote: [...] The goal in allowing a comma-separated list of URLs is that you might conceivably want to put an http and a mailto URL in there, in the try A first, then try B sense. We need to allow for that possibility. We also need to account for

Re: [dmarc-ietf] yet more From rewriting,

On 09/23/2014 10:26 AM, Stephen J. Turnbull wrote: On 09/22/2014 03:17 PM, Josh Aberant wrote: alias. Google Groups (takes ownership of the From per our #RejectPolicy) and then I don't understand our #RejectPolicy. What are you talking about? Surely not DMARC? That reject policy

Re: [dmarc-ietf] yet more From rewriting,

On 09/22/2014 03:17 PM, Josh Aberant wrote: Who uses X-Original-From ? This is a real question, I'm not aware of anyone who does. At Twitter we use the X-Original-From to route our security tickets with users within our ticketing system Salesforce. Users can open and reply to tickets by

Re: [dmarc-ietf] Start of DMARC WG + proposed milestones

I agree with most of the commentary I've seen in this thread. I just wanted to highlight one milestone: - EOY 2014: Deliverable #1 (above document + possible methods to address). - 92nd IETF: Deliverable #2 - Document describing DMARC improvements to better support indirect mail

Re: [dmarc-ietf] Draft DMARC working group charter

On 07/01/2014 07:58 PM, Stephen J. Turnbull wrote: Steven M Jones writes: [ ...] part) how such work completed outside and after this WG could be plugged in? I think precluding is advisable. [...] I don't see how we can really define a plug-in beyond new algorithm, while

Re: [dmarc-ietf] Draft DMARC working group charter

As a couple people have observed it's a complicated charter, but then it's a complicated situation... I think this does the trick. +1. That said, one small point to consider: The task of defining a standard mechanism for identifying organizational domain is out of scope for this working

Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)

On 05/30/2014 11:28 AM, Stephen J. Turnbull wrote: I am of the opinion that the technical DMARC protocols (including p=reject) are fine. I have not heard of any complaint about use by banks (Bank of America joined the ranks of p=reject banks some time in the last 10 days AFAICT). Have there

[dmarc-ietf] New DMARC WG, was Re: DKIM through mailing lists (rebutting MLs won't change)

On 05/30/2014 11:28 AM, Stephen J. Turnbull wrote: Murray S. Kucherawy writes: DMARC change is even more off the table than MLM software change (which does, as you suggest, evolve over time). Are there changes people want to make? I am of the opinion that the technical DMARC

  1   2   >