unt for the example.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
clear, explicit justification for each of the
choices, since it is clear that the goal is quite different from what
DKIM originally intended the header field linkages for.
Absent such justification, the list is arbitrary and even whimsical.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bl
t will the incremental cost be, to the global infrastructure,
when getting everyone to do all of the changes being proposed?
If 0.5% is considered important, it's reasonable to look for the other
side of cost/benefit.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.b
rather than the abstract email architecture.
If a message gets to its specified address, the handling of the message,
at that point, is not being done as part of MTA functionality.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@
errides.
having the expansion event documented informs those heuristics
I thought the goal is to get away from needing heuristics for this problem?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
_
tion between these, it appears
you are proposing a change to SMTP.
note that systems which know there is not a correlation can generate a
DKIM2 header to show the correlation -- the entity that signs that DKIM2
header will be taking some responsibility (to coin a phrase) for that
>
hich may still be useful in a
DKIM2 world if attacks continue -- which they may not since they will be
far less likely to be widely successful)
Since I explained why it likely does not help, what we need is a
response that covers the substance of how it does, rather than simply
getting a declaration of assurance that it does.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
Solving a non-problem.
> A mailing list is generating a new message posting. It can choose
the SMTP
> Mail
>From to be anything it wants, including itself, and this is common.
So this is
> not a problem and does not require additional mechanism.
We will have to differ there.
n about
As noted previously, -- but not responded to -- this is solved by having
the system creating the new addressee replace the SMTP Mail From address.
Unless, of course, the new recipient does a reply...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bs
there's a carbon footprint issue
here that we should not ignore without careful consideration
What percentage of an average email is that?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.s
e of our aims was to enable intermediate entities
(such as mailing lists and ESPs) to become aware of delivery failures.
Again: why?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
_
quate
controls over users, on some platforms.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
On 4/11/2025 12:56 PM, Richard Clayton wrote:
At the end of January Dave Crocker posted a review of the then current
"-01" version of draft-gondwana-dkim2-motivation. This document has now
been split into an "-02" and draft-gondwana-dkim2-headers (-01).
And it is unfortunat
ing: 3. enthusiasm for…. Learn more.
🔗 https://dictionary.cambridge.org/dictionary/english/motivation
<https://dictionary.cambridge.org/dictionary/english/motivation>
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
_
about preferences -- is the how.
Since you read the charter quite differently, please cite and explain
the portions that leave open the `what issues´.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
On 4/8/2025 5:43 AM, Alessandro Vesely wrote:
On Sun 06/Apr/2025 20:56:35 +0200 Dave Crocker wrote:
...
The semantics of the new effort really are orthogonal to DKIM. (And
that is one of the reaon the technical errors in the Motivation draft
demonstrate a fundamental misunderstanding, rather
f import to a very, very narrow
demographic, whereas the much larger demographic is a lot more likely to
more attention to basic email functionality than to abstract network
architecture placement.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcr
rely
different from what DKIM intended to do.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email
On 3/24/2025 8:05 AM, Murray S. Kucherawy wrote:
I agree that such a world is possible -- I mean, anything is possible
-- but I would really like such a change to come from below rather
than above.
+10.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast
On 4/1/2025 8:42 PM, Pete Resnick wrote:
On 1 Apr 2025, at 22:30, Dave Crocker wrote:
When calling to have a wg adopt a draft, it is worth reviewing
comments on that draft beforehand
The draft version that was called for adoption is drastically
different than the draft on which you commented
omewhat more interesting: Having mailing lists just bypass DMARC
protections by changing the *22.From address. (This, of course, does
nothing about the Display-Name, there, which is what recipients see --
and they usually do not see the address. And it does nothing about the
phishyness of the
he header field altogether.
Yup.
If it is upward compatible, the new features self-announce. No version
mark needed.
If it not upward compatible, it is a new protocol.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@
would be created, to find a name for the
collection of the fields. (Yeah, we could say "the collection of the
headers", but, well...)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
___
I would have thought that was obvious.
Nice, the way this provided a mutual learning opportunity. One learns
why you did a thing. You learn that obvious to you isn't automatically
obvious to others.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.s
has
correlated with it.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
,
rather than casting the new work as something that everyone will
transition to.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To
y screen.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
nt to the entity and not the provider. ->
as they are not sent the notifications
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
___
Ietf-dkim mailing list -- ietf-dkim@ietf.
about DKIM
Replay, I believe it did not become a chartered working group.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsub
On 2/4/2025 8:30 PM, Wei Chuang wrote:
Recall there was a prior WG in 2023 effort to tackle replay that
failed due to a lack of participation by the community
which working group was that?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker
been spared my outburst...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
t email abuse. That
include you. And me. And everyone else on this list.
Really.
And this is a sufficiently tired topic that the burden on anyone making
a claim of utility needs to provide serious, credible evidence. Because
they won't be able to.
d/
--
Dave Crocker
Brandenburg Interne
On 2/4/2025 5:24 PM, Wei Chuang wrote:
On Tue, Feb 4, 2025 at 4:28 PM Dave Crocker wrote:
On 2/4/2025 4:20 PM, John Levine wrote:
It appears that Dave Crocker <mailto:dcroc...@bbiw.net>
said:
If your above statement is true, then why is it necessary to do the
re
On 2/4/2025 4:20 PM, John Levine wrote:
It appears that Dave Crocker said:
If your above statement is true, then why is it necessary to do the
reversal?
So you can tell if the earlier signatures in the chain were real.
A DKIM signature is self-validating.
Why doesn't one handler
of abuse, but
this question goes to the nature of responsibility for handlers:
Why doesn't one handler's taking responsibility eliminate the need to
worry about the predecessors.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast:
ks it is relevant to (and how), and its
efficacy is easily assessed.
(*) "Substance of a message" will, of course, need careful and precise
definition.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
On 2/3/2025 8:58 PM, Murray S. Kucherawy wrote:
On Sat, Feb 1, 2025 at 10:00 AM Dave Crocker wrote:
As such, an honest and pragmatic charter needs to cite that draft
and needs to explicitly encourage consideration of alternatives.
I think I'm fine with adding something like
e of what is needed, and the
desire was to permit some exploration.
Just as it is fine to use the experience to later converge on more
restriction in choice.
That's a process that isn't exotic. It's mature.
Which calling the original arrangement exotic isn'
e problems they
consider to be important to them -- and those problems include code
complexity, latency and energy budgets.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
___
Ietf-dk
ov 2025
*
Implementation guide: Nov 2025
*
Publish documents as a group: Dec 2025
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
___
Ietf-dkim mailing list -- ietf-dkim@ietf.o
ather than insisting on creating a hostile
work environment?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send a
n practice.
But again, my original point on this sub-trhead is that Author: is
trivial, not fragile, and based on constructs that have been used in
email from its start. It does not address the larger problem, but it
does address From field munging.
d/
--
Dave Crocker
Brandenburg InternetWorkin
ut if that server needs to forward the email elsewhere it may
find that there is no signing key available for the relevant domain
(recalling that the incoming email recorded the destination domain
and it is necessary for the next "hop" to match with that. In such a
case, o
.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
een aware of it. Please
provide the citation.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email
2021
https://www.rfc-editor.org/info/rfc9057
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to
ed in transit.
In effect, ARC says "I broke the signature, but before I did, it
validated (or didn't)" and then ARC creates a chain of identifier
certifications by the breaking entity, their assertion, and every
handler after that.
d/
--
Dave Crocker
Brandenburg InternetWork
It really will help community discussion to include a pointer
to their draft. And yes, being careful about casting its role would be
a good idea.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@masto
On 1/27/2025 10:28 PM, Murray S. Kucherawy wrote:
On Fri, Jan 24, 2025 at 5:51 AM Dave Crocker wrote:
An Internet message (email) may, from creation to final delivery,
pass through multiple intermediaries, some of which simply handle
and route the message, others affecting an
re it completely.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
* An Applicability Statement guiding implementation during any
deployment period, in which interoperability with existing mechanisms
needs to be maintained (Standards Track)
Given that 'implementation' is an ambiguous term, differently referring
to writing code, versus deploying, I sugges
ed to be clear about whether this
is expected to be an extension of existing DKIM or ultimately a
replacement of it? Or are we keeping our options open, which is what
the current text seems to be doing?
the draft specification makes very clear it is a brand new protocol.
d/
--
Dave
pgrade path.
There is no 'upgrade' between independent, incompatible protocols.
There is just adoption of the new and, possibly, dropping the old.
If someone thinks otherwise, then please provide a substantive explanation.
/d
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
***
a DNS issue and not a DKIM issue.
That is, if there is serious, Internet-wide concern for that kind of DNS
protection, it is the job of the DNS community to provide it,m rather
than the job of a particular service or application using the DNS.
d/
--
Dave Crocker
Brandenburg InternetWorking
On 12/9/2024 8:59 AM, John Levine via mailop wrote:
I ask because I've ben looking at a paper that asserts that the number
is about 50% and has been for a long time, which just seems wrong.
If the paper is published, what is the citation to it?
d/
--
Dave Crocker
Brandenburg InternetWo
h a fair amount of
participation in the IETF.
Besides Google, Microsoft already has a similar faciliaty in email.
Sure would be nice for them to adapt to the RFC specification...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
*** bluesky: @dcrocker.bsky.social ***
mast: @dcrocker@
On 12/2/2024 5:52 PM, Stephen Farrell wrote:
On 03/12/2024 00:40, Dave Crocker wrote:
I gave reasons for suggesting this is IRTF work.
In the message to which I was reacting you said:
* As provided, this is an extremely broad and extremely vague
statement of work. It continues to sound
On 11/27/2024 7:47 PM, Stephen Farrell wrote:
I do not think this proposed work is research nor ought it
be related to the IRTF in any shape or form.
Stephen,
Howdy.
I gave reasons for suggesting this is IRTF work. It might help for you
to offer your reasons for disagreeing?
d/
--
Dave
They put dates in. I reacted to those estimates.
btw, I heard similar rumors about IETF desires to refrain from putting
dates in. Given history, it's an understandable view.
However given project management realities, the problem is failure to
take dates seriously and manage to them. Hen
s) adopted: Mar 2025
Only two more months for a stable specification effort? Really?
* Experiments and updated drafts: Apr 2025 - Nov 2025
* Implementation guide adopted: Nov 2025
* Group of documents sent to IESG: Dec 2025
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
*** blue
waying, is to look for what
information is lost in the transition.
If the two mail services really are different -- and hence need
gatewaying rather than just relaying -- some information will be lost in
one or both directions.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
**
s not DKIM.
DMARC 'uses bits of' DKIM. It is not DKIM either.
And since it runs in parallel to actual DKIM, it /really/ isn't DKIM.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
*** bluesky: @dcrocker.bsky.social ***
mast:
believe
they never prove useful.
If the protocol is upward compatible, the new features speak for
themselves, and the version number is irrelevant.
If the protocol is not upward compatible, the version number is
insufficient.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
*** bluesky
dy of experience showing it
works on essentially all email traffic.
That's not meant to argue against it, but rather to place the construct
in an area of unknown reliability, efficacy and usability, so that there
is effort to move to a place of engineering knowns.
d/
--
Dave Crocker
Brande
ement rather than upgrade.
Plans for global 'migration' of an Internet service tend to be overly
optimistic about the nature and timing of adoption of the new and
deprecation of the old. By decades.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
*** bl
what the term means.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
*** bluesky: @dcrocker.bsky.social ***
mast: @dcrocker@mastodon.social
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
irect mail.
Please p[oint to published data that supports your claim.
d/
ps DMARC is trivially defeated. This is demostrated by every
intermediary that simply alters the From: address.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
*** bluesky: @dcrocker.bsky.social ***
mast: @dcr
On 11/15/2024 10:55 AM, Alessandro Vesely wrote:
Just a side note...
On 13/11/2024 21:14, Dave Crocker wrote:
While 'indirect' has well-established context in many email technical
circles, I believe it does not have clear, consistent, and precise
meaning. So it needs to be defined
ld thing
-- and will be a lot hard to get widespread adoption.)
This working group will also update the following existing document(s):
* DMARC to add DKIM2 as an additional authentication mechanism
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
*** bluesky: @dcrocker.bsky
rvice like DKIM that involves many
different, independent parts.
So, when the work is done, how will successful satisfaction of this
requirement be tested?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@
On 10/21/2024 4:39 AM, Alessandro Vesely via mailop wrote:
On Mon 21/Oct/2024 05:50:09 +0200 Dave Crocker wrote:
In other words, to get around DMARC fragility and false positive
damage, an intermediary must
1. Break DMARC, by changing the rfc5322.From address to be something
other
than
to permit.
Collateral damage abounds.
DMARC has turned the From field into what the Sender field was intended
to provide; it now primarily servies to specify the handling platform.
If the author address survives in the From: field, that is merely a
collateral benefit, but not required.
d/
--
Da
can be assumed to have no 'outside' sources. This
let's you evaluate the stream as if there is no 'noise' to the stream.
What it does not tell you is whether the actor associated with the
identifier is good or bad.
d/
--
Dave Crocker
Brandenburg InternetWorkin
about practice, rather than theory. Where are
the numbers that show this utility to be actually significant?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https
with DMARC's goal.
Perhaps eep simple SPF as an independent capability, but definitely
remove it from DMARC.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
the sender, but a) it
ignores issues with receivers, and b) it ignores multi-hop scenarios.
3. DKIM -- right. So difficult, almost no one uses it. And it's not as
if the rest of email operations have gotten complicated, right?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbi
he network layer.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
orate?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
ncremental
benefit is real and substantial, never-mind enough to warrant adding its
complexity to the mix of email operations challenges.
Please consider: If SPF were deprecated, was would be the actual,
significant effects on email anti-abuse processes?
d/
--
Dave Crocker
Brandenburg Inter
On 10/14/2024 7:12 AM, Matus UHLAR - fantomas via mailop wrote:
"can be trivial"
For technology, (and most other contexts) "can be" is a code phrase for
"isn't". Especially when already deployed.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw
I wonder whether anyone has noticed that a thread like this demonstrates
that SPF is far from trivial?
d/
On 10/13/2024 2:47 AM, Gellner, Oliver via mailop wrote:
which denies everything as the redirect will never be reached.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast
macros and the nesting/indirection, especially.
d/
On 10/11/2024 1:56 PM, Mark E. Mallett via mailop wrote:
The
macro handling, f
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop
work is trivial, where fully considering the
details and implications actually are quite far from trivial.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mail
fragile and its use more restricted.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
On 10/9/2024 11:32 PM, Thomas Walter via mailop wrote:
On 09.10.24 21:59, Dave Crocker via mailop wrote:
Since the primary function of the SMTP Mail From command is to specify
an address for receiving email handling problem notices, alignment with
the rfc5322.From field domain would seem to be
On 10/10/2024 6:19 AM, Ralph Seichter via mailop wrote:
* Dave Crocker:
Longer-term use has, at least, operational import, for access to the
DKIM key and for access to the message in its signed form. Neither of
these is automatically cheap, given operational vagaries and given the
tions they develop.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
avoided is
still a threat.
Do you have any indication that the use of x= is actually effective for
reducing replay attacks?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop
ttack discussions on the DKIM list, this point was
noted.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
t just how useful it is.
Including it adds to DMARC's operational complexity and when SPF is
relied on, it makes DMARC's scope of use smaller, given the path
limitations.
If SPF support were eliminated from DMARC, what actual change in DMARC
utility would this have?
d/
--
Dave
systems do to the messages they handle.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
complexity and complexity breeds errors.
No?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
field domain would seem to be secondary, at best.
So while the facts you list are no doubt accurate, calling this a
'limitation' seems problematic.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mail
't recall any controversy about it. The
larger lesson to take from it is to think very hard about longer-term
transitions that it might require. In this case, going from
'non-standard' to 'standard' rendered the construct significantly
problematic.
--
Dave Crocker
B
ces. it's
not fine to think they will apply to others, at any scale.
It's also not fine to think it will be cost effective for a mass-market
product to cater to your unrepresentative preferences. They might, but
they also might not.
d/
--
Dave Crocker
Brandenburg InternetW
On 8/27/2024 3:59 PM, Michael Peddemors via mailop wrote:
hey should restrict MAIL FROM to only addresses on their email server?
why?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
nts. As a small example, some originators set
p=reject inappropriately. That is, the originating sites are not
configured or operated well enough to make reject that right choice.
So, yes, your DMARC 'policy' can be ignored or adjusted.
d/
--
Dave Crocker
Brandenburg InternetW
ant to the current topic.
The current topic is about defining timeouts based on expected
distance-related performance. The story is, instead, about sometimes
having a bug depend on distance.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@masto
On 8/14/2024 3:17 PM, Slavko via mailop wrote:
Dňa 14. augusta 2024 13:48:38 UTC používateľ Dave Crocker via
mailop napísal:
Making a distance-sensitive assumption about traffic behavior is a suprisingly
bad idea for anything having to do with the Internet. Resources and their uses
can be
-sensitive assumptions might make sense is when
the interaction is known to be -- and must be --- part of a LAN that
both parties are on. Maybe.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing
1 - 100 of 2675 matches
Mail list logo
