[dmarc-ietf] ARC questions

Hi all, long time. I finally read through the ARC spec after seeing it accidentally in mail headers wondering what it was, especially since it was so DKIM like. My barely informed take is that it allows intermediaries to say "this is what it looked like to me at this point [and before i mess

Re: [dmarc-ietf] ARC questions

ight add legit ARC signatures are. On Sat, Nov 21, 2020 at 2:33 PM Michael Thomas <mailto:m...@mtcc.com>> wrote: Or did I miss where ARC resigns the body? Or is there a tie in for ARC with the mailing list's resigned DKIM signature for the new message? The ARC-Mes

Re: [dmarc-ietf] ARC questions

On 11/22/20 11:14 AM, John R Levine wrote: Is there a reason that there is a separate ARC-signature rather than just using the DKIM signature that is normally created for the new message? Since ARC is new, you'd not want the intermediary to stop DKIM signing the message so you end up with esse

Re: [dmarc-ietf] ARC questions

wait, Kurt just said that the body hash is included. Somebody has to be wrong here. Mike Sent from my Verizon, Samsung Galaxy smartphone Original message From: John R Levine Date: 11/22/20 2:14 PM (GMT-05:00) To: Michael Thomas , "Kurt Andersen (b)"

Re: [dmarc-ietf] ARC questions

On 11/22/20 11:56 AM, John R Levine wrote: On Sun, 22 Nov 2020, Michael Thomas wrote: The ARC signature has a sequence number so you can track the chain of custody.  You are right that it is similar to the DKIM signature but the extra ovehead doesn't seem excessive. Did the wg consider

Re: [dmarc-ietf] ARC questions

On 11/23/20 11:28 AM, John R Levine wrote: From what I can tell, the main thing that ARC is doing is binding an auth-res to a dkim signature-like thing. But as I recall -- it's been a long time -- there were ordering requirements ala received headers for where new dkim-signatures and auth-res

Re: [dmarc-ietf] ARC questions

On 11/23/20 11:42 AM, Brandon Long wrote: Yes, responsibility is the proper word.  My point survives the word change. DKIM says the domain takes responsibility for the message, while ARC says the domain takes responsibility for evaluating the status of the message when they received and fo

Re: [dmarc-ietf] ARC questions

On 11/23/20 11:49 AM, Brandon Long wrote: I imagine that the vast majority of intermediaries that break signatures number exactly one extra domain, so it's not very hard to reconstruct the chain of custody from origin to destination. Assuming the intermediary resigns with th

Re: [dmarc-ietf] ARC questions

On 11/23/20 11:34 AM, Brandon Long wrote: From the other direction, one could say that ARC is a superset of A-R and DKIM with different purpose, and you might be able to subsume them into ARC, but you couldn't build ARC out of the originals. It's seems to me that the superset involves exp

Re: [dmarc-ietf] ARC questions

On 11/23/20 12:09 PM, John R Levine wrote: Since this is an experiment, do we have an idea of what the rest of the problem is after the typical mailing list-like signature breakers are excluded? Sorry, this question makes no sense. The point of ARC is to deal with the kind of breakage that

Re: [dmarc-ietf] ARC questions

On 11/23/20 12:29 PM, John R Levine wrote: 1) A mailing list creates an auth-res on the incoming mail to the list 2) It modified the message 3) It resigns the message with DKIM 4) It is then delivered to the subscriber's mail server 5) The destination mail server can look at the incoming mes

Re: [dmarc-ietf] ARC questions

On 11/23/20 12:15 PM, Brandon Long wrote: This recent article also goes into things that DKIM signatures imply: https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/

Re: [dmarc-ietf] ARC questions

On 11/23/20 12:48 PM, Dave Crocker wrote: This recent article also goes into things that DKIM signatures imply: https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/

Re: [dmarc-ietf] ARC questions

On 11/23/20 3:00 PM, Dave Crocker wrote: On 11/23/2020 2:58 PM, John R Levine wrote: And, again, when ARC work was pursued, I don't recall anyone claiming that mailing lists were (significant) sources of misbehavior. Well, OK.  Please feel free to provide footnoted documentation of what the ac

Re: [dmarc-ietf] ARC questions

On 11/23/20 6:04 PM, John Levine wrote: In article you write: What I'm struggling to understand is what having authenticated auth-res >from a previous hop helps. this is what i found: See some of the previous messages. My usual example is a mailing list message that fails DMARC at the final

Re: [dmarc-ietf] ARC questions

m with existing DKIM signatures, we would have." And as I've said repeatedly, do not contact me in private. Mike On 11/24/20 2:53 PM, John R Levine wrote: This appears to me to be an ad-hominem attack on the people who designed ARC, so I think we're done. On Tue, 24 Nov 2020, Mic

[dmarc-ietf] Messages passing more than one modifying intermediary?

Does anybody know what percentage of traffic that passes through more than one modifying intermediary in different administrative domains? I know that modifying intermediaries like mailing lists are relatively rare, so I'd think that messages that go through more than one would be extremely

Re: [dmarc-ietf] ARC questions

On 11/24/20 3:24 PM, Brandon Long wrote: On Tue, Nov 24, 2020 at 2:49 PM Michael Thomas <mailto:m...@mtcc.com>> wrote: Sorry, changing the auth-res to old-auth-res and dkim signing the message would be completely sufficient, and far easier to understand with a lot l

Re: [dmarc-ietf] ARC questions

On 11/24/20 4:56 PM, Brandon Long wrote: On Tue, Nov 24, 2020 at 3:57 PM Michael Thomas <mailto:m...@mtcc.com>> wrote: Our experience also showed that more than one hop is quite common in enterprise deployments, and those are also the places where the most complexi

Re: [dmarc-ietf] ARC questions

On 11/24/20 8:19 PM, Murray S. Kucherawy wrote: On Tue, Nov 24, 2020 at 7:27 PM Douglas Foster > wrote: Michael, I think the purpose is stated well enough:   Mailing lists want to keep adding their content to messages, without being block

Re: [dmarc-ietf] ARC questions

On 11/24/20 7:27 PM, Douglas Foster wrote: In my opinion, ARC does leave a lot of unanswered questions about how you use the data that ARC provides.   Again, the big organizations have the brain power at their disposal to figure that out for themselves, later. They've had that data for

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

On 11/25/20 11:11 AM, Alessandro Vesely wrote: Hi, On 25/11/2020 19:24, Jesse Thompson wrote: On 11/25/20 11:30 AM, Alessandro Vesely wrote: Without resorting to ARC, it is still possible to validate author domain's signatures directly if the MLM just adds a subject tag and a footer, like, f

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

On 11/25/20 12:31 PM, John Levine wrote: In article , Michael Thomas wrote: When I was at Cisco, with l= and some subject line heuristics I could get probably like 90+% verification rate across the entire company, a company that uses external mailing lists a lot. Definitely not 100% though

Re: [dmarc-ietf] ARC questions

On 11/25/20 4:14 PM, Murray S. Kucherawy wrote: On Wed, Nov 25, 2020 at 11:03 AM Michael Thomas <mailto:m...@mtcc.com>> wrote: That's been known for over 15 years. I'm still trying to understand the assertion that DKIM signatures are a "bad fit". I ju

Re: [dmarc-ietf] ARC questions

On 11/26/20 1:56 AM, Murray S. Kucherawy wrote: ARC was developed over months, even before this WG started, and I remember all of these conversations happening involving the questions you're now asking.  We landed at what became ARC.  I suppose an appendix might've been nice enumerating ever

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

On 11/30/20 8:56 PM, Brandon Long wrote: On Thu, Nov 26, 2020 at 12:59 AM Alessandro Vesely <mailto:ves...@tana.it>> wrote: On 25/11/2020 20:16, Michael Thomas wrote: > When I was at Cisco, with l= and some subject line heuristics I could get > p

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

On 12/1/20 6:21 PM, Brandon Long wrote: On Tue, Dec 1, 2020 at 10:07 AM Michael Thomas <mailto:m...@mtcc.com>> wrote: On 11/30/20 8:56 PM, Brandon Long wrote: Right, some of the other dkim-light or diff concepts we discussed would be better than using l= We again

Re: [dmarc-ietf] ARC questions

On 11/30/20 9:43 PM, Brandon Long wrote: To summarize what I said already in this thread, DKIM is taken by many receivers as the responsible party for a message, in both spam and phishing classifiers, with the latter being perhaps more relevant. DMARC is the one example of that.  DKIM signing

Re: [dmarc-ietf] ARC questions

On 12/2/20 12:31 PM, John R Levine wrote: On Wed, 2 Dec 2020, Michael Thomas wrote: Ignoring the existing usage of DKIM, DKIM+A-R would only work for a single hop, and lead to some complication compared to the other DKIM signatures already on the message. Wait, what? a DKIM signatures

Re: [dmarc-ietf] ARC questions

On 12/2/20 12:35 PM, John R Levine wrote: On Wed, 2 Dec 2020, Michael Thomas wrote: different in that respect. In fact as far as I can tell they are identical modulo the i= difference. Please reread the ARC spec.  The ARC-Authentication-Results at level N tells you whether the ARC and DKIM

Re: [dmarc-ietf] ARC questions

On 12/2/20 2:53 PM, John R Levine wrote: Which could trivially be added as an extension to DKIM and Auth-Res negating the need for the Seal altogether since DKIM can directly sign the old (renamed) auth-res. I can understand for an experiment not wanting to touch dkim or auth-res, but for some

[dmarc-ietf] Advancing ARC?

Was/is there a plan to advance ARC to standards track? I see in the rfc that there are some questions that assumedly need to be answered. I would hope that that list is not exhaustive and that other questions can be posed to determine whether to go forward. As I've said in the other thread,

Re: [dmarc-ietf] ARC questions

On 12/2/20 6:33 PM, John R Levine wrote: On Wed, 2 Dec 2020, Michael Thomas wrote: But why bother?  The IANA header field registry currently has 419 entries. Why is it a crisis if it increases to 422 rather than 420? It does a lot more than that: We've been through this all before and

Re: [dmarc-ietf] ARC questions

PS: you're adding X-Google-DKIM-Signature which nobody knows what its utility is to your bloat total for dramatic effect. Mike On 12/2/20 6:33 PM, John R Levine wrote: On Wed, 2 Dec 2020, Michael Thomas wrote: But why bother?  The IANA header field registry currently has 419 entries. W

Re: [dmarc-ietf] ARC questions

oogle-DKIM-Signature which nobody knows what its utility is to your bloat total for dramatic effect. Um, it was there when your message arrived here.  Complain to your mail provider. On 12/2/20 6:33 PM, John R Levine wrote: On Wed, 2 Dec 2020, Michael Thomas wrote: But why bother?  The I

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

On 12/2/20 10:12 PM, Jim Fenton wrote: On 2 Dec 2020, at 6:09, Dave Crocker wrote: *none*: The Domain Owner offers no expression of concern. *quarantine:* The Domain Owner considers such mail to be suspicious. It is possible the mail is valid, although the failure creates a si

[dmarc-ietf] is DMARC informational?

Is my google fu completely failing me, or is RFC 7489 not the DMARC protocol spec? If it's informational, how did that happen? Mike ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] is DMARC informational?

On 12/4/20 2:27 PM, Brandon Long wrote: The DMARC spec was originally designed by folks outside of IETF, and the current RFC was a "cleaned up" and modified into RFC format version of that spec, to match current practice. There was also concern with the spec's impact on various indirect email

Re: [dmarc-ietf] is DMARC informational?

On 12/4/20 2:42 PM, Dave Crocker wrote: On 12/4/2020 2:38 PM, Michael Thomas wrote: That seems really strange because that pretty much describes DKIM as well, and it's very standards track. And adsp which dmarc made historic was standards track, and certainly had all of the same issues

Re: [dmarc-ietf] is DMARC informational?

On 12/4/20 2:48 PM, Dave Crocker wrote: On 12/4/2020 2:45 PM, Michael Thomas wrote: yes, but the new version was standards track. that's what i'm finding surprising. Perhaps you should review the intended status for the current working group documents, such as dmarcbi

Re: [dmarc-ietf] is DMARC informational?

On 12/4/20 2:59 PM, Dave Crocker wrote: On 12/4/2020 2:51 PM, Michael Thomas wrote: https://datatracker.ietf.org/wg/dmarc/documents/ What changed in the bis version to change its intended status? There is a 'History' button to click on that page, to answer that question.

Re: [dmarc-ietf] is DMARC informational?

On 12/4/20 3:04 PM, Dave Crocker wrote: On 12/4/2020 3:01 PM, Michael Thomas wrote: is responsive to my question in what way? You think "the working group created a new document" is not responsive? No. Mike ___ dmarc mailing

Re: [dmarc-ietf] is DMARC informational?

lt;https://datatracker.ietf.org/meeting/108/materials/slides-108-dmarc-chairs-slides-00> On Fri, Dec 4, 2020 at 3:01 PM Michael Thomas <mailto:m...@mtcc.com>> wrote: On 12/4/20 2:59 PM, Dave Crocker wrote: On 12/4/2020 2:51 PM, Michael Thomas wrote: https://datatracker.ietf.or

Re: [dmarc-ietf] is DMARC informational?

On 12/4/20 3:25 PM, Dave Crocker wrote: On 12/4/2020 3:11 PM, Michael Thomas wrote: Is it really that hard to summarize why the decision was made and what changed in the bis version? I really don't understand this snipe hunt. You ask a series of basic question and get a string of resp

Re: [dmarc-ietf] is DMARC informational?

On 12/4/20 3:30 PM, Dave Crocker wrote: On 12/4/2020 3:27 PM, Michael Thomas wrote: A bunch of non-responsive responses. If you didn't feel like answering the question asked you could have just kept scrolling. I didn't ask for pointers, after all. The pointers are answers.  If

Re: [dmarc-ietf] ARC questions

ikely to be adopted either). So that can't possibly be heavier than adding two new signatures on top of that, since mailing lists would still have to apply the resigned DKIM signature. Mike Brandon On Wed, Dec 2, 2020 at 6:58 PM Michael Thomas <mailto:m...@mtcc.com>> wrote:

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

On 12/5/20 10:29 AM, John Levine wrote: In article you write: mailing list to mailing list mail is very common in GSuite, but maybe we're a special case. I dunno how special that case is, but there are lots of cases where mail passes through multiple layers of ARC signing mutations. I rout

[dmarc-ietf] ARC vs reject

As I understand ARC, it is means of transporting the original auth-res to the destination in case the origin signature is broken by an intermediary. From there the destination can decide one way or the other to override the DMARC policy of, say, reject. There are, however, use cases where th

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

On 12/5/20 12:56 PM, John Levine wrote: 2) Last week someone was complaining about the expense of the signatures in ARC seals, now multiple signatures don't hurt anything. While I agree with the latter sentiment, what changed? It means that you can't control somebody else's infrastructure. We

Re: [dmarc-ietf] ARC vs reject

On 12/5/20 1:03 PM, John Levine wrote: There are, however, use cases where that is exactly wrong and in no case does the originating domain want such an override to happen. Consider my bank sending me transactional email. If somehow somebody managed to get that mail through a mailing list and

Re: [dmarc-ietf] ARC vs reject

On 12/5/20 2:02 PM, John Levine wrote: In article you write: our job to try to guess whether the bank's users are following some internal policy we can't see. There is no guarantee of that. If my bank says reject that mail, I want my provider to reject that mail, period. No amount of ARC she

Re: [dmarc-ietf] ARC vs reject

On 12/5/20 3:10 PM, John Levine wrote: In article you write: If ARC is advocating for a bypass of p=reject that introduces a new state. If my policy is reject, I want you to reject the mail. If I want you to reject the mail unless you think it has come from an acceptable place with receipts, t

Re: [dmarc-ietf] ARC vs reject

On 12/5/20 3:24 PM, Dave Crocker wrote: On 12/5/2020 3:15 PM, Michael Thomas wrote: Can you keep your contempt for me off this list? This is not even responsive to what I wrote, and is nothing more than an ad hominem. Wow. It wasn't an ad hominem. "You can say, no I am smarter

Re: [dmarc-ietf] ARC vs reject

Tim On Sat, Dec 5, 2020 at 6:16 PM Michael Thomas <mailto:m...@mtcc.com>> wrote: On 12/5/20 3:10 PM, John Levine wrote: > In article mailto:dd59f2f3-b17e-6c2b-f756-7dcad2702...@mtcc.com>> you write: >> If ARC is advocating for a bypass of p=reject that in

Re: [dmarc-ietf] ARC vs reject

On 12/5/20 4:21 PM, Dave Crocker wrote: On 12/5/2020 3:37 PM, Michael Thomas wrote: "You can say, no I am smarter than those guys and I REALLY REALLY mean it, but see 2) above." This is really not about questioning my intelligence. eye roll. If I said the same thing to you

Re: [dmarc-ietf] ARC vs reject

quip that the MLM can insert a sed script in a header to unmangle the message since it knows what transforms it has done, unlike the receiving MTA trying to guess the common transformations. Mike On Sat, Dec 5, 2020 at 7:42 PM Michael Thomas <mailto:m...@mtcc.com>> wrote:

Re: [dmarc-ietf] ARC vs reject

On 12/5/20 5:47 PM, John Levine wrote: In article you write: The domain owner might want all sorts of unreasonable things. Having a way to let the domain owner publish demands that are widely ignored indicates a seriously flawed semantic model. And that is, indeed, the current reality for DMA

Re: [dmarc-ietf] ARC vs reject

On 12/5/20 6:22 PM, John R Levine wrote: The question I have is: Should DMARC have a policy (or policy modifier) that says, “Do not accept modifications to this message?” In other words, that the originator values the integrity of their messages over deliverability. Of course not.  That's ju

Re: [dmarc-ietf] ARC vs reject

On 12/5/20 6:22 PM, John R Levine wrote: A lot of this boils down to what if some entity sends signed valid DMARC aligned mail but somehow doesn't mean it, e.g., an internal policy says no mailing lists but their users participate in lists anyway.  If they can't control their own mail syste

Re: [dmarc-ietf] ARC vs reject

On 12/5/20 8:14 PM, John R Levine wrote: On Sat, 5 Dec 2020, Jim Fenton wrote: Of course not.  That's just the tiny gorillas stamping their teensy feet. Why would anyone expect that the people publishing that flag actually understood what it meant?  Many will just turn it on because someone s

Re: [dmarc-ietf] is DMARC informational?

On 12/6/20 4:42 AM, Alessandro Vesely wrote: On Sun 06/Dec/2020 04:33:13 +0100 Jim Fenton wrote: On 4 Dec 2020, at 15:00, Kurt Andersen (b) wrote: The entire point of this working group (and the bis version that is in progress) is to move DMARC into the fully-recognized "standards" track. No

Re: [dmarc-ietf] ARC vs reject

On 12/6/20 5:40 AM, Alessandro Vesely wrote: On Sun 06/Dec/2020 02:34:45 +0100 Michael Thomas wrote: 5) The work you and Alessandro have done with reverse transformation is more likely to produce a solution for the mailing lists.   The lists will continue to do From rewrite, but reverse

Re: [dmarc-ietf] is DMARC informational?

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

Re: [dmarc-ietf] is DMARC informational?

On 12/6/20 7:13 AM, Dotzero wrote: On Sun, Dec 6, 2020 at 8:58 AM Murray S. Kucherawy mailto:superu...@gmail.com>> wrote: On Sun, Dec 6, 2020 at 5:09 AM Alessandro Vesely mailto:ves...@tana.it>> wrote: On chartering the WG in 2013, the decision was made to publish DMARC

Re: [dmarc-ietf] is DMARC informational?

On 12/6/20 7:23 AM, Dave Crocker wrote: On 12/6/2020 7:13 AM, Dotzero wrote: The group advancing DMARC was looking to preserve the installed base for a defined period of time Work that comes to the IETF often has a significant history before that, often including a well-developed specificati

Re: [dmarc-ietf] ARC vs reject

On 12/5/20 7:56 PM, Jim Fenton wrote: FWIW, I don’t think a lot of the people publishing p=reject understood the implications of that, either. This is not significantly more arcane. The audience for what I am bringing up are exactly the clueful set who are paranoid about any modifications a

Re: [dmarc-ietf] ARC vs reject

On 12/6/20 10:31 AM, Alessandro Vesely wrote: On Sun 06/Dec/2020 18:01:04 +0100 Michael Thomas wrote: This actually highlights why my observation is correct. If the intermediary showed how to reverse their changes perfectly to be able to validate the original signature, it says nothing

Re: [dmarc-ietf] ARC vs reject

On 12/6/20 10:45 AM, Douglas Foster wrote: The recent discussion has introduced two challenges to ARC:  first, that it is too complicated, and second, that it opens up security holes that should be unacceptable.    John's response appears to be that the technology will only be used by a small

[dmarc-ietf] draft dkim-transforms

I scanned through Murray's draft and wonder if it's been implemented? Or whether we could in some way simulate what percentage of traffic it would work for? It mostly mirrors a lot of the things I did way back when, but it does go farther with some of the MIME stuff. The advantage I had with

Re: [dmarc-ietf] ARC vs reject

On 12/5/20 6:04 PM, Jim Fenton wrote: I’d like to step back from the specific use case of “a bank”. If a domain publishes p=reject, they’re requesting particular handling of a message they originate. ARC modifies that, which is good for mailing lists and similar intermediaries, but depends o

Re: [dmarc-ietf] ARC vs reject

On 12/6/20 9:05 PM, Murray S. Kucherawy wrote: On Sun, Dec 6, 2020 at 11:02 AM Michael Thomas <mailto:m...@mtcc.com>> wrote: Based on the work I did at Cisco 15 years ago which essentially was a heuristic based form of those two drafts, I found that it worked for abou

Re: [dmarc-ietf] not ADSP, was is DMARC informational?

On 12/6/20 9:18 PM, John Levine wrote: In article you write: As I recall, people took a run at trying ADSP and it was largely unsuccessful. I recall at least Yahoo, PayPal, and Google trying it but finding that it interfered with their employees' participation in lists, so they each invent

Re: [dmarc-ietf] ARC vs reject

On 12/6/20 9:30 PM, Murray S. Kucherawy wrote: On Sun, Dec 6, 2020 at 9:24 PM Michael Thomas <mailto:m...@mtcc.com>> wrote: An idea that i've been rolling around in my head is that the MLM could give a sed-like script to rollback the changes. since they know their

Re: [dmarc-ietf] ARC vs reject

On 12/7/20 1:35 AM, Alessandro Vesely wrote: On Sun 06/Dec/2020 19:47:24 +0100 Michael Thomas wrote: It seems a lot simpler for the originating domain to just be explicit about how they feel about transformations by intermediaries. It's not like another short ascii string is going to

Re: [dmarc-ietf] ARC vs reject

On 12/6/20 9:30 PM, Murray S. Kucherawy wrote: On Sun, Dec 6, 2020 at 9:24 PM Michael Thomas <mailto:m...@mtcc.com>> wrote: An idea that i've been rolling around in my head is that the MLM could give a sed-like script to rollback the changes. since they know their

Re: [dmarc-ietf] ARC vs reject

On 12/7/20 10:32 AM, Murray S. Kucherawy wrote: On Mon, Dec 7, 2020 at 4:05 AM Dotzero > wrote: I've asked here and in other places that validators/receivers consuming ARC headers provide data regarding the results of such consumption. To date we have not s

Re: [dmarc-ietf] ARC vs reject

On 12/7/20 10:33 AM, Murray S. Kucherawy wrote: On Mon, Dec 7, 2020 at 8:59 AM Michael Thomas <mailto:m...@mtcc.com>> wrote: Btw, what is PSD? A working group document: https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ <https://datatracker.ietf.org/doc/draft-ietf-dmarc

Re: [dmarc-ietf] ARC vs reject

On 12/7/20 11:19 AM, John Levine wrote: In article you write: Compared with the use of "l=" tag (Section 8.2 of [RFC6376]), the fact that footers are written in plain text ... They are? Some are, some are added as MIME parts. We really need to keep in mind that there is a lot of li

Re: [dmarc-ietf] ARC vs reject

On 12/7/20 1:00 PM, Tim Wicinski wrote: On Mon, Dec 7, 2020 at 2:26 PM Michael Thomas <mailto:m...@mtcc.com>> wrote: This is why we need actual numbers instead of anecdotes about the long tail. We know that there is no silver bullet. Mailing lists who are config

Re: [dmarc-ietf] not ADSP, was is DMARC informational?

On 12/7/20 4:44 PM, Dave Warren wrote: On Sun, Dec 6, 2020, at 22:31, Michael Thomas wrote: there are clearly many use cases where that isn't a problem -- like bank transactional mail -- and ADSP was just fine for that. There were still surprises to be had here. I still, to this day,

Re: [dmarc-ietf] not ADSP, was is DMARC informational?

On 12/7/20 5:15 PM, Tim Wicinski wrote: A good section of our charter is collection Operational experiences. Doing an Operational BCP on DMARC based on data collected is what the WG should do after DMARC-bis. I guess I don't understand why this should be serialized. When I read over DMARC

[dmarc-ietf] p=quarantine

If you take the literal meaning of quarantine, that means that every piece of email from this and every other mailing list would end up in a quarantine folder, or some such. I'm fairly certain that is not what people want, and I'm doubtful that many receivers implement that. The question to

Re: [dmarc-ietf] A-R results for DMARC

On 12/8/20 4:51 PM, Brandon Long wrote: On Mon, Dec 7, 2020 at 8:31 PM John R Levine > wrote: On Mon, 7 Dec 2020, Murray S. Kucherawy wrote: > The original intent back in RFC 5451 was to relay only those details that > an MUA might care about, such as

[dmarc-ietf] are mailing lists worth saving?

I know it's heresy on an ietf list to suggest it, but we know that amount of traffic going through mailing lists is tiny -- like a couple percent. The amount of traffic going through other forms of manglers has to be even farther down in the long tail of traffic. Mailing lists arose because t

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

On 12/9/20 4:04 PM, Brandon Long wrote: When you switch to p=quarantine pct=0, no one should apply quarantine (so it's equivalent to p=none), but Groups will start rewriting, thereby removing all of those failures from your reports.  Yes, you won't see those messages in the reports at all a

Re: [dmarc-ietf] are mailing lists worth saving?

On 12/10/20 2:58 PM, Dave Crocker wrote: On 12/9/2020 3:05 PM, Michael Thomas wrote: we know that amount of traffic going through mailing lists is tiny -- like a couple percent. Keeping in mind that mailing lists have been a legitimate Arpanet/Internet email activity since the start of

Re: [dmarc-ietf] are mailing lists worth saving?

On 12/10/20 3:23 PM, Dave Crocker wrote: On 12/10/2020 3:17 PM, John Levine wrote: People at very large mail systems tell me that while the amount of traffic from discussion lists is a tiny part of the overall mail flow, it is mail that their recipients really want and complain if they don't g

Re: [dmarc-ietf] are mailing lists worth saving?

On 12/10/20 3:25 PM, Dave Crocker wrote: On 12/10/2020 3:23 PM, Michael Thomas wrote: So no, I won't be doing any of those things because they are completely beside the point. Feel free trying your hand solving it. Yet you were the one making the proposal and making claims as foundat

Re: [dmarc-ietf] are mailing lists worth saving?

On 12/10/20 3:45 PM, Dave Crocker wrote: On 12/10/2020 3:34 PM, Michael Thomas wrote: I'm just making the observation "Basically just declare" is not a linguistic form for 'just making an observation'.  It's a proposal. A proposal that we face reality? I

Re: [dmarc-ietf] are mailing lists worth saving?

ave Crocker <mailto:dcroc...@gmail.com>> wrote: On 12/10/2020 3:34 PM, Michael Thomas wrote: > I'm just making the observation "Basically just declare" is not a linguistic form for 'just making an observation'.  It's a proposal. d/ --

Re: [dmarc-ietf] p=quarantine

On 12/10/20 6:01 PM, Kurt Andersen (b) wrote: On Thu, Dec 10, 2020 at 5:03 PM Dave Crocker > wrote: On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote: to quibble with the "*unauthorized use*"  situation. This situation devolves into use-as-imagined vs. use-a

Re: [dmarc-ietf] p=quarantine

On 12/10/20 6:28 PM, Dave Crocker wrote: On 12/10/2020 6:25 PM, Michael Thomas wrote: I think this all should be driven by "what are you asking me to do?" The domain owner has no business asking the receiver to do anything.  The receiver has no relationship with the domain owner.

Re: [dmarc-ietf] p=quarantine

On 12/10/20 6:44 PM, Dave Crocker wrote: On 12/10/2020 6:32 PM, Michael Thomas wrote: Semantic nit picking at best. Because semantics do not matter in a specification? It's ok, I guess but I wouldn't want to make a career of nit picking. It's a lot more useful to get i

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

On 12/11/20 9:49 AM, Murray S. Kucherawy wrote: I concur.  The fee for virtual meetings is less than half that of the usual in-person meetings since the IETF's costs are obviously lower, but we do need to keep the lights on. For people that can't afford to participate otherwise, there is a

Re: [dmarc-ietf] p=quarantine

On 12/12/20 10:42 AM, Dave Crocker wrote: As soon as this specification text, here, contains language about how this information is to be used, should be used, or could be used, it crosses over into creating confusion about expectations of receiver handling. As a developer for 40 years,

Re: [dmarc-ietf] p=quarantine

On 12/14/20 8:12 AM, Dave Crocker wrote: On 12/12/2020 10:57 AM, Michael Thomas wrote: As a developer for 40 years, I can safely say that reject or discardable or whatever it was in ssp are all abundantly clear and that nobody writing a filter would make the error that you keep insisting

Re: [dmarc-ietf] p=quarantine

On 12/14/20 10:09 AM, Dave Crocker wrote: On 12/14/2020 10:00 AM, Michael Thomas wrote: When we tell you it's not a problem, Except that the telling was by you.  Alone. And you've yet to respond to the observable fact that receivers have been ignoring the directive language. Or

Re: [dmarc-ietf] p=quarantine

On 12/14/20 12:02 PM, Tim Wicinski wrote: All Can we please stop with the non constructive discussions here? It would be helpful to just rule anything about the semantics of p=reject as out of scope. It is what hijacked my original question for which I haven't gotten an answer. Mike ___

Re: [dmarc-ietf] p=quarantine

On 12/14/20 7:26 PM, Douglas Foster wrote: But what I am trying to figure out is under what circumstances a DMARC policy can be considered actionable.  Do I conclude that "p=quarantine" means "domain is still collecting data, so results are unpredictable"?   Or do I conclude that it means "D

Re: [dmarc-ietf] p=quarantine

On 12/15/20 8:01 AM, Todd Herr wrote: I'm not sure there's anything actionable about DMARC's policy values. you mean p=quarantine, or p=* in general? Obviously indirect mail flows, such as mailing lists and forwarding, complicate matters greatly here, as the handling by the intermediary h

  1   2   3   >