Re: [dmarc-ietf] There is no pony, Overall last-call comments on DMARC

On 4 Apr 2024, at 13:31, John R. Levine wrote: >> I don’t think it’s scope creep at all. The WG charter puts “Review and >> refinement of the DMARC specification” in phase III, after “Specification of >> DMARC improvements to support indirect mail flows”. It seems clear to me >> that

Re: [dmarc-ietf] Overall last-call comments on DMARC

On 4 Apr 2024, at 12:08, Murray S. Kucherawy wrote: > On Thu, Apr 4, 2024 at 12:02 PM Dotzero wrote: > >> >> >>> >>> My overall point is that this thread makes it seem like we're not putting >>> forward a complete solution. It feels a lot more like a proposed standard >>> that for its clear

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

On 1 Apr 2024, at 9:26, Todd Herr wrote: > On Mon, Apr 1, 2024 at 12:17 PM Tim Wicinski wrote: > >> I have to agree with Seth's comments that "security teams believe an SPF >> hard fail is more secure". >> I've been on the receiving end of that discussion more than once. >> >> Also, can we

[dmarc-ietf] Overall last-call comments on DMARC

In addition to the editorial review I have provided, I have significant concerns regarding the standardization of DMARC-bis. I do not expect that the working group rough consensus will necessarily agree with these concerns, but I want to state them for the working group and will probably

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

On 30 Mar 2024, at 17:22, John R. Levine wrote: Entities other than domains: Public suffixes aren’t (necessarily) domains, >>> >>> Of course they're domains. What else could they be? The things that are >>> out of scope are IP addresses, ASNs, magic tokens in the messages, stuff >>>

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

On 30 Mar 2024, at 17:13, John R. Levine wrote: >> I concur with Jim that rewriting strategies are in scope for the WG >> according to its charter, especially if we have something to recommend >> going forward. > > Our advice is not to publish a DMARC policy if you want to use mailing lists. >

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

On 30 Mar 2024, at 11:42, John R. Levine wrote: >> Below is a number of “minor issues and editorial comments” on dmarcbis-30. I >> have a larger issue regarding the draft as a whole that I have yet to write >> up and will post separately. > > Thanks for the review even though I disagree with a

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

On 30 Mar 2024, at 7:43, Alessandro Vesely wrote: > On Sat 30/Mar/2024 04:09:10 +0100 Jim Fenton wrote: >> >> [...] >> >> I’m concerned that some (admittedly rare) public suffixes with multiple >> components are not well served by this algorithm, such as pvt.k1

[dmarc-ietf] WGLC review of draft-ietf-dmarc-dmarcbis-30

Below is a number of “minor issues and editorial comments” on dmarcbis-30. I have a larger issue regarding the draft as a whole that I have yet to write up and will post separately. -Jim = 1\. Introduction Paragraph 3 introduces alignment, and goes into relaxed and

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

On 5 Feb 2024, at 22:22, Murray S. Kucherawy wrote: > No, it's perfectly fine to declare that DMARC only applies to certain > classes of messages. This actually concerns me a bit. If having multiple From: addresses causes a message to be out of scope for DMARC and therefore bypass a p=reject

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

On 6 Feb 2024, at 14:47, Murray S. Kucherawy wrote: > On Tue, Feb 6, 2024 at 2:33 AM Jeroen Massar 40massar...@dmarc.ietf.org> wrote: > >> `req=dkim`: requires DKIM, messages not properly signed are then to be >> rejected/quarantined based on 'p' policy. >> > > This sounds like what RFC 5617

[dmarc-ietf] DMARC marketing on NPR

I see that the DMARC marketing machine is hard at work. There was an item on NPR (National Public Radio) “All Things Considered” this afternoon heavily promoting DMARC: https://www-cf.npr.org/2023/11/21/1214529474/how-to-keep-an-eye-out-for-cyber-scams-during-this-holiday-shopping-season I

Re: [dmarc-ietf] Dmarcbis way forward

I’m a little slow responding to this; my apologies for that. On 23 Oct 2023, at 1:03, Francesca Palombini wrote: > I believe there is a rough consensus that a change needs to be made in the > text to include stronger requirements admonishing operators against deploying > DMARC in a way that

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

On 10 Sep 2023, at 18:14, Dotzero wrote: >> I agree that the SHOULD language is not very useful because it’s likely to >> be interpreted as only advice. Instead, I think we need a stronger >> statement about the consequences of this policy. For example, “Domains >> publishing p=reject MUST NOT

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

On 7 Sep 2023, at 9:28, Wei Chuang wrote: Many enterprises already have "p=reject" policies. Presumably those domains were subject to some sort of spoofing which is why they went to such a strict policy. This is not necessarily the case. For example, DHS has

Re: [dmarc-ietf] DMARC session agenda for IETF 117

Barry, Can you add pointers to the various text options (perhaps links to the mailing list archive) so we’re all working off the same text? And which is the “current text”? -Jim On 6 Jul 2023, at 8:00, Barry Leiba wrote: > Below is the agenda I am posting for the session at IETF 117. >

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

On 9 Jun 2023, at 22:35, Murray S. Kucherawy wrote: > > You were previously talking about inserting ">" before a line starting > "From ", which is typically done on delivery when writing to an > mbox-formatted mailbox file, because in that format, "From " at the front > of a line has a specific

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

On 26 Apr 2023, at 9:06, John Levine wrote: > It seems to me there are two somewhat different kinds of DMARC damange > that we might separate. One is what happens on discussion lists, where > messages get lost and in the process unrelated recipients get > unsubscribed. The other is simple

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On 9 Apr 2023, at 11:33, Barry Leiba wrote: > There is an alternative, though: we can acknowledge that because of how > those deploying DMARC view their needs over interoperability, DMARC is not > appropriate as an IETF standard, and we abandon the effort to make it > Proposed Standard. > > I see

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On 9 Apr 2023, at 0:50, Murray S. Kucherawy wrote: > (Note, here, that Barry has in his proposed text limited the constraint to > those types of deployments where the damage is likely. I concur. DMARC, > as currently defined, works just fine when deployed in transactional > situations. Or, at

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On 1 Apr 2023, at 8:25, Dotzero wrote: > Hmm, let's apply this to DMARC. > > " But it interoperates just fine once you make the effort." > > Nobody forces a Sender to publish a DMARC record. Nobody forces a receiver > to validate DMARC. Nobody forces mailing lists to accept mail from domains >

Re: [dmarc-ietf] Namespace delegation limits

On 2 Apr 2023, at 4:19, Douglas Foster wrote: > Jesse observed that ESPs sometimes have difficulty getting a delegated DKIM > scope, because it delegates authority an entire namespace: > > With an assist from the DKIM group, we could specify that a DKIM signature > without a "d=" term is valid.

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

Not picking on Murray here, but his message was the most recent that talked about p=reject with respect to non-transactional email: On 1 Apr 2023, at 15:53, Murray S. Kucherawy wrote: > If we use SHOULD NOT, as you suggest, there's an implication that there > might be a valid reason for

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On 28 Mar 2023, at 17:15, Barry Leiba wrote: > NEW > >5.5.6. Decide If and When to Update DMARC Policy > >Once the Domain Owner is satisfied that it is properly authenticating >all of its mail, then it is time to decide if it is appropriate to >change the p= value in its DMARC

Re: [dmarc-ietf] DMARC Damage

On 25 Jan 2023, at 3:57, Douglas Foster wrote: > We know of two current responses to DMARC Damage: (1) Many senders > avoid p=REJECT, so that damage-prone evaluators cannot learn anything > useful from DMARC evaluation, and (2) sophisticated evaluators throw DMARC > results into a proprietary

Re: [dmarc-ietf] Stats on DMARC adoption ?

On 12 Apr 2022, at 20:39, Seth Blank wrote: > Policies: https://dmarc.org/2022/03/dmarc-policies-up-84-for-2021/ > > For mailboxes that implement DMARC and send reports, Valimail (and Dmarcian > I believe) have historically tracked and published that. I'll hunt down > that data tomorrow. Off the

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

On 6 Jul 2021, at 5:45, Todd Herr wrote: Greetings. 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

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

On 15 Jul 2021, at 18:07, Douglas Foster wrote: >> The aligned DKIM signature test can have three conclusions, not just two: >> >> · Fully Authenticated:A signature is present, a DNS public >> key is available, and the key can be used to verify the signature. >> >> · Provided:

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

On 5 May 2021, at 21:26, Seth Blank wrote: Barry and I propose Thursday, May 27th, from 9-11am PT / 12-2pm ET / 4-6pm GMT. 2) I wish to participate in the interim, but the timing does not work (Unless some standing meetings get cancelled). But it looks like I’m the only one, so have fun,

Re: [dmarc-ietf] Sender vs From Addresses

On 25 Mar 2021, at 11:23, John R Levine wrote: Calconnect’s TC-CALSPAM group is currently looking at this issue and yes, the reason is because of real world corporations that use multiple brands with different domains. Typically employees got a single email address on one of their domains

Re: [dmarc-ietf] Ticket #1 - SPF alignment

On 2 Feb 2021, at 11:13, John R Levine wrote: An SPF library implements the check_host() function. It's up to the client to call it multiple times. Is that client DMARC-aware? As you may have guessed, my question is intended to understand how does a DMARC implementation actually

Re: [dmarc-ietf] Ticket #1 - SPF alignment

On 30 Jan 2021, at 13:57, John R Levine wrote: This is DMARC -- the HELO domain has to match the header From: and there has to be an SPF record that validates it. True, but only if the MAIL FROM address is null and there isn’t a valid aligned DKIM signature. True, but I don't see why

Re: [dmarc-ietf] Ticket #1 - SPF alignment

On 30 Jan 2021, at 13:23, John Levine wrote: In article you write: The issue isn’t the existing use of HELO names, it’s how they could be (mis-)used. The fact that a message sender can put anything there makes HELO basically meaningless. This is DMARC -- the HELO domain has to match the

Re: [dmarc-ietf] Ticket #1 - SPF alignment

On 29 Jan 2021, at 12:30, Murray S. Kucherawy wrote: On Fri, Jan 29, 2021 at 3:02 AM Alessandro Vesely wrote: I just run a quick test on my current folder. Out of 3879 messages I extracted 944 unique helo names. 721 of these matched the reverse lookup exactly. Out of the 223 remaining,

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

On 5 Jan 2021, at 10:17, Paypal security confirm your password now wrote: reputation for the domain. I have trouble imagining why anyone would think it's a good idea to get alignment by using third party domains that recipients don't know. Because recipients often can’t see (or don’t pay

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

On 4 Jan 2021, at 9:46, John Levine wrote: Similarly, DMARC alignment tells you nothing unless you also have a reputation for the domain. I have trouble imagining why anyone would think it's a good idea to get alignment by using third party domains that recipients don't know. Because

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

On 29 Dec 2020, at 12:59, John Levine wrote: In article <14d833ce-0ae0-f818-fd4f-95769266a...@mtcc.com> you write: On 12/29/20 12:10 PM, John Levine wrote: A lot of tiny non-profits like Girl Scout troops use email addresses at webmail providers and send their announcements through ESPs like

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

On 6 Dec 2020, at 21:18, 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

Re: [dmarc-ietf] ARC vs reject

On 5 Dec 2020, at 18:22, John R Levine wrote: 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 on a list of trusted intermediaries that is not under

Re: [dmarc-ietf] is DMARC informational?

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. Note that even the current email specs are not "standards" in IETF parlance (there's another WG

Re: [dmarc-ietf] ARC vs reject

On 5 Dec 2020, at 13:03, John Levine wrote: In article <4f2d2e0e-c773-95df-0958-12344e963...@mtcc.com> you write: 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

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

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 significant concern.

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

On 2 Dec 2020, at 1:47, Laura Atkins wrote: p=quarantine is quite useful, particularly for those folks who are trying to get to a p=reject state. In practice, senders who publish p=none don’t find all of the indirect mail flows as some mailing lists do nothing to transform the 5322.from

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

On 1 Dec 2020, at 17:42, Steven M Jones wrote: On 12/1/20 4:16 PM, Douglas Foster wrote: I really hope no casual readers get the impression that DMARC bypasses spam filtering. DMARC evaluations are expected to be independent of spam evaluations. If there's any overlap here, perhaps it would

Re: [dmarc-ietf] IETF 109 possible agenda/session discussion

On 17 Nov 2020, at 11:35, Dave Crocker wrote: On 11/16/2020 10:46 PM, Murray S. Kucherawy wrote: I'm discussing this with the chairs and they or I will get back to you shortly. Forgive me, but this is all a bit nuts. Very few days before the scheduled session, we get a query about

Re: [dmarc-ietf] IETF 109 possible agenda/session discussion

So what’s the conclusion on this? I still see the dmarc meeting on the agenda page, but without any agenda or meeting materials (unlike virtually every other WG meeting). -Jim On 13 Nov 2020, at 12:26, Tim Wicinski wrote: Dave It's the latter. Alexey and I are quite fine with running the

Re: [dmarc-ietf] Announcing DMARCbis Editors

On 7 Nov 2020, at 20:12, Steven M Jones wrote: Okay, but what is the expected payoff from splitting it out? Does it make it easier to process and approve updates of the policy content separately from, say, the description of record discovery or Alignment concepts? Easier to pass muster for

Re: [dmarc-ietf] Announcing DMARCbis Editors

On 5 Nov 2020, at 9:45, Seth Blank wrote: On Thu, Nov 5, 2020 at 9:31 AM Alessandro Vesely wrote: That's the old spec. The consensus of the working group is to remove the normative constraint about p= (ticket #49). So now only v= is required. As Chair, this is not the consensus of

Re: [dmarc-ietf] Announcing DMARCbis Editors

I gather then that policy is part of the Base specification, and that it is assumed that reporting will not be implemented without also implementing policy. I don’t think that’s a good assumption. I would suggest instead that the base specification describe the common pieces: lookup of the

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

On 8/29/20 12:42 PM, Douglas E. Foster wrote: > To elaborate on my question and Michael Hammer's answer: > > To be unique, a signature needs a unique dataset from which the hash > is computed.   The weak signature will not be unique because it will > be computed on non-random content such as From,

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

On 8/26/20 10:54 AM, Dotzero wrote: > > > On Wed, Aug 26, 2020 at 1:32 PM Doug Foster > > wrote: > > Are the weak signatures vulnerable to a replay attack?    I > thought that one of the reasons that DKIM signatures included the > whole

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

On 8/25/20 7:39 PM, John Levine wrote: > In article you write: >>> If the list is somel...@lists.foo.org, does the signature have to be >>> d=lists.foo.org?  How about d=foo.org? >>> >> This seems like an analogous situation to the DKIM i= flag, where the >> domain MUST be the same as, or a

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

On 8/25/20 11:13 AM, John R Levine wrote: > On Tue, 25 Aug 2020, Dotzero wrote: I would expect there to be multiple potential approaches to identifying acceptable intermediaries. >>> >>> The harder part is to decide which intermediary gets to re-sign which >>> message at the time

Re: [dmarc-ietf] non-mailing list use case for differing header domains

On 8/17/20 3:52 PM, Jesse Thompson wrote: > With a complex organization the only way to get people to change is to > publish a restrictive DMARC policy and then see who comes out of the woodwork > sheepishly admitting that they've been ignoring us for years. > > Normal people sending email

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 8/15/20 3:53 PM, John Levine wrote: > Not really. DKIM was deliberately designed not to be tied to any > visible part of the message. ADSP was a poorly designed hack that was > never implemented other than small experiments, and that I don't think > many people understood. I got a lot of grief

Re: [dmarc-ietf] Good paper analyzing inter-component flaws in email security

On 8/14/20 12:16 PM, Dotzero wrote: > > > On Fri, Aug 14, 2020 at 10:59 AM Kurt Andersen (b) > wrote: > > It would be worthwhile for everyone in the group to read > through  > https://www.usenix.org/conference/usenixsecurity20/presentation/chen-jianjun > as

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On 8/14/20 11:30 AM, Kurt Andersen (b) wrote: > On Fri, Aug 14, 2020 at 9:23 AM Dotzero > wrote: > > >  Is this an interoperability problem that is solved by IETF > standards or is it an organizational problem that requires an > organizational solution?

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 8/10/20 12:04 PM, Tim Wicinski wrote: > > During IETF 108, the chairs realized that there was interest in Dave's > RFC5322.Sender draft.   > > This starts a Call for Adoption for draft-crocker-dmarc-sender I do not support adoption of this draft as a working group document for different

Re: [dmarc-ietf] "Email architecture is single author"

SP 800-63-3 Digital Identity Guidelines has anything to do with this. Jim Fenton Altmode Networks ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] non-mailing list use case for differing header domains

On 8/5/20 9:36 AM, Jesse Thompson wrote: > On 8/4/20 11:52 AM, Alessandro Vesely wrote: >> On 2020-08-04 6:10 p.m., Dotzero wrote: >>> There is another solution. Move users to a separate domain from the domain > Long ago we put users on our org domain as a way to unify users (in a very >

Re: [dmarc-ietf] non-mailing list use case for differing header domains

On 8/2/20 5:43 PM, Douglas E. Foster wrote: > As to the transparency question, it should be clear that there will be > no simple solution to the ML problem. Actually, there is: If your domain has users that use mailing lists, don't publish 'reject' or 'quarantine' policies. Generally this means

Re: [dmarc-ietf] non-mailing list use case for differing header domains

On 8/2/20 2:24 PM, John R Levine wrote: >>> If they would provide a way to register a mailing list and the servers >>> from which it comes, and allow DMARC exceptions for traffic from those >>> registered lists, your situation would be much easier? > > If large mail providers were willing to

Re: [dmarc-ietf] non-mailing list use case for differing header domains

On 7/28/20 2:07 AM, Laura Atkins wrote: > The underlying belief with DMARC is that mail is simple, that > companies are monoliths with only a few brands/domains, that it is > possible to know exactly where every message will come from. These > assumptions are not and have never been true.

Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

On 7/26/20 6:42 AM, Dave Crocker wrote: > On 7/21/2020 12:32 PM, Dotzero wrote: >> >> The original DMARC effort was, in fact, to detect actual cases of >> spoofing, namely unauthorized use of a domain name by outside actors. >> >> Different problem. >> >> >> Actually, part of the

Re: [dmarc-ietf] Agenda requests for Madrid IETF

On 7/20/20 11:36 AM, Seth Blank wrote: > We have a session on the books for IETF108, and would like suggestions > from the group for the agenda, otherwise the chairs will choose > relevant topics. Items in tickets or from the past month are all fair > game. > > Thanks, > > Seth, Tim, and Alexey >

[dmarc-ietf] DMARC marketing

This: On 7/21/20 12:29 PM, Joseph Brennan wrote: > > My understanding of DMARC's purpose was to protect transactional > messages from sources like banks, credit card issuers, online shopping > venues, and the like. It supposed that those messages should pass only > directly from the source to the

Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

On 7/18/20 1:45 AM, Alessandro Vesely wrote: > DMARC filtering is designed to operate at the (edge) MX, not MUA.  If > applied consistently, it grants a well defined kind of protection.  > That is just a building block, not a silver bullet.  Our problem is > that DMARC filtering cannot be applied

Re: [dmarc-ietf] DMARC threat analysis needed

Hi Hector, On 7/17/20 9:01 AM, Hector Santos wrote: > Jim, if we review both RFC4686 and RC5016, I believe we might find > there is not much to be changed. However, imo, something will have to > be done regarding RFC5016 section 5.3 item: > >   https://tools.ietf.org/html/rfc5016#section-5.3 >  

Re: [dmarc-ietf] DMARC threat analysis needed

Hi Mike, On 7/15/20 6:31 PM, Dotzero wrote: > As part of the original DMARC team and having worked with anti-abuse > for a long time at scale for a large set of websites, I can speak to > my motivation. It's not really about defending brand identity. The > data shows (although it is not mine to

[dmarc-ietf] DMARC threat analysis needed

Unburying this from a different thread. I'm really struggling to understand what problem(s) DMARC is trying to solve. The most common answer I have heard says something about "defending brand identity", which is a marketing, not a technical consideration. IMO we need a threat analysis, ala RFC

Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field

On 7/14/20 9:09 AM, Dave Crocker wrote: > On 7/14/2020 8:39 AM, John Levine wrote: >> Admittedly, since a lot of MUAs display neither From nor Sender >> address, it's not clear how much this matters. > > > What is, or is not, displayed is irrelevant, since that has nothing to > do with meaningful

Re: [dmarc-ietf] Integrated scanrios (was: Re: Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt)

On 7/8/20 1:08 PM, Dotzero wrote: > > Once you reverse the transformations you would still need to do the > DKIM lookup to validate the reversed text that was signed. Simply > reversing the transformations without validating doesn't give you much > of anything useful. DKIM lookup: do you mean the

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt

On 7/6/20 6:15 PM, Douglas E. Foster wrote: > About discarding From alignment: > DMARC has been sold to big corporations as essential to defending > their brand identity.    In response, they pay serious money to keep > Valimail and its competitors in business.   I see no way that we can > put

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt

On 7/6/20 3:41 PM, John Levine wrote: > In article , > Jim Fenton wrote: >> Your use of  "credible mediator" and "sleazy mediator" emphasizes that >> we're depending on the mediator behaving responsibly. Given that's the >> case, why not just expe

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt

On 7/6/20 10:41 AM, John R Levine wrote: > On Mon, 6 Jul 2020, Dave Crocker wrote: >>> I don't understand this scenario at all.  Why would I want to show >>> my user a message forwarded by a spammer?  If the original sender >>> wanted me to see it, she could have sent it to me directly, or >>>

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt

On 7/5/20 7:42 PM, John Levine wrote: > > It would not be hard for a bad guy to use the footer or add-part > transformation to lay a big spammy blob on top of some innocuous > original message. Rather than play cat and mouse and try to figure one > when a change is too big, recipients would use

Re: [dmarc-ietf] An alternative proposal to the known intermediary problem

On 6/30/20 10:49 AM, Alessandro Vesely wrote: > There are also some which don't seem to have found a way to deliver > valid DKIM signatures, such as those at lists.sourceforge.net. Yes; they seem to be signing with both sf.net and sourceforge.net, but neither signature verifies successfully.

Re: [dmarc-ietf] What if... Sender:

On 6/25/20 2:20 PM, Scott Kitterman wrote: > > Even before you get to those: > >> The working group will seek to preserve interoperability with the >> installed base of DMARC systems, and provide detailed justification >> for any non-interoperability. The paragraph goes on to say: > As the

Re: [dmarc-ietf] What if... Sender:

On 6/25/20 12:12 PM, John Levine wrote: > Any sensible mail provider will do its usual reputation checks on the > validated identity, whichever header it is, and decide whether to > deliver the message or not. I believe that Dave's point is if you're > going to do that, validating the sender gives

Re: [dmarc-ietf] What if... Sender:

On 6/25/20 8:17 AM, Dave Crocker wrote: > On 6/24/2020 12:24 PM, Jim Fenton wrote: >> You have explained why Sender: is better than From: (which I agree with) >> but not why specifically Sender needs to be used. > > Existing practice is less risky than new practice.  The exis

Re: [dmarc-ietf] What if... Sender:

On 6/24/20 11:52 AM, Dave Crocker wrote: > On 6/24/2020 11:35 AM, Jim Fenton wrote: >> On 6/23/20 9:19 PM, Dave Crocker wrote: >> Please explain why it is important that specifically the Sender: >> header field be used for this. > > From: is demonstrably problematic.

Re: [dmarc-ietf] What if... Sender:

On 6/23/20 9:19 PM, Dave Crocker wrote: > On 6/23/2020 4:14 PM, Jim Fenton wrote: >> I do have a concern about Sender:. It has existing semantics defined in >> RFC 5322 Section 3.6.2, and this proposal might conflict with that > > > I don't think it conflicts at all.

Re: [dmarc-ietf] What if... Sender:

On 6/23/20 11:49 AM, Dave Crocker wrote: > So... what if DMARC's semantic were really for the Sender: field?  If > a message has no separate Sender: field, then of course the domain in > the From: field is used. > > The would produce obvious possibilities: > >    From: someone@goodplace.example >  

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

On 6/19/20 10:41 AM, Todd Herr wrote: > On Fri, Jun 19, 2020 at 1:23 PM Dotzero <mailto:dotz...@gmail.com>> wrote: > > > > On Fri, Jun 19, 2020 at 1:09 PM Jim Fenton <mailto:fen...@bluepopcorn.net>> wrote: > > On 6/19/20 6:06 AM, Douglas E

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

On 6/19/20 6:06 AM, Douglas E. Foster wrote: > DMARC helps establish a verified identity.  Delivery is based on > reputation.  The two are very different.  > > Unwanted mail with DMARC validation will be blocked on the same basis > is unwanted mail without it. > > But a verified identity is

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

On 6/18/20 7:35 PM, Dave Crocker wrote: > On 6/18/2020 4:01 PM, Jim Fenton wrote: >> It would be remarkable for IETF to achieve rough consensus on a >> specification with a known vulnerability while we "wait for the bad >> actors to catch on." Particularly

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

On 6/18/20 3:42 PM, Dave Crocker wrote: > > And now I'll note that when DMARC moved from being a way to > authenticate a tightly controlled mail stream, as was originally > discussed during its development, into its broader role, I expressed > the same concern that a correlation not inherently

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

On 6/18/20 2:29 PM, Dave Crocker wrote: > On 6/18/2020 2:10 PM, Jim Fenton wrote: >> On 6/17/20 12:11 PM, Pete Resnick wrote: >>> On 17 Jun 2020, at 13:27, Dave Crocker wrote: >>>> DMARC has nothing to do with display of author information to a >&g

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

On 6/17/20 12:11 PM, Pete Resnick wrote: > On 17 Jun 2020, at 13:27, Dave Crocker wrote: > >> DMARC has nothing to do with display of author information to a >> recipient, and everything to do with differential handling by a >> receiving filtering engine.  Were the Sender: field always present, >>

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

On 6/13/20 8:17 PM, Dave Crocker wrote: > On 6/13/2020 7:53 PM, Jim Fenton wrote: >> Alas, others do, > > Other groups do all sorts of things.  They once mandated OSI, for > example. > > Please explain how that is relevant, here and now. The WG needs to consider the ope

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

On 6/13/20 1:13 PM, John Levine wrote: > In particular, there is no chance whatsoever that any DMARC policy > will become mandatory, because the IETF doesn't do mandatory. Alas, others do, apparently because they see that DMARC has an RFC number (even though it's informational). For example, in

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

On 6/12/20 10:49 AM, Alexey Melnikov wrote: > Hi Alessandro, > > On Fri, Jun 12, 2020, at 5:51 PM, Alessandro Vesely wrote: >> Hi, >> >> On Fri 12/Jun/2020 18:09:41 +0200 Alexey Melnikov wrote: >>> On behalf of DMARC chairs I would like to ask for volunteers to edit future >>> revisions of

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

On 6/7/20 6:16 AM, Douglas E. Foster wrote: > 2) Some of the discussion appeared to resolve around the assertion > that DMARC can have no value.   Since that view is not universal, I > think the project can continue with those who do believe that it adds > value. > That's not how it works; this

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

On 6/6/20 2:42 PM, Scott Kitterman wrote: > On Saturday, June 6, 2020 5:26:08 PM EDT Dave Crocker wrote: >> On 6/6/2020 2:23 PM, Scott Kitterman wrote: >>> If things like DMARC, SPF, and DKIM do nothing more than get abusers to >>> use >>> different domains than they would otherwise, I think

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

On 6/5/20 3:37 PM, Scott Kitterman wrote: > On Friday, June 5, 2020 5:26:19 PM EDT Jim Fenton wrote: >> >> So maybe the core question here is, does the identity in the domain name >> matter or not? It does to me personally because I look at it (whenever I >> can -- my

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

On 6/4/20 10:39 PM, Dotzero wrote: > > The goal of DMARC was (and is) to mitigate direct domain abuse. > Nothing more and nothing less. It helps receiving systems identify a > (correctly) participating domain's mail. That is why a DMARC policy is > often described as a sending domain's request and

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

On 6/2/20 10:35 AM, Dotzero wrote: > > As part of the original DMARC team, the goal was to make clear whether > the email was authorized by the domain being used, hence the reliance > on SPF and DKIM. These are clearly under the domain > owner/administrator's control to the extent they choose to

Re: [dmarc-ietf] Domain-based Message Authentication, Reporting & Conformance (dmarc) WG Virtual Meeting: 2020-06-11

On 5/11/20 6:55 AM, IESG Secretary wrote: > The Domain-based Message Authentication, Reporting & Conformance (dmarc) > Working Group will hold > a virtual interim meeting on 2020-06-11 from 16:00 to 17:00 UTC. > > Agenda: > Joint DMARC 2.0 Discussion (M3AAWG and IETF) Since this meeting is a

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

On 5/29/19 10:13 AM, 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

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

On 5/27/19 11:19 AM, Dilyan Palauzov wrote: Hello Jim, Do you want to split yourself reporiting and policy and create two separate documents, or do you know somebody wiliing to perform the separation?  I cannot imagine why shall one want to read and understand only reporting or only policy

  1   2   >