Do you trust the ARC signer is the only appropriate policy test. Everything
else, including your "wanted and valued sender" test is a value judgement
for a message filter, not an ARC evaluation. If you trust the ARC signer of
a message, then you trust their assertion as to the authentication
>
> Any hint about why it's not used?
>
PII. Report generators are reluctant to send reports that may contain PII for
compliance, security, and privacy reasons.
Plus, if you are a report receiver those reasons may be valid too. What's the
point in requesting failure reports if your email ops
>
> I still don't see any value in adding text like this. The description
> of the tree walk is clear enough.
+1 (again), I don't understand why this is needed.
What problem statement is the proposed text attempting to address?
Ken.
___
dmarc
>
> I'm with Barry. I see no reason to mention zone cuts or anything like
> zone cuts at all.
>
> They are not relevant to DMARC. It would just confuse people.
+1
I also believe it to be unnecessarily confusing and distracting.
Ken.
___
dmarc
The IETF have no control over how third parties choose to implement RFCs. If a
vendor chooses not to implement a particular RFC because of its status, and
that choice results in an interoperability issue, then that discussion is
between the vendor and their customers - the IETF have no part to
Bis means "again", in this case it refers to the next iteration of the DMARC
specification. It's an IETF naming convention, nothing to do with DMARC or the
working group specifically.
Ken.
> -Original Message-
> From: dmarc On Behalf Of Damian Lukowski
> Sent: Monday 20 June 2022
>
> I don't think there is any other place where the default is not one of
> the explicit options. The benefit of psd=u, such as it might be, is to
> make it more consistent, and to be clear that we really mean it when we
> say that psd=y, psd=n. and psd=u mean three different things.
>
> This
No. “?all” in an SPF record is a negative signal to many filters and a quick
way to the spam folder. It also exposes the domain to abuse unconnected with
DMARC.
If a sender intentionally relies on DKIM-only alignment, then that’s their
decision. Making any recommendations as to what their SPF
Organisations using DKIM-only (also SFP-only) with an enforcing DMARC policy
are more common than you may think. While some configurations are perhaps in
error, many I have encountered are deliberate decisions based on specific use
cases.
For example, I have a finance house that uses
Well, I have had a deliverability related encounter with ARC in the wild, and
can report that ARC is actively being used by Zoho.
A client was using Zoho for their service desk and messages started going
missing. The way these service desks work is that you forward say
supp...@example.com to
+1
Ken.
From: dmarc on behalf of John Levine
Sent: Wednesday, 16 June 2021, 19:02
To: dmarc@ietf.org
Cc: ves...@tana.it
Subject: Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language
It appears that Alessandro Vesely said:
>It might make sense to reject
I think this is a bad idea as it adds unnecessary additional complexity.
Currently, a domain owner can choose to only implement DKIM or SPF on a mail
stream if they only wish one mechanism to be evaluated.
Further, if there is a (renewed?) desire to apply a policy layer to DKIM signed
Hi Charles,
DMARC is intended to prevent unauthorised use a domain name in the 5322.From
header. This header was chosen because it is displayed in MUAs and is the
target of spoofing attempts in phishing campaigns. I agree that there is some
ambiguity in the original RFC but the intention is
Arne,
You should post this over on mailop too - a lot of postmasters and senders who
would find this useful don’t lurk here.
Also, are your GDPR compliant aggregate reports the same as the RFC
specification, or are you going to modify them in some way?
Ken.
From: dmarc On Behalf Of Arne
On Monday 22 February 2021 16:14, Dave Crocker wrote:
> Strictly speaking co.uk is not ICAN-authorized. It's authorized by
> mechanisms internal to the UK.
>
None of the ccTLDs registry operators would call or consider themselves
"ICANN-authorized". The original authorisation to use the
I would go even further and not even talk about the trees and nodes. Also,
echoing elsewhere in this thread, making it really clear that this is not a
case of DMARC is coming for your TLD. So, I’d propose something super basic
like this for the second paragraph:
Domain name suffixes (for
the organization making the delegation escape liability for how the
information is handled and used?
On Wed, Feb 17, 2021 at 4:27 PM Ken O'Driscoll
mailto:40wemonitoremail@dmarc.ietf.org>>
wrote:
I PM deployments for organisations and the concept of aggregate reports have
caused problem more tha
no evil" risk mitigation strategy is
tried and tested. The whole IG/DPO space is really crazy in some places too.
Ken.
> -Original Message-
> From: John Levine
> Sent: Thursday 18 February 2021 02:46
> To: dmarc@ietf.org
> Cc: Ken O'Driscoll
> Subject: Re: [dmar
I PM deployments for organisations and the concept of aggregate reports have
caused problem more than once. Similar to the PII concerns of providers which
originated this ticket, these organisations operate in heavily a regulated
industry and have extensive DPO functions. To give a flavour of
> -Original Message-
> From: dmarc On Behalf Of John R Levine
> Sent: Friday 4 December 2020 18:22
> To: Alessandro Vesely ; John R Levine ;
> dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI
> functionality
>
> >> I meant "at the same time" as in during
The "resent" fields are currently used for their stated purpose, which as you
correctly note, is to signal that a message has been re-introduced into the
mail transport. These fields are typically used when a message which has
already been delivered to a mailbox is resent unmodified (and
If you are referring to section 3.2.4. then I'm pretty sure that's referring to
gateways in the protocol sense (see RFC 5598, section 5.4.) which convert
internet mail into a different messaging protocol, such as SMS/MMS or
(historically) UUCP. The interoperability concerns are still valid
On 03/08/2020 01:43, Douglas E. Foster wrote:
>
> I am not sure what "Internet Scale" means to you. Most of the major
> recipients have bulk mailer registration systems. It does not
> guarantee whitelisting, but it tends to produce that effect. I have
> had occasion to register with most of
On 30/07/2020 11:39, Jeremy Harris wrote:
> That works at a domain-controlled level. But people sign up for,
> and write to, mailinglists on an individual level. Mismatch.
To be fair, this thread is specifically about a non-MLM use case at an
organisational level. But, I believe that any
On Mon, 2019-04-08 at 09:50 -0400, Douglas E. Foster wrote:
[...snip...]
> My focus is on defining a framework for discussing product capabilities,
> while leaving room for vendors to add value above the minimum
> configuration.
That sounds more like what organisations such as Gartner are there
Apologies if this has already been caught by others.
Just spotted some small typos in section 8. Was reading this specific
section in connection with something GDPR (the fun!) related.
8. Privacy Considerations
The Authenticated Received Chain provides a verifiable record of the
26 matches
Mail list logo
