We do not currently plan to request a DMARC session for IETF 120 in
Vancouver, and expect to finish up on the current documents on the
list (expect a new document revision soon).
Barry, as chair
___
dmarc mailing list -- dmarc@ietf.org
To unsubscribe
I agree. This is not a substantive issue, but is simply correcting an
oversight. SHOULD NOT was the consensus call, and the correction Todd
proposes is just making that sentence consistent with that.
Enough said on this; Todd, please just add this change to your other
editorial changes.
Barry,
Maybe better?:
NEW
If they can block outgoing or reply DNS messages, they can prevent
systems from discovering senders' DMARC policies. Recipients will
then use their local policies for handling mail in the absence of
DMARC and will not be able to take the senders' policies into account.
END
This document is also ready for our final look, so this message starts
a working group last call for the aggregate reporting document, with
the same timing as for the DMARC spec.
Please post to the DMARC mailing list by 31 March, giving your last
call comments (which should include “I read it and
The editors and chairs think version -30 resolves the open issues and is
ready for a final look, so this message starts a working group last call
for the DMARCbis spec. Because of the upcoming IETF 119 meeting, we’ll let
this go until the end of March, so there’s lots of time to review.
Please
A paper was presented this morning at NDSS about the state of SPF, which is
worth a read by this group:
https://www.ndss-symposium.org/ndss-paper/breakspf-how-shared-infrastructures-magnify-spf-vulnerabilities-across-the-internet/
Barry
___
dmarc
The sense I’m getting is to cancel the session in Prague. I’ll do that
tomorrow (Thursday) morning SFO time unless someone screams loudly with a
convincing reason that we need to keep the session.
Barry
On Sat, Oct 28, 2023 at 10:38 AM Barry Leiba
wrote:
> I'm starting this in a separ
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 that clearly is still in discussion about adding a tag
to specify which authentication mechanism(s) to use when
> > * Is there consensus on moving ahead with the idea of a way to indicate
> > which authentication method(s) the Domain Owner wants Receivers to use? If
> > so, it doesn't seem to be in the document yet.
>
> My recall is that we want to limit DMARC evaluation to DKIM only, for the edge
> cases
DMARC is a protocol that uses a published DNS record to advertise a
sending domain's policy. It's described in RFC 7489 and the DMARCbis
draft.
What anyone does in the absence of a published DMARC record is *not*
part of DMARC, in the same way that use of FTP to deliver email is not
part of
Now that we have a consensus call on the main issue that has remained open:
1. Do we need to retain our session at IETF 118 and discuss this (or
something else) further?
...or...
2. Do we have what we need to finish up the DMARCbis document, and
should the chairs cancel the session at 118?
Oh,
Thanks for that, Scott. For what it’s worth, i have sympathy for your
position, both as a participant and as chair. I do, though think that what
we have now or something like it is the only way we will get rough
consensus, that the other option is not to publish DMARC as a standard, and
that
> The point of the Tree Walk was to detect and prevent the problems caused by
> PSL errors.
The point of the tree walk was twofold:
1. To eliminate the PSL in DMARC, as the PSL was not designed to be
used by DMARC and has problems in its application to DMARC as a
result.
2. To provide a
Thanks for that, Todd!
Alex, if you want to post a new revision before I start a WGLC, I'll wait
for that.
Barry
On Wed, Sep 27, 2023 at 3:07 PM Todd Herr wrote:
> On Wed, Sep 20, 2023 at 3:56 PM Brotman, Alex 40comcast@dmarc.ietf.org> wrote:
>
>> Hey folks,
>>
>> It feels like we're
Thanks for this, Alex. I will start a working group last call on this
late next week, so if anyone knows of a reason to hold off on that,
please post something by next Wednesday, 27 September. Of course,
issues can be raised during WGLC, so
Barry
On Wed, Sep 20, 2023 at 12:56 PM Brotman,
Indeed. Besides content filtering there could be knowledge that the
message came from a mailing list, there could be ARC or another
mechanism of that nature, there could be knowledge of the sending
domain and its user base, there could be knowledge of the specific
recipient and her preferences,
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 contribution or experimental draft.
>
> Doug
>
>
> On Fr
> Content filtering creates a need for whitelisting
> Any domain may require whitelisting, regardless of sender policy.
> Whitelisting is only safe if it is coupled with an authentication mechanism
> which prevents impersonation.
> Therefore, sender authentication, by a combination of local
Apart from "never finish", I would contend that changes of that nature
violate the "preserve interoperability with the installed base of
DMARC systems" clause of our charter. We *can* make changes such as
this if we have a reason that's compelling enough, but as we talk
about changing the strings
Indeed. We can do what we've done in other cases: create a registry
if/when we add something else later.
Barry
On Mon, Aug 7, 2023 at 4:11 PM Scott Kitterman wrote:
>
>
>
> On August 7, 2023 7:47:03 PM UTC, "Murray S. Kucherawy"
> wrote:
> >On Sat, Aug 5, 2023 at 1:09 PM Tim Wicinski wrote:
> One last thing, how about directly assessing extensibility?
>
> dmarc-method = %s"dkim" / %s"spf" / dmarc-value
First, why the "%s"? I see no reason to make the method name case sensitive.
Second, there's no need for "dmarc-value". With Tim's original proposal:
> dmarc-method = "dkim" /
Two things:
> If unspecified with a policy tag "auth=", this indicates that both DKIM
and SPF are supported.
I don’t like this approach. I think that the absence of auth= means what
it has always meant: the sending domain is not specifying what
authentication methods it is using and the
I don't agree. An allow list bypasses something -- whatever
processing the list allows something past -- but not everything.
In this case, we might be talking about a list that means "If we are
sufficiently certain that a message same from the entity on the list,
we will not reject it even if
The IETF's policy is to consider replacing these obsolete terms; there
is no mandate.
That said, I will push us strongly to do so: there is no harm in using
"block list" and "allow list" instead, and we should.
Barry
On Thu, Aug 3, 2023 at 1:53 PM Steven M Jones wrote:
>
> On 8/3/23 12:50 AM,
I think Richard’s suggestion would be a fine addition to what’s there now,
but not a replacement. I would really prefer MUST in Richard’s text over
the SHOULD, given the “trusted attestation”.
Barry
On Sat, Jul 29, 2023 at 12:09 PM Richard Clayton
wrote:
> -BEGIN PGP SIGNED MESSAGE-
>
> Can the discussion on "SPF use in DMARC" include the optional "auth=" and in
> particular "auth=dkim"?
That'd be the third bullet under "options currently open" on the agenda.
Barry
___
dmarc mailing list
dmarc@ietf.org
Other than the chars’ agenda slide, I have no slides for Friday, with a
plan of just discussing ideas and text — so everyone, please do read the
text proposals and be prepared to discuss them.
That said, if anyone has slides to propose, please do so by end of the work
day Thursday. I do not plan
> Without bounces the sender is in the dark.
Yes, if the sender is a human.
Not so, if the sender is a mailing list and that sender will then
unsubscribe the intended recipient.
Also not so, if the sender is a malfeasant who may use the bounce
message for bad purposes.
It's very clear to me
> I think that it shouldn't affect the answer about what to put in the
> document. Those of us here are a
> miniscule slice of the overall user base for email, I think it's a serious
> mistake to think peculiarities of
> the exact lists we use is relevant to anything.
Indeed: I caution
> - An attacker sends 10 messages that maliciously impersonates a
> big bank. With help from DMARC p=reject, the evaluator blocks
> them all. The attacker follows up with 10 messages that
> maliciously impersonate a major university. The stupid
> evaluator says, "p=none means no problem here".
> The issue is not about lists being second class. What lists do to a message
> is a privileged function, because
> modifying a message can be done maliciously as easily as it can be done
> innocently. So the real problem
> is that DMARC demoted them from privileged to non-privileged by
that and decided, as you say, to
try to be more inclusive. But we've seen problems caused by the From
rewriting also, related to difficulties in replying... it's not
benign.
Barry
On Tue, Jul 11, 2023 at 4:30 PM Tero Kivinen wrote:
>
> Barry Leiba writes:
> > > 2) As other
> To Murray's observation about fairness, my thoughts:
I don't see any use of the word "fair" in the message from Murray that
you quote.
> 1) Life is not fair.
This is impolitely dismissive. Please don't do that.
> 2) As others have observed, the mailing list problem is exclusively an
>
> Another consideration is that a non-standard, internal blocking would have
> been
> effective only for their users. Perhaps they though they were doing the rest
> of the world a favor by following standard protocols. Had that MUST NOT been
> in place then, /perhaps/ we'd have spared ourselves
> I’m one of those people who prefer for “xxx considerations” sections to be a
> descriptive discussion
> of the xxx issues and not contain new normative requirements.
I disagree, and certainly the Security Considerations sections are
normative and often use BCP 14 key words.
> the statement
t;
> On 6 Jul 2023, at 8:00, Barry Leiba wrote:
>
> > Below is the agenda I am posting for the session at IETF 117.
> > Comments, changes, and additions are welcome; please post them here.
> >
> > Barry
> >
> > -
The point isn't to place blame. The point is to specify how to
maintain interoperability, and in the case of DMARC p-reject there are
two places where we can lessen the interop problems: telling the
senders not to use p=reject in inappropriate conditions, and telling
the receivers to consider the
list operation", I'll take the former to prevent the latter
every time.
Barry
On Fri, Jul 7, 2023 at 11: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 consensu
let DMARC participants decide between themselves, on a
> case by case basis, how they solve *their* deliverability problems.
>
> Cheers,
> Baptiste
>
> Le 06/07/2023 à 16:55, Barry Leiba a écrit :
> > I had some off-list discussions with Seth, who was very much against
> > my orig
, but we will tell receivers how
> to avoid this situation.
>
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy
> Comcast
>
>
> > -Original Message-
> > From: dmarc On Behalf Of Barry Leiba
> > Sent: Thursday, July 6, 2023 10:55 AM
&
stuff that's been lying fallow for a few months) and release it
> today.
>
> On Thu, Jul 6, 2023 at 12:02 PM John Levine wrote:
>
>> It appears that Barry Leiba said:
>> >This makes it explicitly clear that any MUST/SHOULD stuff with regard
>> >to using and honor
munging. Isn't that practice widespread enough that it deserves being
> considered?
>
>
> Best
> Ale
>
>
> On Thu 06/Jul/2023 16:55:02 +0200 Barry Leiba wrote:
> > I had some off-list discussions with Seth, who was very much against
> > my original proposed tex
> This language works well for me.
Excellent; thanks.
> I suggest adding some language about why MTAs should not rearrange message
> headers or MIME
> sections, even though earlier documents grant permission to do so.
>
> Additionally, when adding headers, an MTA must add them at the top if (a)
> For clarity: When you say, "AD will call consensus on this issue", you mean
> after the results of the discussion
> are brought to the list and reviewed by the working group, not at the
> meeting, right?
Yes, correct. I wanted to make it clear that Seth and I both have a
conflict on this,
I had some off-list discussions with Seth, who was very much against
my original proposed text, and he suggested an alternative
organization that would be more palatable to him. I've attempted to
set that out below. The idea is to remove the normative requirements
about using p=reject from
Chair speaking and agreeing. While I do not think it's out of scope
to think about how DKIM replay attacks affect DMARC, I think it is out
of scope to design DMARC to address DKIM replay attacks. These two
things are very close to each other, and we're going to have to be
careful about it. But
effective against DKIM reply, but your
> analysis doesn't cover that case explicitly.
>
> Perhaps there are better ways to counter that specific problem, and certainly
> it's not what this WG is tasked to do. But, just to make the point, I think
> it's interesting to know.
>
>
>
r than single, no?
No.
Barry
On Tue, Jun 27, 2023 at 6:36 AM Alessandro Vesely wrote:
>
> On Mon 26/Jun/2023 20:13:53 +0200 Barry Leiba wrote:
> > I'm saying I don't want "and" to be an option, because I think it's
> > damaging to DMARC. There is no reason anyone shoul
It
would be very bad for deliverability of legitimate mail and would
provide no additional security. It would be a terrible mistake.
Barry
On Mon, Jun 26, 2023 at 11:55 AM Murray S. Kucherawy
wrote:
>
> Just to clarify something:
>
> On Mon, Jun 26, 2023 at 5:52 AM Barry Leiba wrote:
&
If we consider this sort of thing, I want to push to keep one thing
off the table:
Saying that SPF *and* DKIM *both* have to pass is a VERY BAD approach.
Let's please just remove that from consideration. It has not been in
DMARC up to this point, and it would be really bad to add it.
> > Presumably, a sender who uses DMARC might publish SPF to cover
> > recipients who don't use DMARC, but would prefer that recipients use
> > DMARC (authenticated by DKIM only).
>
> I get that, but that's still simultaneously saying "use SPF to
> authenticate me" and "don't use SPF to
Presumably, a sender who uses DMARC might publish SPF to cover
recipients who don't use DMARC, but would prefer that recipients use
DMARC (authenticated by DKIM only).
Barry
On Fri, Jun 23, 2023 at 1:54 PM John R Levine wrote:
>
> > My understanding is that if `auth=dkim` then SPF would be
> I concur that this isn't really a problem for either working group to solve
> as part of a standard,
Well, the part that the working group needs to solve is whether the
challenges of getting DKIM right are such that we need to retain SPF
to fill that gap, or whether the issues with relying on
> DMARC requires using SPF or DKIM or SPF and DKIM. If neither method is
> used, DMARC can report the situation, but it won't prevent receipt (m'I
> correct?).
You are not correct; DMARC is designed to handle this situation, among others.
I'll oversimplify here, because you really do need to
Thanks for all this detail, Tero! I will have to digest it and reply
further later.
Barry
On Tue, Jun 13, 2023 at 5:34 PM Tero Kivinen wrote:
>
> Barry Leiba writes:
> > > DKIM only: ~99.5%
> > > DKIM + SPF: ~100%
> > > SPF only: ~100%
> >
> > Th
The misconfiguration is changing it after the message was signed.
Once the message is signed and in the MTA-to-MTA relay system, no one
should be altering the message body any more until final delivery.
Barry
On Mon, Jun 12, 2023 at 6:02 PM Jim Fenton wrote:
>
> On 9 Jun 2023, at 22:35, Murray
gt; On Sun, Jun 11, 2023, 8:27 AM Barry Leiba wrote:
>>
>> Are we *again* questioning the tree walk, which is, recall, a settled issue?
>>
>> Barry
>>
>> On Sun, Jun 11, 2023 at 7:53 AM Douglas Foster
>> wrote:
>> >
>> >
Are we *again* questioning the tree walk, which is, recall, a settled issue?
Barry
On Sun, Jun 11, 2023 at 7:53 AM Douglas Foster
wrote:
>
> Given that the PSL is subject to errors, it is reasonable to warn senders that
>
> "Because of the risk of PSL errors, some evaluators MAY NOT accept some
> What if MIME-Version changed on every new MIME type?
(I presume you mean "subtype", as we've only defined two new media
types: example (RFC 4735) and font (RFC 8081).)
This is a red herring, as MIME was specifically designed to be
extensible by adding new media types and subtypes, as well as
Hm...
Why not say "SHOULD use tree walk", and then document, as explanation
for "SHOULD" instead of "MUST", non-normative reasons why you might
not?
Waddyathink?
Barry
On Sat, Jun 10, 2023 at 5:05 PM John Levine wrote:
>
> It appears that Scott Kitterman said:
> >
> >What's the incentive
osal. Not anything for the
> current DMARCbis.
>
> Is the chair suggesting the current charter for DMARCbis should change to
> remove SPF? Was the charter changed for this?
>
> To be clear, DMARC2 is not DMARCbis right now, are you wishing this now?
>
> Hector
>
>
&g
ctor Santos wrote:
>
> > On Jun 9, 2023, at 4:41 AM, Barry Leiba wrote:
> >
> > Repeating this one point as chair, to make it absolutely clear:
> >
> > The proposal we're discussing is removing SPF authentication from
> > DMARC evaluation *only*. We will *not
Thanks for the follow-up, Scott.
> It's not a case of I've seen a few failures, it's consistent (all I can say
> for certain is that it was as I no longer have access to this data). It was
> consistent across time and providers. At scale, DKIM would always have a
> fraction of a percent failure
Keep in mind that we have looked at this extensively, and what we've
found is this:
1. Almost all [1] of the DMARC senders out there will see the same
results when recipients look them up using the tree walk as they have
using the PSL. In other words, the change will be different an
*extremely*
> One case I saw multiple times where DKIM fails while SPF verifies is when the
> message contains a line starting with "from " which some agent changes to
> ">from ". Some signing software eliminates such lines before signing, but
> that's not in the spec, so one cannot say a signer is defective
its current charter.
Barry, as chair
On Fri, Jun 9, 2023 at 9:39 AM Barry Leiba wrote:
>
> Thanks for some data, Doug. One comment on what's after the data
> (still talking as a participant here):
>
> > We have two topics intermixed: (a) should we deprecate SPF for DMARC
&g
I think, Scott, that you and I have a fundamental disagreement that's
not resolvable, and I won't just repeat what I've already said. But a
couple of the things you said are ones I can't make sense of, so I'll
talk about those:
> Software engineering isn't a perfect science. In general, a more
> There are DKIM verification failures for reasons unrelated to DNS failures.
> As an example, I
> recently fixed a DKIM validation bug in the library I maintain which was
> causing a small fraction
> of valid signatures to fail verification since at least 2011. SPF + DKIM
> reduces DMARC
> A sender using both SPF and DMARC will see a slight
> boost in validation rates due to increased resiliency when there are
> transient DNS failures and other problems.
Do you mean "both SPF and DKIM", perhaps?
I don't see how that makes sense: if there's a transient DNS failure,
then neither
;through the bis process and removing flags, but what about a way to say “I
> >only send with DKIM, and do not evaluate SPF on my behalf”?
> >
> >That wouldn’t create an interop problem, and gives a path to upgrade
> >without creating breaking change out of the gate?
>
at led to DMARC showed that SPF and DKIM were both necessary to
> determine legitimacy broadly. What would we need to understand now to see
> if only DKIM is necessary?
>
> On Thu, Jun 8, 2023 at 3:44 PM Barry Leiba
> wrote:
>
>> See, I don't look at it as "harmed"
the goal
> should be to eliminate it. I just don't believe we're anywhere close to
> that being a reality yet.
>
> The data that led to DMARC showed that SPF and DKIM were both necessary to
> determine legitimacy broadly. What would we need to understand now to see
> if only DKIM is
See, I don't look at it as "harmed". Rather, I think they're using "we use
SPF" as a *reason* not to use DKIM, and I think that *causes* harm.
SPF is, as I see it, worse than useless, as it adds no value to domain that
use DKIM -- any time DKIM fails SPF will also fail -- and actually impedes
In a recent post, Doug said this:
> Back when we thought this process would finish in our current century,
> Scott volunteered to hunt down these domain owners prior to publication.
The snide tone of that (“current century”) compels me to reply as chair,
because it is exactly the dredging up of
We have discussed and settle the tree walk issue many times now. What
new information is here that we haven't already discussed? Please be
very specific.
Barry, as chair
On Thu, Jun 1, 2023 at 7:03 AM Douglas Foster
wrote:
>
> I cannot support the current draft because it creates new problems
And now following this up as chair:
I believe this topic has been discussed at length before and is well
settled: the working group's rough consensus on the tree walk is
clear. Todd, please close issue 113 as settled, with no document
change needed.
Let's please avoid opening tickets on
As a participant, I fully disagree with the second paragraph of this.
The justification for changing the mechanism is that in cases where
the mechanisms differ, the tree walk produces results that are more
likely to represent the intent of the sending side than consulting the
PSL does. This has
;
> Can there ever be proposed text to suggest a smooth transition to
> DMARCbis endorsing 3rd party authorization exploration and solutions?
>
> Maybe when it is endorsed we can get the enterprises to at least do
> verification, even if they can use it themselves for outbound mail.
>
Ok, everyone, let’s take a rest here.
First: John’s message was not nice. We can all agree on that. So…
(1) John, please don’t send messages like that, even off list. You can
clearly see why that’s good advice.
(2) Everyone other than John, please just accept John’s word — I do — that
> 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 language, that's a bit different. The
> original proposal was: "To be explicitly clear: domains used for
> general-purpose
We can say that as well, but I want to specifically say "don't use SPF
without DKIM and expect it to work right;"
b
On Thu, Apr 13, 2023 at 12:41 PM Dotzero wrote:
>
>
> On Thu, Apr 13, 2023 at 12:19 PM Barry Leiba
> wrote:
>
>> Maybe just add a sentence to
> I think we all understand the inconvenience that DMARC can cause to a
> subset of domains, or more accurately its users.
The problem here that we're describing as an interoperability issue is
not that DMARC causes problems for the users of domains that choose to
use p=reject -- that would be
Maybe just add a sentence to the end of the second paragraph:
The use of SPF alone, without DKIM, is strongly NOT RECOMMENDED.
Barry
On Thu, Apr 13, 2023 at 12:04 PM Todd Herr wrote:
> On Thu, Apr 13, 2023 at 11:21 AM Barry Leiba
> wrote:
>
>> > Anyone who does for
> Anyone who does forwarding is damaged by DMARC because there are a lot of
> people who do DMARC on the cheap with SPF only.
This brings up another issue, I think: that there should also be
stronger advice that using DKIM is critical to DMARC reliability, and
using SPF only, without DKIM, is
I would like to make the receiving advice stronger *also*, yes. In
particular, I would change the SHOULD NOT to MUST NOT, and I would add text
that suggests that it's a particularly bad idea to react to p=reject for
domains that are known to host email addresses for the general public, and
expand
> I've also been thinking about ways to push the burden back on the
> advertisers. Imagine we have some kind of signaling mechanism that
> MLMs can take advantage of indicating to them that the author is using
> a strong policy, and so it would be possibly a bad idea for the MLM to
> accept,
> As Todd previously stated, my preference is for language that
> acknowledges the primacy of the domain owner over interoperability
The problem is that IETF standards are about interoperability, not about
anyone’s primacy.
There is an alternative, though: we can acknowledge that because of how
We simply fundamentally disagree here.
Barry
On Sun, Apr 2, 2023 at 12:33 AM Dotzero wrote:
>
>
>
> On Sat, Apr 1, 2023 at 3:02 AM Barry Leiba wrote:
>>
>> > If we use SHOULD NOT, as you suggest, there's an implication that there
>> > might be a valid re
> If we use SHOULD NOT, as you suggest, there's an implication that there might
> be a valid reason for
> non-transactional mail to use "p=reject". Are we okay with that?
I, for one, am not. We often use "SHOULD NOT" incorrectly to mean
"MUST NOT, but we know it will be widely violated so
> Absolutely a false assertion. When browser providers decided to stop
> supporting HTTP and only support HTTPS, there were websites not
> reachable that people wanted to reach. That is the very definition of
> broken interoperability. Websites that wanted to be reached (which
> hadn't already
> Compare that with the move to https everywhere. Having to get certificates
> and
> encrypting and decrypting all stuff is certainly not an interoperability
> improvement.
Say WHAT? There's no interoperability issue there.
There's some effort involved in doing it, and one has to weigh that
> I don't see any hope that people will back away from the perceived security
> benefits of DMARC to
> accommodate mailing lists, even if we publish Barry's language.
But here's where we're missing my main point, so I'll highlight it:
The spec needs to say what the right thing is for the
> Our spec needs to fix the evaluators, and their products, not the sender
policy.
No: it should be doing both.
Let’s look at it this way:
Suppose a general-use email provider called “Hooya” promulgated a policy
that said receiving domains should bounce any message from a hooya.com
sender that
1. IETF has installed a very ugly workaround to the problem, rewriting the
"from" header field. It's absolutely a workaround, and not a proper
solution.
2. Without the workaround, the real pain is not that a message from Comcast
posted to the list doesn't get to you (though that's true): the
with existing, decades-old mail flows.
Barry
On Thu, Mar 30, 2023 at 12:36 AM Todd Herr wrote:
> On Wed, Mar 29, 2023 at 10:15 AM Barry Leiba
> wrote:
>
>> I'm very much against text such as this, as I think it encourages
>> deployments that are contrary to interoperability and
>one of our employees wants to use a mailing list. But that still feels like
> >the right thing to do.
> >
> >If it’s not obvious, I’m having a hard time with “MUST NOT”, and dictating
> >to domain owners what is in their best interests, regardless of our
> >perceived
I'm very much against text such as this, as I think it encourages
deployments that are contrary to interoperability and to the intent of
p=reject.
I contend that p=reject (as with the similar construct in the older ADSP)
was intended for high-value domains and transactional mail, and that it was
I raised this issue in the DMARC session in Vienna, and have let it
sit for a while so as not to derail other discussion. As we're pretty
close to finished with the DMARCbis document, I'd like to raise it
again, this time with specific proposed text for us to discuss.
And so:
OLD
5.5.6.
Thanks,
Barry
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
; enough interest first, I can do that.
> -Wei
>
> On Sun, Mar 12, 2023 at 9:15 AM Barry Leiba wrote:
>>
>> What I'm hearing so far is: "Cancel the DMARC session."
>>
>> I will do that on Wednesday if I don't hear a reason not to. Please
>> speak up q
1 - 100 of 245 matches
Mail list logo
