cliff once the DKIM TTLs were at
> 24 hours.
>
> This also seems to apply to SPF as well.
>
> - Mark Alley
> On 11/4/2024 5:31 PM, Douglas Foster wrote:
>
> Surprisingly, for email, DNS errors are not rare. I have been collecting
> data from three sources:
>
> - The inc
42 +0100 Douglas Foster wrote:
> > The other problem is that the Tree Walk makes the entire document
> > experimental. Tree Walk is a great tool for batch-mode detection of
> > PSL errors, but it has multiple problems as a real-time tool.
> >
> > - It disa
The other problem is that the Tree Walk makes the entire document
experimental. Tree Walk is a great tool for batch-mode detection of
PSL errors, but it has multiple problems as a real-time tool.
- It disables best-guess DMARC based on default policy. Instead of
disabling best-guess D
4 at 9:05 AM Richard Clayton
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> In message il.com>, Douglas Foster writes
>
> >SPF is designed
>
> for clarity I am not addressing your comments on DKIM in this response
>
> >for the situation whe
When studying indirect mail, I noticed that some forwarders change SPF,
some do not. Some organizations add auth result data and some do not.
Some mailing lists are real and some are gimmicks to distribute spam. The
only way to evaluate correctly is to have a profile for each indirect flow.
Doe
I would observe that Outlook.com evaluates SPF/DKIM/DMARC, documents the
test results, ignores the failed results, and then continues processing.
And it has never registered it's private registries in the PSL (and no one
else can do it for them.)
So I do not include Microsoft in a list of infrast
This is my analysis of what is possible, based on research that I have
been pursuing on this subject for the last few months.
Doug Foster
--
The purpose of Sender Authentication is to confirm that the purported
author of a message, as indicated by the RFC5322.From address, is the
actual author.
or should do to keep
malicious impersonation out of their network. If they choose "p=reject
means malicious" or "I have no idea", then the document has failed.
Doug
On Thu, Oct 24, 2024 at 10:54 AM Murray S. Kucherawy
wrote:
> On Thu, Oct 24, 2024 at 4:34 AM Dou
The necessary first step is to acknowledge that RFC7489 is a heuristic, and
like all heuristics, it will make mistakes. So the interesting work is
determining how to detect and correct mistakes.
>From a security standpoint, authentication is a binary Pass/Fail issue.
There are not 4 types of fa
I can speak from first-hand study of ARC:
1) When present, it is very useful for analyzing complex flows. When it is
not present, I fallback to Results-SPF and Authentication-Results fields.
2) ARC Sets are inserted by some message originators. In general ARC Sets
are used differently by differen
It makes no sense for people who despise DMARC, for its damage to mailing
lists, to sign off on a document that ratifies everything that is
problematic about RFC7489.
The engineering issues are abundantly clear, but have been ignored for too
long.
- The most information that a domain owner can
How many Tree Walk pilot implementations do we have?
How do those implementations handle DNS errors during the Tree Walk?
How do those implementations plan to implement overrides if the Tree Walk
does not return the optimal organizational domain?
How much volume has been evaluated using the Tree Wa
> domain?
>
> It does not. Please refer to the first part of this message.
>
> > Fix these problems, and I will be happy to stop objecting to this
> document.
>
> I may be wrong, but those problems are not part of the Working Group
> charter ?
> C.F Murray's email:
forcing sender authentication has been a huge win to my network
security. DMARC has the right idea, but it takes shortcuts that make it
unsuitable as a general tool. The solution is not to minimize reject
policies, as DMARCbis suggests. The solution is to put effort into
evaluating DMARC results.
D
It is not about fixing the text, it is about fixing the design.
Authentication has only 2 states:
- Authenticated, therefore judged free of impersonation risk
- Unauthenticated, therefore possibly an impersonation and possibly a
malicious impersonation.
The Unauthenticated result can oc
he current document because it misleads in the same way
as RFC7489, calcifying all that was wrong with it
On Tue, Oct 8, 2024, 7:41 AM Alessandro Vesely wrote:
> On Tue 08/Oct/2024 13:14:23 +0200 Douglas Foster wrote:
> >
> > The proper use of DMARC is something that is not fully
About "does it reach this goal?"
RFC7489 provided this outcome:
"A simplistic and fully automated technique that blocks a small but
insufficient subset of malicious impersonation, in exchange for blocking a
small but important subset of legitimate mail."
DMARCbis has this charter:
"A simplistic a
Five years ago, Dave Crocker launched a powerful challenge against DMARC.
I will paraphrase his concepts in this way:
"RFC7489, as typically implemented, causes more harm than good."
Five years ago, I doubted the premise. Today, I substantially agree with
it. Five years ago, much of this grou
024 5:59 PM, Douglas Foster wrote:
>
> We have a significant problem with broken ARC chains, and it is caused by
> email security providers.I think the only way to get the issue
> addressed is to give it visibility, by including an ARC chain verification
> option in the DMARC
We have a significant problem with broken ARC chains, and it is caused by
email security providers.I think the only way to get the issue
addressed is to give it visibility, by including an ARC chain verification
option in the DMARC aggregate reports.
Here is the triggering scenario:
Outlook.c
gt; Are you proposing a text change? Working Group Last Call closed some time
> ago.
>
> On Thu, Sep 12, 2024 at 4:29 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> A DKIM signature acts like a notary public, "This person, who is well
>&g
A DKIM signature acts like a notary public, "This person, who is well known
to me, can be reliably associated with this document."
Signing works for DMARC only when the DKIM signer has actually validated
the entity before adding the signature.
Therefore, when a signature is applied by an outbound
I suspect my experience is typical of many businesses: The most common
target of impersonation is my own domain, by both good and evil actors.
The good guys feel free to impersonate me because they know that they are
the good guys. They assume that I will know that they are the good guys
and wil
Psd=n is the best evidence that the walk has ended in the right place and
that the domain owner has embraced DmarcBis.
Without it, we have swapped one risk for an equivalent one. RFC7489 is at
risk of false alignment caused by missing PSL entries, while DMARCbis is at
risk of false alignment from
ut if we want to stick with SPF alignment for everyone, we need to deal
with the auto-reply problem.
Doug
On Sun, Jun 9, 2024 at 1:32 PM Richard Clayton
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> In message w...@mail.gmail.com>, Douglas Foster
> writes
>
es, so the concept is not likely to scale up But
it works for me.
Doug
On Mon, Jun 10, 2024, 9:55 PM Neil Anuskiewicz wrote:
>
>
> On Jun 7, 2024, at 1:14 AM, Richard Clayton
> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> In message il.com>, D
I would be interested in starting an independent discussion leading to an
informational document about disposition notification.
Rejection can be considered the entry point into a stimulus-response
sequence. The decision to reject is a probabilistic decision with
variable certainty. The origin
On Sun, Jun 9, 2024 at 1:32 PM Richard Clayton
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> In message w...@mail.gmail.com>, Douglas Foster
> writes
>
> >I would be happy to have you or anyone else explain to me
> >(a) What data indicates
sage il.com>, Douglas Foster writes
>
> >Here is an example of the real problem:
> >
> >Example.com is hosted on Outlook.com
> >
> >The user's mailbox is full, so
>
> so hopefully you get a 4xx or 5xx to that effect and your own server
> tells you o
I have 1603 messages from google.com servers that are not signed by the
>From domain. These are all domains other than Gmail.
All but 18 messages are proxy signed with a d= of the form
{domain}.{digits}.gappssmtp.com. At least some of the exceptions are known
to be forwarded messages where a pro
They will, if the client domain provides them with a scope ID and a private
key..
My discussion about null sender is about the many senders that do not or
cannot configure DKIM signing.
On Thu, Jun 6, 2024, 6:02 PM A. Schulze wrote:
>
> Douglas Foster:
>
> > Here is an exam
Google applies annotation signatures from ..
gappsstmpt.com, with periods replaced in the domain name.
Microsoft applies proxy signatures from .onmicrosoft.com
In both cases, the signatures appear to be an assertion by the hosting
service that the message was processed by a particular client of th
Doug
On Mon, Jun 3, 2024 at 1:08 AM Richard Clayton
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> In message il.com>, Douglas Foster writes
>
> >Richard, you miss my point. I know what RFC 7208 says to do with null
> >sender, but we rightly
On Wed, May 29, 2024 at 8:29 AM Richard Clayton
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> In message il.com>, Douglas Foster writes
>
> >Consider the case of an environment with a single server, properly
> >configured with SPF but without
Consider the case of an environment with a single server, properly
configured with SPF but without DKIM:
- Original messages from this server are considered authenticated based
on SPF Pass with alignment, but
- Bounce messages from this server are considered unauthenticated
because mes
The solution is to eliminate the forwarding step. There are many good
reasons why organizations should not allow forwarding to their personal
email accounts. Among other reasons, given that employees are missing
these alarms, it is likely that they are losing other messages also.
But for the b
Huh? The design is fine: check the exact match domain and then move up
to N if more than N labels.
The N applies to both original and secondary walks
I have legitimate messages with exact match on 6 labels, so there is no
reason to disavow the ability to put a policy at that level or to disav
A look at my data was helpful.
Organizational alignment means that N labels match exactly. Relaxed
alignment means that at least one of the names is longer than N.
Those rules are easy to check on my historical data.
I have examples of mismatched domains with 4 matching labels. I also have
e
4, 10:02 AM Todd Herr wrote:
> On Mon, Apr 15, 2024 at 7:58 AM Scott Kitterman
> wrote:
>
>>
>>
>> On April 15, 2024 11:43:08 AM UTC, Alessandro Vesely
>> wrote:
>> >On Mon 15/Apr/2024 13:16:50 +0200 Douglas Foster wrote:
>> >> Our orig
024 13:16:50 +0200 Douglas Foster wrote:
> > Our original choice of N was based on the PSL.The PSL could not
> detect
> > organizational boundaries could not boundaries below level 5, because it
> had no
> > entries longer than 5 labels, and we determined that the 5-label
Our original choice of N was based on the PSL.The PSL could not detect
organizational boundaries could not boundaries below level 5, because it
had no entries longer than 5 labels, and we determined that the 5-label
entries were not used for mail.Therefore, any increase in N is new
capabili
I am concerned that the Tree Walk will have poorer performance and poorer
reliability than implementations based on RFC 7489
The boundary between organizational domains and their registries is very
stable, which is why it is highly suitable for a static reference like a
locally-implemented PSL.
We can complain about people treating SPF Fail as definitive, but DMARC
perpetuates the very same myth, which is:
“If Sender Authentication test X produces FAIL, then the message is
malicious and should be blocked.”
It does not matter whether "X" is SPF Fail, DKIM Fail, ADSP Fail, DMARC
Fail, or
Sender reputation is in use everywhere. What is lacking is an omniscient
data source, but I have no hope of finding one. Small senders will always
be at a disadvantage because sender reputation is entirely based on past
experience, and smaller senders have less experience to draw upon. ARC
doe
Murray, I was hoping your proposal to advance ARC was serious.
Google has solved the problem of limited ARC deployment. To my mind, this
means that we cannot revoke the experiment and we cannot do much to change
it, so we might as well advance it to standards track. It became a
de-facto standard
In response to Ale's comment that we describe the mailing list problem
without defining a path forward, I suggest the text below.
Doug Foster
Some legitimate messages are sent on behalf of an individual account, based
on an established relationship between the sender and the account owner,
but w
As a concept, DMARC is a powerful tool for detecting and blocking malicious
senders.
As a document it does much less. DMARCbis perpetuates the known problems
in RFC 7489, thereby ensuring a continuation of negative outcomes.
Both documents define an imaginary evaluator who follows the senders ad
On SPF, our document should say simply,
" a DMARC-compliant evaluator MUST NOT reject a message, based on SPF
result, prior to receiving the Data section and checking for aligned and
verifiable signatures."
Of course, evaluators may still reject early base on known-bad server or
known-bad Mail Fro
But if we have no advice on how to detect a false Pass, how is this
useful? Are we helping evaluators or just giving ourselves cover that
"your disaster is not our fault because we warned you"?
On Sun, Mar 17, 2024, 10:59 AM Scott Kitterman wrote:
>
>
> On March 17, 2024 11:11:04 AM UTC, Aless
DMARC is an imperfect tool, as evidenced by the mailing list problem, among
others. DMARCbis has failed to integrate RFC7489 with RFC 7960, because it
provides no discussion of the circumstances where an evaluator should
override the DMARC result. I believe DMARCbis needs a discussion about the
a
Wed, Mar 13, 2024 at 6:24 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> My unsuccessful attempt to implement to the specification has reminded me
>> of my past concerns.
>>
>> Our document gives primacy to the Tree Walk, as if it will b
are in the sub1.example.com subtree (including exact
match or child)
DF
On Wed, Mar 13, 2024, 7:18 AM Alessandro Vesely wrote:
> On Wed 13/Mar/2024 11:23:43 +0100 Douglas Foster wrote:
> >
> > The reality is that the Tree Walk is an inefficient and unreliable way of
> > ob
My unsuccessful attempt to implement to the specification has reminded me
of my past concerns.
Our document gives primacy to the Tree Walk, as if it will be used on every
>From domain, SPF domain, and DKIM domain. The Tree Walk algorithm is
explained in detail before any discussion of how it is
Neil, to your question about mitigating false SPF PASS:
There are three possible mitigations by senders:
- Drop the SPF policy so that messages evaluate to SPF None. A few
domains do this.
- Change the SPF Policy to return SPF Neutral for cloud services, as
currently proposed.
-
I have been building a DMARC implementation, starting with a simple
function:
TreeWalk(domain) which returns:
- Policy found or not found indicator
- Policy Domain
- Organizational Domain
- Policy record
My thought was that the Tree Walk result was independent of the domain
identifier
Both of these statements seem unnecessarily weak, bordering on apologetic.
5.3.General Record Format
PSD ("n")
."... There is no need to put psd=n in a DMARC record, except in the very
unusual case of a parent PSD publishing a DMARC record without the
requisite psd=y tag."
11.8 Determination of t
unrelated recipients suffer the consequences. The
wrong people take the hit.We need to provide a way to mitigate the harm
caused by unjustified trust in SPF.
Doug
On Thu, Feb 29, 2024, 1:29 PM Scott Kitterman wrote:
>
>
> On February 29, 2024 6:15:37 PM UTC, Benny Pedersen wrote
I am surprised at the lack of feedback about Barry's research link. It is
a devastating attack on our ability to trust SPF when shared infrastructure
is involved. As a result of that document, I have switched camps and
believe that we MUST provide a DKIM-only option for DMARC.
The proposed wor
I have been thinking about the other way that an attacker could have two
>From addresses: by having two From headers.Not a problem as long as
the evaluator rejects the message based on standards violation.
But what if the evaluator does not test for dual headers because the
configuration is s
The volume of current attacks should not be a consideration, and
speculation about future risks is vacuous. The industry routinely raises
C.V.Es against newly discovered and not-yet-exploited security holes, and
we should act the same way.
The evidence from Google is that multi-valued From DOES
I see no conflict.
A domain with DMARC enforcement asserts that it sends only authenticated
messages. Since multiple-From messages cannot be fully authenticated,
such messages are inconsistent with the domain owner's stated practices
Therefore, the domain owner's published Failure disposition re
Even in the unlikely event that all From addresses can be authenticated
with DKIM, the result still cannot be trusted. It would be easy for an
attacker to anticipate signatures that will be added in transit, and use
those signatures to create false authentication.
RFC 7489 treats a multiple-doma
Ale is right, the document needs to address the problem.
I agree with Google that multiple-From has no important use-case, and
therefore a wise evaluator should simply reject the message. For the same
reason, I believe the RFC5322.bis group should have deprecated the
feature.But since that i
Assume this RFC5322 header:
From: user@attackdomain, presid...@whitehouse.gov
For messages like this:
- Verifying one identity (e.g. "user@attackdomain") does nothing to say
that the unverified identity is used with authorization.
- Technical issues mean that it will be rare, nearl
As with the mailing list problem, when the recipient expects authentication
but the sender cannot provide it, the sender is disadvantaged.
Nor an I concerned about the limitations of a particular MSA product.
However, we know that mailing list posts almost always start as authorized
messages, so
The purpose of DMARC is to demonstrate that the purported author (From) is
either the actual author or the authorized agent of the actual author.
Because of practical difficulties, this is an indirect process: DMARC
PASS demonstrates that a specific sending domain is authorized to speak on
behal
Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> If this implied solution was working, we would not have a mailing list
> problem 10 years running.
>
>
>
> On Thu, Nov 23, 2023, 10:41 AM Dotzero wrote:
>
>>
>>
>> On
If this implied solution was working, we would not have a mailing list
problem 10 years running.
On Thu, Nov 23, 2023, 10:41 AM Dotzero wrote:
>
>
> On Thu, Nov 23, 2023 at 10:19 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> The gap between
does not even try.
Doug Foster
On Wed, Nov 22, 2023 at 5:58 PM Seth Blank wrote:
> Is there a point to this thread, that affects the text in the DMARCbis
> document under charter criteria?
>
> Seth, as Chair
>
> -mobile
>
>
> On Wed, Nov 22, 2023 at 07:13 Douglas Foster
RFC 7489 and DMARCbis are written as algorithms without exception
conditions. That silence leads product developers and mail administrators
to conclude that the algorithm can be implemented without allowing for
exceptions. Why would we expect a different result?
Withheld information can deceive
I reviewed the list of DMARC-publishing PSL entries and realized that the
10-fold increase in PSL DMARC participation was due to the success of RFC
9091. Private registries are deploying policies to protect their
sub-registry clients.
It is indeed unfortunate that concerns about PSL accuracy were
MUST NOT or SHOULD NOT make little difference. Both are the Crocker
Proposal revived and simplified: "The solution to authentication problems
MUST be LESS AUTHENTICATION!"If you can convince nearly all senders to
use p=NONE, and if you can convince nearly all evaluators to enforce only
when
, server operators are the most important part of this
protocol.
Doug
On Tue, Nov 14, 2023, 7:07 AM Richard Clayton
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> In message j...@mail.gmail.com>, Douglas Foster > writes
>
> >Our document needs a
Our document needs a section on server controls.
Impersonation requires a server that allows impersonation messages to be
created.This means that impersonation usually comes from attacker-owned
servers. Legitimate infrastructure services should, and usually do,
implement controls which preven
Axioms:
(1) Most lists are legitimate
(2) Mailing list posts have characteristics that make them readily
distinguishable from other traffic.
Charter Goal: The protocol will cause Evaluators to accept mailing list
posts without From munging (as long as the list is a legitimate operator)
The first
tes:
> > On Sun, Oct 29, 2023 at 12:35 PM Douglas Foster <
> > dougfoster.emailstanda...@gmail.com> wrote:
> >
> > By contrast, the new tag cannot be effective until DMARCbis is
> published
> > and filtering software updated. This involves years. Even the
it's
solution needs to be laid out in our document because I am one of those who
did not understand it as a possible strategy
Doug
On Sun, Oct 29, 2023, 2:03 PM Richard Clayton
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> In message f...@mail.gmail.com>
I have become persuaded to Scott's approach, as long as it is documented
clearly.
For DMARC-enabled evaluators:
- auth=DKIMOnly requires that the domain owner have high confidence that
every message source is applying DKIM signatures.
- ?include=hostingservice only requires knowledge tha
Like Ale, I thought the group had agreed to implement an auth=DKIM-only
option of some type.
I understood the motivation to be false pass created by malicious
forwarding through a legitimate hosting platform. Therefore SPF precision
is an unrelated issue.
Doug
On Thu, Oct 26, 2023, 5:46 PM Ter
:
> On Tue, Oct 24, 2023 at 5:34 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> In short, I am not part of the presumed consensus on this document. I
>> will vigorously oppose any document which does not discuss malicious
>> impersonation defen
nd make their own
determination of intent, blocking messages with malicious intent and
allowing acceptable messages.
Doug Foster
On Tue, Oct 24, 2023 at 11:30 PM Murray S. Kucherawy
wrote:
> On Tue, Oct 24, 2023 at 5:34 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com&g
My working assumption is that this document, if approved, will be the last
statement, for a long time to come, on matters of sender authentication and
malicious impersonation defenses. That assumption raises the question,
"Is this the best possible statement of how to defend against malicious
imp
Offlist
Do you support the notion that DMARC evaluation is only possible if a
record is found?
Doug Foster
On Fri, Oct 20, 2023, 11:16 AM OLIVIER HUREAU <
olivier.hur...@univ-grenoble-alpes.fr> wrote:
> Hi,
>
> > The correct solution is that the person responsible for creating the
> problem re
Then, Seth, I am confused.
We have a non-trivial number of PSL entries that have DMARC policies which
either specify relaxed alignment or specified nothing and acquired relaxed
alignment by default. Are these organizations that have been victimized
by PSL errors, or are the PSLs that are enablin
Why do we need to support relaxed alignment at all?
When a domain is suddenly harmed by a PSL error, the necessary fix is to
implement same-domain policies with same-domain signatures. The
appropriate technique to prevent that problem, before it happens, is
exactly the same configuration. This
Neil, this is a delayed reply to your earlier email about my implementation
efforts, and whether I am on-board with the Tree Walk. The response has
been delayed while I investigated the algorithm.
I began by building a cache of DMARC policies using the PSL and my mail
stream as input.
The first
2023 at 7:18 AM Neil Anuskiewicz
wrote:
>
>
> > On Oct 13, 2023, at 3:59 AM, Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
> >
> >
> > The first step in my research has been to do DMARC policy lookups on the
> PSL domains About 400 of
Tue 10/Oct/2023 19:16:10 +0200 Todd Herr wrote:
> >>> On Tue, Oct 10, 2023 at 6:14 AM Alessandro Vesely
> wrote:
> >>> On Tue 10/Oct/2023 00:19:56 +0200 Douglas Foster wrote:
> >>>> Both approaches have problems. Stop-at-last enables the walk to
> e
Great question. On Feb 23rd, I had this exchange which John settled:
It appears that Douglas Foster said:
>-=-=-=-=-=-
>
>I seem to have missed this redesign. I thought the plan had always been
>to take the top-most policy not flagged as PSD=Y.
The current design has been
200 Douglas Foster wrote:
> > Attached it is a spreadsheet with the problems from my data set.
>
> I see no blocking. For example, the list shows From: bayer.com,
> d=crm.bayer.com, the latter deemed blocking. Both domains feature a
> DMARC
> record and (unsurprisin
ange to an inferior trust state.
Whether the best number is 7% or 7.9%, the error rate is too high to ignore.
Doug
On Sat, Oct 7, 2023 at 10:00 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Attached it is a spreadsheet with the problems from my data set. If it
Attached it is a spreadsheet with the problems from my data set. If it is
dropped during the forwarding process, let me know and I will re-post it in
the body of the message.
The WG needs to prove that "The Tree Walk will cause no significant
disruption".We should have understood that trying
:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> In message hgv...@mail.gmail.com>, Douglas Foster com> writes
>
> >So initially, I am asking for a compsrison between my results and
> >the data used to justify the asserted consensus.
>
> if you publishe
Chair
>
> On Fri, Oct 6, 2023 at 19:49 Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> I have only recently implemented all of the tools needed to be able to
>> test PSL vs Tree Walk.
>>
>> I looked at messages which had passed reputat
I have only recently implemented all of the tools needed to be able to test
PSL vs Tree Walk.
I looked at messages which had passed reputation filtering and content
filtering, to isolate messages where DMARC alone could be determinative.
Within that group, 75% of the messages did not need tree wa
ad already promised to go away,
but then I felt Barry misrepresented my perspective, and then you responded
to the group twice.
Doug Foster
On Sun, Sep 17, 2023 at 6:20 PM Murray S. Kucherawy
wrote:
> On Sun, Sep 17, 2023 at 2:47 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com>
For those who have implemented to the specification, "No Result" means
"Content Filtering must carry the whole load," which it cannot do. So I
reject the notion that "No Result" is harmless.
Doug Foster
On Sun, Sep 17, 2023 at 5:29 PM Murray S. Kucherawy
wrote
the DMARCbis and reporting documents and get them published.
>
> Barry
>
> On Sat, Sep 16, 2023 at 6:56 AM Douglas Foster
> wrote:
> >
> > Yes, I suspected awhile back that I was the only one in the world
> implementing mandatory authentication. This group has confirm
Yes, I suspected awhile back that I was the only one in the world
implementing mandatory authentication. This group has confirmed it.
But I hold out hope thst others will see the opportunity that it provides.
Perhaps someone will read my Best Practices draft and sponsor it as an
individual contr
malicious senders.
Doug Foster
On Wed, Sep 13, 2023, 9:32 PM Richard Clayton
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> In message czy...@mail.gmail.com>, Douglas Foster com> writes
>
> >The coverage problem is aggravated if we assume rational at
1 - 100 of 710 matches
Mail list logo
