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
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
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
: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 origi
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
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,
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
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
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
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
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
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,
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
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 be used on
IM domains that 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
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
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
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
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
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
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
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,
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
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 betw
n 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
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
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
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
and 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>, Do
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
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
:
> 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...@gma
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
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
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
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
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
change 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 publi
r
>
> 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 reputation f
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
,
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> wrote:
>
>>
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:
&g
is 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 confirmed
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
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
Foster
On Fri, Sep 15, 2023 at 7:23 AM Alessandro Vesely wrote:
> On Thu 14/Sep/2023 16:39:49 +0200 Murray S. Kucherawy wrote:
> > On Wed, Sep 13, 2023 at 6:01 PM Douglas Foster wrote:
> >
> >> Our assumed reference model is a fully automated, by-the-spec
> &g
13, 2023 at 5:29 PM Hector Santos wrote:
> On Sep 11, 2023, at 9:24 AM, Dotzero chastised
> Douglas Foster
>
> Absolutely incorrect. DMARC is a deterministic pass|fail approach based on
> validation through DKIM or SPF pass (or if both pass). It says nothing
> about the acce
We are still trying to fix an evaluator problem by changing domain
owner behavior. No harm in giving domain owners the warning, but changing
evaluator behavior would be much better. Presumably, the evaluator
behavior that we have today is the result of RFC 7489 wording, so we may be
able to
ing hole in our security model.
Doug Foster
On Sat, Sep 9, 2023 at 10:22 PM Murray S. Kucherawy
wrote:
> On Sat, Sep 9, 2023 at 11:16 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> I understand the phased roll-out goal, but phased rollout and p
ep 9, 2023 at 12:20 PM Murray S. Kucherawy
wrote:
> I'm not looking to change the WG's mind on this matter, but:
>
> On Sat, Sep 9, 2023 at 3:54 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> There are many percentages mixed up together in this issue
that they
try p=quarantine pct=0, I already know how to filter their current traffic
correctly.
Doug Foster
On Sat, Sep 9, 2023 at 12:20 PM Murray S. Kucherawy
wrote:
> I'm not looking to change the WG's mind on this matter, but:
>
> On Sat, Sep 9, 2023 at 3:54 AM Dougl
I objected strongly to the RFC 7489 language which provides disposition
instructions based on the PCT clause, and still do.
A brief review:
There are many percentages mixed up together in this issue:
- The percentage of domain message sources which provide proper
authentication at
it was not well handled.
Doug
On Mon, Aug 28, 2023, 5:21 AM Alessandro Vesely wrote:
> On Sun 27/Aug/2023 20:49:26 +0200 Douglas Foster wrote:
> > I am much discouraged by the recent discussion about false DMARC PASS
> > based on false SPF PASS or malicious mDKIM replay.
I am much discouraged by the recent discussion about false DMARC PASS
based on false SPF PASS or malicious mDKIM replay. When combined with the
discussion about false DMARC FAIL for mailing lists, it seems like we have
a very unimpressive standards proposal.
We have proposed defending against
don't know that obtaining different information from the domain owner
will fix this.
Doug Fosster
On Tue, Aug 22, 2023 at 11:40 PM Jesse Thompson wrote:
> On Mon, Jul 24, 2023, at 1:03 PM, Neil Anuskiewicz wrote:
>
>
>
> > On Jul 19, 2023, at 3:21 PM, Douglas Foster <
>
I am reluctant to consider DMARCbis ready to button-up unless we have at
least a rough idea of how an evaluator uses it safely and appropriately in
the real world.
Doug
On Sun, Aug 6, 2023, 2:38 PM Scott Kitterman wrote:
> On Sunday, August 6, 2023 2:10:35 PM EDT Hector Santos wrote:
> > >
A nit on whitelisting.
I suggest that we use the term "Alternate Authentication" rather than
"Whitelisting". In my experience, whitelisting often implies exemption
from both authentication checks and content checks.When an
administrator simultaneous disables both types of defenses, his
ent point in
message processing. Additionally, we need to state that, to be considered
minimally useful, an ARC set should include at least MailFrom, From,
SourceIP, and Helo.
Doug Foster
On Mon, Jul 31, 2023 at 2:59 PM Murray S. Kucherawy
wrote:
> On Mon, Jul 31, 2023 at
Does "Trusted Attestation" have any envisioned implementation other than an
ARC Set? Murray has said that we cannot impose obligations on mailing
lists, because he does not perceive them as DMARC participants. But to my
mind, "Trusted Attestation" means that the mailing list SHOULD provide an
the notification that I would want.
Doug
On Mon, Jul 24, 2023 at 11:57 AM Neil Anuskiewicz
wrote:
>
>
> On Jul 23, 2023, at 9:39 PM, Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>
> Neil, this is about whether to block first and ask questions later:
>
I have stumbled into the same position as Barry, or maybe a more extreme
one. I send no bounce messages, and very few 5xx responses.
In my environment, one of the more common causes of non-delivery is a
terminated employee. It has not seemed like automated messages sources
pay much attention
Also, isn’t it best to block first and ask questions
> later to mitigate damage while you investigate? I guess I’m saying the two
> ideas aren’t mutually exclusive.
>
> Neil
>
> > On Jul 15, 2023, at 4:27 AM, Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wro
ated email is likely to be high payback
Doug
On Fri, Jul 21, 2023, 2:53 PM Jan Dušátko
wrote:
>
>
> Dne 21. 7. 2023 v 16:34 Murray S. Kucherawy napsal(a):
> > On Wed, Jul 19, 2023 at 6:31 PM Douglas Foster <
> > dougfoster.emailstanda...@gmail.com> wrote:
> >
It is not at all clear that my goals for this effort match with others, so
I will state mine:
My goal is to develop documents that help evaluators make better
disposition decisions, to save civilization from as much malicious
content as possible. An inference from my piece of reality is that
.
We need to find words in our document that begin to fix this, to obtain the
products and evaluator behavior that we both want and their users need.
Doug
On Wed, Jul 19, 2023, 8:07 PM Dotzero wrote:
>
>
> On Wed, Jul 19, 2023 at 6:21 PM Douglas Foster <
> dougfoster.emails
line is that the domain owner's preference is
of no interest to my filtering decision, but the DMARC result is.
Doug
On Wed, Jul 19, 2023, 8:07 PM Dotzero wrote:
>
>
> On Wed, Jul 19, 2023 at 6:21 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> P
Perhaps you can clarify what you think DMARC is.
Apparently a significant number of evaluators think that "DMARC Fail with
p=reject always means unwanted mail". Or to use Michael Hammer's
language, "DMARC Fail with p=reject means the domain owner wants it
rejected so I will reject it."These
entication to become the norm when the
concept scales upward. Disclosure statements only work when they are not
announcing vulnerabilities.
Doug Foster
On Wed, Jul 19, 2023 at 2:20 AM Murray S. Kucherawy
wrote:
> On Tue, Jul 18, 2023 at 4:27 AM Douglas Foster <
> dougfoster.email
The question was about this list, because Murray has advised that every
specification needs a working prototype. Barry has said that we will not
bloat DMARCbis with advice to mailing lists, but it could be in a companion
document. The topic is closely tied to DMARCbis so there is no other
ganizations started to break
> away from the IETF and RFC7489 in particular.
> You only have to look at the inconsistencies between what is suggested and
> stated in the RFC and what happens in reality to understand why it went
> wrong.
>
>
> Best,
> Olivier Hureau
>
> --
<
devel2...@baptiste-carvello.net> wrote:
> Hi,
>
> Le 15/07/2023 à 12:22, Douglas Foster a écrit :
> > [...]
> > Track 2: Exception Request
> > [...]
> > Track 2 benefits:
> > [...]
> > - Elimination of From munging is potentially availabl
Murray recently observed, correctly, that something went horribly wrong
with the DMARC rollout, because it caused (continues to cause) many safe
and wanted messages to be blocked.
My assessment was in a recent post:
Something about the language of RFC 7489 caused implementers to focus on
We have two tracks that we can pursue for eliminating From munging from
this list: They can be pursued in parallel:
Track 1: Downgrade Request
We identify the small number of domains and subscribers who participate
from p=reject domains, and consequently have their submissions munged.
We
12, 2023 at 6:20 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> Does anyone believe that things will change if we publish an RFC which
>> says "Verizon Media MUST change to p=none"? I don't.
>>
>
> It would be absurd to mak
Does anyone believe that things will change if we publish an RFC which says
"Verizon Media MUST change to p=none"? I don't.
Lists have been hurt by the move to authenticated email. Point taken.
However, the world is not going back to the good old days,.
There is no hope for a list solution to
So we disable SPF when the sender tells us to do so., but leave it enabled
by defaultThat makes a lot of sense to me.
When the domain passes SPF on a shared server farm, but provides no DKIM
signatures, I currently have no choice other than to consider the message
to be authenticated. The
:14 AM Murray S. Kucherawy
wrote:
> On Fri, Jul 7, 2023 at 6:14 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> Malicious impersonation creates a need for authentication. If the list
>> makes changes that disable the originator's authenticatio
Unsophisticated administration will be mediated when/if software developers
make the necessary features available out-of-the-box.
At least one reason that we have undesirable DMARC dispostioning is
software that implements reject-on-fail without a test mode and without a
usable override process.
now that the traffic is wanted and will be accepted. So we need more
than From munging and ARC-derived un-munging. But this combination is a
start.
Doug
On Sun, Jul 9, 2023, 12:27 AM Murray S. Kucherawy
wrote:
> On Fri, Jul 7, 2023 at 6:35 PM Douglas Foster <
> dougfoster.emailstanda...@gmai
Start with the underlying objective:
Evaluators SHOULD accept mailing list traffic.
Google's requirement: Given whatever standards-track DMARCbis rules we
produce, these rules MUST be something that can be fully automated.
Consequently, the problem remains: How does an evaluator distinguish
1 - 100 of 669 matches
Mail list logo
