Kurt
This is pretty interesting. I've been assisting several teams as we have
been (very) slow rolling the DMARC policy out of reporting through
quarantine into reject. They been pulling all the disparate teams into
deploying DKIM, but I was pointing out they have been guessing on who is
using DK
+1 on moving the discussion elsewhere
Tim
On Mon, Apr 8, 2019 at 10:27 PM Murray S. Kucherawy
wrote:
>
>
> On Mon, Apr 8, 2019 at 5:27 PM Douglas E. Foster <
> fost...@bayviewphysicians.com> wrote:
>
>> Scott, you misunderstand what this type of standard would look like. It
>> would defines
Oh, Thanks Scott!
The chairs were chatting about this a week ago. I'm going to reconfirm,
but look forward a WGLC coming this week.
Tim
On Mon, May 27, 2019 at 6:59 PM Scott Kitterman
wrote:
> On Monday, May 27, 2019 6:53:17 PM EDT internet-dra...@ietf.org wrote:
> > A New Internet-Draft is
I'm good with either of Scott's wordings on this.
I guess I'm making an assumption that the TLD operators know what they can
and can't do
(but that may be a horrible assumption).
Tim
(no hats)
On Sun, Jul 14, 2019 at 6:13 AM Alessandro Vesely wrote:
> On Fri 12/Jul/2019 20:27:05 +0200 Scott
I totally agree with the logic behind the experiment.
>From a document point of view, should we not document the 'np' part of the
experiment?
"The experiment will also evaluate the effectiveness of the 'np' tag for
non-existent subdomains. "
Tim
On Fri, Jul 12, 2019 at 2:28 PM Scott Kitterman
Thanks for the update Scott, and your wording on the 'np' tag in the
Appendix works.
I just want to call out your statement:
I think changing existing defined behavior for non-participants in an
experiment is not appropriate. It's even more unacceptable in a case like
this where we absolutely do
An experimental draft isn't the best place for a deployment guide.
an operational document that discusses deployment among other things is a
different story
On Fri, Jul 19, 2019 at 11:13 PM Scott Kitterman
wrote:
> On Friday, July 19, 2019 11:30:01 AM EDT Kurt Andersen (b) wrote:
>
> > > >
>From our end user point of view, I'm against abolishing quarantine, even
with its current shortcomings.
Tim
(no hat)
On Sun, Jul 28, 2019 at 8:48 AM Дилян Палаузов
wrote:
> Hello Alessandro,
>
> abolishing policy quarantine means with p=reject that for failed messages
> there should be some pe
Dave
I've had discussions with folks within the W3C on the PSL and the
possibility of extending it,
and there is always interest in considering requests from the IETF, but
they are the final
decision makers.
The whole idea of running an experiment would be to produce data that can
be shared and
c
Alessamdro
There are a couple of different combinations of dnssec
valid/invalid/expired you would want to account for.
Tim
On Mon, Oct 21, 2019 at 10:54 AM Alessandro Vesely wrote:
> On Wed 07/Aug/2019 17:16:29 +0200 Murray S. Kucherawy wrote:
> >
> >> If the definition of ptype smtp were "a
Scott
PSD DMARC does talk about organizational domains which from the original
DMARC spec (section 3.2)
does say 'Acquire a "public suffix" list'
The addition of the preamble text shouldn't move the document in either
direction.
I do feel anything which helps focus us on moving forward on DMARC-b
en (b) wrote:
> On Mon, Nov 11, 2019 at 1:58 AM Tim Wicinski wrote:
>
>> Scott
>>
>> PSD DMARC does talk about organizational domains which from the original
>> DMARC spec (section 3.2)
>> does say 'Acquire a "public suffix" list'
>>
>>
>
> If it were possible to infer OD from some kind of DNS record (or from RDAP
> responses, for another way) then we'd have a tool alternative to the PSL.
> That
> proves that the concept of OD is independent of the PSL, doesn'it?
>
Over in DNSOP we're been working with the authors on this Related
Scott
Instead of thinking one must choose between a locally consumed registry and
a lookup service, why not both?
In the land of DNSOP we put out RFC7706 which talks about running a copy of
the root Nameservers locally to
speed lookups. This seems to be so highly useful that we're just finished
W
+1
Tim
(just a fan of
https://www.ietf.org/archive/id/draft-levine-dbound-dns-03.txt)
On Sun, Dec 8, 2019 at 4:58 PM John Levine wrote:
> In article q...@mail.gmail.com> you write:
> >So we could decide on doing a combinatory of #3 and #1, with the right
> >mechanisms.
>
> Publishing a list of
Informational works for me if that helps moves things forward.
I also agree with Mr. Crocker's thesis on teasing about the PSL from DMARC,
but that should not hinder forward progress on PSD.
tim
On Thu, Feb 27, 2020 at 4:50 PM Kurt Andersen (b) wrote:
> On Thu, Feb 27, 2020 at 4:16 AM Aless
If we're going down the road of definitions, RFC8499 defines what a "Public
suffix" is
https://tools.ietf.org/html/rfc8499#page-28
Which could assist in the Public Suffix Domain definition here.
If this makes sense, I can offer some suggested text
On Sat, Feb 29, 2020 at 2:06 PM Murray S. Kuchera
I would agree with John here on keeping the implementation section should
be kept.
tim
(with no hats)
On Sat, Mar 7, 2020 at 3:43 PM John Levine wrote:
> In article <
> cabugu1rhecafhshcrwrehpru2kjpctoeqwai1g_njbb5ajf...@mail.gmail.com> you
> write:
> > Since information about existing impleme
-dmarc-dmarcbis-00.txt
To: Murray S. Kucherawy , Tim Wicinski <
tjw.i...@gmail.com>, Elizabeth Zwicky
A new version of I-D, draft-kucherawy-dmarc-dmarcbis-00.txt
has been successfully submitted by Tim Wicinski and posted to the
IETF repository.
Name: draft-kucherawy-dmarc-dm
On Wed, Mar 18, 2020 at 9:17 PM John Levine wrote:
> In article 5wsh0xluijs48fwb00vbq...@mail.gmail.com> you write:
> >> Consider: From foo@bogus.bogus.bogus.bogus.bogus...
> bogus.bogus.example.com
> >>
> >Yeah, I'm familiar with the nature of the attack. But based on what
> >amounts to the h
-kucherawy-dmarc-dmarcbis-01.txt
> has been successfully submitted by Tim Wicinski and posted to the
> IETF repository.
>
> Name: draft-kucherawy-dmarc-dmarcbis
> Revision: 01
> Title: Domain-based Message Authentication, Reporting, and
> Conformance (DMARC)
Agree with John/Scott/Kurt on keeping this in 7489 and trying to weasel
word around it for now.
I tried to reference 8499 thinking we'd done the right thing in there, and
Kurt pointed
out the error of my ways.
We should take an item to really sort this out in 7489bis.
and John has heard me on se
That works for me. I noticed Wikipedia has an entry for
https://en.wikipedia.org/wiki/Second-level_domain
and I remember seeing a spreadsheet of all the second level domains that
ccTLD registries offer,
and it was quite lengthy. (Longer than the list in Wikipedia)
tim
On Fri, Apr 10, 2020 at 1
Jim
This part of the meeting will be under the IETF Note Well
M3AAWG is holding a meeting in the previous hour which will
be under the M3AAWG rules, with the idea of bringing forward
useful discussion, etc.
tim
(Not being a M3AAWG member myself)
On Tue, May 12, 2020 at 5:19 PM Jim Fenton wro
+1 John and thanks.
tim
On Mon, May 18, 2020 at 3:51 PM John R. Levine wrote:
> While the setup for dmarc.ietf.org was correct before, it was pretty
> funky.
>
> I suggested they make a few changes which they have now done:
> there is now an explicit _dmarc.dmarc.ietf.org TXT record, and there
(With no hats)
I agree with John the v=DMARC1; is magic and MUST be first. Everything
else can show up wherever.
tim
On Fri, May 15, 2020 at 9:09 PM John Levine wrote:
> In article s9cqa7...@mail.gmail.com>,
> Murray S. Kucherawy wrote:
> >It's been a while since the original discussion,
(with no hats)
p=none with no reporting is fine, and we should keep it.
One thing the WG could do is a BCP document on operational recommendations
where there are certain suggestions like this.
tim
On Sat, May 16, 2020 at 5:37 AM Alessandro Vesely wrote:
> On Fri 15/May/2020 20:26:24 +0200 Se
BEGIN:VCALENDAR
VERSION:2.0
METHOD:PUBLISH
PRODID:-//IETF//datatracker.ietf.org ical agenda//EN
BEGIN:VEVENT
UID:ietf-interim-2020-dmarc-01-12834-dmarc
SUMMARY:dmarc - Domain-based Message Authentication, Reporting & Conformance
LOCATION:None
STATUS:CONFIRMED
CLASS:PUBLIC
DTSTART;TZID="UTC":2020061
We are also looking for someone to take minutes and someone to assist
monitoring the Jabber room
For minutes, we'll try to use the Etherpad (link in the Agenda) but minute
taker is not bound by that.
Thanks
tim
On Thu, Jun 4, 2020 at 8:32 PM Tim Wicinski wrote:
>
> All
>
>
All
The minutes from the Etherpad have been uploaded into the meeting
materials. You can review them here:
https://datatracker.ietf.org/doc/minutes-interim-2020-dmarc-01-202006111600/
If there are any incorrect statements please let the chairs know.
Alternatively, a pull request will also work:
(no hats)
On Mon, Jun 15, 2020 at 2:18 PM Brandon Long wrote:
>
> We sometimes use a different solution that isn't listed, which is
> basically where internal groups have access to the
> domain DKIM key, so they just re-sign. Those aren't really an interesting
> case, though.
>
>
I used to enco
On Mon, Jun 15, 2020 at 2:27 PM Scott Kitterman
wrote:
>
> To follow-up on Brandon's note about Google's use of ARC, it's bigger than
> mailing lists and so is this problem. It's any intermediary that modifies
> a
> message in such a manner that DKIM fails (SPF is only useful for direct
> source
Have to agree with Dave here. We have to accept it's a
constantly moving target.
On Thu, Jun 18, 2020 at 6:26 PM Dave Crocker wrote:
> On 6/18/2020 3:24 PM, Jim Fenton wrote:
> > We need to consider not just what's a useful correlation today, but what
> > will continue to be so.
>
> Oh good.
group on this.
Please review this draft to see if you think it is suitable for adoption,
and
send any comments to the list, clearly stating your view.
Please also indicate if you are willing to contribute text, review, etc.
This call for adoption ends: 2
Speaking not as a chair...
I do think the tree walk deserves another look. Years back when it was
brought up,
there was lots of talk of overloading resolvers. But as someone who spent
the past
several years looking at the DNS query data of good sized SaaS domains,
DMARC lookups
(or even DMARC NX
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
issues raised, the chairs feel
they can be addressed through the document process.
thanks
tim
On Mon, Aug 24, 2
Kurt
Seth had sent out a detailed email about our plan for working through three
tickets a week. Now it was from May but the process is spelled out:
https://mailarchive.ietf.org/arch/msg/dmarc/B6M4VSD7tDkPT6KCYul7uRGtI-Q/
Seth has been picking the three tickets over the weekend, which could be
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
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 sign
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 y
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:
https://datatracker.ietf.org/doc/draf
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
During the chairs call this morning we were discussing the upcoming
meeting. Now Seth has a conflict with the meeting time that can't be
altered. Since work items have been progressing rather well recently, and
the editors are in positing, we discussed canceling the meeting. We wanted
to g
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
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 discussin
tes-ietf-109-dmarc
### Chairs
* 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-reporti
ggest several ways to do a test of this type, then 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&quo
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 6:1
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 a
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, a
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
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 tellin
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 ki
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, 2020
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
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 undermin
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 DMARC/DKIM/SPF/A
sed of being 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 an
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 h
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 clear
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 S
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 sent
) 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
(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 r
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
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 su
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 ann
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, pleas
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
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 t
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
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
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
like
registry, 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"): T
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, ther
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 M
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 t
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 t
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 a
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
>
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 incl
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:
> >T
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 appears
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 the
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 t
On Tue, May 11, 2021 at 12:24 AM Benjamin Kaduk wrote:
> Hi Tim,
>
>
> > >
> > > --
> > > COMMENT:
> > > --
> > >
> > > This document is generally in pretty good
.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
eve: seems like there are deeper existential issues to be resolved
>
> ## Failure reporting (Steve)
> * [Ticket 55] - 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 fr
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]. Ea
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,
>> >
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
wrote:
> 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
+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:
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 Secti
-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 &qu
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 "imp
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
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 argue
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 record
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 Doug'
1 - 100 of 150 matches
Mail list logo
