Re: [dmarc-ietf] Jumping the Gun

On Wed, Oct 25, 2023, at 4:06 PM, Todd Herr wrote: > Someone posting at Security Boulevard has decreed that DMARCbis (at least the > t= tag parts of it) are now codified: > > https://securityboulevard.com/2023/10/dmarc-t-tag-replaces-pct-in-dmarcbis/ > > This person did a fantastic job of

Re: [dmarc-ietf] Why Relaxed Alignment?

Correct. ESPs need to process async bounces to help their customers adhere to best practices. The only way to do that (for a rfc5322.from domain which typically has MX pointed at a mailbox host) is to use a return path subdomain with MX pointed at the ESP. Strict DKIM alignment would be easier

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

On Wed, Aug 23, 2023, at 11:11 AM, John Levine wrote: > It appears that Jesse Thompson said: > >I'm beginning to think that a solution to this problem is "other channels" > > > >Let's discuss p=interoperability, p=compliance, or p=orgname:policyname > >

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

On Mon, Jul 24, 2023, at 1:03 PM, Neil Anuskiewicz wrote: > > > > On Jul 19, 2023, at 3:21 PM, Douglas Foster > > wrote: > > > >  > > Perhaps you can clarify what you think DMARC is. > > > > Apparently a significant number of evaluators think that "DMARC Fail with > > p=reject always means

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

On Sat, Aug 12, 2023, at 11:48 AM, John Levine wrote: > It appears that Jesse Thompson said: > >> This of course requires that the recipient SMTP server can't simply > >> reject the incoming email after the MAIL FROM because SPF checks do > >> not match, they actu

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

I'm woefully behind on this list. Apologies if these points have already been made. On Wed, Jul 19, 2023, at 4:42 PM, Tero Kivinen wrote: > Wei Chuang writes: > > 2) The proposed language calls out "“alumni forwarders”, role-based email > > aliases, and mailing lists" for consideration by

Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

On Tue, Jul 11, 2023, at 7:49 PM, Wei Chuang wrote: > Also can we do more to harden SPF? The SPF upgrade attacks needs three > things: > • IPs shared by multiple sending domains > • Some sender uses those IPs that permits spam and phish traffic > • Those multiple sending domains have SPF

Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?

On Sat, Aug 5, 2023, at 11:49 AM, Dave Crocker wrote: > On 8/5/2023 9:30 AM, Jesse Thompson wrote: > > Governance seems like the best word to me, since Governance is what > > Reporting has provided to ADs in Monitoring Mode, but I do not want to > > say DMARG out loud eith

Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?

On Sun, Jul 23, 2023, at 4:38 PM, Neil Anuskiewicz wrote: > > On Jun 30, 2023, at 11:33 AM, Dave Crocker wrote: > > > On 6/30/2023 11:22 AM, Todd Herr wrote: > >> Why is the mechanism called "Domain-based Message Authentication, > >> Reporting, and Conformance" and not "Domain-based Message

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

On Sat, Jun 10, 2023, at 12:50 AM, Barry Leiba wrote: > Are there working group participants who can do this sort of > evaluation, not just giving numbers but also analyzing why DKIM > failures happened when they should not have? As primarily an outbound ESP, we don't have access to relevant

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

On Thu, Apr 27, 2023, at 9:54 PM, Scott Kitterman wrote: > > > On April 28, 2023 2:49:48 AM UTC, Jesse Thompson wrote: > >On Thu, Apr 27, 2023, at 9:40 PM, Jesse Thompson wrote: > >> On Thu, Apr 27, 2023, at 10:44 AM, Alessandro Vesely wrote: > >>> Al

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

On Thu, Apr 27, 2023, at 9:52 PM, Scott Kitterman wrote: > > > On April 28, 2023 2:25:57 AM UTC, Jesse Thompson wrote: > >On Thu, Apr 27, 2023, at 9:30 AM, Brotman, Alex wrote: > >> Attempt to make it a tad more concise (I think), altering so

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

On Thu, Apr 27, 2023, at 9:40 PM, Jesse Thompson wrote: > On Thu, Apr 27, 2023, at 10:44 AM, Alessandro Vesely wrote: >> Also, state that serious consideration includes testing p=quarantine; >> pct=0^H t=y. > > I was going to say something similar but I think that it is impl

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

On Thu, Apr 27, 2023, at 10:44 AM, Alessandro Vesely wrote: > Also, state that serious consideration includes testing p=quarantine; pct=0^H > t=y. I was going to say something similar but I think that it is implied by section A.7 Jesse ___ dmarc

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

On Thu, Apr 27, 2023, at 9:30 AM, Brotman, Alex wrote: > Attempt to make it a tad more concise (I think), altering some of the > language: > > - > There can be inherent damage to the ability to use certain SMTP-based systems > in conjunction with a policy of quarantine or

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

On Wed, Apr 26, 2023, at 5:47 PM, Scott Kitterman wrote: > On April 26, 2023 9:39:08 PM UTC, Jesse Thompson wrote: > >On Wed, Apr 26, 2023, at 11:06 AM, John Levine wrote: > >> It appears that Scott Kitterman said: > >> >>Domains owners who have users who

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

On Wed, Apr 26, 2023, at 6:21 AM, Scott Kitterman wrote: > > > On April 26, 2023 8:08:39 AM UTC, Alessandro Vesely wrote: > >On Tue 25/Apr/2023 20:27:18 +0200 Scott Kitterman wrote: > >> My recollection is that a general formulation that I proposed had at least > >> some traction out of both

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

On Wed, Apr 26, 2023, at 11:06 AM, John Levine wrote: > It appears that Scott Kitterman said: > >>Domains owners who have users who individually request 3rd parties to emit > >>mail as an address within the domain MUST NOT publish a > >restrictive DMARC policy if they wish to support their

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

On Tue, Apr 25, 2023, at 8:06 PM, John Levine wrote: > It appears that Scott Kitterman said: > >My recollection is that a general formulation that I proposed had at least > >some traction out of both groups: > > > >> [some appropriate description] domains MUST NOT publish restrictive DMARC > >>

Re: [dmarc-ietf] Delegated authentication for Gmail

On 4/22/2023 6:20 AM, Alessandro Vesely wrote: > Those kinds of sender-side authorization schemes seem to be designed for > ESP-like businesses, where a domain owner delegates Domain2 to send messages > on its behalf.  Using such schemes for mailing lists, thereby going down to > per-user

Re: [dmarc-ietf] Delegated authentication for Gmail

A DNS-based lookup, perhaps in the style of ATSP as this thread is describing, to query for not just domain-level authorization, but also potentially user-level authorization, I think is compelling because it can: * Give domain owners a mechanism to achieve least-privilege authorization of 3rd

Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

On Wed, Apr 19, 2023, at 12:35 PM, Alessandro Vesely wrote: > On Wed 19/Apr/2023 15:37:25 +0200 Laura Atkins wrote: > > To me it’s not so much the company can’t delegate authentication - it’s how > > many SaaS providers (some of which are ESPs and some of which are 3rd > > parties > > that send

Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

On Mon, Apr 17, 2023, at 8:37 AM, Laura Atkins wrote: > Should the IETF make the interoperability recommendation that SaaS providers > who send mail on behalf of companies support aligned authentication? That > means custom SPF domains and custom DKIM signatures. > > And if they can’t, then do

Re: [dmarc-ietf] list history, Signaling MLMs

On Sat, Apr 15, 2023, at 12:07 PM, John Levine wrote: > It appears that Jesse Thompson said: > >Why not turn off rewriting on this list, as an experiment? The hypothesis is > >that everyone will switch to Gmail and not tilt > >at IETF, but instead they will tilt a

Re: [dmarc-ietf] Signaling MLMs

On Fri, Apr 14, 2023, at 10:24 PM, Scott Kitterman wrote: > On Friday, April 14, 2023 10:31:33 PM EDT Jesse Thompson wrote: > > On Fri, Apr 14, 2023, at 7:17 PM, Murray S. Kucherawy wrote: > > > The Sender's users being denied the ability to participate in a list due > >

Re: [dmarc-ietf] Signaling MLMs

On Fri, Apr 14, 2023, at 7:17 PM, Murray S. Kucherawy wrote: > The Sender's users being denied the ability to participate in a list due to > its policies seems to me like it puts this customer service problem where it > belongs. Let's say, tomorrow, IETF configures this list to reject Todd's

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

On Sat, Apr 8, 2023, at 8:17 PM, Mark Alley wrote: > Personally, I prefer the latter of the two, quoted below. > > "to preserve interoperability, domains SHOULD NOT publish p=reject unless > they are [not general purpose]* domains" > > "Publishing DMARC records with restrictive policies does

Re: [dmarc-ietf] AOL-compatible mailing lists

On Sat, Apr 8, 2023, at 4:12 AM, Douglas Foster wrote: > It is pretty clear how an AOL-compatible mailing list can be configured: > > • All messages come from the list domain > • Plus addressing is used to give each subscriber a unique From address.. > • To be standards-compliant the plus

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

On Thu, Apr 6, 2023, at 11:43 AM, Murray S. Kucherawy wrote: > > > On Sat, Apr 1, 2023 at 3:13 PM Jesse Thompson wrote: >> __ >> I just read https://datatracker.ietf.org/doc/rfc6541/ (or, re-read, I can't >> remember) >> >> I'm struggling to understan

Re: [dmarc-ietf] Proposed text to close out Ticket 96

On Wed, Apr 5, 2023, at 5:20 PM, Seth Blank wrote: > When we talk about DMARC and interoperability, we have to remember that there > are THREE participants within DMARC that need to interoperate, the sender, > the receiver, and the domain owner. We keep on discussing the sender and > receiver

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

On Wed, Apr 5, 2023, at 4:41 PM, Jim Fenton wrote: > This got me to musing: What if IETF decided to remove its From address > rewriting and started bouncing all incoming mail to its mailing lists from > domains that have a p=reject (and maybe p=quarantine) policy? I don’t think > it would be

Re: [dmarc-ietf] Solving DMARC damage with User quarantine and Steram-Info tag

trust by defining metrics that can be verified over > time. ++ Jesse > > Doug > > > > On Mon, Apr 3, 2023 at 7:00 PM Jesse Thompson wrote: >> __ >> On Sat, Apr 1, 2023, at 9:41 PM, Douglas Foster wrote: >>> My approach to ESP traffic i

Re: [dmarc-ietf] Solving DMARC damage with User quarantine and Steram-Info tag

On Sat, Apr 1, 2023, at 9:41 PM, Douglas Foster wrote: > My approach to ESP traffic is simple. I assume that the ESP has authorized > the account indicated by the From address, so I don't worry about Sender > Authentication as long as the message passes SPF based on the ESP domain. > DMARC

Re: [dmarc-ietf] Namespace delegation limits

On Sun, Apr 2, 2023, at 9:25 AM, Jim Fenton wrote: > 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

Re: [dmarc-ietf] Solving DMARC damage with User quarantine and Steram-Info tag

On Sat, Apr 1, 2023, at 8:04 AM, Douglas Foster wrote: > For purposes of the following discussion, assume that messages from known-bad > senders and messages with unacceptable content have already been blocked. > The question at hand is how to handle Sender Authentication failure when a >

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

I'm looking at this through the lens of formerly being a domain owner for a complex organization doing a successful DMARC deployment which ended at p=quarantine for the organization domain primarily housing user-generated email. A subdomain strategy is employed for most other non-user generated

Re: [dmarc-ietf] Treewalk causing changes

On 3/1/2023 6:12 AM, Douglas Foster wrote: > A sub-issue to consider:   Should we do a Tree Walk on the authenticating > domain? > For example, assume that "virgina.gov " and > "dmas.virginia.gov " both have DMARC policies with > relaxed alignment. 

Re: [dmarc-ietf] Minutes from IETF 112

On 11/18/2021 1:44 PM, John Levine wrote: > It appears that Todd Herr said: >> It seems to me that DMARC already provides the ability for >> security.example.edu to ensure that no other part of example.edu can send >> mail on their behalf. To accomplish this, security.example.edu can today: >>

Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report

On 12/11/20 7:48 AM, Alessandro Vesely wrote: > On Thu 10/Dec/2020 17:59:54 +0100 Jesse Thompson wrote: >> On 12/9/20 10:28 PM, seth wrote: >>> As an individual, I feel extremely strongly that failure reports should go >>> away in their entirety. Although Jesse Thomp

Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report

On 12/9/20 10:28 PM, seth=40valimail@dmarc.ietf.org wrote: > As an individual, I feel extremely strongly that failure reports should go > away in their entirety. Although Jesse Thompson has outlined a use case that > really has no other good solution, and is equally true in ot

Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report

On 12/9/20 6:12 PM, Brandon Long wrote: > At best, we considered allowing RUF reports for cases where the dmarc domain > was the receiver, ie if someone had a message that failed dmarc while sending > to the same domain, then presumably the domain admin already has the power to > view the

Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report

On 12/9/20 11:07 AM, Alessandro Vesely wrote: > We would like to close this ticket by Dec 23, two weeks from now, so please > get on it. > > The ticket text is: > >     It has been asked for a new report type (perhaps a subset of failure >     reports) that provides minimal data from the email

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

On 12/3/20 8:21 AM, Todd Herr wrote: > On Thu, Dec 3, 2020 at 4:28 AM Laura Atkins > wrote: > > > >> On 3 Dec 2020, at 06:03, Jim Fenton > > wrote: >> >> On 2 Dec 2020, at 1:47, Laura Atkins wrote: >> >>> p=quarantine

Re: [dmarc-ietf] Domains and tree walk

On 12/1/20 8:50 PM, John Levine wrote: > On the other hand, I observe that Brown, Cornell, Dartmouth, U Penn, > and Yale, whose situations are not altogether unlike Columbia's, all > publish DMARC records. Closer to home so do NYU and CUNY. They all say > p=none with rua= to collect reports. You

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

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, > for example, this list does.   While ARC solves "deep" forwarding problems, > which may

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

On 11/24/20 9:52 AM, todd.herr=40valimail@dmarc.ietf.org wrote: > On Tue, Nov 24, 2020 at 10:37 AM Dave Crocker > wrote: > > Just to be clear, I'm not challenging the need.  Rather I'm just looking > for text that explains the need.  And I'm not finding it...

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

On 11/23/20 1:00 PM, Dave Crocker wrote: > On 11/23/2020 10:50 AM, Jesse Thompson wrote: >> Would it help if there was a new DMARC policy tag to trigger the tree walk? > > > policy tags are useful when one has a dmarc record that might contain it.  > the challenge here i

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

On 11/20/20 6:02 PM, John R Levine wrote: > Here's a draft about how DMARC might do a tree walk rather than look up an > organizational domain in the PSL. > > https://datatracker.ietf.org/doc/draft-levine-dmarcwalk/ Would it help if there was a new DMARC policy tag to trigger the tree walk?

Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd

On 11/23/20 8:28 AM, eric.b.chudow.civ=40mail@dmarc.ietf.org wrote: > Even for .mil, the vast majority of email domains are fairly short with four > or fewer labels. Most of the other ones tend to be individual servers that > send automatic performance emails, and I think should be

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

On 11/13/20 9:03 AM, dotz...@gmail.com wrote: > > > On Fri, Nov 13, 2020 at 9:46 AM Joseph Brennan > wrote: > > > > As another case, would people be surprised that email for the > medical center cumc.columbia.edu is a

Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND

On 11/12/20 5:06 PM, Kurt Andersen (b) wrote: > On Thu, Nov 12, 2020 at 2:58 PM Jesse Thompson > mailto:40wisc@dmarc.ietf.org>> > wrote: > > On 11/12/20 3:23 PM, John Levine wrote: > > You now can put a DMARC > > record on a name below the org

Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND

On 11/12/20 3:23 PM, John Levine wrote: > You now can put a DMARC > record on a name below the org domain to shadow a subtree, but I don't > think that is a problem that needs to be solved. I'm confused by this statement. Are you saying that you can "now" do subtree shadowing with sp? as in

Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND

On 11/12/20 10:30 AM, John Levine wrote: > In article > you > write: >> As another case, would people be surprised that email for the medical >> center cumc.columbia.edu is a separate system managed by a separate IT >> group from columbia.edu, and that any authentication for one should not be

Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports

On 10/19/20 7:17 AM, Brotman, Alex wrote: > Sure, I think Masaki Kase is suggesting roughly the same thing (along with IP > address). Tell the domain who is the entity responsible for attempting this > delivery? This might need to be a hash of some sort. > I think this sort of data would

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

On 10/6/20 10:20 AM, John Levine wrote: > In article <1265372281.9984.1601969016...@appsuite-gw1.open-xchange.com> you > write: >> It would be much better if there were a few professional/community efforts >> to build reliable and complete lists of good >> and bad ARC intermediaries, like for

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

On 9/28/20 10:35 AM, Kurt Andersen (b) wrote: > On Sun, Sep 27, 2020 at 11:23 AM Scott Kitterman > wrote: > > On Sunday, September 27, 2020 1:16:11 PM EDT John Levine wrote: > > Agreed.  Maybe it would help if someone who takes the latter view would >

Re: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Sep 20 06:00:05 2020

On 9/20/20 4:59 AM, jo...@taugh.com wrote: >Count| Bytes | Who > ++--- > 4 (19.0%) | 59259 (32.1%) | Douglas E. Foster > > 4 (19.0%) | 34450 (18.7%) | Joseph Brennan > 2 ( 9.5%) | 20361 (11.0%) | Jesse Thompson

Re: [dmarc-ietf] DMARC as Signal to MLMs for Rewrites (or not)

On 9/17/20 5:09 PM, Sabahattin Gucukoglu wrote: > On 17 Sep 2020, at 20:59, Jesse Thompson > wrote: >> On 9/17/20 2:11 PM, Sabahattin Gucukoglu wrote: >>> Wouldn’t it be nice if you could ask for MLMs to transform, just using a >>> DMARC policy, even p=no

Re: [dmarc-ietf] DMARC as Signal to MLMs for Rewrites (or not)

On 9/17/20 2:11 PM, Sabahattin Gucukoglu wrote: > Wouldn’t it be nice if you could ask for MLMs to transform, just using a > DMARC policy, even p=none, It is possible via p=quarantine pct=0. I think it makes sense to consider codifying beyond this defacto standard hack. Isn't this part of

Re: [dmarc-ietf] AutoForward problems

tching side's UI for handling re-authentication, so it's not a slam dunk alternative to SMTP forwarding. Jesse > > Doug Foster > > > -Original Message- > From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Jesse Thompson > Sent: Thursday, September 03, 2020 8:42

Re: [dmarc-ietf] AutoForward problems

On 9/2/20 6:33 AM, Douglas E. Foster wrote: > For mailing lists, we have pushed the limits of authorization.   But there is > another class of problems where sender authorization is not feasible:   mail > which is auto-forwarded after a spam-filter has made content-altering changes. Yes, this

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

On 8/21/20 4:05 PM, Brandon Long wrote: > > > On Fri, Aug 21, 2020 at 12:24 PM Jim Fenton <mailto:fen...@bluepopcorn.net>> wrote: > > On 8/17/20 3:52 PM, Jesse Thompson wrote: > > With a complex organization the only way to get people to change is to

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

On 8/20/20 4:00 PM, blong=40google@dmarc.ietf.org wrote: > Neither atps or spf include are really designed for large scale usage That's my conclusion, as well. I don't want to authorize every potential MLM to use all addresses in all of our domains cart blanch, even if I would otherwise

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

On 8/17/20 3:00 PM, Luis E. Muñoz wrote: > DMARC can be quite useful even with p=none. Agreed. People commonly request that we accept-list their IP/domain from inbound spam scanning. We now tell them to send DMARC-aligned mail (SPF or DKIM pass, aligned with From), and we'll use that as

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

On 8/7/20 9:32 PM, John Levine wrote: >> We need spoofing protection for all of our domains without being told we're >> misdeploying. > > I would be interested to better undertstand the meaning of "need" > here. It is my impression that most people vastly overestimate how > much of a phish target

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

On 8/13/20 10:03 AM, John R Levine wrote: >> -Admittedly, that's where my bias comes in. My job is working with >> organizations that have paid my employer for me to be that outside help, so >> it's rare for me to see how badly it can be done by people setting >> restrictive DMARC policies

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

On 8/7/20 2:12 PM, John Levine wrote: > In article > > you write: >> I feel like what is happening sometimes is that central university IT is >> trying to drag their whole institutions into a >> more secure posture before anybody in a position to stop them fully >> understands what's going on

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

On 8/4/20 11:52 AM, Alessandro Vesely wrote: > On 2020-08-04 6:10 p.m., Dotzero wrote: >> On Tue, Aug 4, 2020 at 11:39 AM Jim Fenton wrote: >>> 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

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

On 7/23/20 8:07 AM, Joseph Brennan wrote: >> I think that we just have to agree that From-munging by MLMs is a permanent >> reality. It needs to be documented more prominently (and promoted as part >> of the DMARC marketing) so that implementations are more consistent, so that >> un-munging

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

On 7/30/20 2:47 PM, superu...@gmail.com wrote: > Email domains that have more than a few users don't want to authorize > every potential 3rd party (converges quickly to all of them, for > large/complex organizations) to sign as every user/address in the domain.  > Even if SPF didn't have

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

On 7/30/20 2:47 PM, superu...@gmail.com wrote: > Translated into IETF-ese: "I have not read your document but I do have an > opinion about it..."   ;-) Yeah, Dave sent me that feedback too. I was just trying to make it clear that I only have $0.02 to give, rather than trying to sound like I'm

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

On 7/29/20 12:34 PM, Hector Santos wrote: > On 7/28/2020 1:19 PM, Doug Foster wrote: >> Hector, I do not understand this comment: >> >> "The DKIM Policy Model since ADSP lacked the ability to authorize 3rd party >> domains. DMARC did not address the problem and reason ADSP was abandoned. >>

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

On 7/28/20 10:59 AM, Alessandro Vesely wrote: > I understood the problem is the lack of agility.  Delegation to smaller > domains using local servers would solve it, wouldn't it?  Even with many > domains... > > What am I missing? It's assuming there are local servers in the mix, which is

Re: [dmarc-ietf] DMARC marketing

On 7/22/20 5:55 PM, Jim Fenton wrote: > These get to the heart of the problem: DMARC policy was designed for > official mail that is about business transactions. If that was the way > it is actually used, we wouldn't be having this problem. But it was > oversold, and it is being used in use cases

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

On 7/22/20 12:05 PM, John Levine wrote: > I don't believe we have a charter to tell mailing list operators what > to do, even if we believed, against all experience, that they would > take our advice. https://cyber.dhs.gov/bod/18-01/ references

Re: [dmarc-ietf] Why are MUAs hiding or removing the From address?

On 7/21/20 6:05 AM, Douglas E. Foster wrote: > I would like a better understanding of why MUAs are hiding or removing the > FROM address. > > I have one mail store that formerly used hover-to-view, but recently changed > to always-show.   This was done in response to a client request on their

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

On 7/20/20 7:55 AM, Douglas E. Foster wrote: > I am advocating for MLMs to stop spoofing and make their peace with DMARC. Maybe the recommendation should be that MLMs (or any ESP, for that matter) should never send as a domain they do not directly own unless it's authorized to send aligned mail

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

On 7/19/20 1:33 PM, dcroc...@gmail.com wrote: > The essential point that needs to be made is that standards like this MUST > NOT be cast in terms of what end users will do.  In practical terms, this > work has nothing to do with end users.  Really.  Nothing. > > To the extent that anyone wants

Re: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers

On 6/29/20 4:18 AM, Alessandro Vesely wrote: > Hi all, > > I mentioned setting To: author instead of From: author-like, near the bottom > of a message[*] a week ago, but missed any WG comments on it. That setting > would result if I run a mailing list "by hand", using a normal email client.

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

On 6/23/20 1:49 PM, dcroc...@gmail.com 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. Wouldn't MUAs need to consistently display Sender? Jesse

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

On 6/22/20 6:23 AM, Alessandro Vesely wrote: > The fact that it cannot be set by a MUA implies Sender: already lost > its menial meaning. So it became a Mediator sort of thing. This list > sets it to "dmarc" . Does anybody use it, or > ever happened o take a look at it? Yes, and I assume

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

On 6/17/20 4:23 AM, Alessandro Vesely wrote: > On Mon 15/Jun/2020 20:27:08 +0200 Scott Kitterman wrote: >> On Monday, June 15, 2020 2:19:22 PM EDT Jesse Thompson wrote: >> >>> Even if you ignore my line of reasoning, I think that Ale made in the OP a >>> compelli

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

On 6/15/20 12:44 PM, John Levine wrote: > In article <1ef0572d-a83c-ad97-9c0d-5f5615ab1...@wisc.edu> you write: > They both claim they're working on ARC. > >> So, solution 1.3 has been naturally selected. Does it need to be >> standardized, or is a BCP good enough? >> I'd still like to see a

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

On 6/15/20 2:33 AM, Alessandro Vesely wrote: > Let me quote a list of nineteen usable solutions: > >     1 Sending side workarounds >     1.1 Exclude domains that require alignment >     1.2 Turn off all message modifications >     1.3 Replace address with a generic one >     1.4

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

in Trac? I think I know the answer to the second concern, but I'll defer to people more adept at explaining the nuance. See below... Thanks, Jesse Thompson UW-Madison " I don't see on the list of issues the most fundamental problem of DMARC, namely that it conflicts with RFC 5322 on th