) seal ARC, workarounds
like this are unfortunately necessary.
- Mark Alley
On Wed, May 8, 2024, 5:48 AM Laura Atkins wrote:
>
>
> On 8 May 2024, at 02:25, Scott Kitterman wrote:
>
> On Tuesday, May 7, 2024 9:09:02 PM EDT Mark Alley wrote:
>
> On 5/7/2024 7:00 PM, Dot
that would be acceptable language in an Standards track
document to encourage urgency behind a transitory state of p=none use by
domain owners? Would that even make sense to do? (Legitimate question
for the WG)
- Mark Alley
___
dmarc mailing list -- dmar
in the thread), there's still valid, expected, and reasonable
use cases of it as it stands today. Personally, I don't see a need for
it to be deprecated.
- Mark Alley
On 4/7/2024 7:52 AM, Neil Anuskiewicz wrote:
Forgive me if this a dumb idea but, Scott and others, any discussion of just
deprecating SPF
now
any better.
I don't think it's fair to characterize SPF -all's entire usage based on
the assumption everyone knows what it does, when reality demonstrates
otherwise.
- Mark Alley
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Agreed as well. It's worth calling out, IMO.
- Mark Alley
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
presumed the reader has a working conceptual understanding of DNS; I see
your point how it could add only more questions.
- Mark Alley
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On 3/14/2024 3:49 PM, Todd Herr wrote:
On Thu, Mar 14, 2024 at 4:43 PM Mark Alley
wrote:
On 3/14/2024 3:38 PM, Todd Herr wrote:
On Thu, Mar 14, 2024 at 4:34 PM Scott Kitterman
wrote:
I think this is correct. I think it's obviously enough
correct that I'm
- Mark Alley
On 3/14/2024 3:38 PM, Todd Herr wrote:
On Thu, Mar 14, 2024 at 4:34 PM Scott Kitterman
wrote:
I think this is correct. I think it's obviously enough correct
that I'm surprised anyone was confused.
Do we know what the theory was that led people to think otherwise
If we need some real world examples of this, got a few here:
_dmarc.oit.alabama.gov
_dmarc.tjx.com
_dmarc.walmart.com
_dmarc.novanta.com
- Mark Alley
On 3/14/2024 3:18 PM, Todd Herr wrote:
Colleagues,
There was a discussion among M3AAWG members on March 13 that centered
on the question
or willful negligence.
- Mark Alley
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
questions of the WG about these two sections
in the future, because they're not consistent.
- Mark Alley
On 2/29/2024 1:47 PM, Scott Kitterman wrote:
Okay. I think 8.6 is the one in error. You see how this is going to go, right?
Scott K
On February 29, 2024 7:45:15 PM UTC, Todd
Herr wrote
of the section seems pretty clear to me (barring
the suggestion I raised for clarification), if you publish a strict
DMARC policy, one also wants to sign valid, aligned DKIM as well to pass
DMARC.
- Mark Alley
On 1/9/2024 7:07 AM, Benny Pedersen wrote:
Alessandro Vesely skrev den 2024-01-09 12:35
cure a DMARC pass, and *MUST *apply valid
*aligned *DKIM signatures to their messages./"
- Mark Alley
On 1/2/2024 2:30 PM, Mark Alley wrote:
Quick question I had while re-reading 8.6 - for this text below, might
just be me on this one though.
"/It is therefore critical that domains
valid DKIM signature, not one that specifically aligned
with their domain.
- Mark Alley
On 1/2/2024 2:12 PM, Todd Herr wrote:
Revision 28 was due to expire this weekend, so I tweaked the language
a bit in section 8.6 in response to the thread Francesca started here
- https://mailarchive.ietf.or
of time before we see any semblance of ubiquitous
adoption.
I'm on the fence currently about the auth= method.
- Mark Alley
On Sun, Oct 29, 2023, 2:35 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Reporting allows certainty within the limits of the reporting mechan
filtering; if a sender used the latter two (~ or -) instead of
neutral (?), it would only cause more issues.
But as you stated, I agree the handling of the neutral qualifier is most
likely non-standardized across the internet.
- Mark Alley
On Sun, Oct 29, 2023, 1:39 AM Wei Chuang
wrote:
>
painting a potato red, and calling it a tomato. It
still tastes like a potato.
-Mark Alley
On Sat, Oct 28, 2023, 3:04 PM Emanuel Schorsch wrote:
> As to why, I don't think there's a valid use case and the proponents for
>> this haven't really thought it through. As an example, someone
rs rolling non-standard DMARC
evaluation logic with liberal interpretations of expected syntax and tags,
even though the ABNF and section 5.3 are explicit with instruction on how
to proceed in those cases.
- Mark Alley
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
+1 for SHOULD NOT.
On Tue, Oct 24, 2023, 12:14 PM Matt V wrote:
> I also agree that "SHOULD NOT" would be my vote as the preferred language
> going forward.
>
> ~
> Matt
>
> On Tue, Oct 24, 2023 at 12:41 PM Dotzero wrote:
>
>> I'd like to first thank Francesca for taking the time to review
lly implied through the existing ABNF(s),
but given the simplicity and conciseness of the language Murray provided
from the DKIM RFC, I concur it may be worth at least stating it
explicitly for clarity in bis.
- Mark Alley
___
dmarc mailing list
dm
[dmarc-sep]
; components other than dmarc-version and
; dmarc-request may appear in any order
- Mark Alley
On 7/24/2023 10:05 AM, OLIVIER HUREAU wrote:
I am wondering how a parser should behave when the record contains two
identical tags.
i.e: 'v=DMARC1; p=none;
To supplement Oliver's reply, and Doug's question, most commercial secure
email gateways are capable of this in terms of granular inbound email
authentication customization. (Proofpoint, Mimecast, Cisco, Barracuda, etc.)
- Mark Alley
On Thu, Jul 20, 2023, 4:15 AM OLIVIER HUREAU <
olivier.
On 7/19/2023 8:10 AM, Murray S. Kucherawy wrote:
On Wed, Jul 19, 2023 at 12:27 AM Alessandro Vesely wrote:
> How do you determine that an evaluator is enforcing DMARC
"against lists"?
That assumes there are lists that don't munge From:. Is that real
today?
I wasn't aware
- reject (wv.gov)
- Mark Alley
On 4/18/2023 5:25 PM, Jim Fenton wrote:
On 9 Apr 2023, at 11:33, Barry Leiba wrote:
There is an alternative, though: we can acknowledge that because of how
those deploying DMARC view their needs over interoperability, DMARC is not
appropriate as an IETF standard
own issues and
workarounds.
If I'm being honest, given the different versions put forth so far, it
seems like this type of language is closer to the compromise on the
interoperability statement. The other versions say relatively the same
thing.
- Mark Alley
On Fri, Apr 14, 2023, 7:08 PM Scott Kitter
mechanism check."
No ESP I'm aware of evaluates a DMARC failure result if *any* of the
authentication methods produces a failure. That is definitely not expected
behavior.
Do you have examples of any ESPs that deviate from this?
- Mark Alley
On Fri, Apr 14, 2023, 8:42 PM Hector Santos wrote:
I can agree with the premise of this version. This expanded definition of
"general purpose" domains makes it somewhat more clear what/who the
intended target for the language is.
- Mark Alley
On Fri, Apr 14, 2023, 4:16 AM Matthäus Wander wrote:
> Barry Leiba wrote on 202
+1
On 4/13/2023 10:21 AM, Barry Leiba wrote:
Anyone who does forwarding is damaged by DMARC because there are a lot of
people who do DMARC on the cheap with SPF only.
This brings up another issue, I think: that there should also be
stronger advice that using DKIM is critical to DMARC
a statement about perceived security benefits of strict DMARC
policies... - My hope is that should be sufficient enough of a
compromise to address everyone's concerns.
- Mark Alley
On 4/11/2023 10:15 AM, Neil Anuskiewicz wrote:
On Apr 11, 2023, at 4:29 AM, Douglas
Foster wrote:
Neil, I am
rate receivers handle the policy. Point is, it
seems conflicting to have two documents telling (and expecting) domain
owners to do different things.
- Mark Alley
On 4/9/2023 1:33 PM, Barry Leiba wrote:
> As Todd previously stated, my preference is for language that
> acknowledges the pri
Personally, I prefer the latter of the two, quoted below.
"to preserve interoperability, domains SHOULD NOT publish p=reject unless they are
[not general purpose]* domains"
"Publishing DMARC records with restrictive policies does cause interoperability
problems for some normal email usage
Re-looking at the definition of "SHOULD NOT", I don't see why it can't
be considered.
"SHOULD NOT - This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
Depending on the definition of "valid reason", is not "An organization
wants unauthenticated mail to be rejected" a valid reason? Although, with
the noted interoperability issues, I'm not sure if it qualifies.
On Sat, Apr 1, 2023, 1:53 AM Murray S. Kucherawy
wrote:
> On Fri, Mar 31, 2023 at
+1 to Todd's statement, this sums up my views on this as well.
On 3/30/2023 9:16 AM, Todd Herr wrote:
On Wed, Mar 29, 2023 at 7:55 PM Barry Leiba
wrote:
1. IETF has installed a very ugly workaround to the problem,
rewriting the "from" header field. It's absolutely a workaround,
es are still delivered. There have
been outliers, of course, but they are dealt with by the organizations
on a case-by-case basis, which, to date, have been less than a handful.
- Mark Alley
On 3/29/2023 3:59 PM, Scott Kitterman wrote:
Would you feel any better if the MUST NOT was followed by '
I know that M3 is totally separate from this group, but this is more-so
a question for Todd H- does this mean that the M3AAWG authentication
best practices recommendation will also change based on this if this is
the intended usage going forwards with DMARCbis?
Quote from the existing
as to when an
ARC set is applied. Possibly by giving sealing condition capabilities to
the customer?
- Mark Alley
On Fri, Mar 24, 2023, 6:18 PM Seth Blank wrote:
> Microsoft is using ARC quite heavily, and has reported on this list and at
> M3AAWG of the impact it makes
>
&
Okay. That was my understanding, but wanted to make sure it was crystal
clear. Thanks for the clarification.
On Thu, Mar 9, 2023, 2:53 PM John Levine wrote:
> It appears that Mark Alley said:
> >-=-=-=-=-=-
> >
> >This question probably has an obvious answer, but asking
?
- Mark Alley
On 2/23/2023 6:13 PM, John R. Levine wrote:
I haven’t done extensive research but here is a live example where
treewalk will cause a result change.
From: is in the domain Ret.bmcc.cuny.edu which has no DMARC record.
_dmarc.bmcc.cuny.edu.300INTXT"v=DMARC1; p=quara
It does vary widely, agreed; I believe knowing how the behavior changes
can affect existing implementation and common usage scenarios may be
useful for at least consideration of its effects on domain owners.
On 2/28/2023 6:58 PM, Murray S. Kucherawy wrote:
On Tue, Feb 28, 2023 at 9:51 AM
ew outliers are also
following the same structure, the subdomain zones for an agency not
under jurisdiction of OIT are delegated to their respective agency, of
which has a separate DMARC record and policy that were created during
implementation.
- Mark Alley
On 2/28/2023 11:51 AM, Alessandro
I agree with Laura's stance. Many organizations (that are not PSDs, and
not on a PSL) will publish explicit subdomain-specific DMARC policies to
prevent inheritance from a higher level, or the organizational domain
(which may not be ready for a stricter policy), during implementation.
This is
I'm of the opinion this goes back to Todd Herr's topic on the ARC ML
(Topic: Simplifying the Decision to Trust an ARC Header Set) as to
whether a validator trusts a sealer's results to be "true and correct".
With the method this is currently handled in adding of false DKIM
results, how can a
level. They would
also reduce the risk of unwanted data leakage.
But I am willing to be convinced. Can someone explain how success
reports, message counts, or unaligned signatures serve a domain owner
purpose which is relevant to DMARC?
Doug
On Thu, Dec 8, 2022 at 7:56 AM Mark A
Adding clarification since I forgot to specify - this would be
per-sender per-source. Not a set percentage of all mail received from a
source, that obviously would not work as intended.
On 12/8/2022 6:52 AM, Mark Alley wrote:
This may have been thought of before, so forgive the potentially
This may have been thought of before, so forgive the potentially
duplicate idea, I was musing earlier about feedback reporting based on a
percent of the overall mail per-source. I'm thinking of something
similar in concept to the pct= tag for published policy.
This would reduce the overhead
And I don't think I
have seen any reporting from icloud.com.
So, as you noted, what we're left with are gaping holes in data
reporting with some of the largest ESP's, one can only hope they
eventually decide to share with the rest of the world.
- Mark Alley
On 11/20/2022 11:16 AM, Douglas
47 matches
Mail list logo
