per the proposal, please explain exactly what bad things
will happen, in the case you offer.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
tion for needing a new
and separate header field.
Simple summary:
These days, the original From: field is tending to get corrupted
and we need some place to put author information that won't be.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw
parts aligned to one another does require an updates= tag.
ahh. hadn't seen that was your point. well, whenever there is an
effort to do substantial revisions to mail format, this might be worth
considering.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 7/13/2020 9:29 AM, Alessandro Vesely wrote:
On 13/07/2020 05:10, Dave Crocker wrote:
I've just submitted an initial draft to define an RFC5322.Author field:
https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/
Dave,
since you also posted a second draft, I'd strike considerations
signature?
cf, above, about the nature of the requirements. Again, it would make
sense to bind it, but mandating is a separate issue.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.o
not discern any specific substance in
your note that relates to the substance of my draft. Please clarify.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
FYI,
I've posted an initial draft for having DMARC use the Sender: field:
https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https
FYI,
I've just submitted an initial draft to define an RFC5322.Author field:
https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https
it integrates into end-to-end service. How is it expected to
get used and why is that believed to be practical (as well as useful?)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org
On 7/6/2020 10:41 AM, John R Levine wrote:
On Mon, 6 Jul 2020, Dave Crocker wrote:
Perhaps, like some others, I'm not understanding this correctly, but
I think the proposal has nothing at all to do with what the recipient
sees. Rather, I've understood this as an attempt to reverse
additions
ions
made by a Mediator, with the goal of validating the origination DKIM
signature. Presumably that is so as to use the origination domain's
reputation and even permit DMARC to validate.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc ma
is needing to be more tentative. Opinions are of course
fine. The state of being an opinion is transitive. It flows onto any
assertions made based on it.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https
interpretation also having been expressed.
Please don't do that.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Item 1 in the charter that precludes this work?
What is it about Item 2 in the charter that precludes this work?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On 6/25/2020 8:10 AM, David I wrote:
From: Dave Crocker
set a 'From' they're not entitled to use that's of a trusted contact, and the
DMARC associated with the abused domain in the 'From' has no effect and
can't be used for filtering. So while you could so a similar filter on Sender
semantics match
what is
I see the use of a
long-standing header field as being a disadvantage, not an advantage,
because of potential obscure uses we don't know about.
That line of logic means we should never modify or add to any existing
practice.
d/
--
Dave Crocker
Brandenburg
to the Sender: aligned domain, and reports
refer to that, why is a report on the From: field also required?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
books are not used in some filtering work.
I said that I doubted that it is relevant to DMARC use. Feel free to
document counter-examples.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https
On 6/24/2020 4:12 PM, Douglas E. Foster wrote:
If DMARC settles on Sender, what tool will validate the relationship
between Sende and From?
None.
Please explain why you think it has to. Not in terms of theory but in
terms of observable practice.
d/
--
Dave Crocker
Brandenburg
On 6/24/2020 11:35 AM, Jim Fenton wrote:
On 6/23/20 9:19 PM, Dave Crocker wrote:
On 6/23/2020 4:14 PM, Jim Fenton wrote:
I do have a concern about Sender:. It has existing semantics defined in
RFC 5322 Section 3.6.2, and this proposal might conflict with that
I don't think it conflicts
On 6/24/2020 9:31 AM, Alessandro Vesely wrote:
On Tue 23/Jun/2020 20:49:11 +0200 Dave Crocker wrote:
So if Sender: wouldn't be as useful as From:, why not?
I'm a bit skeptic.
The assertion that "DMARC protects the domain name in the address part
of the From:" would have to
understand what that means.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
display Sender?
They don't consistently display From:
More importantly, MUAs are essentially -- or completely -- irrelevant to
the use of DMARC now. I don't see why that should change.
Again: end-user recipient decision-making is irrelevant to meaningful
email abuse handling.
d/
--
Dave
missed?
I suspect that very little -- if any -- of the current use of DMARC
relies on an end-user's address book.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo
On 6/23/2020 4:14 PM, Jim Fenton wrote:
I do have a concern about Sender:. It has existing semantics defined in
RFC 5322 Section 3.6.2, and this proposal might conflict with that
I don't think it conflicts at all. So it will help for you to explain
your concern in detail.
d/
--
Dave
two entities qualifying for the 'posting' definition: The author's
originating MSA and the MLM's MSA.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On 6/21/2020 4:35 PM, Murray S. Kucherawy wrote:
Armed with such a list and a plan, I can see what the IRTF Chair
thinks of the idea.
cool!
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https
RFC 5322 says display names are "associated" to a mailbox.
I don't see such language in RFC 5322. In fact, other than the ABNF for
display-name, I don't see any explanation of its semantic.
Certainly, changing just the addr-spec breaks the association and
wr
ommon 'patterns' of mailing list
patterns.
* Get reasonable community support (rough consensus) for the document
-- including from MLM developers and operators
* Formulate survivable authentication choices
* Get reasonable community support for that approach
* ...
d/
--
Dave Crocker
Brande
of sand, in terms of operational
realities, since none of what it would be relying on was documented
standards and, again, there was (and I suspect remains) a view that
mailing list operators did not make good candidates for reliable
adherence to IETF 'standards'.
d/
--
Dave Crocker
These risk
factors do not encourage pursuing the complexities and costs of a global
standard.
That leaves just a staged trust model, establishing a basis of
accountability (and reputation) for the mediator sequence. Hence, ARC.
d/
--
Dave Crocker
Brandenburg InternetWorkin
On 6/19/2020 2:20 PM, Pete Resnick wrote:
Crap. My deepest apologies to Dave. I am very embarrassed by fat
fingering that. It is not the worst private thing I've ever sent to a
list, but still.
A bigger concern should be with thinking that such paternalism is
appropriate.
d/
--
Dave
On 6/19/2020 12:02 PM, Pete Resnick wrote:
On 19 Jun 2020, at 13:38, Dave Crocker wrote:
The description of what a Mediator might do is not incompatible with
also viewing it as having characteristics of a publisher:
### [5.3](<https://tools.ietf.org/html/rfc5598#section-5.3>).
Mailing
point that keeps being ignored is that there is quite a bit of
objective information showing that it does NOT have an effect. As far
as I'm aware, there is no objective data that it DOES have an effect.
So, no, this is not just a matter of differing 'opinions'.
d/
--
Dave Crocker
Brandenburg
"certifying" the
domain name of the From: field is relevant to reducing end-user
vulnerability.
There is quite a bit of evidence that improving trust signals to end
users has no significant effect.
d/
--
Dave Crocker
Brandenburg InternetWorkin
s more
like a publisher and less like a simple relaying service.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On 6/18/2020 10:16 PM, Jim Fenton wrote:
On 6/18/20 7:35 PM, Dave Crocker wrote:
vulnerability?
Yes. When bad actors (your choice of words) can work around an aspect of
the specification that is depended upon to enable differential handling
by a receiving filtering engine (again your choice
has caused widespread deployment problems.
vulnerability?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On 6/18/2020 2:10 PM, Jim Fenton wrote:
On 6/17/20 12:11 PM, Pete Resnick wrote:
On 17 Jun 2020, at 13:27, Dave Crocker wrote:
DMARC has nothing to do with display of author information to a
recipient, and everything to do with differential handling by a
receiving filtering engine. Were
, destroying the original
information about content authorship.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On 6/14/2020 10:29 PM, Jim Fenton wrote:
On 6/13/20 8:17 PM, Dave Crocker wrote:
On 6/13/2020 7:53 PM, Jim Fenton wrote:
Alas, others do,
Other groups do all sorts of things. They once mandated OSI, for
example.
Please explain how that is relevant, here and now.
The WG needs to consider
On 6/14/2020 10:25 AM, Kurt Andersen (b) wrote:
On Fri, Jun 12, 2020 at 5:52 PM Dave Crocker <mailto:dcroc...@gmail.com>> wrote:
> ARC lets the recipient look back and retroactively do the filtering
> the list didn't.
The concern about the creator of an ARC
and more about possible use/abuse by
other agencies?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
of an ARC chain, ARC let's
the receiving filtering engine do filtering based on the proffered
address of the originator.
(Recipient end-users are irrelevant to this process.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing
is indeed quite separate.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
issues.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
. Especially since
it already has a section discussing 'implementation'.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
-- and receiving administrations often implement
behaviors that differ from what is requested via DMARC.
There is no basis for believing that requests about MUA display
will achieve meaningful support on the receive side, nevermind whether
they would be at all useful.
d/
--
Dave Crocker
, for end-user trust notifications.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
at all to do with system-provided
trust assertions.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
ong, but I believe the IETF does not intend to make global
standards on the basis of possible utility for only one engineer working
on the specification. Or two. Or three.
cf, above.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dma
of domain name.
With that in mind, I'll ask you why you think the kind of change you
cite is a win.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On 6/3/2020 10:20 AM, Alessandro Vesely wrote:
On Wed 03/Jun/2020 18:43:16 +0200 Dave Crocker wrote:
On 6/3/2020 9:38 AM, Alessandro Vesely wrote:
MUAs should be discouraged from displaying or using Author:, unless
(verifiably) signed by a trusted domain or otherwise configured by the user
On 6/3/2020 9:38 AM, Alessandro Vesely wrote:
MUAs should be discouraged from displaying or using Author:, unless
(verifiably) signed by a trusted domain or otherwise configured by the user.
Why?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
do serious research. And they often
document it. But this is quite different from marketing literature or
hallway discussion. I'm asking to see the research writeups. (I made
that plural since you are so firm in saying there is lots of supporting
research.)
d/
--
Dave Crocker
Brandenburg Inter
On 6/2/2020 5:13 PM, Seth Blank wrote:
On Tue, Jun 2, 2020 at 4:02 PM Dave Crocker <mailto:dcroc...@gmail.com>> wrote:
On 6/2/2020 3:53 PM, Seth Blank wrote:
> The point I was trying to make is that consumers are susceptible to
> fraud,
Of course they are.
.
That's what alignment fixes and what's so powerful about DMARC.
Seth, your statement is so confused, I'm not sure I can fix it up.
"Authenticate to the MTA?" DKIM and DMARC don't do that.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
into misbehavior by the presence of a problematic From: field domain name.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Wow. I'll ask folk to reread my text, here, carefully, since it
specified something quite narrow and concrete, but is somehow being
taken to have meant something broad and general:
On Tue, Jun 2, 2020 at 1:46 PM Dave Crocker <mailto:dcroc...@gmail.com>> wrote:
However ther
On 6/2/2020 1:36 PM, Murray S. Kucherawy wrote:
On Tue, Jun 2, 2020 at 11:01 AM Dave Crocker <mailto:dcroc...@gmail.com>> wrote:
Your comment implies that what is displayed to the user is
important in
anti-abuse efforts, but there is no data to support that view, and
On 6/2/2020 12:32 PM, Pete Resnick wrote:
On 2 Jun 2020, at 13:29, Dave Crocker wrote:
On 6/2/2020 11:12 AM, Pete Resnick wrote:
On 2 Jun 2020, at 13:01, Dave Crocker wrote:
There's no reason that DMARC couldn't have included the sender or
tried to have some kind of
PRA like spf v2
On 6/2/2020 11:12 AM, Pete Resnick wrote:
On 2 Jun 2020, at 13:01, Dave Crocker wrote:
There's no reason that DMARC couldn't have included the sender or
tried to have some kind of
PRA like spf v2... but that's not the goal.
But the Sender: field is not reliably present and, of course
hat really want to get strict about who gets to
claim to be an author associated with a domain, then do something like
add a DMARC option that prohibits use of the Author: field. (Note that
just having DKIM and ARC pre-sign a non-existent Author field
accomplishes this, too...)
d/
--
Da
I've been able to formulate is: create a new field,
such as Author:.
(Give it a simple, clean, appropriate name, rather than something like
Original-From.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc
On 5/20/2020 8:29 AM, Kurt Andersen (b) wrote:
Agree 100%
This looks like it has a strong constituency against the proposal, a
much smaller constituency in favor of it, and little or no offered
benefit. Yes?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
that does not have a clear need is especially expensive.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
things markedly better.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
onstrated the challenges of ensuring that
users correctlyinterpret the icons and do not get fooled by imposters
"Challenges" is incorrect. "Failure to be useful" is more appropriate
language.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
the claim that the
purported interest has not made itself both visible and
enthusiastic. Such dearth absolutely does not rise to the level of
supporting something on the standards track, to be sure, but that
wasn't the goal here either.
Heh. An IETF-approved 'experiment' is not a casual ac
ize, since it is now clear to me that these suffixes are very much
NOT public. They are private or governmental.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On 2/5/2020 6:40 AM, Dave Crocker wrote:
Help me understand.
I'll try with the
no idea why my text got truncated.
what I typed was: I'll try with the other response I'm considering.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 2/4/2020 10:13 PM, Scott Kitterman wrote:
On Tuesday, February 4, 2020 10:20:14 PM EST Dave Crocker wrote:
I don't recall that scaling limitation was an embedded and acknowledged
fact about that spec. And with a quick scan I don't see anything about
that in the document
(I am trying to formulate a response on the higher-level technical and
process issues under consideration, but decided to respond now on these
particulars, since they are more focused...)
On 2/3/2020 10:47 AM, Murray S. Kucherawy wrote:
Dave,
On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker
On 1/17/2020 12:06 AM, Murray S. Kucherawy wrote:
On Mon, Dec 9, 2019 at 8:44 AM Dave Crocker <mailto:dcroc...@gmail.com>> wrote:
The IETF does not typically -- or, as far as I recall, ever -- promote
specifications known not to scale. (While I think of this concern as
fou
it will get used is
incomplete. (if workable at scale.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
lieving it will be
maintained well.
d/
[1] Mission and principles
[2] https://ietf.org/standards/process/informational-vs-experimental/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc
On 12/2/2019 8:29 AM, Dave Crocker wrote:
It will help to have folk comment on the IETF mailing list, so that
Klensin's comments don't just get responses from me.
Sorry, wrong venue. The discussion is on the ietf-smtp mailing list, but
the request for others to participate remains!
d
On 12/2/2019 7:56 AM, Kurt Andersen (b) wrote:
There's also already RFC7960 which expands upon 5598 with specific
reference to DMARC's impact.
ahh. thanks.
It will help to have folk comment on the IETF mailing list, so that
Klensin's comments don't just get responses from me.
d/
--
Dave
a document that discussed all this coherently, defined
basic terminology, and had undergone IETF review and approval. If only
we had RFC 5598...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://ww
On 11/11/2019 2:21 PM, Dave Crocker wrote:
and those typically are called experiments.
/not/ called.
(sorry)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo
ly those only happen when there is a
complete failure, and those typically are called experiments.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On 11/7/2019 3:16 PM, Brandon Long wrote:
On Thu, Nov 7, 2019 at 9:28 AM Dave Crocker <mailto:dcroc...@gmail.com>> wrote:
On 11/6/2019 9:43 AM, Brandon Long wrote:
> What's more, the point of including Subject and other mutable
headers is
> the same as it is
are
provided by the standard. That's fine, of course, but it has nothing to
do with the standard. Hence any receive-side reliance on such signer
data validation is outside the DKIM standard.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 9/5/2019 2:49 PM, Scott Kitterman wrote:
I don't think so. The draft defines PSD as org - 1.
Writing a definition for something you don't control and that can (and
has) change tends to be problematic.
As it is here.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 9/4/2019 6:28 AM, Dave Crocker wrote:
ence my current view that:
1. The change to DMARC should be limited to permitting the query for the
organization domain to be anywhere in the DNS tree, including a TLD.
Within DMARC this would not look like 'extra' mechanism.
2. The mechanism
obsolete.
Yet these portions still haven't been eliminated from the specification.
Twenty years later.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
the small matter of a small (actually tiny) base of
demonstrated support for this proposal.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
s produces zero change to DMARC's lookup behavior and almost no
change to its specification.
d/
(*) Public Suffix List <https://publicsuffix.org/>
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On 6/11/2019 8:12 AM, Alessandro Vesely wrote:
On Mon 10/Jun/2019 22:17:01 +0200 Dave Crocker wrote:
On 6/10/2019 1:17 AM, Alessandro Vesely wrote:
On Sat 08/Jun/2019 18:49:03 +0200 Dave Crocker wrote:
Except that most users don't actually see that address because these days most
MUAs only
On 6/10/2019 1:17 AM, Alessandro Vesely wrote:
On Sat 08/Jun/2019 18:49:03 +0200 Dave Crocker wrote:
Except that most users don't actually see that address because these days most
MUAs only display the display address.
We often came across this realization. Since DMARC hinges on that field
imple, concise
language about what it does.
But I have already been told that IETF is not interested in Recipient
product problems, and is not concerned with security, which has left me
very disappointed.
I suspect you have been told nothing of the sort.
d/
--
Dave Crocker
Brande
that specifies how to avoid dmarc report loops.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
t find it. So again, ad hoc mechanisms
might also be useful, but they are separate.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
with respect to report looping.
d/
--
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
, many seders
do not have SPF configured for HELO name and SPF failure can trigger a
report.
I don't understand how the HELO domain name is relevant to this
discussion, since it isn't a full email address.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
assessing the submission. There
doesn't seem to be a good reason to require an AD to make that decision.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
count as
errata.
What this means is that there is no standard way to record the need for
better-performing capabilities or addition of new capabilities or the like.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
ur concern?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
301 - 400 of 581 matches
Mail list logo
