.
d/
--
Dave Crocker
dcroc...@gmail.com
mast:@dcrocker@mastodon.social
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
h
could bog the stressed reader down.
When writing specifications, yes, it is good to consider the casual or
harried reader. To that end, vocabulary should not mislead. 'Policy'
misleads about the effect of choosing a particular value.
d/
--
Dave Crocker
dcroc...@gmail.com
mast:@dcrocker@mast
ut loud either :-)
Here, too, the domain owner does not govern the platform receiver.
d/
--
Dave Crocker
dcroc...@gmail.com
mast:@dcrocker@mastodon.social
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Re
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 loud. Now say DMARD out loud.
d/
--
Dave Crocke
If anyone in the DMARC wg has status information for us to include in
the Silicon Valley Red Cross chapter monthly report, I'll be glad to
include it. For the rest of you, apologies for the misaddressed message...
d/
On 2/23/2023 2:58 PM, Dave Crocker wrote:
On 2/23/2023 2:23 PM, Meyerson
out the problem. Any chance you have some time tomorrow
(Friday) afternoon?
d/
--
Dave Crocker
dcroc...@gmail.com
mast:@dcrocker@mastodon.social
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross
version, the new stuff is self-declaring and version number isn't needed.
if the changes produce an incompatible spec, it's a new protocol, rather
than a 'version'.
cf, MIME history that landed on this realization.
d/
--
Dave Crocker
dcroc...@gmail.com
mast:@dcrocker@mastodon.social
y are in the process of
changing.) That is, the what from the how. As you have also done.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
__
On 1/30/2022 10:39 AM, Scott Kitterman wrote:
On Saturday, January 29, 2022 11:25:30 PM EST Dave Crocker wrote:
On 1/29/2022 7:53 PM, Scott Kitterman wrote:
1. Using 7489 or 9091 as fixed, controlling documents is problematic, as
I've noted. So, 'consistency' with them is frankly irrelevant
should be treated differently.
In other words, the issue is with problematic operational policies,
rather than with needing to place special technical restrictions on TLDs.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordin
re correct.
The RFC 9091 does not contain the word 'relaxed', so I'm curious about
the basis for your assertion of the limitation.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock..
On 1/29/2022 1:58 PM, Scott Kitterman wrote:
So going
back to Dave's proposed text that started the thread:
On Saturday, January 29, 2022 1:11:29 PM EST Dave Crocker wrote:
Here is some alternative phrasing:
For DMARC, an Organizational Domain can contain a DMARC record, to
be used
discussion and respond to my proposed language... substantially?
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mai
, something that is not a given.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf
stablished and new practice,
without emphasizing either or the excluding the possibility of other
methods.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave
with a larger and more abstract scope.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
h
came from a
creative misreading of my posting.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf
will have (at least) two very different operational
designs with the new one being... new and lacking solid field experience
that gives assurance for uptake. (Thought I said all that in the
original note. Should I have used caps?)
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Voluntee
On 1/26/2022 10:38 AM, John R Levine wrote:
It appears that Dave Crocker said:
The method of finding the organizational domain should be specified
outside of the base DMARC specification. I suggested this back during
the PSD discussion.
That assumes that the org domain is useful on its own
On 1/26/2022 10:04 AM, John Levine wrote:
It appears that Dave Crocker said:
The method of finding the organizational domain should be specified
outside of the base DMARC specification. I suggested this back during
the PSD discussion.
That assumes that the org domain is useful on its own
but as long as
the separation is an open point, that's fine.
thanks!
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing
of the core, leaving only the 'what'.
4. To the extent that there is a view that having tree walk inside the
base spec somehow encourages or forces adoption, experience tends to
show that, instead, it makes the transition confusing. Also, see points
1 & 2, above.
d/
--
Dave Crocker
d
that specifications the 'conditions' 'intent' about
when it /is/ used, then inferring anything by its absence is quite
literally outside the scope of DMARC specification.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordin
imagine some tortured logic where
the tossing or marginalizing of some mail by the receiver is only
beneficial to the domain owner, but I'll claim it fails on the pragmatics.)
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordin
nefit only to the domain owner is simply
incorrect.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ie
, in quotes from the Abstract and Introduction sections
of the current rev of DMARCbis, an alternate viewpoint:
+1
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross
or no policy are not valid substitutes.
That's doubly and impressively wrong.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
d
to embrace. But only maybe.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
h
that
are outside of the DMARC specification. Operational variations are
important, of course, but they really are outside the scope of the
protocol specification.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red C
of the benefits of distinguish the message object specification from the
message transport specification.
Apologies. I've probably entirely missed your point.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red C
/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
a separate operations
or architecture document.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
h
cation makes it seem to carry extra weight.
Which it doesn't. For example, it often seems to be granting permission
or constraint, but it is doing that for something about which the
specification has no power or authority.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Si
clarification and is not providing useful
guidance, then drop that text.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
d
On 12/6/2021 10:06 AM, Scott Kitterman wrote:
OK. What's your recommendation then?
Scott,
I think my note contained a series of very basic recommendations. I'm
not sure what else you are looking for.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
the problematic
view that adding bits of vague or redundant text will provide meaningful
protection against the points of concern. They won't.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.c
r requirements, but a
failure to satisfy these is NOT a DKIM fail. The extra requirements are
outside the scope of the DKIM specification and therefore the failure
has nothing to do with the standard.
This is not a minor point, but it does seem to be a common point of
confusion.
d/
--
D
to see a compelling case for the time, effort and expense.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
d
/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On 10/29/2021 6:40 PM, John Levine wrote:
It appears that Dave Crocker said:
Except that Alessandro's original reference was in the service of
explaining why a mechanism DMARC relies on, for establishing
organization authority, should not necessarily rely on everyone's being
a good actor.
I
to focus
on, had you not chosen to distract from it.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
d
, following all the rules, and
the rules perfectly protect against misbehaviors, which they'd never
think of finding a way around.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.c
of the same action is not what was being
suggested. Rather, a matter of corporate culture was.
I'm not commenting on the company, but do suggest that it helps more to
respond to a point being made than to a point not being made.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer
But it is nice to know who a message is from. ...
That, and the ability to reply to author.
And for the recipient's MUA to organize messages from the same author as
if they were from the same author, rather than from a variety of
different authors.
d/
--
Dave Crocker
dcroc...@gmail.com
On 10/12/2021 3:52 AM, Laura Atkins wrote:
It strikes me that these fields (Original From, Reply To, Original
Author) may be used rather than unmunging as well.
And the purpose of the Author: specification is to suggest there be a
single, common place for this.
d/
--
Dave Crocker
dcroc
that circumvent the
intrusive, destructive effects of DMARC, they requires changes to a long
history of use. The word that you might be looking for, here, is
Procrustean.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordin
both wrong and confusing.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/ma
On 10/8/2021 12:12 PM, John Levine wrote:
It appears that Dave Crocker said:
The purpose of the Author field is to retain some information that
presumably won't get modified. ...
The problem for me is that this is just another entry in the list of
things that are supposed to help peek back
On 10/8/2021 10:44 AM, Alessandro Vesely wrote:
On Fri 08/Oct/2021 18:18:45 +0200 Dave Crocker wrote:
Whether signed fields are validated depends on the signing domain's
policy.
That statement is both true and misleading.
DKIM has a semantic that is not dependent on the choices of folk
/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
identification field that is always present,
that's what DMARC latched on to.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
d
, but not really From any more. Author seeks to
recover a purely From semantic.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross
is nice but is quite different from validation.
Since you are pressing the concern, perhaps you could characterize what
danger/threat and what meaningful protection against it you are looking for?
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information
be DKIM signed is a very different
task and needs to be done within the scope of a specification that
worries about message 'protections' or the like.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red C
and is not subject to modification by
Mediators. This document is published as an Experimental RFC to
assess community interest, functional efficacy, and technical
adequacy.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Plan
/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On 10/7/2021 8:11 AM, Murray S. Kucherawy wrote:
He didn't specify, but I took the suggestion to mean a new document,
not any of the current ones.
The use of DMARC, and its collateral effects, are atypically complex.
So a separate discussion piece would certainly make sense.
d/
--
Dave
, there should
be associated text discussing related mechansisms. The Author spec has
already been mentioned, but the discussion should try to be exhaustive.
ARC and whatever else makes sense, too.
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information
=none outght to
suffice for that?
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
h
On 7/20/2021 7:04 PM, John Levine wrote:
I suppose we should have a Former DMARC Tags registry to prevent them
from being recycled with a different meaning.
Or keep the current entry, changing the specification citation to NONE,
or even just keep the existing one.
d/
--
Dave Crocker
dcroc
e optional. Make its use a matter of private choice, beyond
the four walls of the public protocol specification.
"Deprecated" makes things complicated and conditional. Neither of those
are protocol attributes to aspire to.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volun
On 7/20/2021 7:54 AM, Barry Leiba wrote:
I would like to see us deprecate PCT entirely,
+1
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross
needs to use language of approximations, estimations,
heuristics and trade-offs.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross
On 6/7/2021 3:10 PM, Tim Wicinski wrote:
dmarc-nprequest = "np" *WSP "=" *WSP
( "none" / "quarantine" / "reject" )
I suggest adding a comment that makes the linkage of 'nprequest' to the
prose text explicit.
d/
--
Dave
On 6/7/2021 2:30 PM, Todd Herr wrote:
I have plans to remove the comments when version -02 is released soon.
dandy. tnx. /d
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross
is no longer
needed and might even be confusing.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
h
On 6/3/2021 7:50 PM, Dave Crocker wrote:
(this time without an attachment...)
Interesting. My own MUA is not showing a received copy of any of my
postings of the message through the IETF list. Hence the re-sends,
guessing at why not.
Finally looked at the IETF's IMAP archive
have Domain
Owners whether they are PSOs or not; hence the fact of being a PSO
has minimal import in the Introduction
* General wordsmithing, to tighten things up
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
Amer
* General wordsmithing, to tighten things up
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
DMARCbis-Intro-dcrocker.docx
Description: MS-Word 2007 docu
that is not need in an introduction
* Minimizing PSO text, since I belive the covered domains have Domain
Owners whether they are PSOs or not; hence the fact of being a PSO
has minimal import in the Introduction
* General wordsmithing, to tighten things up
d/
--
Dave Crocker
dcroc...@gmail.com
epresented in
the ABNF. Perhaps the IANA Consideration section should also spell
out that for new tags, the specification should also include the
incorporating ABNF.
+1
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing
, versioning adds the illusion of utility, but really only
adds unnecessary complexity.
Incompatibilities, where new constructs conflict with previous ones,
mean that the new specification is not a new version. It is an
independent specification. It needs to be labeled accordingly.
d/
--
Dave
On 5/7/2021 2:45 PM, Murray S. Kucherawy wrote:
Yeah, but it also means the tools team should probably arrange that
announcements of new I-Ds don't use the dead URLs.
where's the fun in that?
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information
On 5/5/2021 9:26 PM, Seth Blank wrote:
The Chairs ask group participants to explicitly speak up if:
1) they intend to participate in the interim
yes.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red C
DMARC has
relegated it to. The draft for this is being pursued outside of the
working group.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & PLanning Coordinator
American Red Cross
dave.crock...@re
.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & PLanning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
omains remains an active line
of effort for (some) companies.
Consequently, the requirement here is to explain why it isn't scalable,
rather than to simple assert the fact.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & PLanning Coo
main-based Message Authentication, Reporting, and Conformance
(DMARC) permits a domain-controlling
organization to express domain-level policies and preferences for
message validation, disposition, and reporting,
which a mail-receiving organization can use to improve mail handling.
+1
d/
--
Da
a DMARC record that specifies policy for mail sent from addresses
@tax.gov.example. However, due to DMARC's current method of
discovering and applying policy at the organizational domain
level, the non-existent organizational domain of @t4x.gov.example
does not and cannot fall under a
On 2/22/2021 7:49 AM, Douglas Foster wrote:
So what is the best nomenclature for referring to the
"ICANN-authorized registries"? Dave's phrase or something else?
Strictly speaking co.uk is not ICAN-authorized. It's authorized by
mechanisms internal to the UK.
d/
--
Dave Cro
However the rest of the above statement is correct. A transaction to
record gain access to a resource or to reserve access to it.
Registration is a process of signing up. That's all. And it says
nothing about the role or relationship of the entity the registration is
with.
d/
--
Dave
On 2/18/2021 9:10 AM, Murray S. Kucherawy wrote:
Circling back to this:
On Fri, Jan 29, 2021 at 12:56 PM Dave Crocker <mailto:dcroc...@gmail.com>> wrote:
On 1/29/2021 12:15 PM, Murray S. Kucherawy wrote:
On Fri, Jan 29, 2021 at 7:51 AM Dave Crocker mailto:dcroc...@gmail.co
On 2/10/2021 3:24 PM, Douglas Foster wrote:
Huh? Are you asserting that SPF MAILFROM and SPF HELO are
interchangeable? They are not, but they can work together.
Perhaps I misread, but I thought I saw that this really is out of scope
for this working group.
d/
--
Dave Crocker
dcroc
On 2/6/2021 3:57 PM, Kurt Andersen (b) wrote:
+1 - now, if only we had a real voting system :-P
Yeah, 'cause this one is really close, and it's hard to tell what the
decision is...
d/
ps. +1
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
American Red
On 2/2/2021 9:19 AM, Alessandro Vesely wrote:
On Tue 02/Feb/2021 02:42:25 +0100 Dave Crocker wrote:
On 2/1/2021 5:38 PM, John R Levine wrote:
If we want to document existing practice, I guess we would say that
reports should be authenticated and aligned if practical, but it's
OK to send them
On 2/1/2021 6:33 PM, Michael Thomas wrote:
On 2/1/21 6:24 PM, Dave Crocker wrote:
DMARC has been deployed for 6 or 7 years. Where is this onerous abuse
on reporting that you feel is inevitable?
Email was around for 20 years until spam became a problem.
Perhaps you missed the difference
to pragmatics.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
the barrier, rather than those who don't.
The problem with arbitrarily claiming a requirement, without justify it
carefully and in a balanced matter is that it is, well, arbitrary.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock
be authenticated and aligned if practical, but it's OK
to send them if not.
exactly.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc
a hostile work environment.
It's a shame the working group management hasn't put serious effort into
curbing such behavior.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org
/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On 2/1/2021 3:49 PM, Michael Thomas wrote:
It strains credulity that one part of a company would want to send out
reports when some other can't even sign their email. Both need access
to the email stream for starters.
No it doesn't.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
separate
from the 'signing' side of DMARC and could easily be different parts of
a company.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc
On 2/1/2021 10:25 AM, Michael Thomas wrote:
On 2/1/21 10:13 AM, Dave Crocker wrote:
The model that a receiving site is not allowed to report DMARC
traffic unless that site is also generating DMARC authentication is
Procrustean. And as I noted, is likely counter-productive
On 2/1/2021 10:15 AM, Michael Thomas wrote:
On 2/1/21 9:25 AM, Dave Crocker wrote:
So, it's probably a good thing I emphasized:
"It should take a very, very substantial record of reporting problems
to justify such a barrier."
Meanwhile in 2021, the internet is a dangerous p
On 2/1/2021 10:08 AM, Alessandro Vesely wrote:
On Mon 01/Feb/2021 17:38:07 +0100 Dave Crocker wrote:
Consider the challenges to ensuring a DMARC pass. That's a pretty
high barrier to entry against generating reports.
Well, if a mail site is unable to get a DMARC pass, they have more
urgent
On 2/1/2021 9:12 AM, Michael Thomas wrote:
On 2/1/21 8:38 AM, Dave Crocker wrote:
Mostly this will discourage reporting. Legitimate reporting.
Versus illegitimate ones you'd assumedly want to ignore.
So, it's probably a good thing I emphasized:
"It should take a very, very substa
Consider the challenges to ensuring a DMARC pass. That's a pretty high
barrier to entry against generating reports. It should take a very,
very substantial record of reporting problems to justify such a barrier.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Am
On 1/29/2021 12:15 PM, Murray S. Kucherawy wrote:
On Fri, Jan 29, 2021 at 7:51 AM Dave Crocker <mailto:dcroc...@gmail.com>> wrote:
Abstract
DMARC (Domain-based Message Authentication, Reporting, and
Conformance) is a scalable mechanism by which a mail-or
1 - 100 of 581 matches
Mail list logo
