> On Jun 7, 2024, at 1:14 AM, Richard Clayton wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> In message il.com>, Douglas Foster writes
>
>> Google applies annotation signatures from ..
>> gappsstmpt.com, with periods replaced in the domain name.
>> Microsoft applies proxy s
> On May 8, 2024, at 12:59 PM, John Levine wrote:
>
> According to Mark Alley :
>> -=-=-=-=-=-
>>
>> p=none is one solution, the other ( interoperable method) is to exempt the
>> traffic from whatever process is breaking DKIM (i.e. external subject/body
>> warning tags, URL rewriting, etc.).
> On May 7, 2024, at 6:09 PM, Mark Alley
> wrote:
>
>
>>
>> On 5/7/2024 7:00 PM, Dotzero wrote:
>>
>> https://www.ic3.gov/Media/News/2024/240502.pdf
>>
>> This was released this past week by the FBI. Although we are in last call, I
>> have to wonder if a) the attack itself, and/or b) the
> On May 7, 2024, at 7:19 PM, John Levine wrote:
>
> It appears that Scott Kitterman said:
>>> Addressing this issue - perusing Section 5.5.6, is there anything else
>>> we could add that would be acceptable language in an Standards track
>>> document to encourage urgency behind a transitory
ng systems to SPF.” I said no,
> because that’s unworkable.
>
> It seems to me that until ARC is in widespread use, there will be mail that
> is too important to use p=reject for.
Yes, in fact, if I’m not mistaken the concept of the “general purpose” domain
that’s perpetually p=none came about because of these kind of scenarios. One or
more subdomains set aside for such use cases. It might be just a necessity as
an intermediate step along this journey.
Neil
___
dmarc mailing list -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org
> On Apr 17, 2024, at 6:20 PM, John Levine wrote:
>
> It appears that Todd Herr said:
>> When DMARC was first developed, there was concern about DNS load and
>> needing to minimize DNS lookups. Operational expertise now shows that this
>> is no longer cause for concern.
>>
>> Short circuiti
> On Apr 17, 2024, at 8:29 AM, Alessandro Vesely wrote:
>
> On Wed 17/Apr/2024 15:42:23 +0200 Todd Herr wrote:
>>> On Wed, Apr 17, 2024 at 1:06 AM Scott Kitterman
>>> wrote:
>>> I am confused.
>>>
>>> Under the current (7489) rules a record for _dmarc.c.d.e.f.tld won't be
>>> found either
On Apr 17, 2024, at 6:33 AM, Todd Herr wrote:On Wed, Apr 17, 2024 at 1:18 AM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:On Apr 16, 2024, at 2:18 PM, Todd Herr 40valimail@dmarc.ietf.org> wrote:Colleagues,DMARCbis currently describes the value of 'n' for th
> On Apr 16, 2024, at 2:18 PM, Todd Herr
> wrote:
>
>
> Colleagues,
>
> DMARCbis currently describes the value of 'n' for the 'psd' tag in a policy
> record as follows:
>
> The DMARC policy record is published for a PSD, but it is not the
> Organizational Domain for itself and its subdom
> On Apr 1, 2024, at 2:43 PM, John R. Levine wrote:
>
> On Sun, 31 Mar 2024, Jim Fenton wrote:
>> Based on the above problems, I do not think DMARC-bis should be published as
>> a standards track document by IETF.
>
> This reminds me of the NAT wars in the 1990s. We all understand that DMAR
On Mar 31, 2024, at 12:45 PM, Seth Blank wrote:On Sun, Mar 31, 2024 at 2:00 PM John Levine wrote:It appears that Mark Alley said:
>> People who publish -all know what they do.
>
>I posit that there is a non-insignificant amount of domain owners that
> On Apr 7, 2024, at 6:20 PM, Scott Kitterman wrote:
>
>
>
>> On April 8, 2024 1:02:53 AM UTC, Neil Anuskiewicz
>> wrote:
>>
>>
>>>> On Apr 7, 2024, at 7:00 AM, Neil Anuskiewicz wrote:
>>>
>>>
>>>
>&g
> On Mar 17, 2024, at 9:12 AM, Alessandro Vesely wrote:
>
> On Sun 17/Mar/2024 16:50:40 +0100 internet-drafts wrote:
>> Internet-Draft draft-ietf-dmarc-failure-reporting-10.txt is now available. It
>> is a work item of the Domain-based Message Authentication, Reporting &
>> Conformance (DMARC)
> On Apr 7, 2024, at 7:00 AM, Neil Anuskiewicz wrote:
>
>
>
>> On Apr 7, 2024, at 6:54 AM, Tero Kivinen wrote:
>>
>> Scott Kitterman writes:
>>> I hear you. Your operational issue is my system working as designed.
>>> DMARC works on top
> On Apr 7, 2024, at 9:27 AM, John R Levine wrote:
>
> On Sun, 7 Apr 2024, Neil Anuskiewicz wrote:
>> I think clear statement and supporting text explaining clearly that SPF is
>> no longer the policy layer would be a good idea. While it might be slightly
>> out o
> On Apr 7, 2024, at 6:54 AM, Tero Kivinen wrote:
>
> Scott Kitterman writes:
>> I hear you. Your operational issue is my system working as designed.
>> DMARC works on top of SPF, it doesn't change it.
>
> Yes, DMARC works on top of SPF, and DKIM and provides policy layer. We
> are trying to
Forgive me if this a dumb idea but, Scott and others, any discussion of just
deprecating SPF hardfail at some point?
> On Apr 6, 2024, at 1:40 PM, John Levine wrote:
>
> It appears that Scott Kitterman said:
>> I hear you. Your operational issue is my system working as designed. DMARC
>> w
> On Apr 6, 2024, at 1:40 PM, John Levine wrote:
>
> It appears that Scott Kitterman said:
>> I hear you. Your operational issue is my system working as designed. DMARC
>> works on top of SPF, it doesn't change it.
>>
>> Anything like this belongs in an operational guidance document, no
grok what exactly
they’re supposed to do and why.
Neil
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
concise explanation of the
general purpose domain. It’s not complicated but I think the idea is going to
be new for a lot of people. Some people might misunderstand in less than useful
ways as well.
Neil
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
ity to use CNAME on their own.
> Those who don't are better off not trying it.
It’s mostly ESP’s with large customer bases that ask for CNAMES, providing them
with scalability, and the ability to rotate keys. It’s the appropriate choice
in some contexts. Why is this a concern of the WG?
Neil
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
> On Mar 11, 2024, at 10:38 PM, Neil Anuskiewicz wrote:
>
>
> The solution to that vulnerability is in part use a subdomain and, when
> possible, narrow the scope of what you permit. Better yet, choose a vendor
> that’s known for tight security. A quick Look at the the
> On Mar 4, 2024, at 11:07 PM, Chuhan Wang wrote:
>
>
> Hi Douglas,
>
> Thank you for your insightful summary of our paper. I'd like to share some of
> my opinions.
>
> You mentioned clients lose control of their SPF integrity. It's one of the
> key problems exactly. Clients host their em
Is there any reason to lead with don’t worry about the tag but there is one
critical use case. I think a more declarative statement in favor of the tag for
those who will be stressed and skimming. Sure they might add a psd where it’s
not needed but that’s better than not know the important part:
until threat actors started writing thank you notes.On Tue, Mar 12, 2024 at 1:38 AM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:The solution to that vulnerability is in part use a subdomain and, when possible, narrow the scope of what you permit. Better yet, choose a vendor that’s kn
The solution to that vulnerability is in part use a subdomain and, when possible, narrow the scope of what you permit. Better yet, choose a vendor that’s known for tight security. A quick Look at the the security headlines will show you some vendor red flags. But the sad state of spf is a misleadin
> On Mar 1, 2024, at 5:39 PM, John R Levine wrote:
>
> On Fri, 1 Mar 2024, Seth Blank wrote:
>>> It seems OK but I would say that at this point that mailto: URI are the
>>> only ones currently defined.
>>>
>>
>> Participating, to this point. Throwing out an idea, that may be
>> spectacularly
Well done! This was a technical and quasi political journey and I felt I had
front row seats.
Neil
> On Feb 28, 2024, at 3:05 PM, internet-dra...@ietf.org wrote:
>
> Internet-Draft draft-ietf-dmarc-dmarcbis-30.txt is now available. It is a
> work
> item of the Domai
I’d say extend your thinking on why beyond the format itself. What else could be the cause? On Mar 11, 2024, at 7:33 PM, Neil Anuskiewicz wrote:Wow, the stat on how many domain operators move to enforcing reject policy sans aggregate reports shocked me. Trust the force, Luke.On Feb 28, 2024, at
Wow, the stat on how many domain operators move to enforcing reject policy sans aggregate reports shocked me. Trust the force, Luke.On Feb 28, 2024, at 4:54 AM, OLIVIER HUREAU wrote:Hello,TLDR: I think Dmarcbis should not have reference to the XML format of the aggregate reports in 5.5.3 and only
> On Mar 3, 2024, at 1:41 AM, ves...@tana.it wrote:
>
> Hi,
>
> the last two paragraphs of section 4.1 also show a neat asymmetry between rua
> and ruf. The first sounds like the notification that feedback exists rather
> than something a mail receiver should do. The second is good, but no
> On Feb 29, 2024, at 10:55 AM, Todd Herr
> wrote:
>
>
> Colleagues,
>
> I've been reading DMARCbic rev -30 today with a plan to collect the first set
> of minor edits and I came across a sentence that I believe goes beyond minor,
> so wanted to get a sanity check.
>
> Section 7.6, Domai
Please remove the pct tag from the spec.
> On Mar 9, 2024, at 7:05 AM, Alessandro Vesely wrote:
>
> Hi,
>
> as ADSP is historical, perhaps we can strike A5 entirely. If not, we should
> at least eliminate bullet 5:
>
> 5. ADSP has no support for a slow rollout, i.e., no way to configure
> On Mar 9, 2024, at 7:33 PM, OLIVIER HUREAU
> wrote:
>
>
> >> dmarc-version = "v" equals %s"DMARC1
> > I believe the "%s" should be dropped
>
> 'DMARC1' is case-sensitive in 7489.
> Either we keep the "%s" or we go back to 7489 version : "%x44 %x4d %x41 %x52
> %x43 %x31"
>
> > I think it
Well done! I feel that rough consensus must be close.
> On Dec 2, 2023, at 5:10 AM, Alessandro Vesely wrote:
>
> On Fri 01/Dec/2023 21:06:24 +0100 Steven M Jones wrote:
>> There are only four open items on the issue tracker - though I think the SPF
>> question
>> (https://github.com/ietf-wg-d
> On Nov 12, 2023, at 4:00 AM, Alessandro Vesely wrote:
>
> On Sat 11/Nov/2023 14:57:12 +0100 Neil Anuskiewicz wrote:
>>>> On Oct 23, 2023, at 11:00 AM, Alessandro Vesely wrote:
>>> My opinion is that Barry's text is good as is. As far as delimiting a
&g
> On Nov 11, 2023, at 7:24 PM, Steven M Jones wrote:
>
> On 11/12/23 03:59, Neil Anuskiewicz wrote:
>> What is the definition of rough consensus. That is if you took a vote, 100
>> people voted yes and 3 voted no, the three win? Id there’s a document that
>> stat
eresting
to know what they sent and how it assuaged those worried about the PII.
Eventually, I’d reckon, Yahoo will stop sending failure reports, rendering them
worthless as nobody you’ve heard of will send them. This issue isn’t a five
alarm fire. I f
the data
or send straight up failure reports?
Neil
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
> On Nov 11, 2023, at 11:06 AM, Scott Kitterman wrote:
>
> The short answer is it depends. We don't vote.
>
> Here's the longer answer:
>
> https://datatracker.ietf.org/doc/html/rfc7282
>
> Scott K
>
>> On November 11, 2023 6:59:20 PM UT
On Nov 11, 2023, at 1:21 PM, Dotzero wrote:On Sat, Nov 11, 2023 at 3:45 PM Neil Anuskiewicz <n...@marmot-tech.com> wrote:Michael, I’m realizing I started this discussion thinking we were talking about failure reports and a bit about aggregate reports when I think we might have pivo
On Nov 11, 2023, at 11:56 AM, Dotzero wrote:On Sat, Nov 11, 2023 at 1:47 PM Neil Anuskiewicz <n...@marmot-tech.com> wrote:
The fact that you aren't seeing failure reports doesn't mean they aren't being generated. My experience has been that they are being made available thro
What is the definition of rough consensus. That is if you took a vote, 100
people voted yes and 3 voted no, the three win? Id there’s a document that
states these rules I’d be happy to dig into it. If there’s a rule we should
have a vote. Who is entitled to vote? Like I’m new to this and so it’d
The fact that you aren't seeing failure reports doesn't mean they aren't being
generated. My experience has been that they are being made available through
3rd parties where there is a contractual relationship.
>
> Michael Hammer
> ___
> dmarc mailin
On Oct 25, 2023, at 3:57 AM, Olivier Hureau wrote:
On 25/10/2023 08:10, Steven M Jones
wrote:
It's not so much changing the handling as changing the
reporting.
*
The policy to apply is "none," because the p/sp/np value was
st a few minutes to
avoid dead horse beating that I’m sure is annoying.
Neil
>
>
>> On Mon 23/Oct/2023 10:03:36 +0200 Francesca Palombini wrote:
>> I have been asked by Murray to assist with a consensus evaluation on the
>> discussion that has been going on for a while ab
On Nov 9, 2023, at 6:40 AM, Todd Herr wrote:Colleagues,I note that lately in various email fora that the term "apex domain" has found some favor, said term being used interchangeably with "organizational domain", and having the same contextual meaning as "organizational domain".DMARCbis does not
> On Oct 28, 2023, at 5:01 AM, Alessandro Vesely wrote:
>
> On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote:
>>> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely
>>> wrote:
>>> On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote:
If there isn't a consensus to do a DKIM-only
For routine, remote is perfect but I’d imagine hums leave no doubt in Prague and a chance for rapport to be established. As an observer this proces made me tense and annoyed at time. Myn2 cents is go to Prague. It’s a gorgeous city. This group has a gruff vibe in the tradition of Usenet but our tri
On Oct 29, 2023, at 7:57 AM, Dotzero wrote:On Sat, Oct 28, 2023 at 1:38 PM Barry Leiba wrote:I'm starting this in a separate thread that I want to keep for ONLY
the following question:
Do we want to use the session we have scheduled at IETF 118 to talk
about the issue t
> On Nov 8, 2023, at 8:46 AM, John R. Levine wrote:
>
> On Mon, 6 Nov 2023, Douglas Foster wrote:
>> Since IETF cannot protect its own lists from conspicuous impersonation, it
>> seems poorly qualified to tell anyone else how to do so.
>
> Actually, that message had nothing whatsoever to do w
> On Oct 20, 2023, at 8:43 AM, Alessandro Vesely wrote:
>
> On Fri 20/Oct/2023 15:50:29 +0200 OLIVIER HUREAU wrote:
>> Hi,
>> Assuming that the comma is an Oxford comma, I do interpret the sentence with
>> the following boolean:
>> ( 'retrieved policy record does not contain a valid "p" tag'
On Oct 18, 2023, at 7:24 AM, Todd Herr wrote:On Tue, Oct 17, 2023 at 9:51 PM Douglas Foster wrote:Why do we need to support relaxed alignment at all?A common use case for relaxed alignment is when an organization (e.g., WeSellStuff) employs a third party Emai
On Oct 16, 2023, at 6:48 PM, Neil Anuskiewicz wrote:
>
>
>> On Oct 16, 2023, at 6:43 PM, Seth Blank
>> wrote:
>>
>> I'm sorry, to what are you referring? I co-chair the M3AAWG technical
>> committee, and am unaware of any advocacy for relitigating
See section VOn Oct 16, 2023, at 6:43 PM, Seth Blank wrote:I'm sorry, to what are you referring? I co-chair the M3AAWG technical committee, and am unaware of any advocacy for relitigating DBOUND...On Mon, Oct 16, 2023 at 6:36 PM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:M
On Oct 16, 2023, at 6:43 PM, Seth Blank wrote:I'm sorry, to what are you referring? I co-chair the M3AAWG technical committee, and am unaware of any advocacy for relitigating DBOUND...On Mon, Oct 16, 2023 at 6:36 PM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:M3AAWG is ad
M3AAWG is advocating for DBOUND as most of you likely know. Does it seem a
viable alternative? We could sure use the support of M3AAWG. How could we earn
their support or are they committed to DBOUND?
Perhaps once we prove that DMARCbis works they’ll reconsider.
Neil
> On Oct 16, 2023, at 4:53 PM, Dotzero wrote
> https://www.m3aawg.org/ had sessions on DMARCbis, DKIM replay, etc. at their
> meeting in Brooklyn last week. I did not attend. A number of ISPs, mailbox
> providers, ESPs, etc. participate. I don't see it as something IETF organizes.
>
> Michae
through multiple mediums. I think good articles and videos
will be key.
Neil
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
> On Oct 16, 2023, at 11:00 AM, Scott Kitterman wrote:
>
>
>
>> On October 16, 2023 5:53:13 PM UTC, Alessandro Vesely wrote:
>>> On Fri 13/Oct/2023 16:35:43 +0200 Neil Anuskiewicz wrote:
>>> Thank you, sir. That’s part of the reason to cautiously trans
that these domains want to be treated as organizations, not PSOs, and tbe stop-last Tree Walk will enable what they have been wanting.DougOn Fri, Oct 13, 2023, 1:06 AM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:
> On Oct 10, 2023, at 11:57 AM, Alessandro Vesely <ves...@tana.
thers may find minor variants of this data.Doug FosterOn Fri, Oct 13, 2023 at 7:18 AM Neil Anuskiewicz <n...@marmot-tech.com> wrote:
> On Oct 13, 2023, at 3:59 AM, Douglas Foster <dougfoster.emailstanda...@gmail.com> wrote:
>
>
> The first step in my research has been t
luence your decisions. The low numbers at
this stage make getting the basic data much easier.
Neil
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
I’d say it’s best practice to have a separate policy subdomains. We should encourage it.foo.example.com’s spoofed by one vendor most likely, so switching vendors isn’t too big a task. No need to roll example.com back to none. Just role foo back. It’s clearly a better way to go. Set things up so whe
hack such
as the hosts file for DNS will become largely irrelevant in the big picture,
taking the Internet another step out of childhood toward adulthood. That’s a
good thing even if some things go wrong along the way that need to be fixed or
mitigated. The Internet is a place where the perfect is often more blatantly
the enemy of the good.
Neil
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
From: Dave Crocker
Date: Saturday, August 5, 2023 at 9:49 AM
To: Jesse Thompson , Neil
Cc: Todd Herr , IETF DMARC WG
Subject: Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?
> The language used for DMARC has always been problematic. "Policy"
> implies control
> On Jul 19, 2023, at 3:21 PM, Douglas Foster
> wrote:
>
>
> 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=r
rt of the goal of the 100% authentication effort. I have to depend on content filtering to flag those suspicious actors, and the confirmed attackers will be given a block rule.Doug FosterOn Sun, Jul 23, 2023 at 9:30 AM Neil Anuskiewicz <n...@marmot-tech.com> wrote:Doug, you’ve done a fin
> On Jun 8, 2023, at 4:25 PM, Scott Kitterman wrote:
>
> The data I have seen (and it sounds like Mike is saying the same thing)
> shows DKIM verification results are less than 100%, consistently, for direct
> connections. It was always lower than the SPF pass rate for hosts listed in
> a
Michael,As someone who did work for an ESP, your bit about the conflict between short term cash flow that a short term customer with some money to spend for a few months and the optimizing for customer lifetime value. That war, or shall I say tension, was always there. I’d imagine the little ESP I
Yes sir, I’m convinced. Some of my more conservative customers who take
security deadly serious won’t even bounce a DMARC failure with a helpful
message. It’s discard. I respect the person I’m thinking of who hates bouncing.
He’s appropriately paranoid for a InfoSec manager.
> On Jul 23, 2023,
At a fundamental authentication property level, there are additional differences too. IPs tend to be shared more than private keys. Proving an IP based validation to a third party is harder than with a digital signature. (This is one the issues of trusting the SPF results in ARC-Authentication-R
On Jun 20, 2023, at 11:42 PM, Wei Chuang wrote:On Tue, Jun 20, 2023 at 8:18 AM Scott Kitterman wrote:I am starting a separate thread, because this isn't just about SPF.
I think the criticism of the reliability of SPF data is valid, but I think
DKIM is similarly problemati
> On Jun 30, 2023, at 11:33 AM, Dave Crocker wrote:
>
> On 6/30/2023 11:22 AM, Todd Herr wrote:
>> Why is the mechanism called "Domain-based Message Authentication, Reporting,
>> and Conformance" and not "Domain-based Message Authentication, Reporting,
>> and Disposition"?
>
> Say DMARC out
I hated that concept until I tried it out with a client, a law firm, and they
loved it and I saved them massive headaches. The general purpose we used was a
subdomain just for lists and it’s worked perfectly so far.
I’m now in favor of advocating general purpose domains. Let’s get ESR to put
th
> On Jul 12, 2023, at 3:47 AM, Scott Kitterman wrote:
>
> It's not news that there's a risk for SPF associated with shared IP
> addresses.
> That's why it's in RFC 7208 (11.4) and was in RFC 4408 similarly before.
>
> I understand your view and agree on the problem. I also sympathize with
> On Jul 7, 2023, at 8:48 AM, John Levine wrote:
>
> It appears that Barry Leiba said:
>> I, too, prefer MUST to SHOULD there, but it was clear to me that we
>> will not reach rough consensus on MUST, but that we can reach rough
>> consensus on SHOULD.
>>
>> I do like your suggestion of sil
> On Jul 6, 2023, at 12:04 PM, Barry Leiba wrote:
>
> As I've said before, I think we should specify what we think is right,
> and allow implementers to make their decisions. We can't and won't
> police them.
No way. It wouldn’t be possible even if we all made it our life’s work to be
stand
>>
>>
>
> I think it is a mistake to consider technologies such as SPF, DKIM, and DMARC
> as anti-spam. They are a component of spam mitigation, but authentication of
> an identifier isn't a solution for spam. Meng Wong (for those of you that
> weren't around, he's the one that synthesized
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
> wrote:
>
>
> Murray recently observed, correctly, that something went horribly wrong with
> the DMARC rollout,
> On Apr 15, 2023, at 6:56 AM, Jesse Thompson wrote:
>
>
>> On Fri, Apr 14, 2023, at 10:24 PM, Scott Kitterman wrote:
>> On Friday, April 14, 2023 10:31:33 PM EDT Jesse Thompson wrote:
>> > On Fri, Apr 14, 2023, at 7:17 PM, Murray S. Kucherawy wrote:
>> > > The Sender's users being denied the
ould be one of the established players that gets there first or
it could be an upstart. I think the odds favor one of the better established
players.
Neil
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
market. It could be one of the established players that gets there first or
it could be an upstart. I think the odds favor one of the better established
players.
Neil
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On Apr 15, 2023, at 7:52 AM, Hector Santos wrote:On Apr 14, 2023, at 7:31 PM, Dotzero wrote:On Fri, Apr 14, 2023 at 5:55 PM Hector Santos isdg.net> wrote:Yes, it is simple DeMorgan’s Theorem where you use short-circuiting logic.DMARC says that any FAIL calculated via SPF or DKIM is an overall DM
ty statement. The other versions say relatively the same thing.
>
> - Mark Alley
I think what Mark’s saying isn’t perfect for but I think it can get the rough
consensus we’re seeking. That’s my humble opinion.
Neil
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
> On Apr 15, 2023, at 4:21 PM, Scott Kitterman wrote:
>
>
>
>> On April 15, 2023 10:58:06 PM UTC, Neil Anuskiewicz
>> wrote:
>>
>>
>>>> On Apr 14, 2023, at 8:26 PM, Scott Kitterman wrote:
>>>
>>> Perfect. The
e with the straw men
and especially the red herrings.
Neil
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
> On Apr 14, 2023, at 6:42 PM, Hector Santos
> wrote:
>
> On 4/14/2023 7:31 PM, Dotzero wrote:
>> On Fri, Apr 14, 2023 at 5:55 PM Hector Santos
>> mailto:40isdg@dmarc.ietf.org>> wrote:
>>
>>Yes, it is simple DeMorgan’s Theorem where you use
>>short-circuiting logic.
>>
>>DM
On Apr 14, 2023, at 2:54 PM, Dotzero wrote:On Thu, Apr 13, 2023 at 9:52 PM Barry Leiba wrote:> I don’t think folks are objecting to cautionary language. I think
> folks are objecting to a blanket MUST NOT. If we're going to qualify
> the MUST NOT with a bunch of langua
On Apr 11, 2023, at 9:25 PM, Murray S. Kucherawy wrote:On Tue, Apr 11, 2023 at 8:25 PM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:The standard and the document should reflect that it’s already making a massive difference and could do even more. I don’t think it’s unreasonable
> On Apr 8, 2023, at 6:56 AM, John Levine wrote:
>
> We're never going to persuade DMARC absolutists that the damage is real,
> nor the rest of us that we can wave our hands and ignore the damage.
John, the damage is real. There’s no doubt about that. Trade offs, painful
trade offs, have to b
ic that is pretty impressive. My Gmail accounts have very few problems with either spam getting through or wanted messages getting blocked.I don't have the same content filtering sophistication, so I have ramped up my sender filtering.Doug FosterOn Tue, Apr 11, 2023, 11:15 AM Neil Anuskiewi
> On Apr 11, 2023, at 2:45 PM, Neil Anuskiewicz wrote:
>
>
>
>> On Apr 11, 2023, at 2:29 PM, John Levine wrote:
>>
>> It appears that Neil Anuskiewicz said:
>>> Thanks. Even if it hasn’t always been the case, DMARC has evolved to be
>>>
> On Apr 11, 2023, at 2:29 PM, John Levine wrote:
>
> It appears that Neil Anuskiewicz said:
>> Thanks. Even if it hasn’t always been the case, DMARC has evolved to be
>> thought of by most technical people as focused on security.
>
> I can believe that's t
> On Apr 11, 2023, at 9:14 AM, Mark Alley
> wrote:
>
>
> I agree with where you're coming from, as these were my same concerns as
> well. That's why I also tried to say a couple of times that I feel if we make
> an effort to make clear the interoperability expectations, but also have
> ac
> On Apr 11, 2023, at 4:29 AM, Douglas Foster
> wrote:
>
>
> Neil, I am slowly embracing the position of the Mailing List advocates.
>
> If mailing lists and all other exceptional situations could be eliminated,
> evaluators could mindlessly apply a rule to &quo
> On Apr 10, 2023, at 9:38 PM, Neil Anuskiewicz wrote:
>
>
>
>>> On Apr 10, 2023, at 9:24 PM, Scott Kitterman wrote:
>>>
>>> On Tuesday, April 11, 2023 12:13:33 AM EDT Neil Anuskiewicz wrote:
>>> I’m a bit concerned that the document will
> On Apr 10, 2023, at 9:24 PM, Scott Kitterman wrote:
>
> On Tuesday, April 11, 2023 12:13:33 AM EDT 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 pe
> 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
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
1 - 100 of 147 matches
Mail list logo