Re: [dmarc-ietf] Weakening of enforcement concern

> On Apr 10, 2023, at 9:13 PM, Neil Anuskiewicz wrote: > > I’m a bit concerned that the document will discourage domain owners from > working toward an enforcing policy. I’ve seen at least one person say that > most domains don’t need to go to p=reject. I’ve seen all s

[dmarc-ietf] Weakening of enforcement concern

will receive the most attention but threat actors absolutely do attack all sorts of organizations all the time. Maybe I’ve misunderstood but I hope that no langue that could be construed as discouraging domain owners from moving toward an enforcing policy would be a mistake. Neil

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

> On Apr 9, 2023, at 6:33 AM, Jesse Thompson wrote: > >  >> 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]* domai

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

any further discussion on this thread. >>>>> >>>>> I reviewed the thread and I think this is the closest we got to anything >>>>> (most) people agreed on. I know not everyone liked it, but I doubt >>>>> we're >>>>> going to get closer to a consensus on this. >>>>> >>>>> Can we adopt this and move forward on to the next thing? >>>>> >>>>> Scott K Yes, I think so. I get the feeling you possibly think it’s text that isn’t going to make much of an impact but presumably it’ll at least make a difference at the margins? The margins can grow as others see the benefits. I don’t know. Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

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

t of them.Doug FosterOn Wed, Apr 5, 2023 at 4:14 AM Neil Anuskiewicz <n...@marmot-tech.com> wrote:I’m with Doug on this one. The bandage should be pulled off quickly and sympathy expressed to those who miss backward compatibility. I wouldn’t say utilitarianism is the right frame but here why woul

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

lp. But at the end of the day, when there are so many people and personalities a small percentage of them seem to want to do everything the hard way. To each their own.NOn Wed, Apr 5, 2023 at 4:14 AM Neil Anuskiewicz <n...@marmot-tech.com> wrote:I’m with Doug on this one. The bandage should be

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

I’m with Doug on this one. The bandage should be pulled off quickly and sympathy expressed to those who miss backward compatibility. I wouldn’t say utilitarianism is the right frame but here why wouldn’t it be morally right not to mention technically sound to inconvenience and anger the few to crea

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

On Mar 29, 2023, at 7:25 PM, Murray S. Kucherawy wrote:On Thu, Mar 30, 2023 at 11:01 AM Douglas Foster wrote:Someone please explain to me why everyone should make themselves more vulnerable to ransomware and other attacks so that mailing lists can avoid being

Re: [dmarc-ietf] Justifying DMARC authentication and handling exceptions

audience. So I have an interest in a standards document that’s as clear and explicit as possible. As complicated as it needs to be and no more. This probably goes without saying.I’d like to see more of what you just did which moved the ball forward, IMO.NeilOn Fri, Nov 25, 2022, 3:46 PM Neil

Re: [dmarc-ietf] Justifying DMARC authentication and handling exceptions

to create a general solution rather than a > local-policy solution, and (2) failing to provide an alternative to "same > organization" as the meaningful Sir, your knowledge of this domain is clearly deeper than I could ever achieve so it’s with deep respect that I acknowledge th

Re: [dmarc-ietf] Security considerations - Aggregate reports

On Nov 15, 2022, at 7:11 PM, Douglas Foster wrote:General:For a reporting specification, the Security Considerations are by definition any risks of unwanted information disclosures.   So that is where attention needs to be given.Operational experience:  I don't have specific knowledge of the info

Re: [dmarc-ietf] Not Multiple From: mailboxes, was I-D Action: draft-ietf-dmarc-dmarcbis-24.txt

On Nov 24, 2022, at 7:10 AM, Dotzero wrote:On Tue, Nov 15, 2022 at 12:29 PM Douglas Foster wrote:Your solution is straightforward, but I am not sold.DMARC PASS means that the message is free of author impersonation.  This can only be true if all authors are v

Re: [dmarc-ietf] Missing participation from big tech members

Foster, you seem to be suggesting a game theory model. The calculus of decision maker doesn’t necessarily align with what’s good for the group and chips away at their own self interest in a slower, less obvious manner. So you seem to be suggesting that incentives could be adjusted t

Re: [dmarc-ietf] Standardizing signature contents

is on about the 30 yard line so let’s get it across the line. Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Standardizing signature contents

> On Oct 29, 2022, at 10:35 AM, Dotzero wrote: > > On Sat, Oct 29, 2022 at 1:30 AM Neil Anuskiewicz wrote: > > >> >> DMARC’s job is to flat out prevent unauthorized spoofing. It’s not a >> stretch to imagine some higher signature standard without feeli

Re: [dmarc-ietf] Standardizing signature contents

> On Oct 27, 2022, at 10:46 PM, Murray S. Kucherawy wrote: > >  >> On Thu, Oct 27, 2022 at 4:16 PM Douglas Foster >> wrote: > >> Murray raised the issue of a signature which produces PASS, but lacks trust >> because it is constructed with weak coverage, such as omitting the Subject >> or

Re: [dmarc-ietf] Standardizing signature contents

> On Oct 27, 2022, at 4:16 PM, Douglas Foster > wrote: > >  > Murray raised the issue of a signature which produces PASS, but lacks trust > because it is constructed with weak coverage, such as omitting the Subject or > including an L=valuie clause. > > DKIM was designed to be flexible so

Re: [dmarc-ietf] Standardizing signature contents

realistic or even a good idea for this group to come to a working consensus on DMARC not accepting half assed DKIM signatures but it’s worth thinking about. Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Weak signatures

Instead, the result is noted but the evaluation continues in > hopes of finding an aligned and verified strong signature. > Strong defined as the strength of the encryption algorithm (i.e., key size). I’m sorry if you already defined and I missed it. Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result

> On Oct 19, 2022, at 5:42 PM, Neil Anuskiewicz wrote: > >  > >> On Oct 19, 2022, at 6:59 AM, Scott Kitterman wrote: >> >>  >> >>>> On October 19, 2022 12:44:16 PM UTC, Dotzero wrote: >>> On Tue, Oct 18, 2022 at 11:18 PM Scott

Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result

> On Oct 19, 2022, at 6:59 AM, Scott Kitterman wrote: > >  > >> On October 19, 2022 12:44:16 PM UTC, Dotzero wrote: >> On Tue, Oct 18, 2022 at 11:18 PM Scott Kitterman >> wrote: >> >>> >>> >>> On October 18, 2022 10:1

Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result

> On Oct 2, 2022, at 11:01 AM, Douglas Foster > wrote: > >  > In many cases, an evaluator can determine a DMARC PASS result without > evaluating every available identifier. > If a message has SPF PASS with acceptable alignment, the evaluator has no > need to evaluate any DKIM signatures

Re: [dmarc-ietf] Issue 2

There’s a small typo: A policy search is used to determine the applicable DMARC policy, and where applicble, the organizational domain to be used for relaxed alignment. Replace applicble with applicable. > On Oct 12, 2022, at 5:18 PM, Douglas Foster > wrote: > > A policy search is used to de

Re: [dmarc-ietf] dmarcbis-16 - some minor corrections

On Fri, Sep 9, 2022 at 7:46 AM Todd Herr wrote: > On Thu, Sep 8, 2022 at 9:24 PM Neil Anuskiewicz > wrote: > >> To clarify, these aren’t the changes from a week ago but for the whole >> document this time. Sorry for the top post. >> >> On Sep 8, 2022, at 4:

Re: [dmarc-ietf] dmarcbis-16 - some minor corrections

On Fri, Sep 9, 2022 at 7:46 AM Todd Herr wrote: > On Thu, Sep 8, 2022 at 9:24 PM Neil Anuskiewicz > wrote: > >> To clarify, these aren’t the changes from a week ago but for the whole >> document this time. Sorry for the top post. >> >> On Sep 8, 2022, at 4:

Re: [dmarc-ietf] dmarcbis-16 - some minor corrections

To clarify, these aren’t the changes from a week ago but for the whole document this time. Sorry for the top post. > On Sep 8, 2022, at 4:10 PM, Neil Anuskiewicz wrote: > >  > I went ahead and committed my changes. I hope these small changes are > helpful. > > Neil

Re: [dmarc-ietf] dmarcbis-16 - some minor corrections

I went ahead and committed my changes. I hope these small changes are helpful. Neil On Sat, Aug 27, 2022 at 9:12 PM John R Levine wrote: > If you're feeling really enterprising you can do a github pull request, > but sending the suggested changes to this list is fine. > > On

Re: [dmarc-ietf] dmarcbis-16 - some minor corrections

ject any of it. How exactly would I submit my proposed changes? Thanks. Neil On Sat, Aug 27, 2022 at 7:14 PM John Levine wrote: > Thanks, we can always use more proofreading. I'll put those in the next > pull request. > > > It appears that Neil Anuskiewicz said: > >-=

[dmarc-ietf] dmarcbis-16 - some minor corrections

and practices are having, they are *more* willing and able to use quarantine and reject policies. 7. Changes from RFC 7489 says: This section will summarize *thos* changes. It should say: This section will summarize *those* changes. Thanks. Neil __

Re: [dmarc-ietf] Time to work on failure reporting

> On Aug 13, 2022, at 9:10 AM, John R Levine wrote: > > redac...@yyy.zzz I think it’s good to be as clear and explicit as possible. The word redaction, in general, explicitly states what you’re trying to accomplish. And the reader might be able to more efficiently visually parse explicit exa

Re: [dmarc-ietf] Collecting message metadata, was Time to work on failure reporting

> On Aug 9, 2022, at 3:17 AM, Ken O'Driscoll > wrote: > >  >> >> >> Any hint about why it's not used? >> > > PII. Report generators are reluctant to send reports that may contain PII for > compliance, security, and privacy reasons Most receivers don’t provide failure reports but sometim

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-10.txt

f us observing the process can feel confident about the ultimate outcomes. And a side effect is that observers can learn the technical aspects and observe the process in real time. Good work! Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] fall back

sed to find an org > domain when the exact-match policy is not present, and to find the subtree > scope for relaxed alignment when relaxed alignment is specified. > >> On Tue, May 3, 2022, 12:54 AM Neil Anuskiewicz >> wrote: >> Currently, receivers must use the policy pub

[dmarc-ietf] fall back

Currently, receivers must use the policy published by a subdomain before falling back to the organizational domain policy (i.e., must choose the first record found). Under the new standard, receivers would discard policies, continuing to the next level up. So how would you handle the existing subd

Re: [dmarc-ietf] Additions to draft - Security Considerations

On Apr 24, 2022, at 8:57 PM, Scott Kitterman wrote: > > For cases where strict alignment is not appropriate, this issue can be > mitigated by periodically checking the DMARC records, if any, of PSDs above > the organization's domains in the DNS tree and (for legacy [RFC 7489] checking > that app

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

On Mon, Aug 17, 2020 at 1:00 PM Luis E. Muñoz wrote: > On 14 Aug 2020, at 12:47, Neil Anuskiewicz wrote: > > Under 50% of companies have any DMARC record. Of those who deploy > > DMARC, > > about ~2% have p=quarantine and ~5% p=reject, though some industries > > s

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

On Fri, Aug 14, 2020 at 11:15 AM Dotzero wrote: > > > 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

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

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=reject for >> somewhere North of 6,000 domains. As a sending domain, the heavy lifting is >> in getting buy-in across the or

Re: [dmarc-ietf] Firing the vendor

> On Aug 13, 2020, at 3:09 PM, Douglas E. Foster > wrote: > >  > Yours is the better answer! > > DF > > > Original message > From: Dotzero > Date: 8/13/20 5:54 PM (GMT-05:00) > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ? > > > >> On

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

On Thu, Aug 13, 2020 at 2:33 PM Doug Foster wrote: > If I followed Neil’s discussion of MajorCRM: > > > > The current DMARC architecture supports authorizing a vendor to mail on > behalf of their clients if the client includes them in their SPF policy or > delegates a DKIM scope to them and they

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

On Thu, Aug 13, 2020 at 12:21 PM Dotzero wrote: > > > 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 ab

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

er of all things) at a company or some other efficient arrangment to be able to make changes in applications, update DNS, test, monitor. Here, there's this dept with control of the CRM, another for marketing, another controls DNS, and a vendor says something isn't possible. My point

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

> On Aug 7, 2020, at 12: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 >> understan

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

On Wed, Aug 12, 2020 at 6:32 AM Dave Crocker wrote: > On 8/12/2020 6:23 AM, Neil Anuskiewicz wrote: > > IETF are more relaxed than I expected. > > Don't believe it. The advice was warranted. > > Well, it's good to mostly lurk for a while as a courtesy unless and u

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

On Wed, Aug 12, 2020 at 6:04 AM Dave Crocker wrote: > On 8/12/2020 5:55 AM, Neil Anuskiewicz wrote: > > > > > > On Wed, Aug 12, 2020 at 5:13 AM Dave Crocker > <mailto:d...@dcrocker.net>> wrote: > > > > On 8/12/2020 4:45 AM, Neil Anuskiewicz wrote

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

On Wed, Aug 12, 2020 at 6:04 AM Dave Crocker wrote: > On 8/12/2020 5:55 AM, Neil Anuskiewicz wrote: > > > > > > On Wed, Aug 12, 2020 at 5:13 AM Dave Crocker > <mailto:d...@dcrocker.net>> wrote: > > > > On 8/12/2020 4:45 AM, Neil Anuskiewicz wrote

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

On Wed, Aug 12, 2020 at 5:13 AM Dave Crocker wrote: > On 8/12/2020 4:45 AM, Neil Anuskiewicz wrote: > > Mr. Crocker, is there a document that describes some of these proposals > > and perhaps the best arguments for an against somewhere? The firehose of > > learning would

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

Mr. Crocker, is there a document that describes some of these proposals and perhaps the best arguments for an against somewhere? The firehose of learning would a bit easier if there were a FAQ. I think it might even help the participants if this was all documented. Yes, I know there's the archived

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

record 56% none 34% quarantine 1% reject 9% F500 DMARC Adoption DMARC Policy 10/18/2019 no record 49% none 37% quarantine 4% reject 9% ASX DMARC Adoption DMARC Policy 10/18/2019 no record 59% none 33% quarantine 1% reject 7% On Sat, Aug 1, 2020 at 12:57 PM Neil Anuskiewicz wrote: > I look

<    1   2