Re: [dmarc-ietf] DMARC WG Interim meeting Proposal -- request for group feedback on timing and participation

Yes, I will participate and the proposed timing is fine. --Kurt Andersen ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] NXDOMAIN

On Thu, Apr 8, 2021 at 5:02 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > > "IETF is interested in attacks of the form > 'otherdomain.nonexistentdomain.psd', but IETF is not interested in attacks > of the form 'nonexistentdomain.otherdomain.psd'. > I don't understand your

Re: [dmarc-ietf] Sender vs From Addresses

On Wed, Mar 24, 2021 at 3:25 PM Charles Gregory wrote: > > Has anyone considered an option to add "affiliated domains" to a DNS > entry? That way at least you could specify legitimate alternate/authorized > domains that could still pass DMARC. > Yes, but no technically and operationally sound

Re: [dmarc-ietf] Sender vs From Addresses

On Wed, Mar 24, 2021 at 1:21 PM John Levine wrote: > It appears that Gren Elliot said: > >For better or worse, there is long established practice in the > Calendaring community when implementing iMIP (rfc6047) when an > >assistant is working on behalf of a manager for the manager’s email >

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-11.txt

On Sun, Mar 21, 2021 at 3:04 PM Tim Wicinski wrote: > > In Section 1.1 "Example" > > OLD > >Defensively registering all variants of "tax" is obviously not a >scalable strategy. The intent of this specification, therefore, is >to enhance the DMARC algorithm by enabling an agent

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-11.txt

Good work on the updated phrasing, I'd make just a couple of changes to the "tax" suggestion: On Fri, Mar 19, 2021 at 9:28 AM Alessandro Vesely wrote: > > *Example* > > Since the algorithm (last word) hasn't been mentioned yet: > > OLD > Defensively registering all variants of "tax" is

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

This is getting much better - thanks for all the wordsmithing. I have one nuance to add... On Thu, Feb 25, 2021 at 6:13 AM Dave Crocker wrote: > > The suggested revisions to Barry's suggested revisions, below, primarily > serve to reference the PSD construct without needing to reference the >

Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns

On Thu, Feb 18, 2021 at 7:09 AM Ken O'Driscoll wrote: > > . . . I'd propose something like the below, which I think gets across what > we all want to say. > > === > Aggregate feedback reports contain anonymized data relating to messages > purportedly originating from the Domain Owner. The

Re: [dmarc-ietf] Ticket #1 - SPF alignment

On Wed, Feb 10, 2021 at 6:43 AM Scott Kitterman wrote: > No. Sigh. Let's try it again. > > Yes, one might actually use a HELO result for DMARC. It gives you the > same > result as if mail from is null. So what? > > No one has given us a case where an attacker could get a aligned SPF > result

Re: [dmarc-ietf] Ticket #1 - SPF alignment

On Sat, Feb 6, 2021 at 11:53 AM Dotzero wrote: > > On Thu, Feb 4, 2021 at 11:43 AM John R Levine wrote: > >> I really do not see anything to change here, and we have a lot of other >> tickets to work on. Please, can we stop and close this one? >> > > +1 Could we have a show of consensus on

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

On Fri, Jan 29, 2021 at 6:52 AM Tim Wicinski wrote: > > 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. > update to DMARC = yes; update to PSL = no > On Fri, Jan

Re: [dmarc-ietf] Ticket #55, closing

On Mon, Jan 25, 2021 at 10:05 AM John Levine wrote: > In article <63451726-124b-c24f-3be1-d6435e12c...@tana.it> you write: > >OLDER: > >These reports SHOULD include the "call-to-action" URI(s) from inside > >messages that failed to authenticate. > The intent of calling out CTA links was

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

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 in question >>> >>> T

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

On Fri, Jan 22, 2021 at 3:06 PM Tim Wicinski wrote: > > Here's the paragraph in question > > 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 Suffix > List. The process for

Re: [dmarc-ietf] Forensic report loops

On Thu, Jan 14, 2021 at 7:28 AM Murray S. Kucherawy wrote: > On Thu, Jan 14, 2021 at 3:12 AM Дилян Палаузов > wrote: > >> I have not read the thread “Ticket #28 - Failure report mail loops”. >> > > Thanks, and apologies to the group; I should've checked for an open ticket > on this topic first.

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

On Tue, Jan 5, 2021 at 10:18 AM Paypal security confirm your password now < jo...@taugh.com> wrote: > >> reputation for the domain. I have trouble imagining why anyone would > >> think it's a good idea to get alignment by using third party domains > >> that recipients don't know. > > > > Because

Re: [dmarc-ietf] auth-res vs. dmarc

On Tue, Dec 29, 2020 at 5:31 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > > DKIM, A-R, and ARC should all have a mandatory attribute indicating the > HELO name of the server applying the header, the IP Address of the previous > server which supplied the information being

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

On Wed, Dec 23, 2020 at 10:10 AM John R Levine wrote: > On Wed, 23 Dec 2020, Ned Freed wrote: > > Failure reports provide detailed information about the failure of a > single > > message or a group of similar messages failing for the same reason. They > > are meant to aid in cases where a

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

On Tue, Dec 22, 2020 at 11:00 AM Alessandro Vesely wrote: > > Making specifications that cannot be legally abided by is in IETF scope? > Sure - RFC 7258. Unless you want to play the semantic card of BCP vs. specification. --Kurt ___ dmarc mailing

Re: [dmarc-ietf] p=quarantine

On Thu, Dec 10, 2020 at 6:26 PM Dave Crocker wrote: > On 12/10/2020 6:01 PM, Kurt Andersen (b) wrote: > > I think that is much closer to the right semantic but highlights a > > problem that the mail coming from a particular domain probably doesn't > > rate a single broad-b

Re: [dmarc-ietf] p=quarantine

On Thu, Dec 10, 2020 at 5:03 PM Dave Crocker wrote: > On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote: > > to quibble with the "*unauthorized use*" situation. This situation > devolves into use-as-imagined vs. use-as-really-used when one considers > vario

Re: [dmarc-ietf] p=quarantine

On Wed, Dec 9, 2020 at 10:09 AM Dave Crocker wrote: > It might be worth a bit of thinking about what, exactly, DMARC can > reasonably do and how it should be summarized, for popular consumption: > > *Alignment - *DMARC defines a basis for authenticating use of the domain > name in the

Re: [dmarc-ietf] dmarc - New Meeting Session Request for IETF 110

I'm wondering why we should wait for IETF110 rather than having an interim meeting sooner. Interim meetings are also likely to garner greater participation since they do not include participation fee. If there are topics worthy of F2F discussion, why wait? If there are not, then why charge people

Re: [dmarc-ietf] ARC vs reject

On Sun, Dec 6, 2020 at 10:46 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > > I ask the chairs to formally endorse development of an alternative to ARC > as an additional approach to the mailing list problem... > So you are asking the WG to go back to our second milestone and

Re: [dmarc-ietf] ARC vs reject

On Sat, Dec 5, 2020 at 5:21 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > ...much of this is about AOL in particular, and the currently available > information suggests that AOL is not on board with ARC. > I would point you to

Re: [dmarc-ietf] Ticket #1 - SPF alignment

On Sun, Dec 6, 2020 at 11:13 PM Murray S. Kucherawy wrote: > On Tue, Dec 1, 2020 at 2:17 PM John R Levine wrote: > >> We would like to close this ticket by Dec 15, two weeks from now, so >> short >> trenchant comments are welcome. >> >> Ticket #1 is about SPF alignment. We need to replace

Re: [dmarc-ietf] is DMARC informational?

On Fri, Dec 4, 2020 at 2:51 PM Michael Thomas wrote: > > What changed in the bis version to change its intended status? > The entire point of this working group (and the bis version that is in progress) is to move DMARC into the fully-recognized "standards" track. Note that even the current

Re: [dmarc-ietf] ARC questions

As usual, John has pretty well nailed the response, but there was one other part of your question (Mike) that I thought deserved explanation: On Sat, Nov 21, 2020 at 7:14 PM John Levine wrote: > In article you write: > >If I'm a receiver who is going to be making some filtering decisions >

Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

On Fri, Nov 20, 2020 at 5:57 AM Doug Foster wrote: > > However, spoofing of non-existent subdomains is a potential problem for the > RFC5321.MailFrom domain, which then becomes an attack vector for the > RFC5322.From address as well. The problem exists because because SPF has > no >

Re: [dmarc-ietf] IETF 109 possible agenda/session discussion

+1 to being able to sleep through the night and deal with issues asynchronously on the list. --Kurt On Tue, Nov 17, 2020 at 12:10 PM Dotzero wrote: > Considering that some of us have to be up in the wee hours to participate, > it would be nice to know whether it is happening or cancelled. Just

Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd

On Sun, Nov 15, 2020 at 12:21 PM John Levine wrote: > In article wm5wltcgib0jby0gubntop3qhzfr68yb2__r...@mail.gmail.com> you write: > > > https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08=draft-ietf-dmarc-psd-09 > > > >Please review the changes and offer up comments to the working

Re: [dmarc-ietf] IETF 109 possible agenda/session discussion

On Fri, Nov 13, 2020 at 10:41 AM Tim Wicinski wrote: > > 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

Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND

On Thu, Nov 12, 2020 at 2:58 PM Jesse Thompson wrote: > On 11/12/20 3:23 PM, John Levine wrote: > > You now can put a DMARC > > record on a name below the org domain to shadow a subtree, but I don't > > think that is a problem that needs to be solved. > > I'm confused by this statement. Are you

Re: [dmarc-ietf] Announcing DMARCbis Editors

On Thu, Nov 5, 2020 at 9:31 AM Alessandro Vesely wrote: > The consensus of the working group is to remove the > normative constraint about p= (ticket #49). So now only v= is required. > I must have completely misunderstood the discussion and will have to go back and look up the thread. I

Re: [dmarc-ietf] Subject: Call for Adoption: DMARC-bis

On Mon, Oct 26, 2020 at 2:59 PM Tim Wicinski wrote: > > 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/draft-kucherawy-dmarc-dmarcbis/ > > Changes made so far have been to include

Re: [dmarc-ietf] DMARC bis: ticket 51: disposition reporting in aggregate reports

On Tue, Sep 29, 2020 at 3:50 PM Dave Crocker wrote: > On 9/29/2020 3:08 PM, Seth Blank wrote: > > I don't know of any receiver that checks DMARC, but then doesn't check > > alignment > > It's not a matter of field statistics: > > Since checking alignment is an obvious part of the DMARC >

Re: [dmarc-ietf] DMARC bis: ticket 51: disposition reporting in aggregate reports

On Tue, Sep 29, 2020 at 3:15 AM Alessandro Vesely wrote: > > +1. The rationale, AIUI, is that if the receiver successfully evaluated > alignment, then "pass" is fine. If the receiver didn't evaluate anything > after > it saw p=none, then "none" is fine. and should agree. > If a receiver

Re: [dmarc-ietf] DMARC bis: revisiting ticket 66

On Mon, Sep 28, 2020 at 8:47 PM Seth Blank wrote: > At a minimum, per Dave's comments here: > https://mailarchive.ietf.org/arch/msg/dmarc/XXE3r5FUozl6LVohv8rTkn5QG4E/ > I still believe there's some clear consistent language that needs to be > agreed upon to drive the appropriate specificity in

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Mon, Sep 28, 2020 at 10:46 AM Dave Crocker wrote: > . . .given that 'disposing of' the message is a domain owner goal, > frequently, perhaps changing "disposed of" to "processed" would be less > inviting of misunderstanding? > Yes, I think that, at least in American English usage, "disposal"

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Sun, Sep 27, 2020 at 11:23 AM Scott Kitterman wrote: > On Sunday, September 27, 2020 1:16:11 PM EDT John Levine wrote: > > Agreed. Maybe it would help if someone who takes the latter view would > explain what they think RFC 7489, Section 6.6.2, Step 6 is for: > > >6. Apply policy.

Re: [dmarc-ietf] DMARC bis: ticket 38: reporting the proper DKIM key(s)

On Wed, Sep 23, 2020 at 2:56 PM Seth Blank wrote: > The original question in this thread had two parts: > > "Is it desirable to clarify this language, [1] such that it is clear which > DKIM keys are required to include in a report, and [2] if so, how should > the appropriate keys be determined?"

Re: [dmarc-ietf] DMARC bis: ticket 51: disposition reporting in aggregate reports

On Thu, Sep 24, 2020 at 1:39 AM Murray S. Kucherawy wrote: > On Sun, Jun 7, 2020 at 2:23 PM Seth Blank 40valimail@dmarc.ietf.org> wrote: > >> https://trac.ietf.org/trac/dmarc/ticket/51 >> >> In a DMARC aggregate report, a record with a disposition of "none" is >> ambiguous, as a disposition

Re: [dmarc-ietf] DMARC and Gateways?

A scenario that you did not list, but which used to be common was a mail transit path that went both in and out of a foreign protocol. Consider the example of a message that starts with SMTP --> X.400 (with irreversible changes) --> SMTP --> recipient. If the inbound and outbound gateways are not

Re: [dmarc-ietf] DMARC and Gateways?

The lack of universal DMARC verification and insufficient flexibility in the application of enforcement and local policy overrides in the "filter spam as a service" market (as well as the X.400, SMS, UUCP, Bitnet sort of protocol gateways) were the problems that we were addressing within this item

Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01

On Wed, Aug 19, 2020 at 12:11 PM John R Levine wrote: > > It is abundantly clear that Ericsson and AOL and Yahoo do not object to > their users sending mail through discussion lists. Ericsson doesn't want > their execs to be phished, AOLhoo doesn't want complaints "why am I > getting spam from

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

On Wed, Aug 19, 2020 at 1:34 AM Alessandro Vesely wrote: > On Tue 18/Aug/2020 01:21:33 +0200 Murray S. Kucherawy wrote: > > The industry in general, and the IETF in particular, have chosen not > > to pursue widespread use of any kind of standards-based third party > > domain signature policy or

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On Fri, Aug 14, 2020 at 12:16 PM Jim Fenton wrote: > On 8/14/20 11:30 AM, Kurt Andersen (b) wrote: > > On Fri, Aug 14, 2020 at 9:23 AM Dotzero wrote: > >> >> Is this an interoperability problem that is solved by IETF standards or >> is it an organi

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On Fri, Aug 14, 2020 at 9:23 AM Dotzero wrote: > > Is this an interoperability problem that is solved by IETF standards or > is it an organizational problem that requires an organizational solution? > Perhaps we need to generate an RFC entitled "Don't Do Stupid Things". ;-) > I think that it

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On Fri, Aug 14, 2020 at 7:31 AM Dotzero wrote: > > I've been involved in setting up DMARC with a policy of p=reject for > somewhere North of 6,000 domains. As a sending domain, the heavy lifting is > in getting buy-in across the organization that it is a worthwhile effort, > getting control of

[dmarc-ietf] Good paper analyzing inter-component flaws in email security

It would be worthwhile for everyone in the group to read through https://www.usenix.org/conference/usenixsecurity20/presentation/chen-jianjun as they analyze implementation flaws that allow attacks against DMARC in existing implementations. The paper should be publicly accessible now since the

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On Thu, Aug 13, 2020 at 2:33 PM Doug Foster wrote: > The current DMARC architecture supports authorizing a vendor to mail on > behalf of their clients if the client includes them in their SPF policy or > delegates a DKIM scope to them and they use it. > > > > I agree that SPF is too limiting

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On Thu, Aug 13, 2020 at 12:06 PM Neil Anuskiewicz wrote: > > Tunable! You said the magic word I have a client now getting spoofing. > Receiving spoofed mail or having their domain *being* spoofed? > My point is that it sure would be nice to be able to tune so that BigCRM > and BigCRM

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Mon, Aug 10, 2020 at 12:05 PM Tim Wicinski wrote: > > During IETF 108, the chairs realized that there was interest in Dave's > RFC5322.Sender draft. > > This starts a Call for Adoption for draft-crocker-dmarc-sender > +1 for adopting the document into the WG for continued discussion. --Kurt

Re: [dmarc-ietf] non-mailing list use case for differing header domains

This is a known issue with many calendaring frameworks. Besides the issue of delegates who are sending on behalf of someone in another domain, most calendaring systems send "forwarded" invitations by trying to resend in the name of the event originator. --Kurt

Re: [dmarc-ietf] Agenda requests for Madrid IETF

On Mon, Jul 20, 2020 at 11:36 AM Seth Blank wrote: > We have a session on the books for IETF108, and would like suggestions > from the group for the agenda, otherwise the chairs will choose relevant > topics. Items in tickets or from the past month are all fair game. > Based on the recent

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

On Fri, Jun 19, 2020 at 12:41 AM Laura Atkins wrote: > On 19 Jun 2020, at 07:59, Murray S. Kucherawy wrote: > > So to those of you with access to such (e.g., M3AAWG regulars among > us), is there evidence in the wild of spammers and phishers using > discardable (ahem) domains to achieve

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

On Mon, Jun 15, 2020 at 11:30 AM Tim Wicinski wrote: > > 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

Re: [dmarc-ietf] why ARC

On Fri, Jun 12, 2020 at 5:52 PM Dave Crocker wrote: > > > ARC lets the recipient look back and retroactively do the filtering > > the list didn't. > > The concern about the creator of an ARC chain spoofing the purported > origin of a message is valid. > By "creator" do you mean "initiator"

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

On Fri, Jun 12, 2020 at 5:06 PM Scott Kitterman wrote: > > On June 12, 2020 11:33:13 PM UTC, "Kurt Andersen (b)" > wrote: > >I would like to understand what you mean by: > > > >On Fri, Jun 12, 2020 at 1:02 AM Alessandro Vesely > >wrote: > >

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

I would like to understand what you mean by: On Fri, Jun 12, 2020 at 1:02 AM Alessandro Vesely wrote: > . . . ARC chains can be forged. > --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

I'm sorry to pile on but could not restrain myself: https://www.bmj.com/content/327/7429/1459?ijkey=c3677213eca83ff6599127794fc58c4e0f6de55a=tf_ipsecsha I get Dave's point, but at the same time, it is well known that copy tweaks can have significant effects on conversion rates. Whether the

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On Fri, May 15, 2020 at 6:14 PM John Levine wrote: > In article zmn0oxmgns0cspywu58hqlaw7wvvbh1442yu4e...@mail.gmail.com> you write: > >-=-=-=-=-=- > >Should we consider adding JSON formatting to DMARC? > > What Scott said, no. Report processors will always have to be able to > decode the

Re: [dmarc-ietf] Composition Kills: A Case Study of Email Sender Authentication

Extracting from the abstract of a paper in process by Casey Deccio (now researching SPF at BYU, formerly at Cisco): Our techniques elicit SPF and DMARC validation activity of the servers, > while minimizing spam and perceived abuse. We find that only 25% of mail > servers and less than half of

Re: [dmarc-ietf] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

On Thu, Apr 16, 2020 at 7:29 AM John Levine wrote: > In article <4666d39f-85f5-4ad2-a754-11fed0a5c...@kitterman.com> you write: > >Perhaps I'm too pessimistic, but I don't think it's possible to actually > make this clear to anyone that isn't familiar > >with RFC 7489 without essentially turning

Re: [dmarc-ietf] Genart last call review of draft-ietf-dmarc-psd-08

On Fri, Apr 10, 2020 at 9:34 AM John Levine wrote: > In article skkohn-j+qiccser1rtg1anwpw...@mail.gmail.com> you write: > >-=-=-=-=-=- > > > >Agree with John/Scott/Kurt on keeping this in 7489 and trying to weasel > >word around it for now. > > So how about renaming it Policy Super Domain

Re: [dmarc-ietf] Genart last call review of draft-ietf-dmarc-psd-08

On Fri, Apr 10, 2020 at 6:49 AM Scott Kitterman wrote: > On Friday, April 10, 2020 9:38:40 AM EDT Todd Herr wrote: > > > > I don't disagree, but what I was going for here was some level of > > consistency with section 3.2 of RFC 7489. . . > And it needs to stay entirely in RFC7489 :-) > >

Re: [dmarc-ietf] Genart last call review of draft-ietf-dmarc-psd-08

On Thu, Apr 9, 2020 at 1:36 PM Murray S. Kucherawy wrote: > > That seems like it paints a much clearer picture, which is what Dale was > after. A great start! > > On Thu, Apr 9, 2020 at 12:54 PM Todd Herr wrote: > >> Having reviewed the comments, I'm wondering if perhaps the following >> draft

Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers

On Fri, Apr 3, 2020 at 1:09 PM John Levine wrote: > In article < > caba8r6sbhlfkzhd4gapbxqbgny57j1elxt2spyafatyay3t...@mail.gmail.com> you > write: > >In practice, I don't know how common it is for clients to consume this > >header. > > They have to if they're adding ARC seals on the way out. >

Re: [dmarc-ietf] Definition of "value" in RFC8601

On Tue, Mar 31, 2020 at 10:56 AM Damian Lukowski wrote: > > I don't see any reason to exclude them. We could do this: > > > > autbserv-id = sub-domain *("." sub-domain) > > > > Where sub-domain is imported from 5321 for ASCII mail and 6531 for EAI > mail. > > Does this mean that a

Re: [dmarc-ietf] Definition of "value" in RFC8601

On Mon, Mar 30, 2020 at 10:43 PM Murray S. Kucherawy wrote: > On Mon, Mar 30, 2020 at 4:21 PM John R Levine wrote: > >> > Does someone have a fix in mind that could be submitted as an erratum? >> The >> > intent was indeed to make the authserv-id either a plain old ASCII >> domain >> > name or

Re: [dmarc-ietf] Publication has been requested for draft-ietf-dmarc-psd-07

On Sat, Mar 7, 2020 at 7:15 AM Murray S. Kucherawy wrote: > >> Thanks to you and Murray for carrying out that writeup. For a nit: >> >> There is one implementation already . . . >> >> Actually two. Besides Scott's implementation, zdkimfilter 1.7 implemented >> PSDDMARC since Tue 24 Sep

Re: [dmarc-ietf] A tweak to draft-ietf-dmarc-psd

On Sat, Feb 29, 2020 at 11:16 AM Tim Wicinski wrote: > > 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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

On Thu, Feb 27, 2020 at 4:16 AM Alessandro Vesely wrote: > On Thu 27/Feb/2020 06:30:59 +0100 Murray S. Kucherawy wrote: > > > > With a completed (and now seven month old) Working Group Last Call on the > > PSD document, and as far as I can see no sustained objection, we should > > proceed toward

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

On Tue, Feb 4, 2020 at 10:13 PM Scott Kitterman wrote: > > Assuming that's correct, please help me understand what PSD DMARC is > affected at all. All it does is consume the org domain however > DMARC/DMARCbis choose to define it. I don't see as it makes a difference > from a PSD DMARC

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

On Tue, Dec 10, 2019 at 2:13 PM Brandon Long wrote: > > On Mon, Dec 9, 2019 at 6:27 PM Kurt Andersen (b) wrote: > >> On Mon, Dec 9, 2019 at 4:54 PM Scott Kitterman >> wrote: >> >>> On Monday, December 9, 2019 7:41:27 PM EST Brandon Long wrote:

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

On Mon, Dec 9, 2019 at 4:54 PM Scott Kitterman wrote: > On Monday, December 9, 2019 7:41:27 PM EST Brandon Long wrote: > > > I'm sure I probably missed this, but couldn't we avoid this question by > just mandating no reporting for non-existing organizational domains? Is > that a non-starter? >

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

On Wed, Dec 4, 2019 at 2:39 AM Alessandro Vesely wrote: > > > Rather, it's primed as a possibly useful data collection exercise. > > Kurt also talked about reporting some findings. I'm embarrassed, I have no > idea what I, as a receiver, should report. What data should I, and other > receivers

Re: [dmarc-ietf] DMARCbis / Re: Collecting DMARC issues and nits for DMARC WG phase III - DMARC standardization

I'm willing to volunteer. On Tue, Dec 3, 2019 at 12:42 PM Murray S. Kucherawy wrote: > On Mon, Nov 18, 2019 at 7:49 AM Дилян Палаузов > wrote: > >> who is going to work on DMARCbis document and is it realistic to finish >> it with a year? >> > > We haven't started the process of selecting

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

I think that if we could get a core set of receivers who would be willing to test this and report on their findings in 3-6 months, that would be great. --Kurt On Tue, Dec 3, 2019 at 12:40 PM Murray S. Kucherawy wrote: > On Mon, Nov 11, 2019 at 2:21 PM Dave Crocker wrote: > >> On 11/10/2019

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 refe

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

On Mon, Nov 11, 2019 at 12:43 PM Alessandro Vesely wrote: > > about the need for each OD to opt out by defining its own DMARC record, > lest > have reports delivered to the realm. In the latter sense, Nominet solved > the > problem of what rights has gov.uk on domains below it. > Requiring

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

On Mon, Nov 11, 2019 at 9:50 AM Alessandro Vesely wrote: > On Mon 11/Nov/2019 16:46:17 +0100 Kurt Andersen (b) wrote: > > > > I don't think that it is fair to say that anyone who refers to the org > domain > > concept as cited in the DMARC spec is necessarily invo

Re: [dmarc-ietf] Call for rfc8601 erratum (smtp.remote-ip), was Do is need a new ptype?

On Mon, Nov 11, 2019 at 1:23 AM Alessandro Vesely wrote: > > Does the WG agree to an erratum as follows: > > TYPE: technical > > SECTION: 2.3 > > ORIGINAL TEXT: > >smtp: Indicates information that was extracted from an SMTP command > that was used to relay the message. The "property"

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

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' > > The addition of the preamble text shouldn't move the document in either > direction.

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

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' > > The addition of the preamble text shouldn't move the document in either > direction.

Re: [dmarc-ietf] Question regarding RFC 8617

for ARC to be a valuable addition to DKIM, it > needs to focus on the “custodian” and not the “sender”. > > > > Thank you both for your time and attention. > > -Bill > > > > *From:* Brandon Long > *Sent:* Wednesday, November 6, 2019 12:43 PM > *T

Re: [dmarc-ietf] Question regarding RFC 8617

The choice of which headers are included in the signed set is strictly up to the domain administrators who implement the signing practices. Also, the AMS is only relevant for the next receiver, it is not intended to be validated by hops >1 step away from the domain which adds that instance so I

Re: [dmarc-ietf] Two new fields in aggregate reports

On Fri, Oct 25, 2019 at 3:52 AM Дилян Палаузов wrote: > > If it is a goal to reuse the dmarc-reporting mechanism to report also > about perceived spam probability, then it can be > discussed in more details how this can be achieved. My experience is, > that asking a provider, why an obviously

Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL

On Fri, Aug 2, 2019 at 3:00 AM Alessandro Vesely wrote: > To stick with A-R semantics, it should have been named > tcp.ip, remote.ip or some such. > Note that RFC8617 section 10.2 ( https://tools.ietf.org/html/rfc8617#section-10.2) does add in an smtp.remote-ip method item. --Kurt

Re: [dmarc-ietf] DMARC aggregate reports XML Schema inconsistencies

On Wed, Jul 31, 2019 at 2:47 AM Freddie Leeman wrote: > I’ve been processing millions of DMARC aggregate reports from a lot of > different organizations, and have been trying to make sense of them for > quite some time now. I’ve noticed that most of them, even those from large > parties like

Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

On Fri, Jul 19, 2019 at 8:30 AM Kurt Andersen (b) wrote: > On Thu, Jul 18, 2019 at 10:42 PM Scott Kitterman > wrote: > >> >> If we want to take another run at this and put it in more standard DNS >> terminology, then maybe: >> >> a domain for which

Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

On Thu, Jul 18, 2019 at 10:42 PM Scott Kitterman wrote: > On Thursday, July 18, 2019 11:42:36 AM EDT Kurt Andersen (b) wrote: > > On Wed, Jul 17, 2019 at 7:35 PM Scott Kitterman > > > > Most MTAs will also follow CNAMEs. Should they be included (along with > > othe

Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

On Wed, Jul 17, 2019 at 7:35 PM Scott Kitterman wrote: > > On July 17, 2019 8:14:54 PM UTC, "Kurt Andersen (b)" > > wrote: > > >Firstly, I'm a little concerned with the sentence which says 'Note that > > >"np" will be ignored for DMARC reco

Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

On Wed, Jul 17, 2019 at 2:40 PM John Levine wrote: > In article zsdwzvr...@mail.gmail.com> you write: > >Firstly, I'm a little concerned with the sentence which says 'Note that > >"np" will be ignored for DMARC records published on subdomains of > >Organizational Domains and PSDs due to the

Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

On Tue, Jul 16, 2019 at 10:07 PM Scott Kitterman wrote: > > Updated rfcdiff attached. The only change other than typos is to add > mention > of 'np' to Appendix A. > Having reviewed the thread and the diff insofar as it pertains to the "np" tag, I'm in favor of the "np defaults to sp"

[dmarc-ietf] LC feedback on draft-ietf-dmarc-psd-04

Please note that I did not review Tim's comments in detail so some of the following points may have been covered by him previously. *Page 2 contains the following paragraph:* This memo provides a simple extension to DMARC [RFC7489 ] to allow operators

Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

On Fri, Jul 12, 2019 at 10:50 AM Scott Kitterman wrote: > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > > > 3. If an np= tag is needed to allow PSD functioning for only NXDOMAINs > > The limited feedback during WGLC has been favorable to this. > > This will require a rather

Re: [dmarc-ietf] Working Group Last Call: draft-ietf-dmarc-psd

I, for one, would *really* like to see the rumored "next version" from Scott and prefer to comment on that one, rather than an at-best penultimate version. --Kurt On Wed, Jul 10, 2019 at 1:21 PM Seth Blank wrote: > There is one week left before WGLC closes, and the below three items still >

Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication

On Wed, Jun 12, 2019 at 4:58 PM Alessandro Vesely wrote: > > Well, I personally use it and sometimes find it useful.[†] For a better > statistics, I have a DKIM add-on whose purpose is just to display some > authentication status. With 10,107 users, it ranks 61st of 1,339 in > Thunderbird's

  1   2   3   >