Re: [dmarc-ietf] From: rewriting, was Email standard revision
On 12/2/2019 8:29 AM, Dave Crocker wrote: It will help to have folk comment on the IETF mailing list, so that Klensin's comments don't just get responses from me. Sorry, wrong venue. The discussion is on the ietf-smtp mailing list, but the request for others to participate remains! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] From: rewriting, was Email standard revision
--On Monday, December 2, 2019 09:20 -0800 "Kurt Andersen (b)" wrote: > On Mon, Dec 2, 2019 at 9:11 AM John C Klensin > wrote: > >> >> --On Monday, December 2, 2019 08:29 -0800 Dave Crocker >> wrote: >> >> > On 12/2/2019 7:56 AM, Kurt Andersen (b) wrote: >> >> There's also already RFC7960 which expands upon 5598 with >> >> specific reference to DMARC's impact. >> > >> > ahh. thanks. >> > >> > It will help to have folk comment on the IETF mailing list, >> > so that Klensin's comments don't just get responses from me. >> >> Unfortunately, 7960 does not explicitly update 5598, so that >> relationship is difficult for anyone not heavily involved to >> discover (that neither Dave nor I was aware of the >> relationship is probably symptomatic). This may eventually >> call for an update that replaces both documents or may >> further justify a more or less comprehensive Applicability >> Statement for the core email protocols. > > > In this regard I think that something like Hector's > "practitioner's guide" (probably as a BCP rather than a > protocol standard) would be immensely helpful and meet this > need. Maybe we need to look for making a trilogy of docs > rather than just a duet: *21, *22, *23 :-) Already proposed on the IETF list and in private interactions with the ADs. It is probably a good sign that several of us seem to be reaching similar conclusions. john ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] From: rewriting, was Email standard revision
On Mon, Dec 2, 2019 at 9:11 AM John C Klensin wrote: > > --On Monday, December 2, 2019 08:29 -0800 Dave Crocker > wrote: > > > On 12/2/2019 7:56 AM, Kurt Andersen (b) wrote: > >> There's also already RFC7960 which expands upon 5598 with > >> specific reference to DMARC's impact. > > > > ahh. thanks. > > > > It will help to have folk comment on the IETF mailing list, so > > that Klensin's comments don't just get responses from me. > > Unfortunately, 7960 does not explicitly update 5598, so that > relationship is difficult for anyone not heavily involved to > discover (that neither Dave nor I was aware of the relationship > is probably symptomatic). This may eventually call for an > update that replaces both documents or may further justify a > more or less comprehensive Applicability Statement for the core > email protocols. In this regard I think that something like Hector's "practitioner's guide" (probably as a BCP rather than a protocol standard) would be immensely helpful and meet this need. Maybe we need to look for making a trilogy of docs rather than just a duet: *21, *22, *23 :-) --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] From: rewriting, was Email standard revision
--On Monday, December 2, 2019 08:29 -0800 Dave Crocker wrote: > On 12/2/2019 7:56 AM, Kurt Andersen (b) wrote: >> There's also already RFC7960 which expands upon 5598 with >> specific reference to DMARC's impact. > > ahh. thanks. > > It will help to have folk comment on the IETF mailing list, so > that Klensin's comments don't just get responses from me. Unfortunately, 7960 does not explicitly update 5598, so that relationship is difficult for anyone not heavily involved to discover (that neither Dave nor I was aware of the relationship is probably symptomatic). This may eventually call for an update that replaces both documents or may further justify a more or less comprehensive Applicability Statement for the core email protocols. Given that neither is Standards Track, it is not clear what aspects of them require incorporation into 5321bis and/or 5322bis. If we are going to open the latter documents, I look forward to that discussion at the appropriate time. john ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] From: rewriting, was Email standard revision
On 12/2/2019 7:56 AM, Kurt Andersen (b) wrote: There's also already RFC7960 which expands upon 5598 with specific reference to DMARC's impact. ahh. thanks. It will help to have folk comment on the IETF mailing list, so that Klensin's comments don't just get responses from me. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] From: rewriting, was Email standard revision
There's also already RFC7960 which expands upon 5598 with specific reference to DMARC's impact. On Sat, Nov 30, 2019 at 7:37 AM Dave Crocker wrote: > On 11/30/2019 4:40 AM, Alessandro Vesely wrote: > > Let me quote this from the ietf-smtp mailing list: > > On Sat 30/Nov/2019 00:12:53 +0100 John C Klensin wrote: > > --On Friday, 29 November, 2019 11:16 -0600 Pete Resnick wrote: > [...] > > Even the "From: rewriting" issue is > a gatewaying issue, not a message format issue per se. > > That is less clear. It fits into the gray area that has existed > for years about just exactly what a mailing list exploder / > redistribution system really is. > > > This view is reasonable only if one re-defines accepted terminology and > ignores some basic technical facts. > > A user specifies a recipient address. The message is posted and then > delivered to that address. > > That simple process describes basic email handling, and has been the > accepted view for roughly 40 years. > > And it describes the /first/ leg of a message sent /through/ a mailing > list. > > For the second leg, a bot at that address /re-/posts the message. In > simple, formal email technical terms, this is an entirely new email > transaction. > > It isn't 'gatewaying' per se, since that term applies to transit between > heterogeneous systems, but it /is/ a higher-level process. > > If only we had a document that discussed all this coherently, defined > basic terminology, and had undergone IETF review and approval. If only we > had RFC 5598... > > > d/ > > -- > Dave Crocker > Brandenburg InternetWorkingbbiw.net > > ___ > 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
