Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

er larger esp domain accounts with restrictive mail policies who switched to restrictive policies. They understood the dilemma and used other domains - problem solved. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos _

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

y support IFF the originating domain allows it. There would other things to consider to tie the loose ends, but the #1, would be the rewrite=1 tag. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos On 6/18/2020 3:46 AM, Alessandro Vesely wrote: On Wed 17/Jun/20

Re: [dmarc-ietf] DMARC Policy Boundary Conditions - making DMARC protocol complete.

solutions to review. Thanks -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC Policy Boundary Conditions - making DMARC protocol complete.

ovide good protocol-complete solutions and kludges won't be necessary. Thanks -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos On 6/15/2020 1:15 PM, Brandon Long wrote: I don't understand what adding authorized third party signatures will add. For a corporati

[dmarc-ietf] DMARC Policy Boundary Conditions - making DMARC protocol complete.

ain) Lets finish that part of the DKIM model. Thanks [1] https://tools.ietf.orgy/html/rfc5617 [2] https://tools.ietf.org/html/rfc6541 -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

protocol citing technical quality issues, yet helped a special interest group reintroduce "Super ADSP" under a different name with the same exact technical quality issues and fast tracked it as an informational RFC proposal. -- Hector Santos, https://secure.santronics.com https://t

Re: [dmarc-ietf] Seeking volunteers to edit DMARCbis

-Base proposed standard DMARC-Reporting proposed standard DMARC-TPA (Third Party Authorization) Experimental Get it done. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https

Re: [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

for "bad guy" do the same thing. Honor the policy. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

On 6/13/2020 1:19 AM, Hector Santos wrote: A DKIM Policy compliant list server simply needs to do two things: 1) Prohibit new subscribers using addresses with restrictive domains, just like it is done here: https://secure.winserver.com/public/code/html-subscribe?list=winserver 2) Prohibit

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

an acceptable way to rewrite From:. This is no acceptable way to tamper the mail in this way. But I did suggest with following. For an example of what it did to my headers: X-Original-From: Hector Santos From: Hector Santos In order to close the loophole the rewriting has opened, in addition

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On 6/5/2020 1:39 AM, Dotzero wrote: The goal of DMARC was (and is) to mitigate direct domain abuse. +1, it was the goal of: [1] The original proof of concept with DomainKeys' built-in o= policy tag for 1st party support, and [2] The original DKIM draft augmented with the original SSP

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D

On 6/5/2020 6:34 AM, Alessandro Vesely wrote: 4) Require all recipient systems to make special policy accommodations to grant trust to messages from List B, simply because it comes from List B. This is feasible, but specific to each participants incoming email filter. This is a hindrance

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D

elieve that is what the DKIM Service Overview attempt to depict, by combining two assessment inputs - signing practice/policy and trust info. DomainKeys Identified Mail (DKIM) Service Overview https://tools.ietf.org/html/rfc5585#page-14 -- Hector Santos, https://secure.santronics.com https://

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D

On 6/2/2020 8:45 PM, Douglas E. Foster wrote: Someone said that the Sender Address is all we can trust. Nonsense. +1 As to identifiers: The RFC 5321 MAILFROM sender is intended, at least in my understanding, to represent the login account used to create the message, while the RFC 5322 From

[dmarc-ietf] Requirements for a DKIM Signing Practices Protocol

I have to ask these engineering questions because we spent a lot of time developing this functional specifications. How much does DMARC follow the DKIM Signing Policy functional specs? Requirements for a DKIM Signing Practices Protocol https://tools.ietf.org/html/rfc5016 In addition, is DMARC

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

On 5/20/2020 2:43 PM, Alessandro Vesely wrote: Transaction? I thought we were talking about aggregate reports. So am I. There are no transactions there. Really? Each SMTP session can be considered a transaction. You are provided results on the these DMARC processed transaction. I

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

On 5/20/2020 12:26 PM, Alessandro Vesely wrote: I agree we should consider ways to increase the report generators base, but requiring support for multiple formats goes in exactly the opposite direction. Although automatic converters exist, having to provide multiple formats can be a

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

Thanks Scoot, I hope all is safe for you and family. argg sorry about that, Scott. -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

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

On 5/20/2020 11:49 AM, Dave Crocker wrote: On 5/20/2020 8:29 AM, Kurt Andersen (b) wrote: Agree 100% This looks like it has a strong constituency against the proposal, a much smaller constituency in favor of it, and little or no offered benefit. Yes? Just like DKIM Policy had a "strong

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

On 5/20/2020 10:01 AM, Scott Kitterman wrote: So, from a product design standpoint, for immediate consumer "pay off," at the very least, csv should be the default option, not XML. You're several years too late on deciding a default. DMARC is informational, not a proposed standard. My

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

On 5/19/2020 8:46 PM, Scott Kitterman wrote: Please don't. This is a large stack of protocol and implementation complexity for little or no gain. Rhetorically, I feel the same about reporting. What is gained from it? But that is just my opinion since the proposed ideas for reporting

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

On 5/18/2020 8:25 PM, Seth Blank wrote: On Mon, May 18, 2020 at 1:31 PM John Levine mailto:jo...@taugh.com>> wrote: There are vast numbers of sites producing and consuming XML reports. They interoperate. It works. There is no problem to be solved here. Can we stop now and work on

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

On 5/16/2020 2:41 AM, Dave Crocker wrote: On 5/15/2020 9:54 PM, Hector Santos wrote: Protocols should be flexible. Adding it doesn't mean replace. Explain the need. Convince plenty of folk that it is necessary enough that they are inclined to write the code, deploy it, and use it. Adding

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

On 5/16/2020 11:49 AM, Pete Resnick wrote: On 15 May 2020, at 23:54, Hector Santos wrote: On 5/15/2020 2:26 PM, Seth Blank wrote: Should we consider adding JSON formatting to DMARC? Protocols should be flexible. Adding it doesn't mean replace. Flexible sometimes means less interoperable

Re: [dmarc-ietf] DMARC bis: ticket 63: make p=none with no reporting URI invalid?

On 5/15/2020 2:26 PM, Seth Blank wrote: https://trac.ietf.org/trac/dmarc/ticket/63 A published DMARC record that consists solely of "v=DMARC1; p=none" is syntactically valid, but is semantically equivalent to having no record at all. From an ecosystem perspective, especially in Europe, data

Re: [Ietf-dkim] Adding an aim= tag to DKIM Signature Tag Specifications

We need to update DMARC or any other DKIM Policy proposal to seriously consider 3rd party signature Authorization methods. We have wasted so much time avoiding it. Sure, it may not apply to all, but neither does DMARC and the push to embed a "half-baked" DMARC into our mail network has

Re: [dmarc-ietf] Upcoming personnel changes

Congratulations. The IETF will be enhanced with your new assignments and roles. How will this affect the future and editorship of DMARCbis? I wonder if there could be a "conflict of interest" concerns. Thanks -- HLS On 2/7/2020 1:22 PM, Murray S. Kucherawy wrote: Colleagues, We have

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

From a software engineering standpoint, we have an "Lookup" black box mechanism. It should be left open-ended so the DMARC-bis can move it. The default mechanism is the existing DMARC one. Consider PSD a Lookup extension to DMARCbis.DMARCbis can describe "Lookup Extensions." Remember, we

Re: [Ietf-dkim] Thinking About DKIM and Surveillance

Thanks jon for loading my plate! :) I plan to finish reading the paper later today. Need to recall past discussions and how the paper relates. But with initial reading, it made me recall the proposal I wrote in 2006: https://tools.ietf.org/html/draft-santos-dkim-rcvd-00 related to

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

We need to use the QUERY for the DMARC record to get compliant clients to try (explore) different things. Let the record tell the client what to do. We need an expanded language for the possible tags. SPF was very flexible. DMARC is not because it removed 3rd party capabilities. It is too

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

On 7/31/2019 11:32 PM, Murray S. Kucherawy wrote: On Sun, Jul 28, 2019 at 6:37 AM Tim Wicinski mailto:tjw.i...@gmail.com>> wrote: From our end user point of view, I'm against abolishing quarantine, even with its current shortcomings. Why's that? -MSK, also hatless My opinion.

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

On 6/15/2019 6:13 PM, Steve Atkins wrote: On Jun 15, 2019, at 9:25 PM, wrote: Hello, p=reject; pct=0 is equivalent to p=quarantine; pct=0. I've not been following this thread too closely so I might be missing something, but under current DMARC spec I don't think that's so - see section

Re: [dmarc-ietf] nit - data integrity

On 6/14/2019 9:34 PM, dmarcietf=40tomki@dmarc.ietf.org wrote: The suggestion: provide guidelines on data integrity, which data providers should follow. Examples: - raw SPF 'fail' should never result in DMARC-SPF 'pass' - raw SPF 'pass' out of alignment with header_from should never result

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

On 6/14/2019 5:58 PM, Дилян Палаузов wrote: Hello Ken, effectively I proposed handling p=reject and p=quarantine the same way. .. Lets have an example for p=quaranite: majordomo@domain is an address where commands are sent and the software receiving the command always sends an answer, even

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

On 6/12/2019 9:37 AM, Laura Atkins wrote: On 12 Jun 2019, at 14:28, Hector Santos (o) Reject with 55x before DATA state Given that the 5322.from is crucial for DMARC, and the 5322.from is transmitted after DATA, how can you evaluate DMARC before DATA? When SPF is taking into account

Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication

On 6/11/2019 1:01 PM, Дилян Палаузов wrote: Hello Alessandro, I'd propose bullets like the following for Section 12.4: o The authentication status of the message should be visible. For DMARC policy reject, the failed status will not be visible in the MUA, because the mail will not

Re: [dmarc-ietf] DMARC PSD and non-existent subdomains

On 6/11/2019 11:38 AM, Alessandro Vesely wrote: On Tue 11/Jun/2019 00:41:16 +0200 Scott Kitterman wrote: On Monday, June 10, 2019 8:07:25 AM EDT Richard C wrote: Presumably other PSDs that aren’t brand new will have this problem too? I’m interested to hear whether we’re on our own or not.

Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication

On 6/10/2019 4:17 AM, Alessandro Vesely wrote: On Sat 08/Jun/2019 18:49:03 +0200 Dave Crocker wrote: Except that most users don't actually see that address because these days most MUAs only display the display address. We often came across this realization. Since DMARC hinges on that

Re: [dmarc-ietf] Endless Loops with DKIM reports

On 6/4/2019 10:29 AM, Vladimir Dubrovin wrote: Recommendation to use empty envelope-from / return-path is doubtful, because this recommendation is usually applied to mail transport-level application and DMARC reporting does not belong to transport level. In practice, this recommendation will

Re: [dmarc-ietf] Endless Email Loops with Aggregate Reports

On 6/1/2019 11:38 AM, Murray S. Kucherawy wrote: My understanding matched Dave's originally, but then I found this: https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/ It's not surprising this sort of need to record a deficiency for later handling has come up before, and we've

Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion

atic for DMARC). Mailing lists are not the only case, and, as John has pointed out, reformatting and part stripping are things that happen in mail flows. Elizabeth On May 31, 2019, at 8:02 AM, Hector Santos wrote: On 5/31/2019 6:59 AM, Douglas E. Foster wrote: DKIM was supposed to provide

Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion

On 5/31/2019 6:59 AM, Douglas E. Foster wrote: DKIM was supposed to provide sender authentication when SPF was invalidated by forwarding, so DMARC said that the two techniques should be evaluated together. Unfortunately, DMARC did not have a policy that offered that output. SPF >> FAIL

Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion

ww.winserver.com/public/wcdmarc So there you go. Short history as I lived it. I've been involved with this whole thing since day one. I am firm believer in the DKIM POLICY model. The concept is too strong and "it's scary" as one prominent person here once put it, and I thi

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

On 5/29/2019 1:13 PM, John R Levine wrote: You seem to be suggesting that the standards-track DMARCbis should be different because an informational, non-WG RFC has already been published. From a process standpoint that's bad; standards-track RFCs should go through exactly the same process

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

On 5/23/2019 4:35 PM, Jim Fenton wrote: In response to Seth Blank's call for issues of 9 May 2019: DMARC contains what are really two distinct mechanisms, a reporting mechanism and a policy mechanism. The policy mechanism is largely a request to the verifier about what to do in the event that a

[dmarc-ietf] DKIM

Can anyone provide me some C/C++ or pseudo-code to do DKIM ecdhc encryption?... Using OpenSSL API in v1.1 format? Thanks PS: Not sure where to post this, but it equally applies to OpenSSL at GitHub. -- HLS ___ dmarc mailing list dmarc@ietf.org

Re: [dmarc-ietf] DMARC Coverage

On 4/14/2019 9:38 AM, Dotzero wrote: Scott, it's almost certainly an undercount as there are domains which validate for DMARC but do not send reports. +1, without a doubt. -- HLS ___ dmarc mailing list dmarc@ietf.org

Re: [dmarc-ietf] Working group next steps

Big time +1. Focus on DMARC PSD! I agree with everything mentioned and hope to allocate time very soon to assist. Thanks Murray, Great news!! On 3/26/2019 12:57 PM, Murray S. Kucherawy wrote: DMARC colleagues, Tim and I met in Prague to get things rolling in terms of getting us progressing

Re: [dmarc-ietf] p=reject

On 3/18/2019 3:48 PM, Michael Davis wrote: If a sender's IP is in SPF, so SPF passes; and the applied DKIM signature is successfully decrypted, so DKIM passes; what good is checking alignment and rejecting a message? I have had Adobe and Cloudflare automated system emails rejected based on those

Re: [dmarc-ietf] Should we encourage the use of SPF "soft include" for common platforms?

On 2/23/2019 2:56 PM, Kurt Andersen (b) wrote: On Sat, Feb 23, 2019 at 11:00 AM Hector Santos wrote: Unless the conditions were limited to when this can be applied, I can see where this can become really complex because of higher recursion potentials. You also have compatibility concerns

Re: [dmarc-ietf] Should we encourage the use of SPF "soft include" for common platforms?

On 2/23/2019 1:07 PM, Kurt Andersen (b) wrote: With the growth of huge platforms that emit mail from the same common set of IPs (such as GSuite, O365, or large ESPs), regular SPF "include" ends up granting a DMARC pass to a lot more potential authors than most organizations would necessarily

Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work

+1 On 12/10/2018 10:50 AM, Kurt Andersen wrote: Now that the charter update has gone through the necessary processing, I'd like to ask the WG to adopt John Levine's https://tools.ietf.org/html/draft-levine-appsarea-eaiauth-05 document as an official WG item. This doc is a normative reference

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

tails codified and worked out. Have a good weekend, Hector Santos/CTO Santronics Software, Inc. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

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

On 10/25/2018 1:42 PM, Kurt Andersen wrote: I'd like to recommend that we (DMARC-WG) accept https://tools.ietf.org/html/draft-kitterman-dmarc-psd-00 into our work queue. It aligns with our charter already. --Kurt Andersen +1 I would also suggest to use the document proposal (and

Re: [dmarc-ietf] AD review of draft-ietf-dmarc-arc-protocol-18

On 10/25/2018 7:51 AM, Alexey Melnikov wrote: 2) I am glad that broken examples from Appendix B were removed, but I would like to have some examples in the document. Is somebody working on generating these? +1. Especially examples of DMARC. -- HLS

Re: [Ietf-dkim] DKIM-Signature: r=y and MLM

On 10/24/2018 4:53 PM, Дилян Палаузов wrote: PS: Please describe the handling, of the above message by the MLM, if the original message contained in addition DKIM-Signature: v=1; d=isdg.net; r=y; … ... or something different than r=y, that permits finding faulty DKIM implementations. Our

Re: [Ietf-dkim] [dmarc-ietf] DKIM-Signature: r=y and MLM

On 10/24/2018 5:18 PM, Kurt Andersen wrote: On Mon, Oct 15, 2018 at 7:30 AM Hector Santos What it should do is: 1) It should use a 1st party signature using d=dmarc.ietf.org to match the new author domain dmarc.ietf.org 2) It should has hash bind the X

Re: [dmarc-ietf] [Ietf-dkim] DKIM-Signature: r=y and MLM

On 10/24/2018 5:18 PM, Kurt Andersen wrote: On Mon, Oct 15, 2018 at 7:30 AM Hector Santos What it should do is: 1) It should use a 1st party signature using d=dmarc.ietf.org to match the new author domain dmarc.ietf.org 2) It should has hash bind the X

Re: [dmarc-ietf] ARC Crypto Algorithm Selection

In my view, ARC, as an "Experimental Status" (and still in design) proposal *should* include support for all valid DKIM STD hashing methods, including rsa-hash1, and I agree, should not be the impetus for removing sha1 support in DKIM implementations. Until a DKIM implementation is "ready" to

Re: [Ietf-dkim] DKIM-Signature: r=y and MLM

e: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1537415189; bh=TJWGUVdPL8OTY+HJnUzpBRd52OaKfWjFqS68Cby0s/M=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From; b=..... X-Original-From: Hector

Re: [dmarc-ietf] List Server Rewrite From Logic

This worked. I had to add the "Reply-Id" address in Thunderbird to better support direct mail (Reply to Sender), otherwise it used the rewritten from address. Thanks On 9/19/2018 11:20 PM, Hector Santos wrote: I found this February 2018 IETF-DISCUSS post describing its rew

Re: [dmarc-ietf] List Server Rewrite From Logic

, Hector Santos wrote: It is my understanding the IETF has begun to do a "rewrite" of the list poster/message RFC8322.From address of restricted DMARC domains to help resolve the IETF list subscribers distribution reject problem. If so, is there some written protocol, method or outli

[dmarc-ietf] List Server Rewrite From Logic

It is my understanding the IETF has begun to do a "rewrite" of the list poster/message RFC8322.From address of restricted DMARC domains to help resolve the IETF list subscribers distribution reject problem. If so, is there some written protocol, method or outline of what is actually being

Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily

this complex protocol first before justifying the massive overhead and experimentation cost being asked of SMTP/Email developers. Thanks Hector Santos, CTO Santronics Software, Inc. On 8/20/2018 6:28 AM, Murray S. Kucherawy wrote: (back from vacation and catching up) On Tue, Aug 14, 2018 at 8:58 PM

Re: [dmarc-ietf] ARC protocol-15 posted

On 6/29/2018 11:13 AM, John Levine wrote: In article you write: Anything that comes close to 'do whatever you want with this information' demonstrates NON-standardization. Not at all. The point of a standard is to say here is what you do if you want to interoperate. Trying to figure out

[Ietf-dkim] Test Msg to ietf-dk...@ietf.org

Ignore -- HLS ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [dmarc-ietf] "next steps?"

On 3/14/2018 5:37 PM, Brandon Long wrote: On Tue, Mar 13, 2018 at 3:44 PM Hector Santos <hsan...@isdg.net If a domain publishes a "p=reject/quarantine" (restrictive policy), the published intent and expectation is to reject or quarantine failures. If the re

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

On 3/7/2018 3:21 AM, Satoru Kanno wrote: Dear DMARC WG Chairs, I'm sending to you on behalf of Genki Yasutaka-san. As I asked you last November, we are preparing for the next track, with the intention of not only reviewing this draft, but also implementing for verification of vDMARC. If

[ietf-dkim] DKIM 3rd party Authorization using DKIM-Conditional

On 2/12/2018 12:40 PM, John R. Levine wrote: Just for fun I sent in a new I-D of the dkim-conditional draft that takes out version numbers and adds feature tags in a backward compatible way. https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ +1. But just for fun? I wish you

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-11.txt

Hi, On 1/26/2018 3:23 PM, Brandon Long wrote: I sometimes override DMARC p=quarantine failures with filters, does DMARC require a filters extended tag and compliance by mail clients to not allow overriding of the filters if the domain requests it? Local Policy always prevails. But we all work

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-11.txt

Quick review note: The draft introduction talks about the "False Positive" problem with restrictive DMARC policies -- the reason why we are here. We need to keep in mind, DMARC also comes with "True Positives" DMARC failures as well. DMARC Author Domains who will either be ignorant

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dmarc-rfc7601bis-00.txt

then we can discuss. On Jan 20, 2018 09:18, "Hector Santos" <hsan...@isdg.net <mailto:hsan...@isdg.net>> wrote: IMEV, 7601 should be extendable without continuing modifying 7601 by augmented technology, i.e. ARC itself should do the

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dmarc-rfc7601bis-00.txt

On 1/19/2018 11:19 PM, Kurt Andersen wrote: On Jan 19, 2018 19:53, Hector Santos <hsan...@isdg.net> wrote: If this is done, then shouldn't the ARC proposal be standard track rather than experimental? Making 7601 more extensible does not affect the state of ARC. It

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dmarc-rfc7601bis-00.txt

On 1/19/2018 1:49 PM, Dave Crocker wrote: On 1/18/2018 11:14 PM, Murray S. Kucherawy wrote: -01 will be up soon, incorporating the suggested changes in prose and ABNF discussed previously on this list. If I missed this, I apologize, but would it be possible to post a message which summarizes

Re: [dmarc-ietf] Duplicate DMARC records and tags?

We should probably add a "v=counter" to the DMARC syntax. But the odds are good that will screwed up too in duplicate records. I think my software will read the first encounter of a DMARC text record and not seek for an "override" that could follow. Not going to waste time to verify it.

Re: [ietf-dkim] DKIM and EAI

+1. I think there are parsing issues to be highlighted. Do you decode first, then extract the Author Domain or extract first before decoding? etc. On 12/5/2017 10:27 PM, John R. Levine wrote: If I may change the topic for a moment ... I'm working on some stuff for ICANN to help people

Re: [dmarc-ietf] Proposed ARC "Experimental Considerations" section

Who's Ken? :) My apology Kurt. On 12/1/2017 8:47 AM, Hector Santos wrote: On 11/29/2017 12:17 PM, Kurt Andersen (b) wrote: While I have a number of issues with the details of the proposal, I'll tackle those in another thread. The fundamental problem that I have with the whole "exper

Re: [dmarc-ietf] Proposed ARC "Experimental Considerations" section

On 11/29/2017 12:17 PM, Kurt Andersen (b) wrote: While I have a number of issues with the details of the proposal, I'll tackle those in another thread. The fundamental problem that I have with the whole "experiment" approach is that it is something like throwing a baseball into a pool of

Re: [dmarc-ietf] Proposed ARC "Experimental Considerations" section

On 11/23/2017 12:34 AM, Seth Blank wrote: 16 Experimental Considerations [[ NOTE TO WORKING GROUP: Should this section be for the IESG only to be removed by the document editor, or should it stay with the document as long as it’s experimental? ]] It must be demonstrated that ARC actually

Re: [dmarc-ietf] dmarc - Requested session has been scheduled for IETF 100

On 11/3/2017 3:32 PM, Brandon Long wrote: If you look at RFC 7960, ARC is intended mostly for the mediators case, though it would also be for the MDA/MTA case. It does nothing for the MSA case, though there have been some proposals about having a hop=0 or just falsifying hop=1 for that. Most

Re: [dmarc-ietf] dmarc - Requested session has been scheduled for IETF 100

, 3) Incorporate ARC somehow into Policy that tells receivers what to expect, i.e. # of hops, etc. I would like to think these are all just DMARC options but it needs to be IETF sanctioned in order to get support which will finally give people a confident chancee to explore these options in ear

Re: [dmarc-ietf] Lenient SPF

On 10/12/2017 2:53 PM, Grant Taylor wrote: * There is a kludge called SRS that embeds the original bounce address in the forwarder's bounce address, but it doesn't help. Where can I find out more about how / why SRS does not help. I've been aware of SRS for quite some time and I always

Re: [DNSOP] RFC2317 Question: Resolving cname delegation

On 8/30/2017 3:53 PM, Tony Finch wrote: Hector Santos <hsan...@isdg.net> wrote: Not expecting this in my DNS resolver code, I modified the resolver to take the CNAMEs into account and return the host names instead. Was this the correct thing to do, thus providing the same results rega

Re: [DNSOP] RFC2317 Question: Resolving cname delegation

On 8/24/2017 12:06 PM, Vladimír Čunát wrote: Hello. On 08/24/2017 05:46 PM, Hector Santos wrote: [...] Not expecting this in my DNS resolver code, I modified the resolver to take the CNAMEs into account and return the host names instead. Was this the correct thing to do, thus providing

Re: [DNSOP] RFC2317 Question: Resolving cname delegation

On 8/24/2017 1:31 PM, Grant Taylor wrote: Before I release my updates, I wonder if this was the right thing to do. I prefer to use a different method to do classless in-addr.arpa delegation. Specifically, I ask ISPs to put an NS record for the IP(s) in question pointing to my own DNS server.

[DNSOP] RFC2317 Question: Resolving cname delegation

I have a question related to RFC2317 "Classless IN-ADDR.ARPA delegation." Earlier this year, I switched from a class C bank of 256 addresses to a reduced set of 32 ips (/27). To get PTR queries to work, RFC2317 was referred by my ISP to prepare the delegation. Having implemented RFC2317, I

Re: [dmarc-ietf] About "non-rewindable crypto"

On 8/20/2017 9:25 PM, Bron Gondwana wrote: It is protected by the original DKIM-Signature. Message-Id is pretty high on the recommended hashed header list. But if the original DKIM signature was lost, all bets are off and nothing else matters unless ARC is attempting to replace DKIM which you

Re: [dmarc-ietf] About "non-rewindable crypto"

On 8/20/2017 7:47 PM, Bron Gondwana wrote: On Mon, 21 Aug 2017, at 09:34, Hector Santos wrote: On 8/18/2017 8:53 PM, Bron Gondwana wrote: ... And the message still arrives at receiver with a valid ARC chain, just via badsite.com instead of site3.com. The same receiver

Re: [dmarc-ietf] About "non-rewindable crypto"

On 8/18/2017 8:53 PM, Bron Gondwana wrote: ... And the message still arrives at receiver with a valid ARC chain, just via badsite.com instead of site3.com. The same receiver? If so, wouldn't this be a duplicate message when the same receiver can see the same 5322.Message-Id? -- HLS

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

On 8/19/2017 3:48 AM, Bron Gondwana wrote: For what it's worth, the ONLY one of these which my "fake Brandon" email would have failed to validate for is p=reject, arc=none. A chain of valid ARC seals is so easy to fraudulently create that it's not funny. Everything other than arc=all there is

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

On 8/16/2017 8:21 PM, Bron Gondwana wrote: On Thu, 17 Aug 2017, at 03:46, Hector Santos wrote: On 8/13/2017 10:28 AM, Kurt Andersen (b) wrote: On Sat, Aug 12, 2017 at 4:51 PM, Hector Santos wrote: If we even have a DMARC ARC Policy concept, than that may be enough to begin

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

On 8/18/2017 2:10 PM, Murray S. Kucherawy wrote: Of course, the danger of proceeding along that line is that we do establish a deployed base, however small, that will be difficult to change later. +1 I don't know the answer to that question immediately, and admittedly I'm only going to be

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

On 8/16/2017 9:32 PM, Seth Blank wrote: On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana > wrote: While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject aware, you can't use ARC on a DMARC p=reject domain without

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

On 8/13/2017 10:28 AM, Kurt Andersen (b) wrote: On Sat, Aug 12, 2017 at 4:51 PM, Hector Santos wrote: If we even have a DMARC ARC Policy concept, than that may be enough to begin pursuing the high cost of experimentation and development here. Beyond the protocol and usage specs

Re: [dmarc-ietf] DMARC mailing list policy with respect to DMARC bounces causing subscription suspensions

at it has come to this new manual "unfriendly" administrative policy. It should to be codify into the integrated specs and everyone will quickly see what needs to be done. Thanks -- Hector Santos, CTO/Founder Santronics Software, Inc. On 7/20/2017 6:08 AM, Barry Leiba wrote: A

Re: [dmarc-ietf] [arc-discuss] openarc defer messages

On 7/15/2017 12:23 PM, Murray S. Kucherawy wrote: I don't think OpenARC development details are appropriate for the IETF list, are they? I agree. -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] using selectors to identify sources

On 7/7/2017 9:12 AM, Tim Draegen wrote: I just caught up on the "selectors in AAR" thread, but wanted to go back to this early statement about key rotation and pairing of "s=" and "d=" to identify a single source. Thus a new Subject: is born. It's true key rotation is rare. People are figuring

Re: [dmarc-ietf] selectors in AAR.

On 6/26/2017 5:26 PM, Gene Shuman wrote: I definitely support this idea, as having the selectors available is extremely useful to us as part of service authentication. And putting them into the AR headers seems to be the appropriate solution. I guess the next question is how we would actually

Re: Git "Keeping Original Dates"

On 6/5/2017 9:22 PM, Jeff King wrote: There are existing scripts which implement this approach, like metastore: https://github.com/przemoc/metastore I haven't used it, but I think it's fairly mature, as it has been around since the early days of Git. -Peff I wasn't considering other

Re: Git "Keeping Original Dates"

On 6/5/2017 6:06 PM, Ævar Arnfjörð Bjarmason wrote: On Mon, Jun 5, 2017 at 11:25 PM, Jason Pyeron <jpye...@pdinc.us> wrote: -Original Message- From: Hector Santos Sent: Monday, June 5, 2017 5:14 PM I'm implementing GIT. If there an option or compile/version that "

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