On 6/14/21 10:09, Brotman, Alex wrote:
> Does this make everyone cringe, or perhaps worth a larger discussion?
This was considered (repeatedly) during the original DMARC work, and I
believe again while it was being put into RFC7489 form.
It was rejected because it increased the likelihood of bro
Thank you for asking.
OK., I will use the term "email suffix" for the part of an email address
that follows the @ character, and "DNS domain" for a name that appears in
DNS as a domain object.
An email suffix can legitimately be associated with an A/
resource record that is not a DNS domain
It appears that Brotman, Alex said:
>Does this make everyone cringe, or perhaps worth a larger discussion?
Cringe. If others have said, if you want DKIM to pass, sign everything with
DKIM. I can promise you
that anyone who says "all of our mail will always pass SPF" doesn't know where
his mai
It appears that Brotman, Alex said:
>To summarize,
>
>We'd like to see extensions available both below the "feedback" and "record"
>elements. The -02 draft only has it below the "feedback" element. I agree
>that all
>elements, each time they are utilized, should mention a reference as to how
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
messages,
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain-based Message Authentication, Reporting
& Conformance WG of the IETF.
Title : Experimental DMARC Extension For Public Suffix Domains
Authors
This risks sendability with the fact that there are a lof of receivers that
require SPF-RRs. So not providing SPF-RRs also fails with such an requirement.
Besides that does SPF not help with any kind of 5322.From spoofing, but this
ist he most important identifier for an enduser.
/ Tobias Herku
HUGE cringe ;-) DMARC has an explicit policy that either SPF or DKIM must
pass aligned. This proposal breaks that foundationally.
This is suggested quite frequently, but fails to understand just how few
senders of email actually send with DKIM. Most email is sent from services
that have a core bus
This rings to me like something that would look like the simple/relaxed
alignment option currently in DMARC. "Require aligned DKIM" being
something along the lines of "rdkim=y; rspf=n;" with the
not-included/default value being "n."
If you agree that adding it is simple enough, the real question i
Hello,
I was talking to some folks about DMARC, and a question came as to suggest as
the domain holder that your messages should always pass DKIM. Effectively, the
asker wants to say "I intend to deploy SPF and DKIM, but I will *always* sign
my messages with DKIM." So the obvious answer may b
On Mon 14/Jun/2021 14:41:44 +0200 Brotman, Alex wrote:
I agree that all elements, each time they are utilized, should mention a
reference as to how they are to be utilized.
[...]
So, a sample report may look something like:
2.0
2
So why doesn't mention a referen
+1
On 6/14/21, 6:42 AM, "dmarc on behalf of Brotman, Alex"
wrote:
To summarize,
We'd like to see extensions available both below the "feedback" and
"record" elements. The -02 draft only has it below the "feedback" element. I
agree that all elements, each time they are utilized,
To summarize,
We'd like to see extensions available both below the "feedback" and "record"
elements. The -02 draft only has it below the "feedback" element. I agree
that all elements, each time they are utilized, should mention a reference as
to how they are to be utilized.
We'd also like to
Doug,
maybe it's me, but I have problems understanding your proposal. Let me quote
what seems to hamper my comprehension.
Besides, #11 in the Subject: is obviously a typo.
On Sat 12/Jun/2021 14:55:33 +0200 Douglas Foster wrote:
ties the design directly to the mailing list problem.
I cou
14 matches
Mail list logo
