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

Just provide a DKIM only mechanism/option. Michael Hammer On Sat, Feb 23, 2019 at 2:56 PM Kurt Andersen (b) wrote: > On Sat, Feb 23, 2019 at 11:00 AM Hector Santos wrote: > >> On 2/23/2019 1:07 PM, Kurt Andersen (b) wrote: >> > >> > Instead of using the standard "(+)include:" approach, if doma

Re: [dmarc-ietf] Email security beyond DMARC?

On Wed, Mar 20, 2019 at 10:49 AM John R Levine wrote: > > DMARC has never been an anti-spam scheme. It's about phishing, which is > not the same thing. > I'm going to have to disagree with you John. DMARC is about preventing direct domain abuse. It does not specifically address phishing as the

Re: [dmarc-ietf] Working group next steps

Douglas, Can you show us a single email authentication standard that is 100% deployed on the Internet? There isn't anything that comes close to that achievement. Even things like DNS are not 100%. I know hosts that are only reachable by IP address. Michael Hammer On Sun, Mar 31, 2019 at 2:31 PM

Re: [dmarc-ietf] Rethinking DMARC for PSDs

What part of that do you need an explanation for? It seems pretty clear to me. If you disagree with the statement then you should explain the rationale for your disagreement. Michael Hammer On Mon, Apr 8, 2019 at 6:55 PM Douglas E. Foster < fost...@bayviewphysicians.com> wrote: > I don't know ho

Re: [dmarc-ietf] DMARC Coverage

Scott, it's almost certainly an undercount as there are domains which validate for DMARC but do not send reports. Michael Hammer On Sat, Apr 13, 2019 at 5:12 PM Scott Kitterman wrote: > A couple of days ago I sent a single message to a reasonably large mailing > list (spf-help, email oriented -

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

I also lean towards Seth's perspective. Additional comments in-line. On Mon, May 20, 2019 at 1:32 AM Murray S. Kucherawy wrote: > Hatless: > > On Tue, May 7, 2019 at 7:30 PM Seth Blank wrote: > >> 2. In Section 3.5, I'm concerned with the normative MUST NOT. This would >> mean .example couldn'

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

Scott expresses it perfectly. +1 There is no compelling reason being given for the split. Absent a compelling reason, this should not be pursued. Michael Hammer On Fri, May 24, 2019 at 10:20 AM Scott Kitterman wrote: > > > On May 23, 2019 8:35:47 PM UTC, Jim Fenton wrote: > >In response to Se

Re: [dmarc-ietf] DMARCbis issue: what is DMARC ?

See below. On Fri, May 24, 2019 at 2:39 PM Jim Fenton wrote: > On 5/24/19 11:25 AM, John R Levine wrote: > > On Fri, 24 May 2019, Jim Fenton wrote: > >> I hope this isn't devolving into a "we can't make any changes, because > >> it might break something" argument. > > > > I don't think so, but w

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

On Fri, May 31, 2019 at 6:59 AM Douglas E. Foster < fost...@bayviewphysicians.com> wrote: > I cannot speak to IETF consensus, since I am new to that process and I > seem to be an outlier already. > Perhaps the onus is on you to take the time to understand IETF and it's processes before demandin

Re: [dmarc-ietf] Mandatory Sender Authentication

Comments in-line. On Thu, Jun 6, 2019 at 1:47 PM Douglas E. Foster < fost...@bayviewphysicians.com> wrote: > >> 1. By 'sender', which actor in the sequence do you mean? The term is > highly ambiguous. > > By Sender Authentication, I mean message "From Address" authentication. > This involves tw

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

On Wed, Jun 12, 2019 at 9:38 AM Laura Atkins wrote: > > On 12 Jun 2019, at 14:28, Hector Santos > wrote: > > On 6/11/2019 5:00 PM, Дилян Палаузов wrote: > > > How about, deleting policy Quarantine and instead rephrasing policy Reject: > > It is up to the receiving server if it rejects messages f

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

On Fri, Jun 14, 2019 at 11:08 AM Vladimir Dubrovin wrote: > > p=quarantine with pct=0 is useful to test DMARC with mailing list/groups > which perform "From" rewrite based on DMARC policy. It's safe, because > it actually works like "none" but it causes From rewrites, because it's > still conside

Re: [dmarc-ietf] Mention ICANN/operational limitations was: Re: Working Group Last Call: draft-ietf-dmarc-psd

+1 Your proposed rewording makes sense. Michael Hammer On Fri, Jul 12, 2019 at 1:41 PM Scott Kitterman wrote: > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > > As Secretary, there are three items that have not yet reached consensus > > that must be resolved during WGLC: > > > 2

Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

On Fri, Jul 12, 2019 at 2:16 PM Seth Blank wrote: > On Fri, Jul 12, 2019 at 10:55 AM Kurt Andersen (b) > wrote: > >> I am much more concerned with adding another tag that can only be used in >> a PSD-DMARC record. I would be much more open to make a "normative" change >> to the DMARC tag list (R

Re: [dmarc-ietf] Amazon Comments to DMARC Extension to PSD

On Wed, Jul 17, 2019 at 7:51 PM Scott Kitterman wrote: > > > On July 17, 2019 10:23:11 PM UTC, "Flaim, Bobby" 40amazon@dmarc.ietf.org> wrote: > >Amazon supports this draft and effort . > > > >This current DMARC extension (IETF DMARC PSD) > >draft

Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

I've been following the discussion but haven't contributed anything until this point. Comment below. On Fri, Jul 19, 2019 at 3:29 AM Ian Levy wrote: > > I think this is one of those "you must be this tall to ride on this ride" > > situations. DNS comes equipped with multiple footguns and you ha

Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working GroupLast Call: draft-ietf-dmarc-psd

+1 on Scott's comment. Michael Hammer On Mon, Jul 22, 2019 at 6:44 AM Scott Kitterman wrote: > > > On July 22, 2019 4:31:40 AM UTC, "Douglas E. Foster" < > fost...@bayviewphysicians.com> wrote: > >About this paragraph: > > > >>> The original pre-standardization version of this protocol included

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

On Wed, Jul 24, 2019 at 7:07 PM Murray S. Kucherawy wrote: > On Wed, Jul 24, 2019 at 4:45 PM Steve Atkins > wrote: > >> > It's interesting that the industry has decided to interpret "p=reject; >> pct=0" the way we intended "p=quarantine; pct=100". >> >> It's semi-explicitly defined that way in t

Re: [dmarc-ietf] Aggregate reporting options tag name 'ao'

Having both passes and failures is incredibly useful. The percentage of failures is very useful. Any set of mail streams will always have some failures. Once you know what the baseline rate for a (sub)domain is, simply seeing changes in that rate will help you identify problems. An increase in the

Re: [dmarc-ietf] New proposed wording for p=quarantiine

On Sat, Aug 10, 2019 at 4:44 AM Дилян Палаузов wrote: > Hello, > > to the idea to amend the existing definition of p=: > > quarantine: The Domain Owner wishes to have email that fails the > DMARC mechanism check be treated by Mail Receivers as > suspicious. Depending on the

Re: [dmarc-ietf] Two new fields in aggregate reports

On Fri, Oct 25, 2019 at 1:53 PM Seth Blank wrote: > On Fri, Oct 25, 2019 at 10:49 AM John Levine wrote: > >> As far as I know, the point of DMARC reports is to help domain owners >> understand who is sending mail that purports to be from them. In a >> large organization it can be remarkably har

Re: [dmarc-ietf] Two new fields in aggregate reports

On Fri, Oct 25, 2019 at 2:36 PM Alessandro Vesely wrote: > > Well, spam score usually is hight for phishing too. To counter phishing is > DMARC core business. > Absolutely wrong. DMARC does one thing and one thing only - mitigate direct domain abuse. Bad guys can and have switched to using cous

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

I do not support publishing draft-ietf-dmarc-psd as is. Running code and rough consensus. I, as were a few others on the list, was part of the private effort that eventually became the "DMARC team". I point out that until DMARC was published openly, the experiment had absolutely zero impact on oth

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

On Tue, Feb 4, 2020 at 3:39 PM Scott Kitterman wrote: > On Tuesday, February 4, 2020 3:25:06 PM EST Dotzero wrote: > > Someone pointed to Sender-ID as an example experiment. A very poor > example > > to choose. It was broken from the start. As an aside, I kept sending > emai

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

On Tue, Feb 4, 2020 at 3:44 PM Scott Kitterman wrote: > On Tuesday, February 4, 2020 3:25:06 PM EST Dotzero wrote: > > I am not against experiments, but having reread the entire thread > starting > > from Dave's post in August, I believe his concerns are valid. My questio

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

On Tue, Feb 4, 2020 at 4:26 PM Murray S. Kucherawy wrote: > > > I think what Dave proposed about PSL separation from DMARC is entirely > appropriate and pragmatic, and in fact probably easy enough: DMARC is > changed so that it says the organizational domain is determined using some > process [c

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

On Tue, Feb 4, 2020 at 6:36 PM Murray S. Kucherawy wrote: > On Tue, Feb 4, 2020 at 1:44 PM Dotzero wrote: > >> On Tue, Feb 4, 2020 at 4:26 PM Murray S. Kucherawy >> wrote: >> >>> >>> >>> I think what Dave proposed about PSL separation from D

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

On Thu, May 21, 2020 at 5:57 PM Tim Wicinski wrote: > (with no hats) > > p=none with no reporting is fine, and we should keep it. > > One thing the WG could do is a BCP document on operational recommendations > where there are certain suggestions like this. > > tim > > +1 > Michael Hammer __

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

On Tue, Jun 2, 2020 at 12:44 PM Jesse Thompson wrote: > I'm relaying these DMARC questions/concerns on behalf of an email admin at > another university. I quickly searched this list's archives for the Sender > header vs DMARC alignment issue and don't see much aside from a > conversation in May

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

On Tue, Jun 2, 2020 at 5:31 PM Seth Blank wrote: > As an individual: > > On Tue, Jun 2, 2020 at 1:46 PM Dave Crocker wrote: > >> However there appears to be no actual evidence that lying in the From >> field affects end user behaviors, and certainly none that lying in the From >> field about the

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

On Fri, Jun 5, 2020 at 12:40 AM Jim Fenton wrote: > 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 unde

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

On Fri, Jun 5, 2020 at 5:26 PM Jim Fenton wrote: > 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. Tha

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

On Fri, Jun 19, 2020 at 1:09 PM Jim Fenton wrote: > 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 u

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

On Sun, Jun 21, 2020 at 1:32 PM Dave Crocker wrote: > > When first specified, Sender: was to cover the case of someone doing the > online work, on behalf of authors who weren't online, or at least not > online for processing the message. Back in those days, that was not > uncommon. Even if the

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

On Wed, Jun 24, 2020 at 10:07 AM Dave Crocker wrote: > On 6/24/2020 7:04 AM, Jesse Thompson wrote: > > 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 t

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

On Wed, Jun 24, 2020 at 9:43 AM wrote: > Hi, > > just answering this one bit, which I believe is at the heart of the > disagreement: > > > > IMHO "phishing and spam messages" is way too broad a concept to permit > useful discussion. DMARC nowadays addresses a whole range of problems of > varying

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

On Wed, Jun 24, 2020 at 1:18 PM Dave Crocker wrote: > On 6/24/2020 8:09 AM, Dotzero wrote: > > Sender: is completely irrelevant to the use of DMARC now. > > Actually, I'm claiming it isn't. > > Or rather, I'm claiming there is a failure to appreciate that it

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

his group to take up or another group. Michael Hammer On Thu, Jun 25, 2020 at 9:53 AM Dotzero wrote: > > > On Wed, Jun 24, 2020 at 1:18 PM Dave Crocker wrote: > >> On 6/24/2020 8:09 AM, Dotzero wrote: >> >> Sender: is completely irrelevant to the use of DMARC no

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

After reading Dave Crocker's proposal, which I consider fundamentally broken, I've given some thought to the issues. 1) Many MLM's do not want to change their current practices yet suffer consequences from DMARC implementations at their subscribers domains. 2) There is a mismatch between the gran

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

hanges to DMARC. Michael Hammer On Thu, Jun 25, 2020 at 10:16 PM Scott Kitterman wrote: > On Thursday, June 25, 2020 8:05:43 PM EDT Dotzero wrote: > > After reading Dave Crocker's proposal, which I consider fundamentally > > broken, I've given some thought to the issues. >

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

On Fri, Jun 26, 2020 at 9:45 PM John Levine wrote: > In article <20200626032027.b7efa1bb5...@ary.qy> you write: > >In article < > caj4xoyecbh4ycofhzmv+a0336aifx55blvsdh-u21kkj+gr...@mail.gmail.com> you > write: > >>B) Specifying the specific Intermediary in the Intermediary Field. This > >>would

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

On Tue, Jul 7, 2020 at 2:19 PM Alessandro Vesely wrote: > On Tue 07/Jul/2020 18:27:40 +0200 John R Levine wrote: > >> There's a distinction though. ARC tells you "that guy over there said > the > >> original message passed", and you have to trust it. On the other hand, > the > >> transformation

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

On Wed, Jul 8, 2020 at 12:42 PM Murray S. Kucherawy wrote: > I'm sorry, I got that backwards. What I meant to say is: > > On Wed, Jul 8, 2020 at 9:04 AM Murray S. Kucherawy > wrote: > >> On Wed, Jul 8, 2020 at 1:21 AM Dotzero wrote: >> >>> At

Re: [dmarc-ietf] DMARC threat analysis needed

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 share) that end users will click on anything based on t

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

On Mon, Jul 20, 2020 at 5:44 AM Benny Lyne Amorsen wrote: > "Douglas E. Foster" writes: > > > Ultimately, this becomes a question of power. Do domain owners have > > the right, with the help of their correspondents, to prohibit spoofing > > (unauthorized use) of their digital identity? > > Doma

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

On Tue, Jul 21, 2020 at 11:52 AM Dave Crocker wrote: > On 7/21/2020 8:48 AM, Jesse Thompson wrote: > > 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 t

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

On Tue, Jul 21, 2020 at 2:06 PM Dave Crocker wrote: > On 7/21/2020 10:58 AM, Dotzero wrote: > > > > > > On Tue, Jul 21, 2020 at 11:52 AM Dave Crocker > <mailto:d...@dcrocker.net>> wrote: > > > > The mail is not spoofed. Consider the definitio

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

On Wed, Jul 22, 2020 at 6:38 PM Jesse Thompson wrote: > 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-0

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

Apologies, I intended on sending this to the group rather than just Seth. -- Forwarded message - From: Dotzero Date: Fri, Jul 24, 2020 at 3:03 PM Subject: Re: [dmarc-ietf] Agenda requests for Madrid IETF To: Seth Blank On Mon, Jul 20, 2020 at 2:36 PM Seth Blank wrote: >

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

On Sat, Jul 25, 2020 at 9:48 AM Murray S. Kucherawy wrote: > On Fri, Jul 24, 2020 at 12:05 PM Dotzero wrote: > >> I would like to see an agenda item as to whether work around "Display >> Name" changes are in scope or out of scope for this effort and this working &

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

On Sun, Jul 26, 2020 at 9: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. >>

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

On Tue, Jul 28, 2020 at 2:54 AM Autumn Tyr-Salvia wrote: > Hello, > > I recently had a conversation with Dave Crocker about proposed changes for > DMARC, and mentioned a use case to him that is not well served by the > current situation that is not a mailing list. He said it might be useful to >

Re: [dmarc-ietf] Meetecho at IETF 108

On Tue, Jul 28, 2020 at 10:20 AM Steven M Jones wrote: > > Having to flip back and forth between the chat column and the > queue/participant column was awkward. Assuming I didn't miss a setting: > Why can't we have both shown? At least as an option on larger > screens/windows/devices. > > --S. >

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

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 problem. > > Actually, there is: If your domain has users that use mailing lists, > don't pub

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

On Wed, Aug 5, 2020 at 12:39 PM Jesse Thompson wrote: > 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: > >

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

On Mon, Aug 10, 2020 at 1:24 PM John Levine wrote: > In article <2ef8e773e7bf467481a05ab3fc4d9...@bayviewphysicians.com> you > write: > >>Even an external reputation system requires recipient participation. > That is why I suggested both a send3="parameters" clause to > >indicate sender support

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

On Thu, Aug 13, 2020 at 3:06 PM Neil Anuskiewicz wrote: > > > Tunable! You said the magic word I have a client now getting spoofing. > Tightening above p=none is a non starter as about 100% of MajorCRM emails > fail SPF (foo.majorcrm is the RFC5321.from), 62% of MajorCRM mail fails > DKIM, and 10

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

On Thu, Aug 13, 2020 at 5:43 PM Kurt Andersen (b) wrote: > On Thu, Aug 13, 2020 at 2:33 PM Doug Foster 40bayviewphysicians@dmarc.ietf.org> wrote: > >> The current DMARC architecture supports authorizing a vendor to mail on >> behalf of their clients if the client includes them in their SPF p

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

On Thu, Aug 13, 2020 at 8:23 PM Murray S. Kucherawy wrote: > On Mon, Aug 10, 2020 at 12:05 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 >> >> The dr

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

On Thu, Aug 13, 2020 at 10:08 PM John Levine wrote: > In article 99yvu0dglz-z19i...@mail.gmail.com> you write: > >> "DISCUSS" shouldn't really be a joke. draft-crocker-dmarc-sender suffers > >from a similar problem as PRA in the SenderId draft. There is no way to > >validate that the specific in

Re: [dmarc-ietf] Firing the vendor

On Fri, Aug 14, 2020 at 2:01 AM Neil Anuskiewicz wrote: > > Wrong answer. If the vendor is uncooperative then fire the vendor. 4-5 > years ago it was difficult to find vendors who were willing to deal with > DKIM and able to do a good job in implementing. The common mantra was "how > does this

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

On Fri, Aug 14, 2020 at 5:21 AM Alessandro Vesely wrote: > On 2020-08-10 7:24 p.m., John Levine wrote: > > In article <2ef8e773e7bf467481a05ab3fc4d9...@bayviewphysicians.com> you > write: > >> Even an external reputation system requires recipient > >> participation. That is why I suggested both

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

On Fri, Aug 14, 2020 at 7:09 AM Douglas E. Foster wrote: > Michael Hammer / Dotzero writes: > > "Earlier in my DMARC journey I felt that MLMs should adjust and send list > mail as themselves. Now I have come to the conclusion that they should > reject list submissions from

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

On Thu, Aug 13, 2020 at 6:53 PM Neil Anuskiewicz wrote: > > > On Thu, Aug 13, 2020 at 2:33 PM Doug Foster 40bayviewphysicians@dmarc.ietf.org> wrote: > >> If I followed Neil’s discussion of MajorCRM: >> >> >> >> The current DMARC architecture supports authorizing a vendor to mail on >> behalf

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

On Fri, Aug 14, 2020 at 10:46 AM Laura Atkins wrote: > > > On 14 Aug 2020, at 09:27, Dotzero wrote: > > Now I have come to the conclusion that they should reject list > submissions from accounts at domains which publish a DMARC policy of > p=reject. Domains should not b

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

On Fri, Aug 14, 2020 at 11:13 AM Kurt Andersen (b) wrote: > On Fri, Aug 14, 2020 at 7:31 AM Dotzero wrote: > >> >> I've been involved in setting up DMARC with a policy of p=reject for >> somewhere North of 6,000 domains. As a sending domain, the heavy lifting is &g

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

On Fri, Aug 14, 2020 at 12:42 PM John Levine wrote: > In article g...@mail.gmail.com> you write: > >policy of p=reject. Domains should not be able to externalize their > >internal problems to others. > > Isn't that exactly the mailing list problem? > No, that is the domains publishing a policy

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

On Fri, Aug 14, 2020 at 1:32 PM Neil Anuskiewicz wrote: > > > On Fri, Aug 14, 2020 at 8:13 AM Kurt Andersen (b) > wrote: > >> On Fri, Aug 14, 2020 at 7:31 AM Dotzero wrote: >> >>> >>> I've been involved in setting up DMARC with a policy of p=r

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

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 they analyze implementation flaws that allow attacks against DMARC in > existing impleme

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

On Sun, Aug 16, 2020 at 11:31 AM Dave Crocker wrote: > > > 2. There was nothing 'established' at that event. There were > interesting discussions, but that's all. > In fact, some of the most interesting discussions took place outside the formal event. > > 3. I'm not finding the reference in an

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

On Sun, Aug 16, 2020 at 2:03 PM Alessandro Vesely wrote: > > >> That conflicts with the coarse-grained authentication strategy, > >> established at the FTC Email Authentication Summit in November > >> 2004, as Doug^W Michael recalled. > > > There was no such strategy established regardless of wha

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

On Sun, Aug 16, 2020 at 2:17 PM John R Levine wrote: > > No, it was just some political theatre. We were already working on SPF > and DKIM. > DKIM didn't exist until that approximate time frame. There was Domain Keys (DK) and there was Internet Identified Mail (IIM) > > > DMARC took that stra

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

On Mon, Aug 17, 2020 at 5:58 AM Alessandro Vesely wrote: > On Sun 16/Aug/2020 20:16:17 +0200 Dave Crocker wrote: > > > > If I put my gmail address into the from field, there is no > > pretending, no matter what platform I am using. > > > That conflicts with the coarse-grain

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

On Mon, Aug 17, 2020 at 8:22 AM Laura Atkins wrote: > > > On 17 Aug 2020, at 12:25, Alessandro Vesely wrote: > > On Mon 17/Aug/2020 11:46:55 +0200 Laura Atkins wrote: > > > The forum page is off the FTC website, but the document links are > still accessible: > > > > A copy is here: > > https://w

Re: [dmarc-ietf] Time for a change

On Sun, Aug 16, 2020 at 3:09 PM Douglas E. Foster wrote: > > The reality is that IETF has mostly provided followership, not leadership, > on matters of security. This forum is replicating history. As has been > mentioned in the historical review, SPF, DKIM, and DMARC were independently > succe

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

On Mon, Aug 17, 2020 at 10:01 AM Laura Atkins wrote: > > > On 17 Aug 2020, at 14:18, Dotzero wrote: > >> >> And, 17 years on, we know that domain level authentication doesn’t >> actually help filter spam nor does it provide law enforcement with a potent >&g

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

On Mon, Aug 17, 2020 at 10:27 AM Dave Crocker wrote: > On 8/17/2020 7:00 AM, Laura Atkins wrote: > > I think the most > useful thing we can say about the FTC workshops is that they were a > forcing mechanism that instigated a lot of effort and innovation in the > space. Some of those efforts fel

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

On Mon, Aug 17, 2020 at 10:37 AM Dave Crocker wrote: > On 8/17/2020 7:33 AM, Dotzero wrote: > > DMARC fixes one thing and one thing only, direct domain abuse. > > > It does no such thing. Domains can still be 'directly' abused in all > sorts of ways that DMARC doe

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

On Mon, Aug 17, 2020 at 2:28 PM Dave Crocker wrote: > On 8/17/2020 11:26 AM, Rolf E. Sonneveld wrote: > >> Michael Hammer (Inaccurately referred to by you as Herr Hammer) > > > > Talking about precise language, Dave, I think you owe Michael an apology > ;-) > > > to mix languages, au contraire.

Re: [dmarc-ietf] Time for a change

On Mon, Aug 17, 2020 at 9:09 PM Dave Crocker wrote: > > DKIM was a synthesis within the IETF of two things (DomainKeys and IIM) > that started outside. It underwent significant evolution in the IETF -- > not once, but twice. > > Actually, it wasn't. > > The constituent parts were separately pro

Re: [dmarc-ietf] DMARC failure scenarios

On Tue, Aug 18, 2020 at 6:49 AM Douglas E. Foster wrote: > You cannot make sense of it, John. I understand the difference between > submssion and SMTP. > > The asserted increase in complexity is not from adding a single signature, > it is the requirement to apply a different signature to every

Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01

On Tuesday, August 18, 2020, Dave Crocker wrote: > On 8/18/2020 12:48 PM, Todd Herr wrote: > >> The race condition here is in item 5, "Emails that fail the DMARC >> mechanism check are disposed of in accordance with the discovered DMARC >> policy of the Domain Owner", specifically when both the S

Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01

On Tuesday, August 18, 2020, John Levine wrote: > In article mail.gmail.com> you write: > >This is just wrong. While I appreciate the enthusiasm for using the Sender > >field, unless there is a mechanism for establishing a relationship between > >the From domain and the Sender domain then we hav

Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01

On Wednesday, August 19, 2020, John R Levine wrote: > On Wed, 19 Aug 2020, Dotzero wrote: > >> If the people you claim don't want the outcome they have as a result of >> the >> DMARC policy that they published then maybe they should publish a >> diffe

Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01

On Wednesday, August 19, 2020, John R Levine wrote: > On Wed, 19 Aug 2020, Dotzero wrote: > >> Then Ericcson as an organization has made a decision regardless of the >> objections of those employees. The correct thing for Ericcson as an >> organization to do is to publish

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

On Thursday, August 20, 2020, Jesse Thompson wrote: > 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

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

On Mon, Aug 24, 2020 at 6:34 PM Douglas E. Foster wrote: > Something seems inconsistent: > > - The people who have implemented DMARC do not see any significant > problems, and as a result they are not interested in a third-party > authorization scheme. > > - Yet adoption is very slow, especially

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

On Tue, Aug 25, 2020 at 5:03 AM Alessandro Vesely wrote: > On Mon 24/Aug/2020 19:24:03 +0200 John Levine wrote: > > In article 8qgy3wky...@mail.gmail.com> you write: > >>> If the intermediary DKIM signs the modified message with their own > >>> signature, that provides some assurance to the rece

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

On Tue, Aug 25, 2020 at 5:48 AM Laura Atkins wrote: > > > On 24 Aug 2020, at 23:34, Douglas E. Foster < > fosterd=40bayviewphysicians@dmarc.ietf.org> wrote: > > Something seems inconsistent: > > - The people who have implemented DMARC do not see any significant > problems, and as a result the

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

On Tue, Aug 25, 2020 at 12:22 PM John R Levine wrote: > On Tue, 25 Aug 2020, Dotzero wrote: > >> https://tools.ietf.org/html/draft-levine-dkim-conditional-00? > > > Under my concept, all mail would still be signed in full. The weak > > signature would be in addition to

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

On Tue, Aug 25, 2020 at 2:13 PM 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 in

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

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 body was to > prevent the signature from being reused. > > > > DF > Not particularly vulnerable. The requirem

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

On Wed, Aug 26, 2020 at 5:00 PM Jim Fenton wrote: > On 8/26/20 10:54 AM, Dotzero wrote: > > > > On Wed, Aug 26, 2020 at 1:32 PM Doug Foster 40bayviewphysicians@dmarc.ietf.org> wrote: > >> Are the weak signatures vulnerable to a replay attack?I thought that

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

> -- > *From*: Jim Fenton > *Sent*: 8/26/20 5:01 PM > *To*: Dotzero > *Cc*: IETF DMARC WG > *Subject*: Re: [dmarc-ietf] third party authorization, not, was > non-mailing list > On 8/26/20 10:54 AM, Dotzero wrote: > > > > On Wed, Aug 2

Re: [dmarc-ietf] Issue submission - Mailing list security and potential solutions using DMARC

This proposal is way outside the scope of DMARC and the scope of the effort for this group. Let's not try to boil the ocean. Michael Hammer On Thu, Sep 10, 2020 at 6:51 PM Douglas E. Foster wrote: > Recently, I have become worried about the risks associated with using my > regular email on this

Re: [dmarc-ietf] Issue submission - Mailing list security and potential solutions using DMARC

On Tue, Sep 15, 2020 at 12:02 PM Joseph Brennan wrote: > > > On Tue, Sep 15, 2020 at 11:55 AM John Levine wrote: > >> In article > bnk2_ckmn...@mail.gmail.com>, >> Joseph Brennan wrote: >> >"Domain administrators must not apply dmarc authentication to domains >> >from which end users send mail

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

On Thu, Sep 24, 2020 at 12:52 PM John Levine wrote: > Personally, I have no interest in defining this stuff but in practice, > there are a lot of places where people are instructed to "implement > DMARC", and it would be nice to encourage them to do more than publish > a lame SPF record and p=rej

Re: [dmarc-ietf] Can we consider some process changes to speed attainment of conclusions?

+1 I'd also like to see calls for consensus rather than a declaration of consensus by the chairs based on posts from a very small minority of the members of the list. Michael Hammer. On Fri, Sep 25, 2020 at 2:01 PM Kurt Andersen (IETF) wrote: > It seems like the chairs have been relatively _la

Re: [dmarc-ietf] DMARC bis: ticket 51: disposition reporting in aggregate reports

On Tue, Sep 29, 2020 at 6:15 AM Alessandro Vesely wrote: > On Tue 29/Sep/2020 05:40:13 +0200 Seth Blank wrote: > > I'm hearing consensus that an aggregate report should retain a > disposition > > of "none" when the dmarc policy is "none", but when the policy is > > quarantine or reject, "pass" sh

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

On Tue, Sep 29, 2020 at 1:26 PM Dave Crocker wrote: > On 9/29/2020 6:40 AM, Hector Santos wrote: > > On 9/27/2020 11:44 PM, Dave Crocker wrote: > > DKIM has a single signature binding requirement, the 5322.From > >> DMARC establishes the relationship. > > I don't read it that way. > > > > DKIM bi

  1   2   3   4   >