From: dmarc On Behalf Of Tim Wicinski
Sent: Monday, April 1, 2024 12:17 PM
To: Dotzero
Cc: Brotman, Alex ; dmarc@ietf.org
Subject: Re: [dmarc-ietf] SPF follies, WGLC editorial review of
draft-ietf-dmarc-dmarcbis-30
I have to agree with Seth's comments that "security teams believe an SPF h
One item left out of Seth’s text is that due to MBPs who act in this fashion,
these SPF evaluation failures will (understandably) not show up in DMARC
reports, and the domain owner may not have visibility for these failures.
However, the text also puts the onus on the domain owner instead of
Apologies, which format should be used. I'm not sure if I should revert to the
one from 7489, or some other prior version.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -Original Message-
> From: dmarc On Behalf Of John R Levine
> Sent: Monday, March 25,
There were a few errata for the aggregate reporting. I wanted to confirm with
the list that these are still valid.
https://www.rfc-editor.org/errata/eid5440 :: I thought it had been determined
the ";" was not necessary.
https://www.rfc-editor.org/errata/eid6485 :: We've since replaced this,
Thanks for the feedback. I believe I've corrected all except
- 2.1: "(...) while there MUST be one spf sub-element". At least one according
to the XML Schema Definition (might be two, each with a different scope "helo"
and "mfrom").
Can we talk about how this looks in a sample report?
--
Thanks, added as a list
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -Original Message-
> From: dmarc On Behalf Of Matthäus Wander
> Sent: Friday, March 22, 2024 7:15 PM
> To: dmarc@ietf.org
> Subject: [dmarc-ietf] Security Considerations in
Hey folks,
Mostly some typos being corrected. Changed the URL in the XSD per Ale's
suggestion. Added a paragraph about the Error field.
Thanks
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -Original Message-
> From: dmarc On Behalf Of
riginal Message-
> From: Alessandro Vesely
> Sent: Friday, November 17, 2023 4:22 AM
> To: dmarc@ietf.org; Brotman, Alex
> Subject: Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML
> Schema
>
> On Thu 16/Nov/2023 16:47:48 +0100 Olivier Hureau wrote:
> &g
+1 SHOULD NOT
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
From: dmarc On Behalf Of Mark Alley
Sent: Tuesday, October 24, 2023 1:26 PM
To: Matt V
Cc: dmarc-cha...@ietf.org; Francesca Palombini
; IETF DMARC WG
; art-...@ietf.org
Subject: Re: [dmarc-ietf] Dmarcbis way
Not that I’m aware of. But even if we leave it unstructured, including
examples about what may be useful could be of assistance.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
From: Murray S. Kucherawy
Sent: Monday, October 23, 2023 3:12 PM
To: Brotman, Alex
Cc: Matt
I can add this.
I should note that generally, while there's an "error" field available, there's
no guidance about what should go in there. (not in 7489 either that I could
find in a brief search)
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -Original
2023 11:44 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] draft-ietf-dmarc-aggregate-reporting-13
>
> On 02/10/2023 15:12, Brotman, Alex wrote:
> > Please let me know if you have any additional issues or concerns.
>
>
> One is the sentence " If validation is att
Hey folks,
I've tried to address the items brought forward by Andreas and Todd. Note that
based on some feedback, some paragraphs were removed. Please let me know if you
have any additional issues or concerns.
One that I don't see as resolved is the "Re ports" broken over two lines, and
this
Thanks Barry. I’ll do my best to address these and get a new version in the
next week or so.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
From: Barry Leiba
Sent: Wednesday, September 27, 2023 4:20 PM
To: Brotman, Alex
Cc: dmarc@ietf.org; Todd Herr
Subject: [EXTE
Hey folks,
It feels like we're sort of getting near the end of work on the core document
(maybe that's the optimist speaking), so I thought I'd see if there are any
known issues with the aggregate reporting draft [1]. I believe I had
previously addressed or closed all tickets and addressed
I believe the only update from the prior revision are the ABNF alterations that
Ale had noted after -11.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -Original Message-
> From: dmarc On Behalf Of internet-dra...@ietf.org
> Sent: Sunday, August 27, 2023 8:18
I suspect the portion that instructs receivers to not act solely on p=reject
may be ignored by a fair set of receivers. I'm not necessarily opposed to the
language below, just that it seems odd to create language that we know will be
ignored. Additionally, I find it odd that we won't tell
One other thing I forgot to note is that there are no longer any open "issues"
attached to this document (in Github at least).
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -Original Message-
> From: dmarc On Behalf Of Brotman, Alex
> Sen
That was the core of the change. Also no longer malicious Domain Owner.
Otherwise, whitespace changes.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -Original Message-
> From: dmarc On Behalf Of Scott Kitterman
> Sent: Tuesday, May 2, 2023 9:13 AM
> To:
This sounds like a separate document to me. (yes, I see Ale's draft below) And
IMO, I don't think we should hold up DMARCbis for that work.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -Original Message-
> From: dmarc On Behalf Of Hector Santos
> Sent: Monday,
nology agnostic, is better.
> As you
> suggest, there are multiple ways to address the requirement and being overly
> specific will not age well.
>
> Scott K
>
> On April 27, 2023 2:11:17 PM UTC, "Brotman, Alex"
> wrote:
> >In summary:
> >
&
Attempt to make it a tad more concise (I think), altering some of the language:
-
There can be inherent damage to the ability to use certain SMTP-based systems
in conjunction with a policy of quarantine or reject. These could include,
though are not limited to, mailing
In summary:
“Report senders SHOULD attempt delivery via SMTP using STARTTLS to all
receivers. Transmitting these reports via a secured session is preferrable.”
I don’t think we should add this in, but receivers could deploy DANE/MTA-STS if
they wanted to ensure senders who honor those will
These should be the updates from the last two days or so. (except John's
s/malicious//, already altered for next run)
I found a few more places where the mmark/xml2rfc process was creating some
improper output, I believe all for the "_report._dmarc" bits.
--
Alex Brotman
Sr. Engineer,
Kitterman wrote:
> >> My suggestion is delete all of it. It's accurate for some cases, not for
> >> others.
> If you want to keep any of it, I think it needs to be properly caveated. I
> expect
> that would be a Sisyphean task that's not worth the effort.
> >&
day, April 24, 2023 10:18 PM
> To: Brotman, Alex ; dmarc@ietf.org
> Subject: [EXTERNAL] Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-
> reporting-09.txt
>
> > I removed the small section that faced objections.
> >
> > I updated the ridtxt definition an
I removed the small section that faced objections.
I updated the ridtxt definition and discovered that mmark was making a mess of
those asterisks. When there are more than one/some on a single line, it
believes you would like some subset to be defined as "" things.
--
Alex Brotman
Sr.
I’ve talked about this before. I ran into a utility company that I conversed
with that explicitly didn’t want to use DKIM because they felt their messages
should not be forwarded to another provider. I didn’t quite understand the
logic, but it was their decision.
I definitely favor some
rotocol police..)
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -Original Message-
> From: Barry Leiba
> Sent: Thursday, April 13, 2023 12:34 PM
> To: Brotman, Alex
> Cc: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Example of Indirect Mail Flow Br
& Messaging Policy
Comcast
From: Murray S. Kucherawy
Sent: Wednesday, April 12, 2023 9:51 AM
To: Brotman, Alex
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?
On Wed, Apr 12, 2023 at 6:31 AM Murray S. Kucherawy
mailto:superu...@gmail
There is a non-zero set of cases where the IETF prefers security over
interoperability. A document like RFC8997/8996 where we've deprecated TLSv1
in because it was no longer secure. I assure you there are still systems/users
who have devices incapable of TLSv1.2. DNSSEC (and things that
I’m just not sure how we determine what is high-value.
comcast.com: p=reject
comcast.net: p=none
xfinity.com: p=quarantine
The top one is corporate, middle is consumer, bottom is consumer (but not
actually used) & customer comms (sub-domains). They’re all used in various
ways for internal
There may need to be a bit more clarification around the use of sp= in these
cases. "We are telling you that p=reject is harmful, but sp=q/r is acceptable
in many cases, where these conditions are satisfied".
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
>
Should it reference consumer-oriented domains instead?
Users of comcast.net can't get an email account with out first being an ISP
customer. I don't believe the intent was to exclude them from the proposed
language. Similarly for a few other providers, and then there are explicit
pay-for
Ale,
Thanks for the notes, I'll try to get those sorted out. I'll check RE the
7405/5234 to see what I can find. I only made one minor modification there
based on a ticket JohnL had submitted.
Scott,
There were two version fields in this document at one point. The second
originally came
Thanks folks, I’ll get this cleaned up for the next revision. I’m also trying
to address the remaining tickets (most, if not all, have been addressed), and
make sure they’re closed.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
From: dmarc On Behalf Of Steven M Jones
in the report to point at, we
can create a field.
Thoughts from others?
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
From: Trent Adams
Sent: Wednesday, March 8, 2023 11:44 AM
To: Brotman, Alex ; dmarc@ietf.org
Subject: Re: [dmarc-ietf] Version in aggregate report
Alex -
While reviewing something in the aggregate doc, I came across this bit in the
XML specification. Unless I've missed something, we're not incrementing the
version in the DMARC DNS record.
So, if we're not changing that DNS record, obviously this "version" string has
less meaning. The
While discussing this with someone at the conference yesterday, we thought
perhaps we could introduce something of a referral.
Currently:
_dmarc.ret.bmcc.cuny.edu NULL
_dmarc.bmcc.cuny.edu "v=DMARC1; p=quarantine; fo=1;
rua=mailto:dmarc_...@emaildefense.proofpoint.com;
ngle IP
address, some disaggregation will occur. This strikes me as a benefit, not a
disadvantage.
Doug Foster
On Wed, Jan 4, 2023 at 6:49 PM Brotman, Alex
mailto:alex_brot...@comcast.com>> wrote:
Which section are you referring to? Can you show where this has changed from
-06 (
Which section are you referring to? Can you show where this has changed from
-06 (or RFC7489)?
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
From: dmarc On Behalf Of Douglas Foster
Sent: Wednesday, January 4, 2023 6:35 AM
To: IETF DMARC WG
Subject: [dmarc-ietf]
Hey folks,
The big changes are XML cleanups from Ale, and then Scott's privacy section.
Thanks to both of them for the contributions. Ale's changes are throughout
various portions of the document, and include some changes to whitespace,
structure, and the way the XML in managed in the
Thanks Scott. I'll try to get this merged in the next few days. I have two
other merges from Ale that I need to sort out. I'll get a new rev done after
they're both merged.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
From:
Thanks Mauro, I'll review and get those in for the next version where
appropriate.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -Original Message-
> From: dmarc On Behalf Of Mauro De Gennaro
> Sent: Tuesday, November 29, 2022 4:23 AM
> To: dmarc@ietf.org
>
Amended language for section 2.1:
"The report may include...
- Sending domain and receiving server organizational domain."
Which organizational domain? Taking my corporate domain as an example, you
send the message to “comcast.com”, which is hosted at pphosted.com
(MX/Proofpoint), but
Are you aware of any evaluators who selectively escalate signatures? I'm not,
and I expect they do so to gather as much domain-based data as possible. I'm
not saying they don't exist, but I would imagine there aren't many, and the
numbers will dwindle.
Are you suggesting the spec should
How will we handle the ever-changing definition of "weak"?
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -Original Message-
> From: dmarc On Behalf Of Scott Kitterman
> Sent: Wednesday, October 26, 2022 10:27 PM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf]
There is a portion of the proposed aggregate document that affords one the
opportunity to use “extensions”, which could potentially be applied to ARC (or
any other reporting extension one would like to define). Mindful, this still
applies within the framework of DMARC. So how the report
Folks,
I started adding some text around the "Report-ID" format. I ran into a bit of
a hurdle, and thought it best to get group feedback. We decided a while ago to
add language that the "Report-ID", "msg-id", and "unique-id" were the same. In
the thread a few weeks ago, it was suggested the
I’ve been going back and forth on this a bit. On one side, I understand that
we’d like to know when a receiving site does not evaluate both SPF and DKIM. I
also am not sure I know of any (sizable?) site which short-circuits evaluation
after SPF. Given how much time receivers talk about
So we would likely need a section in the core document with a SHOULD for
evaluation (if it’s not already there), and then a section in the aggregate
reporting for a MUST for reporting on evaluated information (if they choose to
send reports at all), correct?
--
Alex Brotman
Sr. Engineer,
That says it was addressed in 04, let us know if you believe otherwise, or not
sufficiently.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -Original Message-
> From: dmarc On Behalf Of Alessandro Vesely
> Sent: Saturday, October 1, 2022 4:36 AM
> To:
Folks,
Ticket was opened to address "Report-ID" in aggregate reporting. Today,
RFC7489 (Section 7.2.1.1) refers to a "msg-id" that it uses from RFC5322 as the
format that is required. The document then goes on to say that the true
purpose of the field is to ensure that the receiver can
That would be me I should hope. I'll get that sorted out tonight or tomorrow.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -Original Message-
> From: dmarc On Behalf Of Scott Kitterman
> Sent: Tuesday, August 30, 2022 12:49 PM
> To: dmarc@ietf.org
> Subject:
The main gist of the change was resolving a few inconsistencies that were
reported, as well as a few typos. Thanks folks.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -Original Message-
> From: dmarc On Behalf Of internet-
> dra...@ietf.org
> Sent: Wednesday,
>From section 4.6:
To illustrate, for a message with the arbitrary RFC5322.From domain
of "a.b.c.d.e.mail.example.com", a full DNS Tree Walk would require
the following five queries, in order to locate the policy or
Organizational Domain:
* _dmarc.a.b.c.d.e.mail.example.com
*
Richard,
Thanks for the notes. I'll file a few trac issues to get these resolved, and
try to get a new version released soon-ish. If you're okay with it, I may send
you a preview version to ensure it resolves the items noted below. Thanks again
--
Alex Brotman
Sr. Engineer, Anti-Abuse &
Folks,
I've uploaded a new revision of the aggregate reporting document. I've tried
to incorporate feedback from the list, and some of the more notable items may
include:
https://www.ietf.org/archive/id/draft-ietf-dmarc-aggregate-reporting-04.txt
Hello folks,
We received a ticket about the unique IDs that are included with reporting:
--
unique-id, msg-id, and report_id are loosely defined.
The spec needs to say that they are semantically the same thing and must have
the same content.
In addition:
I know there has been a fair bit of talk about walk-the-tree. Taking a 24h set
of data, and trying to measure the number of times where this situation may be
warranted. We can try to make a guess the goal is to look for a DMARC policy
between the 5322.From which has an unknown number of
Murray,
We’ve started (relatively recently, in volume) logging ARC data so we can try
to make some informed decisions going forward. We’re not yet acting on
anything as a result, nor writing into the message. We’re also not doing
anything when mail is being forwarded. We’ll hopefully have
It feels like folks would prefer that the subject be required to be of a
specific format to better enable duplicate report processing. Do I understand
that correctly?
So that would be:
If a report generator needs to re-send a report, the system
MUST use the same filename as the
ay, August 19, 2021 7:19 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-
> 03.txt
>
> On Wed 18/Aug/2021 22:30:06 +0200 Brotman, Alex wrote:
> > If you feel as though something is amiss, or I've misinterpreted the
> consensu
I tend to agree on that last Receiver bullet being unenforced. If I had to
choose between an organization deploying DMARC without reporting, or holding up
on deploying DMARC because they can’t provide reporting for X,Y,Z reasons ..
I’m choosing the former. Does it potentially leave a hole in
Hello folks,
My updates aren't as exciting as they are for the other document. I wanted to
get a document out with the feedback provided. Tried to clean up the
extensions section, some normative language, and a few other items. If you
feel as though something is amiss, or I've
Folks,
A ticket was opened to add a "human_result" to the SPF results in the report.
As DKIM has similar, I don't necessarily see an issue here. It seems like this
could be useful to those attempting to resolve issues relating to failing SPF
results. The ticket illustrates a few examples:
https://trac.ietf.org/trac/dmarc/ticket/6
Folks,
I'd like to get a bit of feedback on this one. I realized I'd changed this to a
SHOULD, which doesn't really address the "fuzzy" complaint. Seems like the
proper thing to do is make this a MUST, though I'd be interested in opposing
thoughts.
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
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
Hello folks,
During our interim call last week the topic of extensions within the DMARC
aggregate report came up. There was a discussion about how to best introduce
these, but also how they might be best used. I noted three cases that I could
see today; ARC, PSD, and BIMI. And indeed we
arc@ietf.org
> Subject: Re: [dmarc-ietf] Versioning and XML namespaces in aggregate
> reports (#33, #70)
>
> On Fri 14/May/2021 15:42:56 +0200 Brotman, Alex wrote:
> > There are a few tickets that may break report ingestion systems due to
> structure and/or value changes. Sh
I'll give it a look, and incorporate what I can (it seems to diverge from -02)
into the XSD in the repository.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -Original Message-
> From: Alessandro Vesely
> Sent: Thursday, May 13, 2021 3:02 PM
> T
There are a few tickets that may break report ingestion systems due to
structure and/or value changes. Should we decide that's an implementation
issue, or that we truly can't change the format of the reports? I'm sure most
ingestion systems are rather flexible given the number of reports that
Martin,
1. I’ll see if we can get this cleaned up (I’ll create a proper ticket for
tracking this)
2. I’d welcome other inputs here on the original idea for this option. I
would imagine modern systems would be able to deal with rather large XML files,
though MTAs routinely set limits
I sent this over to support the other day, and it was forwarded to operations.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
From: Murray S. Kucherawy
Sent: Monday, May 3, 2021 8:03 PM
To: Brotman, Alex
Cc: Alessandro Vesely ; IETF DMARC WG
Subject: Re: [dmarc-ietf]
1. Just blocked off the time on my calendar to attend
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
From: dmarc On Behalf Of Seth Blank
Sent: Thursday, May 6, 2021 12:27 AM
To: IETF DMARC WG
Subject: [dmarc-ietf] DMARC WG Interim meeting Proposal -- request for group
Are we divided? Seems like use cases have been noted. However, removing these
completely protects some aspects of privacy. Could we perhaps err on the side
of caution, removing these definitions, and leave a note to suggest that if
domain holders need further assistance to reach out to the
I apologize, corporate mail gateway does that (I've asked them to exempt
ietf.org now). The links have an expiration of a few days.
https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -Original
Matt,
While, yes, there is the existing envelope_to, there was a request to add this
to the report format (which I believe I did as the submitter desired). I would
assume we’d hash it out on the list and remove one of them.
However, from an operator side of things, I tend to align with Todd
Hello folks,
Below you'll see the details relating to the most recent iteration of the
aggregate reporting document. I attempted to address as many tickets as I
thought feasible. I would probably suggest that the core of changes were
relating to explaining more about the format, more
Aggregated comments:
--
Aggregate feedback reports contain aggregated data relating to messages
purportedly originating from the Domain Owner. The data does not contain any
identifying characteristics about individual users. No personal information
such as individual
dro Vesely
> Sent: Monday, February 15, 2021 8:31 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns
>
> On Fri 12/Feb/2021 21:30:38 +0100 Brotman, Alex wrote:
> > Hello folks,
> >
> > In ticket #64
> (https://urldef
Sent: Friday, February 12, 2021 3:46 PM
> To: dmarc@ietf.org
> Cc: Brotman, Alex
> Subject: [EXTERNAL] Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns
>
> In article
> 11.prod.outlook.com> you write:
> >Hello folks,
> >
> >In ticket #64
> >(ht
Hello folks,
In ticket #64 (https://trac.ietf.org/trac/dmarc/ticket/64), it was suggested
that a Privacy Considerations section may alleviate some concerns about the
ownership of the data. I created an initial attempt, and thought to get some
feedback. I didn't think we should go too far in
e: [dmarc-ietf] Discussion: Removal of validation for external
destinations (Ticket #76)
Removing this opens up the potential for abuse, I don't see the value in
removing it.
On Sun, 6 Dec 2020, at 11:06 PM, Alessandro Vesely wrote:
On Sat 05/Dec/2020 14:51:52 +0100 Brotman, Alex wrote:
>
&g
Murray,
That is on my to-do (though not ticketed). I’m not quite sure how elaborate
the example should be, but at least enough to demonstrate a basic report.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
From: dmarc On Behalf Of Murray S. Kucherawy
Sent: Wednesday,
report should look
like if it were to be a self-contained piece of XML within the main DMARC
report. That could help drive this section as we move forward.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
From: dmarc On Behalf Of Brotman, Alex
Sent: Wednesday, Decembe
wy
Sent: Monday, January 25, 2021 12:20 PM
To: Brotman, Alex
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Which DKIM(s) should be reported? (Ticket #38)
On Sun, Jan 24, 2021 at 4:25 PM Brotman, Alex
mailto:40comcast@dmarc.ietf.org>>
wrote:
Some time ago, an issue[1] was brought to
cost/benefit assessment can be made. At least some of that justification
should be included in the final document, since one purpose of that document
will be to convince non-reporting entities to begin sending reports.
Doug Foster
On Sun, Jan 24, 2021 at 7:25 PM Brotman, Alex
mailto:40com
Ale,
I didn't incorporate that section as I thought that section about Privacy
Considerations might be in the main document as it applies to both rua/ruf.
I'll work to add something similar for the coming revision, thank you for the
note.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging
Hello folks,
Some time ago, an issue[1] was brought to the list where which DKIM(s) being
reported is not clear in RFC7489 [2]. There was a short discussion, though no
clear resolution before conversation trailed off. It seems like there were
points that may need to be discussed. One was
Hello folks,
Thought I'd see if we could come to a conclusion on this ticket. The gist is
that the reporter believes that (aggregate?) reports can help spammers to
determine some effectiveness of their message attempts.
Full Text:
-
Spammers could use DMARC reports to monitor the
ty within Aggregate
> Reports (Ticket #40)
>
> On Wed 30/Dec/2020 23:18:35 +0100 Brotman, Alex wrote:
> > Hello folks,
> >
> > There's an open ticket
> (https://urldefense.com/v3/__https://trac.ietf.org/trac/dmarc/ticket/40__;!
> !CQl3mcHX2A!VCWZO-
> 6THaYEt
Hello folks,
There's an open ticket (https://trac.ietf.org/trac/dmarc/ticket/40) noting that
we should clarify what constitutes valid data in a report. For example, the
report cannot state that DMARC-DKIM was a "pass" when DKIM itself was a
failure. See the original thread here:
& Messaging Policy
Comcast
From: Emil Gustafsson
Sent: Wednesday, December 23, 2020 2:49 PM
To: Brotman, Alex
Cc: Marc Bradshaw ; DMARC IETF
Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)
While the common format would be great as a consumer of reports, I'm wondering
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -Original Message-
> From: John R Levine
> Sent: Friday, December 11, 2020 4:34 PM
> To: Brotman, Alex ; dmarc@ietf.org
> Subject: RE: [EXTERNAL] Re: [dmarc-ietf] Clarification of Subdomain
>
I'm seeing a report where the XML contains two SPF records within a single
auth_results entity. This doesn't seem correct. I found this thread:
http://lists.dmarc.org/pipermail/dmarc-discuss/2016-April/003474.html and it
says it's a bug, though, I'm a bit surprised (guess I probably shouldn't
> -Original Message-
> From: John Levine
> Sent: Friday, December 11, 2020 2:39 PM
> To: dmarc@ietf.org
> Cc: Brotman, Alex
> Subject: [EXTERNAL] Re: [dmarc-ietf] Clarification of Subdomain Reporting
>
> In article
> 11.prod.outlook.com> you write:
>
Based on a discussion from last year
(https://mailarchive.ietf.org/arch/msg/dmarc/YoHhhaAfwRjbd8aq4fiV6xU1ifw/),
there was a request/ticket to clarify the language in the document.
>From https://tools.ietf.org/html/rfc7489#section-7.2:
* Data for each Domain Owner's subdomain separately from
9:54:51 +0100 Brotman, Alex wrote:
>
>> -Original Message-
>> From: dmarc mailto:dmarc-boun...@ietf.org>> On
>> Behalf Of Alessandro Vesely
>> Sent: Thursday, December 3, 2020 6:24 AM
>> To: dmarc@ietf.org<mailto:dmarc@ietf.org>
>> Subject:
1 - 100 of 108 matches
Mail list logo
