Re: [dmarc-ietf] 3.2.6. Non-existent Domains

It is a relief to finally have this topic open for discussion. The issues go deeper than null MX. The goal is to domain names that the domain owner never uses for RFC5321.From addresses. No direct test exists, so there are two candidate substitutes: - (Relaxed:) A name is rejected if it does

[dmarc-ietf] Best Guess SPF should not be deprecated.

I have multiple objections to this paragraph in section 5.7.2 "Heuristics applied in the absence of use by a Domain Owner of either SPF or DKIM (e.g., [Best-Guess-SPF ]) SHOULD NOT be used, as it may be the case

Re: [dmarc-ietf] Additions to introduction

sender authentication failure when the probability of a true impersonation has reached a high value. I think this assumption should be made explicit somewhere in the document. Doug Foster On Sat, Dec 4, 2021 at 1:52 AM Murray S. Kucherawy wrote: > On Fri, Dec 3, 2021 at 6:16 PM Douglas Foster

[dmarc-ietf] Additions to introduction

I propose that a paragraph along these lines be inserted into the introduction: The DMARC test is characterized by a one-tailed error distribution: Messages which pass verification have a low probability of being false positives of actual impersonation. When a recipient intends to exempt a

Re: [dmarc-ietf] UNCOL and Reversing modifications from mailing lists

Have you noticed the ARC set on Alex Brotman's messages? Microsoft declares the message as having passed DMARC before the message leaves the Office 365 environment. Assume that the average attacker decides to do the same, and applies a DMARC-PASS ARC Set to everything he sends. At minimum,

Re: [dmarc-ietf] Reversing modifications from mailing lists

If you are evaluating messages, you are free to use any strategy that seems worth your effort. However, if you are the sender of messages that cannot produce DMARC PASS, you have a bigger problem. You need an algorithm which can be trusted to usefully distinguish between malicious and

Re: [dmarc-ietf] Minutes from IETF 112

e: > On Thu, Nov 18, 2021 at 8:11 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> >> Do we want to provide a sub-tree alignment option? >> >> Suppose that “security.example.edu” does not want any other part of “ >> example

Re: [dmarc-ietf] Minutes from IETF 112

Consensus on Tree Walk? A comment in the minutes suggested that consensus was forming around Tree Walk for Policy Discovery. I do not have that impression. Instead, the "strongly favor" and "strongly oppose" voices seem about equal, with the balance determined by those who, like myself, are

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

About your proposal to encourage silent discard: I'm sorry that we have not provided any feedback.Feeling ignored or shunned by the group is worse than having an idea rejected. For my part, I am a skeptic of your proposal. The best outcome would be for the evaluator to perform all

Re: [dmarc-ietf] Organizational Alignment Options

Back to Scott's original comment and Ale's skepticism: Is it feasible that DNS flags could provide a less-bad replacement for the PSL, or will it be just a different and maybe even less-reliable mess? If most are not under contract, how can we hope to get cooperation? Does the leadership or

Re: [dmarc-ietf] Organizational Alignment Options

the org-domain of the > 5322.From domain and for this, with the help of the PSL, that would be 2 > DNS requests, do I miss a very important use case for DMARC that is not > solved by these 2 querys? > > > > *Von:* dmarc *Im Auftrag von *Douglas Foster > *Gesendet:* Donnerstag

Re: [dmarc-ietf] Organizational Alignment Options

of DNS non-participation. Can someone explain the private/public distinction in the PSL list? What does the distinction mean as it relates to the four email-related attributes that I have listed? Doug On Thu, Nov 4, 2021 at 4:34 AM Alessandro Vesely wrote: > On Thu 04/Nov/2021 04:09:37 +0100 D

Re: [dmarc-ietf] Organizational Alignment Options

Ale asks: Hm... but PSDs don't seem to gain any extras by letting receivers know they're a PSD, do they? I think they do. They get the benefits of name protection which DMARC previously afforded only to organizational domains and subdomains, which I would expect them to consider very

Re: [dmarc-ietf] Organizational Alignment Options

Foster On Wed, Nov 3, 2021 at 1:23 PM John Levine wrote: > It appears that Douglas Foster > said: > >-=-=-=-=-=- > > > >Correct, but you cannot query _dmarc.host1.domain because host1 is not a > >DNS domain, even though it can be a mail sender and receiver >

Re: [dmarc-ietf] Organizational Alignment Options

November 3, 2021 2:49:03 PM UTC, Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >Type=A, name=host1, domain=a.b.c.d e.f.example.com > > > >Assuming that we will be walking the top n levels, it is only an issue on > >long domain names. > >

Re: [dmarc-ietf] Organizational Alignment Options

sure I understand what you mean by resource record names that is > not a DNS domain. > > Scott K > > On November 3, 2021 10:53:07 AM UTC, Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >The tree walk should address whether we do anything for domain-pa

Re: [dmarc-ietf] Organizational Alignment Options

The tree walk should address whether we do anything for domain-part names that are resource record names rather than DNS domains. Such names cannot be given a _dmarc. subdomain, so they cannot be given an exact-match DMARC policy. Always doing a one-level walk from the bottom would ensure that

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

Currently, the Publicssuffix.org list protects the PSL names. Although I don't believe it is covered anywhere in the DMARC v1 document, any DMARC implementer will have to notice that a PSL name must produce DMARC FAIL, because it cannot be authenticated itself, and it cannot be authenticated by

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

To my mind, it is crazy talk to assert that DMARC is not an authentication method. My bank's phone app gives me the option of authenticating with either a username+password or a fingerprint. For remote access to work computers, I use two authentication methods together. Using two component

Re: [dmarc-ietf] same old org domain, Topic for IETF 112 - Policy Discovery

John said I don't immediately see the utility of the org domain of the HELO unless you're checking SPF on a bounce, but why wouldn't you do the same tree walk? Apparently he has never evaluated the reputation of server organizations by aggregating data based on server organization. It is a

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

DMARC is an authentication test also. The authentication of the first identifier (SPF or DKIM) serves as a proxy to authenticate the second identifer (FROM), which is conditioned on a satisfactory relationship (equal or aligned) between the two domains. You began to address the issue in your

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

We have two issues floating here: 1) For policy lookup, replace the PSL with a constrained tree walk. 2) For authentication testing, replace the PSL with something based on the policy lookup. Currently, the DMARC policy has nothing to do with the authentication test. If the second idea is still

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery -- PSL Replacement using DNS Flags

I enthusiastically endorse John's proposal for policy discovery. But as stated previously, I do not see that it provides a viable mechanism for eliminating the PSL as an alignment tool. To address that part of the problem, I submit my proposal for migrating from the publicsuffix.org list to DNS

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

PSL entries are imputed with four important characteristics: - name not valid for MAILFROM - name not valid for FROM - name not valid for DKIM - name not valid as an alignment point for mismatched names. For non-PSL names, the reverse is assumed by default - any name is valid for any of these

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

John's idea is workable for policy lookup, but the PSL is also used for alignment and to protect the PSL names. Alignment starts by finding the longest shared DNS path between two addresses. The resulting string must be longer than any PSL entry, to verify that the names are in the same

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

I was surprised to see that #111 and #112, about the definition of NP, survived to be included in this policy discussion. I remain strongly opposed to an NP policy based on A//MX.A brief recap: - A non-existent domain test should be based on a DNS query that returns NXDomain, not NODATA.

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

For me, the appeal of a tree walk would be to eliminate the PSL. But an artificially constructed domain name could have more than 100 segments, so walking the entire tree seems like an opportunity for denial of service attacks. If we walk up from the bottom and quit too soon, a phony but long

Re: [dmarc-ietf] DMARC variations

What is meant by "slow entry" in the title? Does it mean that non-compliant messages will be throttled with 4xx temporay failure result codes? On Sun, Oct 24, 2021, 10:51 AM Alessandro Vesely wrote: > Hi all, > > this proposal by some German mailbox providers sounds interesting: > > >

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

As Scott eloquently said, we are not the Internet Police.We need to produce a document that responds to RFC 7960 in the context of DMARCbis. The best that we can do is lay out the options, and let the senders, list operators, and receivers make their choices. We need to move away from

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

Scott writes "True, but SMTP and the body From are unrelated." He is correct, and it is exactly why I have been so upset that the group embraced an SMTP-derived (SPF-precursor) rule to test for a non-existent value of the RFC5322.From address. Doug ___

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

, Oct 14, 2021 at 12:48 AM Murray S. Kucherawy wrote: > On Tue, Oct 12, 2021 at 4:42 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> Under a collaboration solution, the subscriber goes to her email support >> and says,"I joined list X, and

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

S. Kucherawy wrote: > On Tue, Oct 12, 2021 at 4:42 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> Under a collaboration solution, the subscriber goes to her email support >> and says,"I joined list X, and they say that for the best user exp

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

e the original > > From: without validating the author's domain signature, just because > > they trust the MLM. By collecting similar techniques, we might be able > > to cover almost all cases while still ensuring deliverability. > > > > > > Best > > Ale

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

>From a security perspective, Ale's proposal is flawless. But I don't like solutions that make the recipient bear most of the costs of the list's actions. Unmunging creates a high cost of entry for new domains: Under a collaboration solution, the subscriber goes to her email support and

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

t; techniques, we might be able to cover almost all cases while still > ensuring > deliverability. > > > Best > Ale > > > > On Tue 12/Oct/2021 04:40:12 +0200 Douglas Foster wrote: > > Barry, you did a nice job of talking me off the ledge. > > > > If thi

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

o set up a mailing list which doesn't > modify the message in ways likely to make DKIM fail. Almost no one bothers > to do so despite pressures resulting from widespread use of DMARC p=reject. > >> > >> Operators do not need to justify anything to us. We are not the > internet police.

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

and there's no evidence > that it's likely to change. > > Scott K > > On October 9, 2021 7:39:36 PM UTC, Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >I would be pleased to see a document which explains why lists MUST or > >SHOULD alter con

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

I would be pleased to see a document which explains why lists MUST or SHOULD alter content.After more than 2 years following this discussion, no reason for this practice has ever been documented. Content changes would be easier to justify if subscribers granted authorization to modify as part

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

as the stalker does not have the real email address of his target. In the absence of such measures, the best defense is to use a separate email address for each list in which one participates. Doug Foster On Sat, Oct 9, 2021 at 12:35 PM Grant Taylor wrote: > On 10/9/21 6:05 AM, Douglas Foster wr

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

ing or evaluator-specific rewrite decisions, ARC has failed at its original purpose. Doug Foster On Fri, Oct 8, 2021 at 1:02 AM Benny Pedersen wrote: > On 2021-10-08 02:47, Douglas Foster wrote: > > Assume the following: > > > > List "L" has implemented ARC a

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

I don't understand your user experience argument, because the proposed UX would be very different from the current UX. Nor do I think that security should be compromised for user convenience. But I am ready to withdraw the proposal. The substantive argument is the problem of trust in list

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

Assume the following: List "L" has implemented ARC and has subscribers from 10 domains, Domain through DomainJ. A user from DomainA, which publishes p=reject, submits a post to the list. What information does List "L" use to decide whether to rewrite "From", for each of the 10 domains? How is

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

will still need 100% From-munging, unless there is out-of-band communication between the evaluator and the list. Doug On Thu, Oct 7, 2021 at 5:06 AM Alessandro Vesely wrote: > On Thu 07/Oct/2021 00:32:30 +0200 Douglas Foster wrote: > > I can define three ways that a list can be

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

My proposal provides a unique, permanent, user-selected alias which can be used as a valid email address as long as both sender and receiver are still subscribed to the same list. When they want to switch over to actual email addresses, they use the member-to-member alias communication to

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

"Bad idea" is a subjective term, and irrelevant. The purpose of technical standards is not to get somebody elected, it is to define solutions to problems. The critical question is whether a proposal provides the best available solution to a problem. I wonder if the mailing list community is

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

research is requested before the first message is sent, we escape the pattern of watching things break and then doing damage control. Doug Foster On Wed, Oct 6, 2021 at 5:20 AM Baptiste Carvello < de...@baptiste-carvello.net> wrote: > Hi, > > I'll just make a few quick point

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

users > delisted. > > 2) DMARC incorporates its own reporting mechanism, which goes to the > right place. > > Once DMARC-compliant receivers do this, mailing list operators can > remove their workarounds and happily get out of the way. Messages would > be lost at first, but DMARC

[dmarc-ietf] DMARC-Compliant Mailing Lists

-fosterd-dmarc-compliant-mailing-lists-00.txt To: Douglas Foster A new version of I-D, draft-fosterd-dmarc-compliant-mailing-lists-00.txt has been successfully submitted by Douglas Foster and posted to the IETF repository. Name: draft-fosterd-dmarc-compliant-mailing-lists Revision

Re: [dmarc-ietf] Experiments

Stated another way, the problem with ARC is that it requires the evaluator to attribute a positive reputation to the forwarder, in a context where even identifying the forwarder can be difficult. Most email is accepted on a much weaker criteria - the absence of negative reputation. Mailing

Re: [dmarc-ietf] Experiments

ation? On Fri, Sep 24, 2021 at 2:59 PM John Levine wrote: > It appears that Douglas Foster > said: > >-=-=-=-=-=- > > > >The Zoho situation is an interesting application of ARC. The forwarders > >are not altering the messages, so if the DMARC-enforcing domain

Re: [dmarc-ietf] Experiments

The Zoho situation is an interesting application of ARC. The forwarders are not altering the messages, so if the DMARC-enforcing domain was configured with signatures, their messages would have passed DMARC at the final destination. Without the signature, they should have been blocked already.

Re: [dmarc-ietf] Experiments

For messages sent from Office365, Microsoft applies an initial ARC set, and declares the message to be DMARC-compliant.I do not think Microsoft should be passing judgement on messages that it is originating, or attributing an SPF result to a message that was only just submitted with SMTP AUTH.

Re: [dmarc-ietf] Proposing p=validate, another DMARC improvement to better support indirect mail flows

Benny said: "At present, I DKIM sign outgoing mail, but since p=none, the recipients are unlikely to find the DKIM signatures particularly helpful." On the contrary, it helps evaluators. A well-authenticated message might be eligible for whitelisting, and will never be blocked based on sender

Re: [dmarc-ietf] Round Two: Ticket #66 (Define What It Means to Have Implemented DMARC) and #62 (Reporting a MUST)

I am not concerned about defining an acceptable DMARC implementation, but I am concerned about making implementations successful.,My four-way partition is a framework for talking about the obstacles to success: - Domain owners have trouble knowing whether they are ready for p=reject because

Re: [dmarc-ietf] Round Two: Ticket #66 (Define What It Means to Have Implemented DMARC) and #62 (Reporting a MUST)

For evaluators, the implementation discussion could be structured by the degree of information shared with senders: - No sharing Recipient uses DMARC for its own disposition decisions only. Scope elements include: Ability to process a PSL on a recurring basis Ability to apply DMARC policy to

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

On the subject of PCT, we did not reach agreement, we reached silence. Silence comes across as a move by the majority to silence dissenters. The chairs are empowered to decide whether this is an appropriate tactic by the majority, and whether a majority or supermajority is a sufficient

Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion

Thu, Aug 5, 2021 at 4:22 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> PCT could work IF evaluators are willing and able to send a Temporary >> Error result (probably 451), instead of a permanent error, when >> - a DMARC ver

Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion

Alessandro writes in defense of PCT Assume a sender has some feedback mechanisms, such as 5yz SMTP replies, delivery notifications, return receipts or web-based actions. This sender sends transactional messages, but is concerned about authentication errors that happen in an apparent

Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion

nst the goal of the evaluator and his user base. It is too high a price to pay. On Sun, Aug 1, 2021 at 5:13 AM Alessandro Vesely wrote: > On Sun 01/Aug/2021 01:47:12 +0200 Douglas Foster wrote: > > > > My core objection is the partial-enforcement algorithm. I cannot > bel

Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion

>From munging can be a de-facto standard, but I don't think it can ever obtain IETF endorsement. As far as I can tell, IETF has never endorsed BATV or SRS, or any other encoding scheme which lengthens the local-part of the address. I expect >From munging to encounter the same obstacle. We have

Re: [dmarc-ietf] not enhanced status codes Some Proposed Language for a New pct Tag Defintion

2.6.0 really is a mystery to me. The domain under study uses p=reject and is getting 100% authenticated in the RUA reports, so it does not fit John's theory. I always get 2.6.0 from outlook.com servers and a few other destinations. So perhaps it is just their version of "OK so far, but I may

Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion

Ale, I understand your concern but I don't know that it can be solved. My core objection is the partial-enforcement algorithm. I cannot believe that it would be wise for me, or any other receiver, to implement that algorithm. However, DMARCv1 was written with a presumed requirement for

Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion

This language addresses my original concern. You have a typo at this point: ... cases, in can result in... and of course it should read ...cases, it can result in... Since PCT is being removed, I would like to provide something for domain owners that are struggling to complete implementation

Re: [dmarc-ietf] From: munging, was Ratchets - Disallow PCT 1-99

> > Ale said: > "ARC is not a part of DMARC, despite the acronym being a substring." Is this really true? Some time ago, the chairs said that ARC was the candidate solution to the mailing list problem, and that DMARCbis would not fly without a mailing list solution. More recently, we seem to be

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

Barry's comment: I don't agree with the characterization of the second group. I would say that we are partitioning messages into these two groups: - Those for which we can confirm that they originated in the domain they say they did. - Those for which we can not confirm that. When we use

Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99

ity than P=NONE. Domain owners that want to block mailing list messages would eventually switch to "strict", which is the same as our current P=REJECT. Doug Foster On Tue, Jul 13, 2021 at 2:10 PM Todd Herr wrote: > On Tue, Jul 13, 2021 at 7:03 AM Douglas Foster < > dougfoster.e

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

. "Pct=50" fails because it presumes that partial participation is possible, and it presumes that a message evaluator will be willing to use a random number generator to decide message fates. Doug Foster Doug Foster On Fri, Jul 16, 2021 at 7:24 PM Jim Fenton wrote: > On 15 Jul 2021, at 18:0

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

> > We can and should provide an intermediate policy option, if we concentrate > on the principle that both authentication and repudiation require > confirming evidence. Repuudiation is not the simple opposite of > authentication. To this date, our choices have been limited because > DMARCv1

Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99

Thank you. I will review it. On Tue, Jul 13, 2021, 2:10 PM Todd Herr wrote: > On Tue, Jul 13, 2021 at 7:03 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> I understand that under the current specification, PCT has been useful >> because P

Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99

I understand that under the current specification, PCT has been useful because P=NONE with PCT=100 produces different results than QUARANTINE with PCT=0. This is an anomaly that I would hope we can fix, but if not, we need to specify that the only valid settings are PCT=0 or PCT=100. The

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

into the evaluation algorithm, and Alessandro's request for a partial implementation between NONE and QUARANTINE. Doug Foster On Sun, Jul 11, 2021 at 3:32 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > If we are willing to break upward compatibility, it might be preferable to

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

If we are willing to break upward compatibility, it might be preferable to define policy in terms of what the sender knows, rather than what the receiver should do. After collecting feedback, the sender should know whether all message sources are sending with SPF PASS, DKIM PASS, or both. This

Re: [dmarc-ietf] Ticket #112 - Authentication vs. Repudiation.

What is so hard to grasp'? "Treated in a manner that is consistent with the reputation of the responsible party" means that "the message is safe to whitelist if whitelisting is desired." I was not saying that DMARC=PASS was a basis for whitelisting. I said that DMARC=PASS and a trusted

[dmarc-ietf] Ticket #112 - Authentication vs. Repudiation.

DMARC is very effective for message authentication. DMARC PASS allows preferred handling to be applied without fear of spoofing. For example: If DMARC=PASS and RFC5322.FROM ends with “EXAMPLE.COM” they Bypass Tests ( “Spam Scoring”, “Attachment Restrictions” ) (Curiously, I had trouble

Re: [dmarc-ietf] Ticket #111 (and #112) - Proposed language

gt; craft a sample message, sample envelope, and sample DNS context that > highlights the problem you're talking about? Maybe then it'll snap into > focus. > > On Wed, Jun 16, 2021 at 2:43 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> NXDomain

Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language

Yes, The test should most certainly define how MX="." and SPF="-ALL" affect the test. This is why I said that the test needs a more complete definition, but many were unwilling to even address that part of the problem. Even with those modifications, the test is only applicable for names that are

Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language

lighting here. > > I think you've expressed yourself primarily in the abstract. Could you > craft a sample message, sample envelope, and sample DNS context that > highlights the problem you're talking about? Maybe then it'll snap into > focus. > > On Wed, Jun

Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language

You or the others seem to be confusing NXDOMAIN on RFC5321.MailFrom lookup with NXDOMAIN on RFC5322.FROM. The issues are very different. NXDomain on the MailFrom lookup says neither the SPF policy nor the SMTP domain exist, and therefore there is no reverse path. Rejecting such messages makes

Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language

e problems understanding your proposal. Let me > quote > what seems to hamper my comprehension. > > Besides, #11 in the Subject: is obviously a typo. > > > On Sat 12/Jun/2021 14:55:33 +0200 Douglas Foster wrote: > > ties the design directly to the mailing list pro

Re: [dmarc-ietf] Ticket #111 (and #112) - Proposed language

(Subject ticket number corrected.) Michael, I am surprised and disappointed by the severity of your critique. NP Policy - The NP policy is upon us. PSD for DMARC demonstrated the need.The problem is that their definition of NP, which the current DMARCbis draft inherits, is a

[dmarc-ietf] Ticket #11 (and #112) - Proposed language

Below is my proposed language for dealing with the problems that NP is intended to address: - unused DNS names - non-existent DNS names It provides supporting rationale, and provides a more complete solution than anything suggested previously, and ties the design directly to the mailing list

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

omain owner simply needs a way to provide an "existent" signal without affecting other functions. TXT seems like the appropriate way to do this. Doug Foster On Tue, May 25, 2021 at 3:39 PM Murray S. Kucherawy wrote: > On Sun, May 23, 2021 at 12:25 PM Douglas Foster <

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

Murray, here is some data: (I only receive IP4 data and my tool did not check ) Sample size: 3643 messages from 780 unique From domains 611 domains (78%) passed validation using DMARC criteria (DMARC policies were not checked) 599 of 611 (98%) DMARC-verified domains also had MX or A

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

o data submitted on either test rule, so it is not yet a distinguishing characteristic. I think I can build filters to begin collecting that data, but my data set is relatively small. Doug Foster On Tue, May 18, 2021 at 2:19 AM Murray S. Kucherawy wrote: > On Mon, May 17, 2021 at 10:19 PM Douglas Fos

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

Then please explain yourself, John. On Tue, May 18, 2021 at 12:28 PM John Levine wrote: > It appears that Murray S. Kucherawy said: > >-=-=-=-=-=- > > [ various things ] > > I have reread this ticket and found nothing actionable, and a lot of > misconceptions aboout how the DNS works. > >

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

ic RR types for allow or block signals. It is simple to define and simple to implement. Doug Foster On Fri, May 7, 2021 at 5:43 PM Murray S. Kucherawy wrote: > On Thu, May 6, 2021 at 8:14 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> My argu

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

ists. However, the use of placeholder data may have unpredictable effects on subdomain reputation. On Fri, May 7, 2021 at 5:43 PM Murray S. Kucherawy wrote: > On Thu, May 6, 2021 at 8:14 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> My argument

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

e. On Fri, May 7, 2021 at 5:43 PM Murray S. Kucherawy wrote: > On Thu, May 6, 2021 at 8:14 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> My argument is that that A//MX has no useful relevance to determining >> whether the RFC5322.FROM add

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

quirements on the domain owner. New requirements should be stated quite explicitly. On Fri, May 7, 2021 at 3:06 PM Murray S. Kucherawy wrote: > On Thu, May 6, 2021 at 5:02 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> I have begun data co

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

y 6, 2021 at 11:13 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> This is about >> Section 3.8. Non-existent Domains >> >>For DMARC purposes, a non-existent domain is a domain for which there >>is an NXDOMAIN o

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

PM Seth Blank wrote: > On Thu, May 6, 2021 at 18:47 John Levine wrote: > >> It appears that Douglas Foster >> said: >> >My perception has been that NDRs are widely ignored even when they are >> >sent. Is your experience different? >> >> Yes. We

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

and found a mail domain that Ford Motor actually uses. On Thu, May 6, 2021 at 6:32 PM Jeremy Harris wrote: > On 05/05/2021 12:28, Douglas Foster wrote: > > Non-delivery reports are officially discouraged > > RFC 5321 Section 6.2 says the reverse. >

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

causes. On Thu, May 6, 2021 at 6:32 PM Jeremy Harris wrote: > On 05/05/2021 12:28, Douglas Foster wrote: > > Non-delivery reports are officially discouraged > > RFC 5321 Section 6.2 says the reverse. > > -- > Cheers, >Jeremy > > _

[dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

The MX/A/ test is an appropriate tool for verifying the probable existence of a return-path based on the RFC5321.MailFrom address. In the early days, the requirement to send and receive non-delivery reports meant that all mail systems had to participate bi-directionally. This is no longer the

Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

of complexity in their report generation process, and privacy advocates do not want to facilitate this level of tracking. Is there a case to be made that disaggregation is a non-issue? On Mon, May 3, 2021, 8:14 PM Murray S. Kucherawy wrote: > On Mon, May 3, 2021 at 5:26 AM Douglas Fos

Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

t; address (VERP). Are you suggesting that no DMARC reports should be sent for > commercial bulk mail? > > laura > > > > On 3 May 2021, at 12:21, Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > > To address Laura's concerns about individual target

Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

To address Laura's concerns about individual targeting, the reporting needs to ensure a minimum level of aggregation on all reports. This starts with MailFrom. If less than N unique recipient addresses are included, the report should not be sent at all If a DKIM selector occurs on less than N

Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

John, your logic is circular. The only way that Matthäus can know if he objects to what you are doing with his message is to monitor what you are doing with his message. It is also irrelevant. Data privacy is pretty thoroughly lost, notwithstanding GDMR's efforts to fight the system. It seems

[dmarc-ietf] Ticket #108 - Definition of NP

I suspected that the current language is the best that we have, but it is far from an algorithm. Below are the algorithm details that I would expect should be addressed. The dilemma - If we mandate more detailed checks, we add complexity which hurts throughput. - If we take no position, we hinder

[dmarc-ietf] Ticket #60 - definition of NP

There is much to like about the new document. Thank you to the design team for your good work. For the NP policy, the MX/A/AAA test lacks the precise definition that I would expect to be required for a standards-track document. Does another document have language that we can use or reference?

<    1   2   3   4   5   6   7   >