and why; the answers need to be compelling. A
beginning point of consideration can be:
Tussle in cyberspace: defining tomorrow's internet
https://dl.acm.org/doi/10.1145/633025.633059
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
response fully undermines
the necesary firm, direct, disciplinary action.
And yes, I intended this note to go to the list, since my private note
to you apparently was not sufficient.
There is a long-standing pattern of behavior here.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
response fully undermines
the necesary firm, direct, disciplinary action.
And yes, I intended this note to go to the list, since my private note
to you apparently was not sufficient.
There is a long-standing pattern of behavior here.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
others on the list can find something to work with, here, but I
give up.
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
On 9/30/2020 8:39 AM, Seth Blank wrote:
* *
Since quibbling is always more fun than dealing with substance...
Given the recent exchange about 'dispose', perhaps "handling" is a safer
vocabulary choice?
d/
--
Dave Crocker
Brandenburg InternetWorkin
constrains things quite a lot.
In some ways, I fear that the Sender proposal is a solution for the
mailing list problem that throws out almost everything that DMARC added.
Do does From: field re-writing.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_
WAY...
It appears you are working from the original version of the
specification and not the current one.
The current one treats the Sender: field enhancement as an ADDITION, not
an ALTERNATIVE.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon
and approved
specification.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
and approved
specification.
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
, they are not
doing DMARC.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On 9/29/2020 10:56 AM, Dave Crocker wrote:
Sigh, yes. It has caused this misunderstanding, from the start.
It was imposed on the working group by an IETF Area Director and was
agreed to as an expedient.
But, sigh, no. It does not carry any of the semantic import being
claimed in the current
On 9/29/2020 10:46 AM, Alessandro Vesely wrote:
On Tue 29/Sep/2020 19:26:21 +0200 Dave Crocker wrote:
On 9/29/2020 6:40 AM, Hector Santos wrote:
On 9/27/2020 11:44 PM, Dave Crocker wrote:
DKIM has a single signature binding requirement, the 5322.From
DMARC establishes the relationship.
I
On 9/29/2020 6:40 AM, Hector Santos wrote:
On 9/27/2020 11:44 PM, Dave Crocker wrote:
DKIM has a single signature binding requirement, the 5322.From
DMARC establishes the relationship.
I don't read it that way.
DKIM binds the signer d= domain and the from.domain with no
enforcement on it nor
/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
is pretending anything.
2. Since you believe otherwise, please document it.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
that 'disposing of' the message is a domain owner goal,
frequently, perhaps changing "disposed of" to "processed" would be less
inviting of misunderstanding? robustness against reasonable
misunderstanding is helpful... (I could even squeeze in a reference to
the Postel rule, applied to
the
behavior and pretend Step 6 is what will (always) be done.
Protocol specification revision efforts pay attention to established
practice.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org
acceptable results.
Receivers, having their own quality assurance models, immediately
adapted their actions to their own operating criteria, rather than
following the simple, blind directives of random DMARC publishers.
d/
--
Dave Crocker
Brandenburg InternetWorkin
history indicating such information is NOT used by end users.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On 9/27/2020 2:20 AM, Alessandro Vesely wrote:
On Sat 26/Sep/2020 15:06:54 +0200 Dave Crocker wrote:
On 9/26/2020 3:31 AM, Alessandro Vesely wrote:
A pointer to a better aimed report circulated on this list:
An unrefereed presentation (not paper) about a single experiment is
better than
On 9/26/2020 8:41 AM, Scott Kitterman wrote:
On Friday, September 25, 2020 11:03:51 PM EDT Dave Crocker wrote:
Perhaps you have not noticed but the demonstrated field use of DMARC, to
date, tends to be contrary to the design, to the extent anyone thinks
that the design carries a mandate
On 9/26/2020 10:19 AM, John Levine wrote:
I thought he was already in everone's kill file.
John, That's also an ad homen.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman
On 9/26/2020 5:55 AM, Douglas E. Foster wrote:
but you apparently choose not to hear.
that's an ad hominem.
Chairs?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman
in abuse protection?
All of which demonstrates a basic problem with efforts to discuss
human-related work: difficulties in understanding how to evaluate
research and research patterns, with a tendency to instead lean on
confirmation bias.
d/
--
Dave Crocker
Brandenburg Inte
On 9/25/2020 4:21 PM, Scott Kitterman wrote:
On Friday, September 25, 2020 7:05:22 PM EDT Dave Crocker wrote:
I think the obligation to justify is on the advocate for change.
That means you are demanding I prove negative. Which, of course, is an
impossible assignment.
Rather
,
overly-broad assertions and conclusions, without any of the detail that
permits validating the claim.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On 9/25/2020 1:46 PM, Scott Kitterman wrote:
If something like this is going to be
standardized, it shouldn't be called DMARC because it's not.
That was cryptic. Please elaborate on your concerns.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 9/25/2020 11:01 AM, Kurt Andersen (IETF) wrote:
I'd like to call on the chairs to consider bringing a bit more focus
to the discussions so that they could achieve closure more quickly.
+1
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer,Silicon Valley Chapter
American Red
eceiver disposition of the message. IMO.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
-walking.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
their own
boundaries (see https://github.com/jrlevine/bound) then that would be
easy.
And for completeness:
DNS Perimeter Overlay
https://tools.ietf.org/id/draft-dcrocker-dns-perimeter-01.html
(John thinks it's the same as his, but it's not...)
d/
--
Dave Crocker
Brandenburg
on the title page, it says
"pre-MASS"...)
The work in the IETF was a refinement of a complete, integrated spec.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On 8/17/2020 11:53 AM, Dotzero wrote:
Apology accepted. ;-)
nein. maaf.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
in
this space is the lack of careful and precise language when talking
about actions and effects.
So...
DMARC fixes abuse of rfc5322.From field domains.
THAT is the only thing it does.
And it does it at the expense of breaking some legitimate uses.
d/
--
Dave Crocker
Brandenburg InternetWorking
email ecosystem we have today.
This might be quibbling, but I think it kicked a bit more energy into
the anti-abuse industry. So, as a moment to mark in time, it I think it
was useful. But no, not fundamentally for the creation and development
of email anti-abuse work.
d/
--
Dave Crocker
to mention that summit as a conspicuous event
that testifies the emergence of domain-level authentication around the
early 2000s?
No.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org
of valid use that has worked
for 45 years, then those means are problematic. Highly.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
this approach.
There was a debate within the DKIM effort regarding i= vs d= to the
extent that at one industry event people were walking around with
little stickers on their badges to indicate which they supported. I
believe that was courtesy of Dave Crocker.
This was a follow-on issue after DKIM
On 8/16/2020 1:23 AM, Alessandro Vesely wrote:
On Sat 15/Aug/2020 20:12:18 +0200 Dave Crocker wrote:> On 8/15/2020 3:32
AM, Alessandro Vesely wrote:
If X pretends to be Y,
If I put my gmail address into the from field, there is no pretending,
no matter what platform I am us
you think these services are /for/?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On 8/15/2020 3:59 PM, John R Levine wrote:
On Sat, 15 Aug 2020, Dave Crocker wrote:
My comment was not about your opinion of either of the drafts but of
your impatience with considering one you don't like.
Um, if one thinks something is a bad idea, why should we spend more time
on it?
Out
.
2. Integrated
Merging them makes it more likely that the result really is
integrated and seamless.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
orthongonal to my comment.
My comment was not about your opinion of either of the drafts but of
your impatience with considering one you don't like.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https
impediment to constructive
discussion in the industry.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
to
that filtering engine.
"Local policy" is always and entirely in charge of what happens
locally. Everything else is subservient.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.o
Steve, et al,
On 8/12/2020 8:16 AM, Steve Atkins wrote:
On 12/08/2020 04:32, Dave Crocker wrote:
Here's why I think it won't: They already have From:.
The real value in DMARC is not what is displayed to the end-user but
in having a required field that cites the originating domain name
various ideas or proposals and for many of
them thinking "I've no idea whether that will be useful or successful
but it sounds like something worth trying." Not so much these days. Alas.
d/
--
Dave Crocker
Brandenburg InternetWorkin
On 8/12/2020 6:23 AM, Neil Anuskiewicz wrote:
IETF are more relaxed than I expected.
Don't believe it. The advice was warranted.
d/;
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org
On 8/12/2020 5:55 AM, Neil Anuskiewicz wrote:
On Wed, Aug 12, 2020 at 5:13 AM Dave Crocker <mailto:d...@dcrocker.net>> wrote:
On 8/12/2020 4:45 AM, Neil Anuskiewicz wrote:
> Mr. Crocker, is there a document that describes some of these
proposals
> and p
in that development. FAQs, for example, come
later, for wider consumption.
If you have particular questions, ask them.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
s it's own problems.
There's no perfection here, since the task is retro-fitting work-arounds
to an established mechanism that has been altered. As I've noted,
realistically, DMARC makes the From: field be the Sender: field.
d/
--
Dave Crocker
Brandenburg InternetWorkin
Folks,
I was quite surprised -- at the level of astonished -- to see the
pushback on the Author header-field proposal, since it is such a simple
and straightforward mechanism.
I'd like to ask for clarity from the group on both concerns about it and
desires for it.
d/
--
Dave Crocker
that, and honestly see no chance that we ever will.
+1
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
a mailing list is not a 'relay'. The term relay is meant to
refer to an MTA.
Reviewing RFC 5598 might help.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
ing a need to do
something and at first blush this seems to be something.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
no longer be transparent, as it is today.
+1
When someone proposes a scheme, it will help for them to list who the
relevant actors must be and what they must do and then deal with the
question of scaling. That is, how will it be possible for this to work
at Internet scale?
d/
--
Dave Crocker
B
the
better answers. (And so, really, I don't mean a BCP, but rather a
'considerations' doc.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
cially
since that's what it actually is.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
of DMARC, because the issue and
the mechanism are not specific to DMARC.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On 7/28/2020 7:20 AM, Alessandro Vesely wrote:
On Tue 28/Jul/2020 13:09:29 +0200 Dave Crocker wrote:
On 7/28/2020 4:00 AM, Alessandro Vesely wrote:
On Tue 28/Jul/2020 12:37:32 +0200 Dave Crocker wrote:
On 7/28/2020 12:26 AM, Alessandro Vesely wrote:
Receivers can evaluate the Author: domain
tic and
operational challenges.
I think that could reasonably make it worth strongly separating them
into two different documents, no matter has small one of the documents
might be.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmar
On 7/28/2020 4:00 AM, Alessandro Vesely wrote:
On Tue 28/Jul/2020 12:37:32 +0200 Dave Crocker wrote:
On 7/28/2020 12:26 AM, Alessandro Vesely wrote:
Receivers can evaluate the Author: domain just like they would do if
it were the From: domain.
So you want to define DMARC as applying to both
On 7/28/2020 12:26 AM, Alessandro Vesely wrote:
On Mon 27/Jul/2020 20:51:54 +0200 Dave Crocker wrote:
On 7/27/2020 11:15 AM, Alessandro Vesely wrote:
If receivers lookup the Author: domain too, they can evaluate
authentication and alignment also with respect to that domain.
Since
e end-user system would not use that tag. I
think this is the distinction that should be made, for mailing lists
to work but sensitive data to be more protected than end-user mail.
I don't understand what you are suggesting or how it would work usefully.
d/
--
Dave Crocker
Brandenburg InternetWorkin
n addition to/. The heuristic of "until it sees that all (or most)
receivers look for Sender:" sounds nice, but is entirely indefinite.
Worse, as you note, the 'how' doesn't have an answer. So the spec does
not suggest any meaningful endpoint.
d/
--
Dave Croc
.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Forwarded Message
Subject: New Version Notification for draft-crocker-dmarc-sender-01.txt
Date: Mon, 27 Jul 2020 05:16:07 -0700
From: internet-dra...@ietf.org
To: Dave Crocker
A new version of I-D, draft-crocker-dmarc-sender-01.txt
has been successfully submitted by Dave
Forwarded Message
Subject: New Version Notification for draft-crocker-dmarc-author-01.txt
Date: Mon, 27 Jul 2020 05:09:25 -0700
From: internet-dra...@ietf.org
To: Dave Crocker
A new version of I-D, draft-crocker-dmarc-author-01.txt
has been successfully submitted by Dave
.
Please provide objective data that these signals are being perceived and
used effectively by end users.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On 7/26/2020 10:10 AM, Jim Fenton wrote:
On 7/26/20 6:42 AM, Dave Crocker wrote:
On 7/21/2020 12:32 PM, Dotzero wrote:
The original DMARC effort was, in fact, to detect actual cases of
spoofing, namely unauthorized use of a domain name by outside
actors.
Different problem
they actually
do. Behavior.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
the denotational
source of authoring information, in order to get the mail delivered,
then we are in new territory.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo
senders.
What you describe was, rather, the basis for the later use, which is
what then started causing problems for mail going through Mediators.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https
-related decision making/ that is the goal of
these protection mechanisms.
They certainly /are/ relevant to the sorting/searching/presentation
issues that are disrupted by having mail authored by the same person
contain different From: field data.
d/
--
Dave Crocker
Brandenburg InternetWorking
On 7/20/2020 1:44 AM, Alessandro Vesely wrote:
On Sun 19/Jul/2020 20:33:46 +0200 Dave Crocker wrote:
The essential point that needs to be made is that standards like this
MUST NOT be cast in terms of what end users will do. In practical
terms, this work has nothing to do with end users
their
time only for things that require real-time interaction.
Asking for status updates to be posted before the session leaves open
the possibility of raising questions or comments, as follow-on, without
taking time for the basic 'presentation'.
d/
--
Dave Crocker
Brandenburg InternetWorking
ents apply to actors that have chosen to be inside the sandbox.
So, normative language in specifications is meaningful only when it will
be followed. Giving directives to actors not participating in the topic
of the specification is wasteful and likely misleading.
d/
--
Dave Crocker
B
.
To the extent any of that text makes assertions about the performance of
end users, it needs to cite the basis for the assertions.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman
Calvin.
The full discription of TCTALK is available via the net and is in
essense Calvins CASE thesis. Contact CAlvin for that.
Dave
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/li
On 7/21/2020 12:32 PM, Dotzero wrote:
On Tue, Jul 21, 2020 at 2:06 PM Dave Crocker <mailto:dcroc...@bbiw.net>> wrote:
On 7/21/2020 10:58 AM, Dotzero wrote:
For this case, DMARC externalizes that internal personnel problem.
But it does not fit the definition of
On 7/21/2020 10:58 AM, Dotzero wrote:
On Tue, Jul 21, 2020 at 11:52 AM Dave Crocker <mailto:d...@dcrocker.net>> wrote:
The mail is not spoofed. Consider the definition of the word. Then
consider that the MLM is authorized by the user with the address in the
original F
by the user with the address in the
original From field.
Also then consider that the existing MLM behavior has existed and been
useful for roughly 45 years.
The problem, here, is DMARC's imposing a change in email semantics.
d/
--
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
filtering engines, of course.) Not the MUA.
d/
(*) Obviously, if you have some data to the contrary...
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On 7/19/2020 5:04 PM, Murray S. Kucherawy wrote:
On Sun, Jul 19, 2020 at 11:33 AM Dave Crocker <mailto:dcroc...@gmail.com>> wrote:
The track record is that people are unreliable at this.
There is quite a bit of distance between 'unreliable' and 'blindly
open and read a
deceived. I'll claim that
while true, it is not relevant, since the behavior happens after DMARC,
and the like, are relevant. That is, DMARC, etc., do not inform the
end-user behavior.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc
/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On 7/18/2020 9:23 PM, Murray S. Kucherawy wrote:
On Sat, Jul 18, 2020 at 6:32 PM Dave Crocker <mailto:dcroc...@gmail.com>> wrote:
If end users do not reliably make trust decisions based on /any/
of the
information in the rfc5322.From field, then how is this question
-name text. No email address for
any of the messages. As far as I can tell, I have no address book at gmail.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
something that
isn't even secondary.
The persistence of thinking that end users are influenced by trust
indicators is pernicious.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org
On 7/17/2020 2:00 PM, Dave Crocker on behalf of Kurt Andersen wrote:
Do we have any recent numbers on how many users see the From address rather
than or in addition to the display name?
Thereby making clear that this is a spoofed message, since I wouldn't
ask a question like that, potentially
In article you write:
>> I'd counter by personal anecdote that we have had to undertake
>> security remediations because of messages which were forwarded by our
>> CEO to other employees for responses which happened to contain malware
>> and/or bad links. ...
>Except that the problem isn't
they align properly.
(I suspect there's some irony in my choosing 'align' but it was not
intentional, though I'll take the extra point for noting it.)
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf
completely forgotten that Delaney
did that.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On 7/14/2020 10:56 AM, Jim Fenton wrote:
Not specific to Dave's comment above,
Since this is a larger question and, as you note, not specific to my
drafts, please post it under a separate Subject and thread, rather that
confuse the focus of the current thread.
d/
--
Dave Crocker
On 7/14/2020 10:42 AM, Alessandro Vesely wrote:
On 14/07/2020 19:30, Dave Crocker wrote:
Forgive me, but I do not understand how your note, in any way,
responded to the substance of my query.
The bad thing is that _dmarc.fm.bank looses the effect of stopping
phishing attempts, as the Sender
to painstakingly check
From:, and if they get phished I can tell them they're morons.
Forgive me, but I do not understand how your note, in any way, responded
to the substance of my query.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc
On 7/14/2020 8:39 AM, John Levine wrote:
In article <83b1a66f-a2c4-4848-01f9-6de740a0c...@gmail.com>,
Dave Crocker wrote:
On 7/14/2020 2:52 AM, Alessandro Vesely wrote:
And phishers can also send mail From: fm.bank and Sender:
regleissei.icu. To publish a DMARC policy would avail F
sending address in the "From:" header.
and it did not change with DKIM followed up:
DKIM eliminated use of the 822.sender field.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On 7/14/2020 6:48 AM, Hector Santos wrote:
It will modify all specs related to DKIM where there is an Author
(5322.From) design requirement.
It does not need to affect DKIM at all.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
201 - 300 of 581 matches
Mail list logo
