[dmarc-ietf] Re: DMARCbis version -33 is ready for document shepherd and AD processing
Hi Barry,
I just noticed something editorial in nature in the following paragraph
in Section 7.5:
A domain that expects to send only targeted messages to account
holders - a bank, for example - could have account holders using
addresses such as jo...@alumni.example.edu (an address that relays the
messages to another address with a real mailbox) or
finance@association.example (a role-based address that does similar
relaying for the current head of finance at the association). When
such mail is delivered to the actual recipient mailbox...
That first sentence is long and difficult to parse; and domains don't
have expectations. I suggest the following alternative in line with
existing practice and intent:
Some senders use email addresses from domains that are not associated
with a particular SMTP server. For example, Robin Jones might send
messages as jo...@alumni.example.edu when in reality that person's
mail flows through some other bigmailserver.example.com. Another
example would be someone who sends from a role-based address such as
headhon...@standards-organization.example.org. When such mail is
delivered to the actual recipient mailbox...
{yes, I changed the examples. Change them back if you like}
This is intended strictly (so to speak) as a friendly amendment. If
anyone has concerns, I've seen worse writing (from myself, I might add),
and we should just move on.
Eliot
On 08.08.2024 20:58, Barry Leiba wrote:
I've asked the document shepherd (Tim Wicinski, and thanks for
volunteering to handle this!) to do his final review and get the
writeup done, and I've alerted Murray that it's coming soon. I hope
those next steps will happen very soon.
Barry, as chair
___
dmarc mailing list --dmarc@ietf.org
To unsubscribe send an email todmarc-le...@ietf.org
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
dmarc mailing list -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Fwd: [Errata Held for Document Update] RFC7489 (7835)
FYI Forwarded Message Subject:[Errata Held for Document Update] RFC7489 (7835) Date: Mon, 11 Mar 2024 09:34:11 -0700 (PDT) From: RFC Errata System To: giuse...@ohpe.it, superu...@gmail.com, zwi...@yahoo-inc.com CC: rfc-...@rfc-editor.org, rfc-...@rfc-editor.org, rfc-edi...@rfc-editor.org The following errata report has been held for document update for RFC7489, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7835 -- Status: Held for Document Update Type: Technical Reported by: Giuseppe Trotta Date Reported: 2024-03-04 Held by: Eliot Lear (ISE & Editorial Board) Section: 6.6.3 Original Text - 2. Records that do not start with a "v=" tag that identifies the current version of DMARC are discarded. 3. If the set is now empty, the Mail Receiver MUST query the DNS for a DMARC TXT record at the DNS domain matching the Organizational Domain in place of the RFC5322.From domain in the message (if different). This record can contain policy to be asserted for subdomains of the Organizational Domain. A possibly empty set of records is returned. 4. Records that do not start with a "v=" tag that identifies the current version of DMARC are discarded. Corrected Text -- 2. Records that do not start with a "v=" tag that identifies the current version of DMARC are discarded. 3. If the set is now empty, the Mail Receiver MUST query the DNS for a DMARC TXT record at the DNS domain matching the Organizational Domain in place of the RFC5322.From domain in the message (if different). This record can contain policy to be asserted for subdomains of the Organizational Domain. A possibly empty set of records is returned. Notes - The intent of the original text is that indeed step 2 should be repeated as follows: (1) Go get a set of things. (2) Filter them. (3) If the set is now empty, go get a set of things from a different location. (4) Filter them. At the time of this writing, draft-ietf-dmarc-dmarcbis is being developed, and so that text may clarify this point. As such we will hold this erratum for update. -- RFC7489 (draft-kucherawy-dmarc-base-12) -- Title : Domain-based Message Authentication, Reporting, and Conformance (DMARC) Publication Date : March 2015 Author(s) : M. Kucherawy, Ed., E. Zwicky, Ed. Category : INFORMATIONAL Source : INDEPENDENT Area : N/A Stream : INDEPENDENT Verifying Party : ISE & Editorial Board OpenPGP_0x87B66B46D9D27A33.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Apr 30 06:00:04 2023
On 30.04.23 13:49, Hector Santos wrote: What is the count based on? Is the count the amount of mail created since the last date of this report which was 1 week ago? Did Scott create 25 messages and myself 14 messages in one week? I don't think so. I do. Here's what I learned after a few minutes of review. The point of the script is to help you self-moderate, so perhaps there's something for you to discover in these numbers. At the very least, you could check the IETF mail archives before complaining. Eliot Date Message-Id Wed, 26 Apr 2023 16:29:03 -0400 Thu, 27 Apr 2023 10:25:22 -0400 <644a85d2.1050...@isdg.net> Fri, 28 Apr 2023 14:38:32 -0400 Fri, 28 Apr 2023 17:30:00 -0400 <02b35043-8ee8-4666-89dd-251722aeb...@isdg.net> Tue, 25 Apr 2023 21:47:14 -0400 <644882a2.5050...@isdg.net> Tue, 25 Apr 2023 22:50:16 -0400 <64489168.1060...@isdg.net> Fri, 28 Apr 2023 08:54:38 -0400 <644bc20e.1060...@isdg.net> Wed, 26 Apr 2023 11:24:58 -0400 <6449424a.5070...@isdg.net> Thu, 27 Apr 2023 09:10:21 -0400 <644a743d.1000...@isdg.net> Sat, 29 Apr 2023 11:01:01 -0400 <630a8a65-e04d-4c48-ae80-516f610eb...@isdg.net> Mon, 24 Apr 2023 18:02:23 -0400 <6446fc6f.7050...@isdg.net> Sun, 23 Apr 2023 13:20:06 -0400 <644568c6.4000...@isdg.net> Mon, 24 Apr 2023 00:11:19 -0400 Mon, 24 Apr 2023 09:41:31 -0400 <6446870b.5080...@isdg.net> OpenPGP_0x87B66B46D9D27A33.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [RFC 7489: Erratum 6485
Hi, Can I get a bit more clarity on what should happen with this one. Eliot On 21.08.22 17:06, John Levine wrote: I happen to have a folder with 300,000 reports and took a look. Reporters can be pretty random about what they do. Comcast and Yahoo put angle brackets around the report ID but Google and Microsoft don't and nobody else does as far as I can see, so I would change the last line of the ABNF to: 1*FWS dot-atom-text; from RFC 5322 or I suppose we could make them optional 1*FWS [%x3c] dot-atom-text [%x3e] ; from RFC 5322 It appears that Independent Submissions Editor (Eliot Lear) said: -=-=-=-=-=- Dear Authors and DMARC group, In my continuing review of errata posted against RFC 7489, my view is that the following erratum should be verified, and I intend to do so in the next month unless given good cause not to do so. My logic is that running code in the wild should trump whatever is in the spec. Could people please go over the ABNF with a fine tooth comb? Eliot * * *Status: Reported Type: Technical Publication Format(s) : TEXT* Reported By: Kaspar Etter Date Reported: 2021-03-15 Section 7.2.1.1. says: dmarc-subject = %x52.65.70.6f.72.74 1*FWS ; "Report" %x44.6f.6d.61.69.6e.3a 1*FWS; "Domain:" domain-name 1*FWS ; from RFC 6376 %x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:" 1*FWS domain-name 1*FWS %x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:" msg-id ; from RFC 5322 It should say: dmarc-subject = %x52.65.70.6f.72.74 1*FWS ; "Report" %x44.6f.6d.61.69.6e.3a 1*FWS; "Domain:" domain-name 1*FWS ; from RFC 6376 %x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:" 1*FWS domain-name 1*FWS %x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:" 1*FWS %x3c dot-atom-text %x3e ; from RFC 5322 Notes: According to RFC 5322, msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS]. The example given in Section 7.2.1.1. (<2002.02.15.1>) does not adhere to this and neither do reports in the wild. Instead of referring to the msg-id ABNF, I suggest that we refer to the dot-atom-text ABNF and include "<" and ">" as ASCII characters. This also has the advantage of getting rid of CFWS. According to RFC 5322, "comments may be included in structured field bodies" but "Subject" is not a structured header field. -=-=-=-=-=- [Alternative: text/html] -=-=-=-=-=- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] RFC7489, Erratum 5552
Dear Authors and DMARC group, In my continuing review of errata posted against RFC 7489, my view is that the following erratum should be rejected, and I intend to do so in the next month unless given good cause not to do so. My reading is that the reporter has quoted from the wrong section of RFC 5321, and that we are not discussion Message Submission Servers. Eliot (ISE) *Status: Reported Type: Technical Publication Format(s) : TEXT* Reported By: Borislav Petrov Date Reported: 2018-11-09 Section 10.3. says: Everything about it.. Notes: DMARC relies on inspecting header information. This section suggestion is not allowed by rfc5321 and contradicts it: ...a relay SMTP has no need to inspect or act upon the header section or body of the message data and MUST NOT do so except to add its own "Received:" header field.. So the correct behaviour shoud be only the second option - 2xy and decide what to do after that being silent or not. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] [RFC 7489: Erratum 6485
Dear Authors and DMARC group, In my continuing review of errata posted against RFC 7489, my view is that the following erratum should be verified, and I intend to do so in the next month unless given good cause not to do so. My logic is that running code in the wild should trump whatever is in the spec. Could people please go over the ABNF with a fine tooth comb? Eliot * * *Status: Reported Type: Technical Publication Format(s) : TEXT* Reported By: Kaspar Etter Date Reported: 2021-03-15 Section 7.2.1.1. says: dmarc-subject = %x52.65.70.6f.72.74 1*FWS ; "Report" %x44.6f.6d.61.69.6e.3a 1*FWS; "Domain:" domain-name 1*FWS ; from RFC 6376 %x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:" 1*FWS domain-name 1*FWS %x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:" msg-id ; from RFC 5322 It should say: dmarc-subject = %x52.65.70.6f.72.74 1*FWS ; "Report" %x44.6f.6d.61.69.6e.3a 1*FWS; "Domain:" domain-name 1*FWS ; from RFC 6376 %x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:" 1*FWS domain-name 1*FWS %x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:" 1*FWS %x3c dot-atom-text %x3e ; from RFC 5322 Notes: According to RFC 5322, msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS]. The example given in Section 7.2.1.1. (<2002.02.15.1>) does not adhere to this and neither do reports in the wild. Instead of referring to the msg-id ABNF, I suggest that we refer to the dot-atom-text ABNF and include "<" and ">" as ASCII characters. This also has the advantage of getting rid of CFWS. According to RFC 5322, "comments may be included in structured field bodies" but "Subject" is not a structured header field. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] RFC 7489: Erratum 5371
Dear Authors and DMARC group,
In my continuing review of errata posted against RFC 7489, my view is
that the following erratum should be verified, and I intend to do so in
the next month unless given good cause not to do so. This is a
clarification as to which gzip spec should be used.
Eliot
*Status: Reported
Type: Technical
Publication Format(s) : TEXT*
Reported By: Cris van Pelt
Date Reported: 2018-05-28
Section 7.2.1.1 says:
The aggregate data MUST be an XML file that SHOULD be subjected to
GZIP compression.
It should say:
The aggregate data MUST be an XML file that SHOULD be subjected to
GZIP compression (described in [RFC1952]).
Notes:
The term "GZIP compression" is not defined in the text. To clarify,
maintain compatibility with future (potentially incompatible) gzip
versions, and to bring the document in line with other RFCs (e.g. 3712,
6713, 6968), a reference to RFC 1952 ("GZIP file format specification
version 4.3") should be added.
This is assuming RFC 1952 was the author's intent.
OpenPGP_signature
Description: OpenPGP digital signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] RFC 7489: Erratum 5365
Dear Authors and DMARC group, In my continuing review of errata posted against RFC 7489, my view is that the following erratum should be verified, and I intend to do so in the next month unless given good cause not to do so. The example simply doesn't follow the ABNF, and the correction does. Eliot * Type: Technical Publication Format(s) : TEXT* Reported By: Gary Palmer Date Reported: 2018-05-22 Section 7.2.1.1 says: mail.receiver.example!example.com!1013662812!1013749130.gz It should say: mail.receiver.example!example.com!1013662812!1013749130.xml.gz Notes: The specification states that the suffix should be "xml" for an uncompressed file, and "xml.gz" for a compressed file. The example filename is missing the "xml" component of the suffix ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] RFC 7489: Erratum 6729:
https://www.rfc-editor.org/errata/eid6729 Dear Murray and DMARC group, Please comment on the following reported erratum by Scott Kitterman against RFC 7489, an independent submission. I did not participate in the development of this RFC, and could see arguments on either side of this issue. In particular, I don't think the author thought that spinning up a VM meets the bar for generating high quality email. On the other hand, that bar itself may not serve a meaningful purpose. Left to my own devices, my intent would be to mark this one "Hold for update", and will do so in the next month or so, unless given good cause not to. Eliot Date Reported: 2021-11-01 Section 3.2 says: 3. Search the public suffix list for the name that matches the largest number of labels found in the subject DNS domain. Let that number be "x". It should say: 3. Search the ICANN DOMAINS section of the public suffix list for the name that matches the largest number of labels found in the subject DNS domain. Let that number be "x". Notes: The PSL includes both public and private domains. RFC 7489 should have limited name matching to the public, ICANN DOMAINS section of the PSL. As an example, using the current PSL, the organizational domain for example.s3.dualstack.ap-northeast-1.amazonaws.com is example.s3.dualstack.ap-northeast-1.amazonaws.com, not amazonaws.com since it is listed in the private section of the PSL. This is clearly the wrong result. OpenPGP_signature Description: OpenPGP digital signature ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposed rework of the wording in section 2.1 of draft-dmarc-interoperability
Hi Kurt, I need a bit more time to review this text, but I want to point out that one of my main issues was that an example or two that highlights the fields or the SMTP exchange would be helpful. I am willing to toss something together for the group's consideration if you want me to pass the token. Depending on their length I would drop these inline or in an appendix. Eliot On 12/7/15 4:23 PM, Kurt Andersen (b) wrote: > Rather than submit this directly as a draft update, I wanted to > circulate my proposed change for "pre"comment to see if it addresses > the concern with undue textual density in section 2.1, particularly > the last paragraph about SPF identifiers. My proposed rework for > section 2.1 follows below. I have split the section into subsections > dealing each with the DKIM and SPF identifiers and expanded the > discussion around the SPF identifiers. > > Comments welcome. > > --Kurt Andersen > > Currently, section 2.1 reads: > > 2.1. Identifier Alignment > > DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message > source validation. The DMARC [RFC7489] mechanism refers to source > domains that are validated by DKIM or SPF as Authenticated > Identifiers. DMARC requires an Authenticated Identifier to be related > to the domain found in the message's RFC5322.from header field > [RFC5322]. This relationship is referred to as Identifier Alignment. > > DMARC allows for Identifier Alignment to be achieved in two different > modes: strict and relaxed. Strict mode requires an exact match of > either of the Authenticated Identifiers to the message's RFC5322.from > header field [RFC5322]. Relaxed mode allows for Identifier Alignment > if Authenticated Identifiers and the message's RFC5322.from header > field [RFC5322] share the same Organizational Domain. In general, > interoperability issues between strict and relaxed modes are the same, > with strict mode constraining the application of possible solutions. > The mitigations described in this document generally require a relaxed > mode of Identifier Alignment. > > DKIM provides a cryptographic means for a domain identifier to be > associated with a particular message. As a standalone technology DKIM > identifiers are not required to be relevant to the content of a > message. However, for a DKIM identifier to align in DMARC, the signing > domain of a valid signature must be part of the same Organizational > Domain as the domain in the RFC5322.from header field [RFC5322]. > > In addition, DKIM allows for the possibility of multiple valid > signatures. The DMARC mechanism will process Authenticated Identifiers > that are based on DKIM signatures until an aligned Authenticated > Identifier is found (if any). However, operational experience has > shown that some implementations have difficulty processing multiple > signatures. The impact on DMARC processing is clear: implementations > that cannot process multiple DKIM signatures may incorrectly flag > messages as "failing DMARC" and erroneously apply DMARC based policy > to otherwise conforming messages. > > SPF can provide two Authenticated Identifiers. The DMARC relevant > Authenticated Identifiers that SPF provides is the RFC7208.MAILFROM > [RFC7208] based on the RFC5321.mailfrom [RFC5321] domain, or, if the > RFC5321.mailfrom address is absent (as in the case of "bounce" > messages), on the RFC5321.HELO/EHLO SMTP domain. The SPF validated > domain in RFC7208.MAILFROM must be part of the same Organizational > Domain as the domain in the RFC5322.from header field to be aligned. > It is important to note that even when an SPF record exists for the > domain in RFC5322.from [RFC5322], SPF will not authenticate it unless > it is also the domain checked by SPF. Also note that the > RFC7208.MAILFROM definition is different from the RFC5321.mailfrom > [RFC5321] definition. > > --- > Proposed rework: > > 2.1. Identifier Alignment > > DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message > source validation. The DMARC [RFC7489] mechanism refers to source > domains that are validated by DKIM or SPF as Authenticated > Identifiers. DMARC requires an Authenticated Identifier to be related > to the domain found in the message's RFC5322.from header field > [RFC5322]. This relationship is referred to as Identifier Alignment. > > DMARC allows for Identifier Alignment to be achieved in two different > modes: strict and relaxed. Strict mode requires an exact match of > either of the Authenticated Identifiers to the message's RFC5322.from > header field [RFC5322]. Relaxed mode allows for Identifier Alignment > if Authenticated Identifiers and the message's RFC5322.from header > field [RFC5322] share the same Organizational Domain. In general, > interoperability issues between strict and relaxed modes are the same, > with strict mode constraining the application of possible solutions. > The mitigations described in this document generally require a relaxed > mode of Identifie
[dmarc-ietf] handful of issues with draft-ietf-dmarc-interoperability-11
Hi everyone, In doing a review of this current version, I note a small number of issues that can be resolved fairly quickly, I think. In Section 1: >Email messages that do not conform to other email specifications but >are considered legitimate by the intended recipients are not >discussed in this document. I know this may seem obvious to those in this working group, but I think we mean other "IETF email specifications" above, and we should say so. In Section 2.1, re SPF: >SPF can provide two Authenticated Identifiers. The DMARC relevant >Authenticated Identifiers that SPF provides is the RFC7208.MAILFROM >[RFC7208] based on the RFC5321.MailFrom [RFC5321] domain, or, if the >RFC5321.MailFrom address is absent (as in the case of "bounce" >messages), on the RFC5321.HELO/EHLO SMTP domain. The SPF validated >domain in RFC7208.MAILFROM must be part of the same Organizational >Domain as the domain in the RFC5322.From header field to be aligned. >It is important to note that even when an SPF record exists for the >domain in RFC5322.From [RFC5322], SPF will not authenticate it unless >it is also the domain checked by SPF. Also note that the >RFC7208.MAILFROM definition is different from the RFC5321.MailFrom >[RFC5321] definition. This section is sufficiently dense that I would suggest that an example would be very helpful. Thee examples could go here or they could go elsewhere, but a handful would definitely help. I'm happy to develop some, if people are comfortable with that. Similarly, a DKIM example could be useful. We could probably borrow a message from this mailing list to prove the point. In addition we should probably be matching case between RFC 7208 and this document as we did for RFC 5321 so that someone who is searching can easily find the name, and so "RFC7208.mailfrom". In Section 2.2: >Message forwarding is a generic concept encapsulating a variety of >behaviors. This sentence doesn't really convey anything relevant and should be removed. The front of Section 3.1 may lead people to believe we are defining the term "Mediator". We are not. It also comes from RFC 5598 and it should be rephrased as follows: RFC 5598 also defines a Mediator is a hybrid of several component types. A Mediator is given special consideration in this section due to the unique issues they face when attempting to interoperate with DMARC. In Section 3.1.1, the following text is somewhat imprecise: >MSA interoperability issues with DMARC begin when an aMSA accepts a >message where the RFC5322.From header field contains a domain that is >outside of the ADMD of the MSA. The ADMD will almost certainly not >be capable of sending email that yields Authenticated Identifiers >aligned with the domain found in the RFC5322.From header field. >Examples of this issue include "forward-to-friend" functionality >commonly found on news/article websites or "send-as" functionality >present on some MUAs. In fact a number of systems have gotten around this by forming a message in the browser and passing it to the MUA. There is also an ambiguous meaning to the second sentence. For instance, it could mean that someone buying email service from Google who happens to have their own domain will not be able to send mail. If SPF records are configured in their domain, that is not the case. And so I would propose rewriting this paragraph as follows: MSA interoperability issues with DMARC begin when an aMSA accepts a message where the RFC5322.From header field contains a domain that is outside of the ADMD of the MSA. These issues manifest themselves in one of several ways, such as when someone uses a mail service with their own domain but has failed to properly configure an SPF record; or when an MUA attempts to transmit mail as someone else. Examples of the latter issue include "forward-to-friend" functionality commonly found on news/article websites or "send-as" functionality present on some MUAs. It may also be worth mentioning in Section 4.1.1 an additional bullet: o When implementing "forward-to-friend" functionality one approach to avoid DMARC failures is to pass a well formed message to the user's MUA so that it may fill in an appropriate identity. Section 3.1.2. The chapeau seems to dangle with a meaninglessly general statement: > 3.1.2. Message Transfer Agents > >MTAs relay a message until the message reaches a destination MDA. I propose a slight change just for flow: 3.1.2. Message Transfer Agents MTAs relay a message until the message reaches a destination MDA; and are thus in a position to introduce interoperability problems. Section 3.2 Based on the previous edit the first sentence can be removed. Eliot signature.asc Description: OpenPGP digital signature ___ dmarc mailing list dmarc@ietf.org http
[dmarc-ietf] happy to help on editing team on indirect email flows..
Eliot signature.asc Description: OpenPGP digital signature ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base revision submitted
Murray, You've clearly put a lot of work into updating this document, and there are a substantial number of changes. That means it deserves this group's serious attention. You've given me my homework assignment, I can say... Eliot On 10/29/14, 9:37 PM, Murray S. Kucherawy wrote: > On Tue, Oct 28, 2014 at 3:44 PM, Murray S. Kucherawy > mailto:superu...@gmail.com>> wrote: > > Since we're past the I-D deadline, the ISE or Pete will have to > approve its addition to the datatracker, so it will magically > appear at some point soon, and then move forward in the > publication process. > > > It's now available in the datatracker: > https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ > > -MSK > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc signature.asc Description: OpenPGP digital signature ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Start of DMARC WG + proposed milestones
Hi Tim, One suggestion... On 8/18/14, 5:31 PM, Tim Draegen wrote: > - EOY 2014: Deliverable #1 (above document + possible methods to address). That seems quite short a period between adoption and approval, and I question whether you will get sufficient review at a time when in America there is Thanksgiving, and then in December much of the world takes two weeks off". I'd suggest pushing back one month. Eliot signature.asc Description: OpenPGP digital signature ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
