Re: [dmarc-ietf] [Request] Presentation in IETF101
Hi, > DKIM has opt-in nature. If opt-in means that DMARC record exists, our proposal is to change this opt-in nature because, as Shoko mentioned, virtual DMARC only focuses on the case which is obviously determined PASS. No one will not be in troubled, so I think we can modify about that. If not, I would like to know the specific situation. > Receivers can work this kind of operations using logs as they like. Yes, receivers can do by themselves if they do not care about the compliance with RFC7489. It specifies that the receiver adds dmarc=none in case there is no DMARC record, while dmarc=pass will be added if DMARC record exists. So I think we should discuss this contradiction. ---From RFC7489-- 11.2. Authentication-Results Result Registry Update IANA has added the following in the "Email Authentication Result Names" registry: Code: none Existing/New Code: existing Defined: [AUTH-RESULTS] Auth Method: dmarc (added) Meaning: No DMARC policy record was published for the aligned identifier, or no aligned identifier could be extracted. > DMARC is composed by policy and reporting, but Virtual DMARC does not have > reporting. Is it acceptable to introduce the new AR code, such as dmarc=SoftPass, and add it if no reporting policy is published ? With this new code, one can distinguish DMARC with reporting from DMARC without reporting. # In the current I-D, it specifies as PASS. To summarize, 1. Whether DMARC always requires opt-in 2. Whether dmarc=none is appropriate for the case where there is no DMARC record 3. Whether reporting is mandatory for DMARC Best regards, --Takehito Akagiri - 元のメッセージ - 差出人: "Yasutaka, Genki | Dkim | OPS" <genki.yasut...@rakuten.com> 宛先: "Shoko YONEZAWA" <yonez...@lepidum.co.jp>, dmarc@ietf.org Cc: "Yasutaka, Genki | Dkim | OPS" <genki.yasut...@rakuten.com> 送信済み: 2018年4月26日, 木曜日 午後 6:49:46 件名: Re: [dmarc-ietf] [Request] Presentation in IETF101 My understanding is that we have received some comments so far against Virtual DMARC. The main comments are as follows: - DKIM has opt-in nature. - DMARC is composed by policy and reporting, but Virtual DMARC does not have reporting. - Receivers can work this kind of operations using logs as they like. Regards, Genki --- Genki YASUTAKA Rakuten, Inc. Mail: genki.yasut...@rakuten.com -Original Message- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Shoko YONEZAWA Sent: Thursday, April 26, 2018 4:38 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] [Request] Presentation in IETF101 My opinion is that there seems no trouble in the case that the receiver issues dmarc=pass to the mail, whose domain has no DMARC record, and which is determined dmarc=pass even if DMARC record exists. In such case, dmarc=pass will be issued for any DMARC record where "strict" decision policy is set. Shoko On 2018/04/18 0:59, Dave Crocker wrote: > +1, for all of the below. > > > d/ > > On 4/17/2018 8:41 AM, Steve Atkins wrote: >> >>> On Apr 16, 2018, at 11:07 PM, Kazunori ANDO <a...@bbsec.co.jp> wrote: >>> >>> I think "virtual DMARC" is out of DMARC scope, because it's a purely >>> internal policy decision. >> >> +1 for the (not entirely unreasonable, but entirely internal) >> algorithm used, -1 for the terminology. >> >> Where it's in scope is that it's using the term DMARC for something >> that is really not DMARC and as part of that it seems to suggest >> squatting on the dmarc= namespace in Authentication-Results. >> >> On 2018/03/20 6:17, Scott Kitterman wrote: >>> Fundamentally, both SPF "Best Guess" and "Virtual DMARC" destroy the >>> opt-in nature of SPF and DMARC and should be considered harmful. >> >> +1 >> >> Again, please don't do this. >> >> Cheers, >> Steve >> >> ___ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > > -- Shoko YONEZAWA Lepidum Co. Ltd. yonez...@lepidum.co.jp TEL: +81-3-6276-5103 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [Request] Presentation in IETF101
My understanding is that we have received some comments so far against Virtual DMARC. The main comments are as follows: - DKIM has opt-in nature. - DMARC is composed by policy and reporting, but Virtual DMARC does not have reporting. - Receivers can work this kind of operations using logs as they like. Regards, Genki --- Genki YASUTAKA Rakuten, Inc. Mail: genki.yasut...@rakuten.com -Original Message- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Shoko YONEZAWA Sent: Thursday, April 26, 2018 4:38 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] [Request] Presentation in IETF101 My opinion is that there seems no trouble in the case that the receiver issues dmarc=pass to the mail, whose domain has no DMARC record, and which is determined dmarc=pass even if DMARC record exists. In such case, dmarc=pass will be issued for any DMARC record where "strict" decision policy is set. Shoko On 2018/04/18 0:59, Dave Crocker wrote: > +1, for all of the below. > > > d/ > > On 4/17/2018 8:41 AM, Steve Atkins wrote: >> >>> On Apr 16, 2018, at 11:07 PM, Kazunori ANDO <a...@bbsec.co.jp> wrote: >>> >>> I think "virtual DMARC" is out of DMARC scope, because it's a purely >>> internal policy decision. >> >> +1 for the (not entirely unreasonable, but entirely internal) >> algorithm used, -1 for the terminology. >> >> Where it's in scope is that it's using the term DMARC for something >> that is really not DMARC and as part of that it seems to suggest >> squatting on the dmarc= namespace in Authentication-Results. >> >> On 2018/03/20 6:17, Scott Kitterman wrote: >>> Fundamentally, both SPF "Best Guess" and "Virtual DMARC" destroy the >>> opt-in nature of SPF and DMARC and should be considered harmful. >> >> +1 >> >> Again, please don't do this. >> >> Cheers, >> Steve >> >> ___ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > > -- Shoko YONEZAWA Lepidum Co. Ltd. yonez...@lepidum.co.jp TEL: +81-3-6276-5103 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [Request] Presentation in IETF101
My opinion is that there seems no trouble in the case that the receiver issues dmarc=pass to the mail, whose domain has no DMARC record, and which is determined dmarc=pass even if DMARC record exists. In such case, dmarc=pass will be issued for any DMARC record where "strict" decision policy is set. Shoko On 2018/04/18 0:59, Dave Crocker wrote: +1, for all of the below. d/ On 4/17/2018 8:41 AM, Steve Atkins wrote: On Apr 16, 2018, at 11:07 PM, Kazunori ANDOwrote: I think "virtual DMARC" is out of DMARC scope, because it's a purely internal policy decision. +1 for the (not entirely unreasonable, but entirely internal) algorithm used, -1 for the terminology. Where it's in scope is that it's using the term DMARC for something that is really not DMARC and as part of that it seems to suggest squatting on the dmarc= namespace in Authentication-Results. On 2018/03/20 6:17, Scott Kitterman wrote: Fundamentally, both SPF "Best Guess" and "Virtual DMARC" destroy the opt-in nature of SPF and DMARC and should be considered harmful. +1 Again, please don't do this. Cheers, Steve ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc -- Shoko YONEZAWA Lepidum Co. Ltd. yonez...@lepidum.co.jp TEL: +81-3-6276-5103 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [Request] Presentation in IETF101
+1, for all of the below. d/ On 4/17/2018 8:41 AM, Steve Atkins wrote: On Apr 16, 2018, at 11:07 PM, Kazunori ANDOwrote: I think "virtual DMARC" is out of DMARC scope, because it's a purely internal policy decision. +1 for the (not entirely unreasonable, but entirely internal) algorithm used, -1 for the terminology. Where it's in scope is that it's using the term DMARC for something that is really not DMARC and as part of that it seems to suggest squatting on the dmarc= namespace in Authentication-Results. On 2018/03/20 6:17, Scott Kitterman wrote: Fundamentally, both SPF "Best Guess" and "Virtual DMARC" destroy the opt-in nature of SPF and DMARC and should be considered harmful. +1 Again, please don't do this. Cheers, Steve ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [Request] Presentation in IETF101
> On Apr 16, 2018, at 11:07 PM, Kazunori ANDOwrote: > > I think "virtual DMARC" is out of DMARC scope, > because it's a purely internal policy decision. +1 for the (not entirely unreasonable, but entirely internal) algorithm used, -1 for the terminology. Where it's in scope is that it's using the term DMARC for something that is really not DMARC and as part of that it seems to suggest squatting on the dmarc= namespace in Authentication-Results. On 2018/03/20 6:17, Scott Kitterman wrote: > Fundamentally, both SPF "Best Guess" and "Virtual DMARC" destroy the opt-in > nature of SPF and DMARC and should be considered harmful. +1 Again, please don't do this. Cheers, Steve ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [Request] Presentation in IETF101
+1. I think "virtual DMARC" is out of DMARC scope, because it's a purely internal policy decision. On 2018/03/20 6:17, Scott Kitterman wrote: Fundamentally, both SPF "Best Guess" and "Virtual DMARC" destroy the opt-in nature of SPF and DMARC and should be considered harmful. If an entity wants to apply this kind of test, it's a purely internal policy decision. No RFC needed.-- Kazunori ANDO / a...@bbsec.co.jp ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [Request] Presentation in IETF101
On Mon, Mar 19, 2018 at 7:14 PM, Steven M Joneswrote: > I want to thank Yasutaka san for presenting the Virtual DMARC proposal. I > believe the situation he and his colleagues are addressing would benefit > from more attention. > > Aside from changes to the "dmarc=" allowed values in > Authentication-Results: - and I think this echos a point made during the > session - the underlying issue seems to be the use of DMARC-style alignment > checks in the absence of a DMARC policy record. In some hallway discussion after the session yesterday, we discussed the assertion (made during the meeting) that all of the necessary information to evaluate alignment is already present within the headers on a message. While that is true for the initial receiver, there are scenarios for intermediated mail where the 5322.From may be modified (for instance, SRS processing) and as such, the alignment of the original message may not be able to be deduced by downstream MTAs. It may be worthwhile to consider earmarking the 5322.From domain into ARC's AAR header to cover such a scenario. Whether that information should also be recorded into the A-R header is less clear. I think it is pretty clear that this is not and can not be "DMARC" without sender participation, but alignment of identifiers can certainly be recorded for downstream usage. --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [Request] Presentation in IETF101
On 3/19/18 2:02 PM, Yasutaka, Genki | Dkim | OPS wrote: > > > You can download from the following link. > > https://datatracker.ietf.org/meeting/agenda.html > > - Virtual DMARC: DMARC verification without record definitions > > I will send you directly just in case. > Thank you, I found it -- I had used the "download meeting materials as PDF" link, which didn't include either slide deck, but I found the slides under the "Show meeting materials" link. To the list, in the (unlikely?) event I'm not the only one... --S. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [Request] Presentation in IETF101
Since SPF "Best Guess" is mentioned ... This was developed very, very early in the SPF project to help bootstrap the protocol when not very many domains published records. When the original SPF RFC, RFC 4408, was developed, it was considered for standardization and the judgment of the community was that it was not suitable for standardization. Fundamentally, both SPF "Best Guess" and "Virtual DMARC" destroy the opt-in nature of SPF and DMARC and should be considered harmful. If an entity wants to apply this kind of test, it's a purely internal policy decision. No RFC needed. Authentication Results already provides for documenting policy results. No need for trying to shoehorn this into DMARC results. It's not a DMARC result. This is not only not opt-in, there's no opt-out mechanism. Please don't do this (same as last time this came up - yes, I did check the slides to see if anything has changed and it hasn't). Scott K On Monday, March 19, 2018 09:02:15 PM Yasutaka, Genki | Dkim | OPS wrote: > Hi Steven, > > Thank you for your comment. > > You can download from the following link. > > https://datatracker.ietf.org/meeting/agenda.html > > - Virtual DMARC: DMARC verification without record definitions > > I will send you directly just in case. > > Regards, > Genki > > --- > Genki YASUTAKA > > Rakuten, Inc. > Mail: genki.yasut...@rakuten.com > > -Original Message- > From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Steven M Jones > Sent: Tuesday, March 20, 2018 4:15 AM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] [Request] Presentation in IETF101 > > I want to thank Yasutaka san for presenting the Virtual DMARC proposal. > I believe the situation he and his colleagues are addressing would benefit > from more attention. > > The meeting materials at IETF do not seem to include Yasutaka san's slides. > If I didn't just miss it, would it be possible to share that presentation? > > Aside from changes to the "dmarc=" allowed values in > Authentication-Results: - and I think this echos a point made during the > session - the underlying issue seems to be the use of DMARC-style alignment > checks in the absence of a DMARC policy record. > > That practice may be useful to the receiver's evaluation of SPF and DKIM > results. Perhaps that should be explored as a receiver/authenticator best > practice. It may be _very_ useful to capture these statistics to make it > clearer to domain-owners/senders that more current email traffic would pass > DMARC checks than they may presently realize. I would definitely like to > explore that further. > > But DMARC is based on cooperation between domain-owner/sender and > authenticator/receiver. And it depends on the explicit > opt-in/request-for-treatment from the domain-owner, signaled by a public > DNS record, and the reporting mechanisms so that the domain-owner/sender > can correct errors in implementation of authentication measures. > > Virtual DMARC seems to be discussing only what happens within the > authenticator/receiver, but perhaps I have missed this part. I look forward > to re-reading the proposal and slides with this in mind. > > --Steve. > > Steve Jones > DMARC.org, LinkedIn, crash.com, etc. > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [Request] Presentation in IETF101
Hi Steven, Thank you for your comment. You can download from the following link. https://datatracker.ietf.org/meeting/agenda.html - Virtual DMARC: DMARC verification without record definitions I will send you directly just in case. Regards, Genki --- Genki YASUTAKA Rakuten, Inc. Mail: genki.yasut...@rakuten.com -Original Message- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Steven M Jones Sent: Tuesday, March 20, 2018 4:15 AM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] [Request] Presentation in IETF101 I want to thank Yasutaka san for presenting the Virtual DMARC proposal. I believe the situation he and his colleagues are addressing would benefit from more attention. The meeting materials at IETF do not seem to include Yasutaka san's slides. If I didn't just miss it, would it be possible to share that presentation? Aside from changes to the "dmarc=" allowed values in Authentication-Results: - and I think this echos a point made during the session - the underlying issue seems to be the use of DMARC-style alignment checks in the absence of a DMARC policy record. That practice may be useful to the receiver's evaluation of SPF and DKIM results. Perhaps that should be explored as a receiver/authenticator best practice. It may be _very_ useful to capture these statistics to make it clearer to domain-owners/senders that more current email traffic would pass DMARC checks than they may presently realize. I would definitely like to explore that further. But DMARC is based on cooperation between domain-owner/sender and authenticator/receiver. And it depends on the explicit opt-in/request-for-treatment from the domain-owner, signaled by a public DNS record, and the reporting mechanisms so that the domain-owner/sender can correct errors in implementation of authentication measures. Virtual DMARC seems to be discussing only what happens within the authenticator/receiver, but perhaps I have missed this part. I look forward to re-reading the proposal and slides with this in mind. --Steve. Steve Jones DMARC.org, LinkedIn, crash.com, etc. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [Request] Presentation in IETF101
I want to thank Yasutaka san for presenting the Virtual DMARC proposal. I believe the situation he and his colleagues are addressing would benefit from more attention. The meeting materials at IETF do not seem to include Yasutaka san's slides. If I didn't just miss it, would it be possible to share that presentation? Aside from changes to the "dmarc=" allowed values in Authentication-Results: - and I think this echos a point made during the session - the underlying issue seems to be the use of DMARC-style alignment checks in the absence of a DMARC policy record. That practice may be useful to the receiver's evaluation of SPF and DKIM results. Perhaps that should be explored as a receiver/authenticator best practice. It may be _very_ useful to capture these statistics to make it clearer to domain-owners/senders that more current email traffic would pass DMARC checks than they may presently realize. I would definitely like to explore that further. But DMARC is based on cooperation between domain-owner/sender and authenticator/receiver. And it depends on the explicit opt-in/request-for-treatment from the domain-owner, signaled by a public DNS record, and the reporting mechanisms so that the domain-owner/sender can correct errors in implementation of authentication measures. Virtual DMARC seems to be discussing only what happens within the authenticator/receiver, but perhaps I have missed this part. I look forward to re-reading the proposal and slides with this in mind. --Steve. Steve Jones DMARC.org, LinkedIn, crash.com, etc. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [Request] Presentation in IETF101
Hi Satan Thank you for your comment. The first one is that we need to consider more negative impacts, but basically this mechanism will be well becasue this supports only emails which would potentially be "dmarc=pass", I think. The second is that > The second option, in practice, results in bulk, unsolicited email. I’m on the same page. We listed this in discussion points, but that may be a trivial solution. Regards, Genki --- Genki YASUTAKA <genki.yasut...@rakuten.com> Rakuten, Inc. From: Stan Kalisch [mailto:s...@glyphein.mailforce.net] Sent: Saturday, March 10, 2018 12:06 PM To: Satoru Kanno <ka...@lepidum.co.jp> Cc: dmarc@ietf.org; Takehito Akagiri <akag...@regumi.net>; Yasutaka, Genki | Dkim | OPS <genki.yasut...@rakuten.com> Subject: Re: [dmarc-ietf] [Request] Presentation in IETF101 Hi Satoru, On Mar 7, 2018, at 3:21 AM, Satoru Kanno <ka...@lepidum.co.jp<mailto:ka...@lepidum.co.jp>> wrote: Dear DMARC WG Chairs, I'm sending to you on behalf of Genki Yasutaka-san. As I asked you last November, we are preparing for the next track, with the intention of not only reviewing this draft, but also implementing for verification of vDMARC. If possible, I'd like to discuss this at IETF 101. [Details] -- - What I want to talk? Draft Overview and Implementation of vDMARC - Time required 10 minutes (*even for 5 minutes, if your schedule is too busy to adjust.) - Internet Draft https://datatracker.ietf.org/doc/draft-akagiri-dmarc-virtual-verification/ I've only been able to give this draft a brief initial look, but I do have comments regarding two issues. First, regarding this text: "In this draft, we propose to explicitly mark emails which are potentially "dmarc=pass", but are not marked as such via regular DMARC verification (None(2)), as "dmarc=pass"." What could happen as the result of this behavior, in the cases of forwarding or mailing lists, one could end up with one Authentication-Results header which contains, "dmarc=pass", but another which contains, "dmarc=none". Which bizarrely, in this kind of scenario, bypasses the mailing-list problem DMARC presently suffers from, but, well, arguably further confuses the issue, and calls into question the draft's assertion that "simply utilizing "dmarc=pass" makes it easier to leverage the field...for end users without enough expertise..." (I suppose you could still make that argument if the end user is viewing the "DMARC-ish" result via a UI like, say, GMail's, and that UI presents some kind of calibrated result.) Second, regarding this text: "There would be differing opinions regarding DMARC reports. One is the opinion that reports without explicitly published DMARC records are harmful, while another one is that without reports, virtual DMARC verification can not be called DMARC. Currently, we are siding with the first opinion in this draft." I don't see how you have a choice. The second option, in practice, results in bulk, unsolicited email. Thanks, Stan ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [Request] Presentation in IETF101
Hi Hector, Thank you for your comment. You know, we've focusing on emails which would potentially be marked as "dmarc=pass" in this draft, but we'd not almost aware of the opposite point so far. I would like to listen to your suggestions slowly. Regards, Genki --- Genki YASUTAKA <genki.yasut...@rakuten.com> Rakuten, Inc. -Original Message- From: Hector Santos [mailto:hsan...@isdg.net] Sent: Saturday, March 10, 2018 7:05 AM To: Satoru Kanno <ka...@lepidum.co.jp>; dmarc@ietf.org Cc: Takehito Akagiri <akag...@regumi.net>; Yasutaka, Genki | Dkim | OPS <genki.yasut...@rakuten.com> Subject: Re: [dmarc-ietf] [Request] Presentation in IETF101 On 3/7/2018 3:21 AM, Satoru Kanno wrote: > Dear DMARC WG Chairs, > > I'm sending to you on behalf of Genki Yasutaka-san. > > As I asked you last November, we are preparing for the next track, > with the intention of not only reviewing this draft, but also > implementing for verification of vDMARC. If possible, I'd like to > discuss this at IETF 101. > > [Details] > -- > - What I want to talk? >Draft Overview and Implementation of vDMARC > > - Time required >10 minutes (*even for 5 minutes, if your schedule is too busy to > adjust.) > > - Internet Draft > > https://datatracker.ietf.org/doc/draft-akagiri-dmarc-virtual-verificat > ion/ > -- > > Thank you for your cooperation and understanding. +1 to discussing this the concept. Overall, I think "default" protocol considerations should be included as part of a DMARC Proposed Standard effort. Interesting note stated by this draft: Microsoft Office365 employs the same technique as one mentioned in this draft ([BestGuessPass]). They append "dmarc=bestguesspass" to the Authentication-Results to indicate the authenticity of received emails to receiving MUAs. Why can't there be a "dmarc=bestguessfail?" If the Author Domain (5322.From) has no DMARC record, but there is a matching domain SPF record with a HARDFAIL policy, when a message fails due to SPF, some systems will reject at SMTP before or at DATA or accept and quarantine the SPF failed message. With the former, this concept does't apply since there is no AR record for this result. With the latter, the result "dmarc=bestguessfail" would better match what SPF exclusively produced - a failed condition. I actually found this to be a high true condition: If a domain has an exclusive, restricted SPF record (HARDFAIL), the odds are very high that the same or equal spoof detections (failures) would result if the domain only had a exclusive, restricted DKIM Policy model (ADSP, DMARC) record and not a SPF record. -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [Request] Presentation in IETF101
On 3/7/2018 3:21 AM, Satoru Kanno wrote: Dear DMARC WG Chairs, I'm sending to you on behalf of Genki Yasutaka-san. As I asked you last November, we are preparing for the next track, with the intention of not only reviewing this draft, but also implementing for verification of vDMARC. If possible, I'd like to discuss this at IETF 101. [Details] -- - What I want to talk? Draft Overview and Implementation of vDMARC - Time required 10 minutes (*even for 5 minutes, if your schedule is too busy to adjust.) - Internet Draft https://datatracker.ietf.org/doc/draft-akagiri-dmarc-virtual-verification/ -- Thank you for your cooperation and understanding. +1 to discussing this the concept. Overall, I think "default" protocol considerations should be included as part of a DMARC Proposed Standard effort. Interesting note stated by this draft: Microsoft Office365 employs the same technique as one mentioned in this draft ([BestGuessPass]). They append "dmarc=bestguesspass" to the Authentication-Results to indicate the authenticity of received emails to receiving MUAs. Why can't there be a "dmarc=bestguessfail?" If the Author Domain (5322.From) has no DMARC record, but there is a matching domain SPF record with a HARDFAIL policy, when a message fails due to SPF, some systems will reject at SMTP before or at DATA or accept and quarantine the SPF failed message. With the former, this concept does't apply since there is no AR record for this result. With the latter, the result "dmarc=bestguessfail" would better match what SPF exclusively produced - a failed condition. I actually found this to be a high true condition: If a domain has an exclusive, restricted SPF record (HARDFAIL), the odds are very high that the same or equal spoof detections (failures) would result if the domain only had a exclusive, restricted DKIM Policy model (ADSP, DMARC) record and not a SPF record. -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [Request] Presentation in IETF101
We will add this to the agenda. Does anyone else have specific agenda items they'd like to have added? Barry, as chair On Wed, Mar 7, 2018 at 3:21 AM, Satoru Kannowrote: > Dear DMARC WG Chairs, > > I'm sending to you on behalf of Genki Yasutaka-san. > > As I asked you last November, we are preparing for the next track, > with the intention of not only reviewing this draft, but also > implementing for verification of vDMARC. If possible, I'd like to > discuss this at IETF 101. > > [Details] > -- > - What I want to talk? > Draft Overview and Implementation of vDMARC > > - Time required > 10 minutes (*even for 5 minutes, if your schedule is too busy to adjust.) > > - Internet Draft >https://datatracker.ietf.org/doc/draft-akagiri-dmarc-virtual-verification/ > -- > > Thank you for your cooperation and understanding. > > Regards, > Satoru > > -- > Satoru Kanno > Lepidum Co. Ltd. > > E-Mail: ka...@lepidum.co.jp > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc