ARCbis? This could allow for more lengthy discussions around
> policy decisions, and move that discussion out of the technical document.
>
>
>
> --
>
> Alex Brotman
>
> Sr. Engineer, Anti-Abuse & Messaging Policy
>
> Comcast
>
>
>
> *From:* dmarc *On Beha
On Mon, Apr 1, 2024 at 12:27 PM Todd Herr wrote:
> On Mon, Apr 1, 2024 at 12:17 PM Tim Wicinski wrote:
>
>> I have to agree with Seth's comments that "security teams believe an SPF
>> hard fail is more secure".
>> I've been on the receiving end of that discussi
I have to agree with Seth's comments that "security teams believe an SPF
hard fail is more secure".
I've been on the receiving end of that discussion more than once.
Also, can we reference those two M3AAWG documents ? That seems like
operational guidance.
tim
On Mon, Apr 1, 2024 at 8:55 AM
"Explaining how DNS works is out of scope."
Scott is right.
Also, some folks point use something other than CNAME
$ dig +noall +answer _dmarc.valimail.com ns
_dmarc.valimail.com. 300 IN NS ns.vali.email.
tjw@m2[1098]: dig +noall +answer _dmarc.valimail.com txt
_dmarc.valimail.com. 595 IN TXT
There are folks who publish NS records at _dmarc.example.com that point to
some super fancy DNS service that return DMARC TXT records.
tim
On Thu, Mar 14, 2024 at 4:19 PM Todd Herr wrote:
> Colleagues,
>
> There was a discussion among M3AAWG members on March 13 that centered on
> the question
":" dmarc-fo-value)
> dmarc-fo-value = "0" / "1" / "d" / "s"
>
>
The wording for FO has changed to say "0", "1" OR a colon-separated list.
Looking at the 7489 ABNF I
am wondering if someone could say "fo=0:1:d:s"
thanks
tim
&
Re-reading section 9.5, I think we should rewrite this to mention the
registry being deprecated.
I open an issue on this
tim
On Fri, Mar 8, 2024 at 12:00 PM Tim Wicinski wrote:
>
> Generally they will leave it and mark Obsolete. This should be called out
> in the RFC.
> (I hav
Just picking over the ABNF with my checks, some Qs
dmarc-version = "v" equals %s"DMARC1
I believe the "%s" should be dropped
dmarc-value = %x20-3A | %x3C-7E
I think it should be %x20-3A / %x3C-7E
and now just something suggested. The comments for URI read like this
I agree with Ale here - ADSP was moved to Historic in 2013. Appendix A.5
should be dropped, and some text in the document should mention ADSP is
historic
On Sat, Mar 9, 2024 at 10:05 AM Alessandro Vesely wrote:
> Hi,
>
> as ADSP is historical, perhaps we can strike A5 entirely. If not, we
>
Generally they will leave it and mark Obsolete. This should be called out
in the RFC.
(I have not looked right now).
tim
On Fri, Mar 8, 2024 at 11:42 AM Murray S. Kucherawy
wrote:
> On Fri, Mar 8, 2024 at 6:49 AM Alessandro Vesely wrote:
>
>> since we removed the rf= tag (format of failure
Sorry all, I submitted
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/125 with
some spelling nits,
Not realizing all the work Todd put into Issue 121.
tim
On Thu, Feb 29, 2024 at 4:27 PM Todd Herr wrote:
> On Thu, Feb 29, 2024 at 10:10 AM Todd Herr wrote:
>
>> On Thu, Feb
Todd
I hate to get all DNS-y on you but the DNS terminology draft discusses Apex
and Origin in regards to Zones/Domains:
https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc8499bis-10.html#name-zones
(DNSOP spent 6 months trying to clean up the definition of "Glue Records"
to some success)
tim
On Sun, Aug 6, 2023 at 7:14 AM Alessandro Vesely wrote:
> On Sat 05/Aug/2023 22:24:28 +0000 Tim Wicinski wrote:
> >
> > [...]
> >
> > 5.3. General Record Format
> >
> >
> > auth: (comma-separated plain-text list of dmarc-methods; OPTIONAL;
&g
On Sat, Aug 5, 2023 at 7:38 PM Dave Crocker wrote:
> On 8/5/2023 4:23 PM, Neil wrote:
>
> Also, we understand who our audiences are in reality. Sometimes it’ll be
> a harried admin skimming the RFC, and others will take the time to do a
> deep dive. Even the harried admin scanning today might
at 6:17 PM Scott Kitterman wrote:
> On Saturday, August 5, 2023 6:11:03 PM EDT Tim Wicinski wrote:
> > On Sat, Aug 5, 2023 at 6:00 PM Scott Kitterman
> wrote:
> > > On August 5, 2023 9:51:54 PM UTC, Tim Wicinski
> wrote:
> > > >
On Sat, Aug 5, 2023 at 6:00 PM Scott Kitterman wrote:
>
>
> On August 5, 2023 9:51:54 PM UTC, Tim Wicinski wrote:
> >On Sat, Aug 5, 2023 at 5:35 PM John Levine wrote:
> >
> >> According to Tim Wicinski :
> >> >-=-=-=-=-=-
> >> >
&g
On Sat, Aug 5, 2023 at 5:35 PM John Levine wrote:
> According to Tim Wicinski :
> >-=-=-=-=-=-
> >
> >Based on the ABNF in -28, how about something like this:
> >
> >
> >dmarc-method = "dkim" / "spf"
> >
> >dmarc-auth = &q
Based on the ABNF in -28, how about something like this:
dmarc-method = "dkim" / "spf"
dmarc-auth = "auth" equals dmarc-method *(*WSP "," *WSP dmarc-method)
I think this "should"(*) allow for all permutations but also simplifies
it, and I agree with Barry it should be simpler.
tim
* no
On Fri, Aug 4, 2023 at 5:11 PM Scott Kitterman wrote:
>
>
> On August 4, 2023 4:15:35 PM UTC, Wei Chuang 40google@dmarc.ietf.org> wrote:
> >I noted at the DMARC session -117, that with the p=reject downgrade to
> >quarantine language, this increases the risk of SPF upgrade attacks due to
>
I'd rather add an option to flag some behavior rather than do a version
bump.
Have to agree with Scott that version bumps take forever.
(I had a network engineer recently tell me that DNS packets *MUST* be no
larger than 512 bytes - and EDNS0 was 1999?)
tim
On Sat, Jun 10, 2023 at 3:03 PM Scott
Fantastic Whitespace Engineering Mr Levine.
Looks Good.
tim
On Tue, Feb 28, 2023 at 11:17 AM Todd Herr wrote:
> This draft is a merge of the pull request that Mr. Levine mentioned in the
> "Question on RFC7489: trailing whitespaces" thread.
>
> It also automagically updated references to the
I can not agree more than 100 percent on this. The PSL has issues. We need
to stop depending on it.
If anything, the PSD work has shown the W3C folks that there is a path
forward for folks who need to
do PSL-like things without boiling the ocean.
tim
(who has spent a bit too much time recently
I agree that we should fix this tolerance in the bis document.
tim
with no hat on
On Mon, Feb 27, 2023 at 9:48 AM Murray S. Kucherawy
wrote:
> On Mon, Feb 27, 2023 at 2:29 AM Tõnu Tammer
> wrote:
>
>> I am curious to know what the stance is on trailing whitespace within
>> DMARC records.
>>
Ale,
On Sat, Feb 25, 2023 at 5:29 AM Alessandro Vesely wrote:
> On Fri 24/Feb/2023 21:21:15 +0100 Brotman, Alex wrote:
> > While discussing this with someone at the conference yesterday, we
> thought perhaps we could introduce something of a referral.
> >
> > Currently:
> >
Elizabeth,
(speaking as a DNS person). I think this is "OK" - at my last job we set
up DMARC records which stricter in certain subdomains than
the parent domain. (Now I need to go find the machine where I left my code
which did all this validation).
(As a DNS person I want to find the folks
On Thu, Sep 1, 2022 at 7:08 PM Scott Kitterman wrote:
>
>
> On September 1, 2022 6:05:29 PM UTC, Barry Leiba
> wrote:
> >> As we may have mentioned a few times before. PSDs that send their own
> >> mail are extremely rare. You can probably count them all on your
> fingers.
> >>
> >> I cannot
+1
On Thu, Jul 21, 2022 at 2:32 PM John Levine wrote:
> Now that we've gone around the barn a few more times and nothing has
> changed with the psd=u/n/y tag, can we please ask for a tentative IANA
> registration?
>
> R's,
> John
>
> ___
> dmarc
I am all about simpler ABNF
+1
Simple Tim
On Mon, Jun 6, 2022 at 10:03 PM John Levine wrote:
> Here's my alternate take: make the ABNF a lot simpler to
> reflect the actual loose syntax.
>
> dmarc-record= dmarc-version *(*WSP ";" *WSP dmarc-tag) *WSP *%x3b
>
> dmarc-tag =
On Wed, Mar 30, 2022 at 8:50 AM Brotman, Alex wrote:
> >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
>
On Fri, Dec 17, 2021 at 9:06 PM Scott Kitterman
wrote:
> On Friday, December 17, 2021 8:43:17 PM EST Tim Wicinski wrote:
> > On Fri, Dec 17, 2021 at 6:56 PM Douglas Foster <
> >
> > dougfoster.emailstanda...@gmail.com> wrote:
> > > That is not my pos
On Fri, Dec 17, 2021 at 6:56 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> That is not my position, and I don't know how you drew that
> conclusion from those words.
>
Then my mistake.
>
> I do take the position that DMARC PASS means "This name correctly
> represents the
On Fri, Dec 17, 2021 at 6:27 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> The way I evaluate a design is to first look for logical consistency or
> inconsistency.If there is obvious inconsistency, then the design needs
> to be re-evaluated to correct the problem.Once
On Fri, Dec 17, 2021 at 12:30 PM Dotzero wrote:
>
>
>
>
> DMARC does not assess "honesty" nor does it assess "fraudulence". It only
> determines whether something passes or fails the validation check. You are
> apparently trying to overload your value interpretations in a manner that
> does not
On Thu, Dec 16, 2021 at 12:58 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Yes, this is important stuff.
>
> This is one of my problem scenarios:
>
> A record arrives at the first hop and obtains DMARC PASS, based on SPF
> and/or DKIM interpreted by a DMARC policy. Based on
Thanks Scott. _dmarc.police.uk doesn't seem to have the 'np' tag.
There are a number of domains with policies that have 'p=quarantine|reject
sp=none' - it would be good to see if 'np=reject' is added to any.
tim
On Wed, Dec 15, 2021 at 6:50 PM Scott Kitterman
wrote:
> On Wednesday,
On Mon, Dec 6, 2021 at 8:57 AM Scott Kitterman wrote:
>
>
> Unless there's a valid reason for someone to publish PSD=no, I don't think
> it should exist and I can't think of a reason. If you give people a knob,
> someone will turn it [if we leave it in, I guarantee you there will be
> things
On Sat, Dec 4, 2021 at 11:14 PM Scott Kitterman
wrote:
> Should we modify the definition of non-existent domains so that a domain
> that
> only has an RFC 7505 null mx record is still considered non-existent?
>
> I'll propose text if it's agreed this would be a useful change?
>
> Scott K
>
>
I am Ok with adding text of this nature, and I think it's helpful in
explaining to folks approaching
DMARC for the first time. But I start to lose focus on reading long
introductions (okay boomer).
Maybe the Intro could get a section or two to help focus it.
I am glad to assist wordsmithing
On Sat, Dec 4, 2021 at 6:20 AM Alessandro Vesely wrote:
> On Fri 03/Dec/2021 19:38:26 +0100 Todd Herr wrote:
> > On Fri, Dec 3, 2021 at 12:40 PM Alessandro Vesely
> wrote:
> >>
> >> last message for today: the "t" tag instead of "pct".
> >>
> >> That's the only part which breaks existing
I must agree with Mr Levine on this.
tim
On Sat, Dec 4, 2021 at 1:00 PM John Levine wrote:
> It appears that Murray S. Kucherawy said:
> >-=-=-=-=-=-
> >
> >This was reported but not sent to the WG. I believe the right disposition
> >is "Hold for Document Update". Does anyone want to
On Thu, Nov 4, 2021 at 6:54 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> It would be helpful to understand why people want to climb into the
> publicsuffix.org list.My guess: An ISP, such as "ISP.TLD" allows
> customers to create websites under their parent. They need
Thanks for pointing this out Scott, I've been sidetracked.
Section 8 gives me issues also. Many of these topics I've always felt would
go into a BCP on operation practices.
I am not well ensconced in the Mail community, but are this disagreements
between
vendors, software, etc over if one is
-sep dmarc-nprequest]
[dmarc-sep]
My first instinct is some sort of diff type output, but that isn't right.
tim
On Mon, Jun 7, 2021 at 6:26 PM Dave Crocker wrote:
> On 6/7/2021 3:10 PM, Tim Wicinski wrote:
>
>dmarc-nprequest = "np" *WSP "=&
All
When I raised the point for dmarc-bis making sure that new tags define
their ABNF, I realized that the PSD document does no such thing.
It does describe the definition, as it's the same as the "sp" tag.
I added the following section to dmarc-psd updating 7489 as such:
3.3. Changes in
+1 With Mr Levine's line of thinking.
I also agree with keeping pct= tag.
tim
On Thu, Jun 3, 2021 at 7:16 PM Dotzero wrote:
>
>
> On Thu, Jun 3, 2021 at 6:17 PM John Levine wrote:
>
>> It appears that Alessandro Vesely said:
>> >On Thu 03/Jun/2021 05:45:33 +0200 Murray S. Kucherawy wrote:
te:
> Tim, please add a ticket for this
>
> On Fri, May 28, 2021 at 13:54 Dave Crocker wrote:
>
>> On 5/28/2021 12:10 PM, Tim Wicinski wrote:
>>
>> So in looking at removing the "ri" tag from the document, I realized that
>> the ABNF reference neede
So in looking at removing the "ri" tag from the document, I realized that
the ABNF reference needed to be removed also.
Thinking about that, I realized that when one adds a new tag to the
registry there should be a formalized way that it is represented in the
ABNF. Perhaps the IANA Consideration
Editors,
I sent y'all a pull request.
Tim
On Fri, May 28, 2021 at 2:35 PM Dotzero wrote:
>
>
> On Fri, May 28, 2021 at 1:59 PM John Levine wrote:
>
>> It appears that Tim Wicinski said:
>> >-=-=-=-=-=-
>> >
>> >All,
>> >
>
All,
This is the current text in Section 10.4 of dmarc-bis
Names of DMARC tags must be registered with IANA in this new sub-
registry. New entries are assigned only for values that have been
documented in a manner that satisfies the terms of Specification
Required, per [RFC8126].
- may have been addressed
> * [Ticket 28] - report driven mail loops - thought it was closed, but
> then looked like Murray re-opened it
> * Ale: liked the proposal from John L (on the list)
> * Steve: will review the mail thread
> * John L: mail loop thing was deep in the "don't
.txt
To: Scott Kitterman , Tim Wicinski
A new version of I-D, draft-ietf-dmarc-psd-13.txt
has been successfully submitted by Tim Wicinski and posted to the
IETF repository.
Name: draft-ietf-dmarc-psd
Revision: 13
Title: Experimental DMARC Extension For Public Suffix
On Tue, May 11, 2021 at 12:24 AM Benjamin Kaduk wrote:
> Hi Tim,
>
>
> > >
> > > --
> > > COMMENT:
> > > --
> > >
> > > This document is generally in pretty
Ben
On Wed, Apr 21, 2021 at 1:04 AM Benjamin Kaduk via Datatracker <
nore...@ietf.org> wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-dmarc-psd-12: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in
On Wed, Apr 21, 2021 at 4:38 PM Roman Danyliw via Datatracker <
nore...@ietf.org> wrote:
> Roman Danyliw has entered the following ballot position for
> draft-ietf-dmarc-psd-12: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in
Folks that deploy wildcard MX usually have a reason. It may not be a
reason that makes sense to others,
but there's usually a reason.
In those cases, np won't work. We should perhaps spell that out in the
text a bit more clearly.
On Fri, May 7, 2021 at 5:13 PM John Levine wrote:
> It
I will be able to attend.
I will ask the kind chairs that once an Interim is scheduled, you could
send a calendar invite with all the details for those of us unable to
function
without one?
thanks
tim
On Thu, May 6, 2021 at 11:08 AM John Levine wrote:
> It appears that Seth Blank said:
>
Robert,
On Mon, Apr 19, 2021 at 12:52 PM Robert Wilton via Datatracker <
nore...@ietf.org> wrote:
> Robert Wilton has entered the following ballot position for
> draft-ietf-dmarc-psd-12: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses
ion title (keeping the text
> of course)
>
>
>
> As you can guess, this is purely cosmetic, so, feel free to ignore my
> suggestion
>
>
>
> Kind regards
>
>
>
> -éric
>
>
>
> *From: *Tim Wicinski
> *Date: *Monday, 19 April 2021 at 17:36
> *To
On Fri, Apr 16, 2021 at 1:43 AM Eric Vyncke (evyncke)
wrote:
> Tim,
>
>
>
> Thank you for your quick reply and the updates to the document.
>
>
>
> My comment on section 5.1 was actually on section 4.1 ... Sorry about the
> mix, I should drink more coffee it seems :-o
>
>
>
Ahh, I see what you
Eric
On Thu, Apr 15, 2021 at 3:17 AM Éric Vyncke via Datatracker <
nore...@ietf.org> wrote:
> Éric Vyncke has entered the following ballot position for
> draft-ietf-dmarc-psd-12: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in
Lars
See below. Thanks for the comments
On Wed, Apr 14, 2021 at 4:44 AM Lars Eggert via Datatracker <
nore...@ietf.org> wrote:
> Lars Eggert has entered the following ballot position for
> draft-ietf-dmarc-psd-12: No Objection
>
> When responding, please keep the subject line intact and reply
Can you point me to some of the tests you are running? you can do that
offline.
you also want to do some testing with domains signed with DNSSEC and those
without.
This came up as an issue in opendmarc:
https://github.com/trusteddomainproject/OpenDMARC/issues/103#issuecomment-810036114
On
Oh shoot y'all I removed "obviously" once, then accidentally added it back
in.
My mistake.
On Mon, Mar 22, 2021 at 11:41 AM Dave Crocker wrote:
>
>
>> NEW
>>
>>Defensively registering all variants of "tax" is obviously not a
>>scalable strategy. The intent of this specification,
egistry, but presented in a different format.
Welcome feedback
thanks
tim
On Sat, Mar 20, 2021 at 7:41 AM Alessandro Vesely wrote:
> On Sat 20/Mar/2021 01:38:40 +0100 Tim Wicinski wrote:
> >> NEW
> >> o Branded PSDs (e.g., ".google"): The
On Fri, Mar 19, 2021 at 12:28 PM Alessandro Vesely wrote:
> On Fri 19/Mar/2021 15:09:31 +0100 internet-drafts wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > [...]
>
>
> Much better!
>
> There's still a few style points that I'd propose. They
Agree with Murray.
Also, I see changing "Algorithm" to "Specification" makes sense.
looking at the other suggestions
tim
On Fri, Mar 19, 2021 at 7:54 PM Murray S. Kucherawy
wrote:
> Just to nit-pick:
>
> On Fri, Mar 19, 2021 at 9:28 AM Alessandro Vesely wrote:
>
>> There's still a few style
Tim Wicinski has requested publication of draft-ietf-dmarc-psd-11 as
Experimental on behalf of the DMARC working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/
___
dmarc mailing list
dmarc
I have to overly agree with Murray here.
Where there should be discussions around using CNAMEs for DMARC records
would be in
a DMARC best practice document.
I spent some time yesterday digging through all the DKIM RFCs, and there is
no place
where there are discussions about using CNAMEs (Except
Using a CNAME at _dmarc.example should not be a problem, as long as
the CNAME target is a TXT record. The DNS resolver functions should
should handle this seamlessly. This does sound like a vendor software
problem.
I am aware of DKIM records being deployed using CNAMEs pointing to a TXT
record
Thanks Barry
I sent a pull request along to Scott with the changes.
I also generated an rfcdiff which I include for completeness sake.
thanks
tim
On Sun, Feb 28, 2021 at 5:02 PM Barry Leiba wrote:
> It looks right to me. Thanks, Tim.
>
> Barry
>
> On Sun, Feb 28, 2021
I was just working on merging Barry's comments with Dave's and Kurt's.
I attached what should be correct. I would like someone to just double
check my work.
tim
On Sun, Feb 28, 2021 at 4:35 PM Murray S. Kucherawy
wrote:
> These all work for me. Thanks for the contributions.
>
> Scott,
Thanks for sending this out Seth. folks are free to contact the chairs
and our AD if they have questions, concerns.
tim
On Mon, Feb 22, 2021 at 12:59 PM Seth Blank wrote:
> On 27 October 2020, in post
> https://mailarchive.ietf.org/arch/msg/dmarc/qtCDyGbeDHz96G8FaCxJvhJKrvo/
> the chairs
All
We've done a number of updates to the PSD document to reflect the GEN-ART
review,
mostly to expand on the experiments. There has been enough changes that we
want to do a short
working group last call.
https://tools.ietf.org/html/draft-ietf-dmarc-psd-10
To look at the differences, I would
I suggest adding it to this paragraph:
This document specifies experimental updates to the DMARC and PSL
algorithm cited above, in an attempt to mitigate this abuse.
On Fri, Jan 29, 2021 at 1:44 AM Murray S. Kucherawy
wrote:
> On Fri, Jan 22, 2021 at 5:01 PM Tim Wicinski wr
(this is really for Murray)
On Fri, Jan 22, 2021 at 6:25 PM Murray S. Kucherawy
wrote:
>
> Looks good to me where it is. I would add "(PSL)", introducing the
> acronym, right after its first use if we decide to leave it there.
>
> A formatting thing to take care of at some point: Anyplace you
(b) wrote:
> On Fri, Jan 22, 2021 at 4:57 PM Murray S. Kucherawy
> wrote:
>
>> On Fri, Jan 22, 2021 at 4:55 PM Kurt Andersen (b)
>> wrote:
>>
>>> On Fri, Jan 22, 2021 at 3:06 PM Tim Wicinski wrote:
>>>
>>>>
>>>> Here's the paragraph
On Fri, Jan 22, 2021 at 6:25 PM Murray S. Kucherawy
wrote:
> On Fri, Jan 22, 2021 at 3:05 PM Tim Wicinski wrote:
>
>>
>> Thinking twice, perhaps we don't need to introduce the PSL until Section
>>>> 3.4.
>>>> In that case, strike the last two sentences
On Tue, Jan 19, 2021 at 9:19 AM Murray S. Kucherawy
wrote:
> On Tue, Jan 19, 2021 at 2:31 AM Alessandro Vesely wrote:
>
> > To determine the organizational domain for a message under
>> evaluation,
>> > and thus where to look for a policy statement, DMARC makes use of a
>> > Public
On Tue, Jan 19, 2021 at 5:31 AM Alessandro Vesely wrote:
> On Tue 19/Jan/2021 07:43:01 +0100 Murray S. Kucherawy wrote:
> > [...]
>
>
> I guess "[this document]" refers to the RFC number to be. I think it's
> useless
> and can be safely removed, all of the five occurrences of it.
>
> It is
On Tue, Jan 19, 2021 at 1:43 AM Murray S. Kucherawy
wrote:
> In the interests of getting this document on its way, I'd like to suggest
> the following edits in response to Dale's most recent message. If the
> working group concurs, we can finally get this out to Last Call.
>
> My goal as an AD
an optimist.
tim
On Wed, Jan 6, 2021 at 11:52 PM Dave Crocker wrote:
> On 1/6/2021 8:47 PM, Tim Wicinski wrote:
>
> You should have a pretty good idea based on these arguments over the past
> few months to have a sense of how responses will be received. Take a step
> back and tak
Dave
You should have a pretty good idea based on these arguments over the past
few months to have a sense of how responses will be received. Take a step
back and take a second read.
This goes for all. Folks have very specific views of how they think mail
should work in regards to
All
If you feel a need to be heard, that is also what the chairs are here for.
thanks
tim
On Wed, Jan 6, 2021 at 7:21 PM Seth Blank wrote:
> Working Group colleagues,
>
> Discussion on this list is increasingly out of scope and process,
> unproductive, and antagonistic. This behavior
I will admit my memory can get pretty hazy, but I agree with Mr Levine - I
remember splitting out reporting,
but only as one document.
The Working Group can always make a compelling case to change this
tim
On Mon, Dec 28, 2020 at 12:06 PM John R Levine wrote:
> On Mon, 28 Dec 2020, Ned Freed
I would drop that whole third sentence, and mention sending such reports
may contain PII.
The document can refer the reader to non-IETF documents for information,
but in general
we do technical standards, and stay away from policy decisions in standards
track documents.
tim
On Mon, Dec 28,
I Believe I agree with the current version, but can someone post what we
think is the final text?
tim
On Wed, Dec 23, 2020 at 9:12 PM John R Levine wrote:
> On Wed, 23 Dec 2020, Dotzero wrote:
> > Based on my experience, I disagree that failure reports are marginal and
> > seldom used. It's
All
Can we please stop with the non constructive discussions here?
tim
On Mon, Dec 14, 2020 at 1:27 PM Michael Thomas wrote:
>
> On 12/14/20 10:09 AM, Dave Crocker wrote:
> > On 12/14/2020 10:00 AM, Michael Thomas wrote:
> >> When we tell you it's not a problem,
> >
> > Except that the
There are a number of open issues and you open more.
https://trac.ietf.org/trac/dmarc/report/1
I think it is being serialized for lack of people and also WG energy.
tim
On Mon, Dec 7, 2020 at 8:20 PM Michael Thomas wrote:
>
> On 12/7/20 5:15 PM, Tim Wicinski wrote:
>
>
> A good
A good section of our charter is collection Operational experiences. Doing
an Operational BCP on DMARC based on data collected is what the WG should
do after DMARC-bis.
tim
On Mon, Dec 7, 2020 at 7:50 PM Michael Thomas wrote:
>
> On 12/7/20 4:44 PM, Dave Warren wrote:
> > On Sun, Dec 6, 2020,
On Mon, Dec 7, 2020 at 2:26 PM Michael Thomas wrote:
>
> On 12/7/20 11:19 AM, John Levine wrote:
> > In article you write:
> >> Compared with the use of "l=" tag (Section 8.2 of [RFC6376]), the
> >> fact that footers are written in plain text ...
> > They are? Some are, some are added
Michael
I don't see john's comments as ad hominem. He's describing how his mail
system interprets mail flow.
But I do think a lot of this discussion is getting into very
esoteric cases.
I'd suggest trying to put your thoughts into a draft we can sit and chew on.
Tim
On Sat, Dec 5, 2020 at
repudiates all
> of them. NS lookup is not one of the mentioned options.
>
> There is a possible second-level policy test for a "mail-enabled domain".
> I would define that test as "MX record exists or SPF policy exists".
> That could be an additional option to NP
* Seth Blank s...@valimail.com
* Alexey Melnikov alexey.melni...@isode.com
* Tim Wicinski tjw.i...@gmail.com
### Documents:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/?include_text=1
https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/?include_text=1
https
Dave
It's the latter. Alexey and I are quite fine with running the meeting,
that was part of our conversation.
tim
On Fri, Nov 13, 2020 at 3:23 PM Dave Crocker wrote:
> On 11/13/2020 10:40 AM, Tim Wicinski wrote:
> > During the chairs call this morning we were discussing the
All
During the IESG reviews of draft-ietf-dmarc-psd, there were several issues
raised with some of the document. Most of them are editorial but the one
big item was the description of the Experiment. The chairs sat down and
broke out the experiment section into three separate experiments, and
All
The call for adoption ended earlier in the week, with the document being
adopted, and split. Since the existing document was going to be split, we
will wait until the editors produce their documents and those will be
adopted.
Thanks
tim
On Mon, Oct 26, 2020 at 5:58 PM Tim Wicinski
All
While the chairs are aware that working on DMARC-bis is the charter of the
working group, we want to ensure the process is followed.
This starts a Call for Adoption for: DMARC-bis
We'll be starting with the text from the RFC 7489.
This is available here:
Dale
Apologies for the delay on the PSD updates. I sat down with Scott and went
through your review and made lots of edits
related to your comments. I actually attached the reply to your email as
it's been sitting in my editor buffer for a few months too long.
One normative change that I want
And here we were getting along so well!
Mr Foster, it's perfectly fine to disagree with Mr Crocker technical
points, and you are
welcome to have your own opinion on whether he chooses to hear or not. But
those opinions should
be kept to yourself.
I see a lot of these heated discussions as a
published (see: ARC Usage).
tim
On Fri, Sep 25, 2020 at 10:01 AM Tim Wicinski wrote:
> All
>
> This call for adoption ended a few weeks ago, I have been recalcitrant in
> following up. The chairs feel
> there is enough consensus to adopt this work in DMARC. While there were
1 - 100 of 144 matches
Mail list logo
