Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows
On 30 Mar 2023, at 10:32, Douglas Foster wrote: Here is a quick attempt at a definition: Interoperability:Two (or more) entities cooperating to achieve a mutual objective" Not quite. If a third party does something that causes failure even when two entities do cooperate on their mutual objective, that's still a failure of interoperability. Go again to the TCP retransmission example: If I violate the standard, I can cause you and someone else on the network who are behaving reasonably to fail in rather impressive ways (indeed, even taking down whole networks). Documenting interoperability also means documenting what intermediaries and ancillary players MUST and MUST NOT do. Disruption If a message is blocked inappropriately, the responsibility falls on the entity that made the block decision, which is the recipient's evaluator. No, that's not the way we write standards in the IETF. Compare: An SMTP sender definitely has to deal with the possibility of a connection closing unexpectedly, but the standard still says that an SMTP receiver "MUST NOT intentionally close the transmission channel until it receives and replies to a QUIT command (even if there was an error)", and we say that because we know that not doing so causes problems for some senders. Saying, "Hey, it's up to the senders to implement things properly" is all well and good, but we still put requirements on the other end in order to increase interoperability. So: The sender's DMARC policy is an input to that decision, it has no power of its own. Of course it has power of its own: It is interpreted. You can object to the way it is interpreted, but if we have operational experience that it is interpreted in particular ways that cause delivery failures that we expect should complete reasonably, then it is incumbent on us to document that some DMARC policies MUST NOT be used in certain circumstances with known failures. I understand that some people wish the IETF produced conformance standards, but that's not what we do. When we see running code that consistently produces bad results, we write the standard to document that state of affairs. The previous and proposed DMARC specifications are misleading because they communicate false certainty. The only thing that a sender can assert is that all of the messages originated by him will be properly signed by him. Well, that's a bit misleading itself. The directive is not "p=signed". It is called "p=reject" for a reason, and that word is used elsewhere in the document. It carries meaning. The fact that it has been interpreted in a particular way should not be surprising. And given that historical interpretation, we now have an interoperability problem that needs to be documented appropriately. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows
On 29 Mar 2023, at 5:20, Todd Herr wrote: In my estimation, the language you propose here establishes the primacy of interoperability over the needs/wishes of the domain owner. As is appropriate for such normative language. From RFC 2119: 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. My preference is for language that acknowledges the primacy of the domain owner over interoperability. Not only ought there not be primacy of the needs/wishes of the domain owner over interoperability, the IETF has repeatedly rejected such a principle. An implementer might decide to implement a security backdoor, but our protocol documents say that you MUST NOT do that. An implementer might decide to violate TCP retransmission timer requirements to get better performance, but our protocol documents say that you MUST NOT do that. We document interoperability; we do not give primacy to the wishes of of domain owners. If you agree that interoperability is increased, then I'd suggest that you actually do agree that the proposed text is appropriate. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Mediation (was: Re: Header munging, not ARC, can solve the mailing list problem)
On 19 Jun 2020, at 15:05, Douglas E. Foster wrote: Why is the state of the message-id important? You have mentioned it twice. So, we've been talking about the semantics of messages sent by a mailing list. My contention has been that for many mailing lists, and particularly the ones we've been talking about, the intent is that the mailing list is simply resending messages on to the subscribers to the list. The semantics of the message are revealed in the headers: The From: header indicates who the author of the message is. And the message-id is a way for the resender of a message to indicate that it is "the same message" as a previous one that it received, and can used when "threading" messages in a conversation view or deleting duplicates for display purposes. It is not a required header. Well, kinda sorta. My apologies if you already know this; perhaps useful to others: Be careful about MUST/SHOULD/MAY in IETF documents. Of Message-ID:, RFC 5322 says: Though listed as optional in the table in section 3.6, every message SHOULD have a "Message-ID:" field. Furthermore, reply messages SHOULD have "In-Reply-To:" and "References:" fields as appropriate and as described below. And if you have a look at RFC 2119: SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Which is to say, "SHOULD" means "MUST unless you really know what you're doing". We don't do requirements the way other standards folks do. Also from 2119: Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. We don't do "conformance" in IETF by using MUSTs and SHOULDs and MAYs. It's all about interoperability. In this case, read the sentence as, "Use a Message-ID:, because if you don't you may screw up what the receiver of the message needs to do. That said, there might be circumstances where you simply can't produce one, and the recipient is going to have deal with that possibility, but you had better have a pretty good reason." It often uses a domain portion that is not a registered name. It needn't be registered to be useful; only unique. That said, I'm not sure about "often". The recipient has no way to know whether or not it has been changed during forwarding. It could be signed, could it not? I have tried to imagine a way to use message-id in message evaluation, but have given up. Back to your original question: My comment about Message-ID: was not about whether it was particularly useful for DKIM/DMARC, but more about how its semantics are reflected in mailing list email messages. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Mediation
On 19 Jun 2020, at 16:15, Pete Resnick wrote: [Offlist] Crap. My deepest apologies to Dave. I am very embarrassed by fat fingering that. It is not the worst private thing I've ever sent to a list, but still. (*Sigh*) pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Mediation
[Offlist] On 19 Jun 2020, at 15:07, Dave Crocker wrote: Please re-read my text... If there is a specification ... I apologize that I don't know what it is. These little passive-aggressive turns of phrase are not useful habits to teach to others on the list. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Mediation
We seem to be having a discussion with some premises misunderstood, so let me attempt to answer your message upside down, in hopes of undoing that: On 19 Jun 2020, at 15:07, Dave Crocker wrote: On 6/19/2020 12:02 PM, Pete Resnick wrote: On 19 Jun 2020, at 13:38, Dave Crocker wrote: But typical mediators are trying to maintain a sense and ability for the original author and the final recipient to experience an end-to-end message exchange. Yep. That's the point I was trying to make. Except you seem to be pressing this as essentially a requirement they have Ah, no, I think that's the crux of the misunderstanding: I was responding to Alessandro, who I interpreted to be saying that *all* mailing lists were, by definition, publishers, defining a publisher like a newspaper, where the true author of the content are the folks in the masthead, even though they acknowledge individual authors in the by-line. I disagree with that view. Indeed, I think for most of the mailing lists we have been referring to in this discussion, they are not publishers in Alessandro's sense, but rather view themselves as redistributors of author messages. As 5598 points out, there is variance in how much "editing" is done by any given mailing list, but again, for the discussion we've been having about how the From: field should be used, we've been talking about mailing lists which do the sort of minimal editing of messages. (For mailing lists that do more substantial editing, I may not be as motivated to keep the From: field unchanged. If we get more deeply into the discussion, it might be useful to start drawing more distinct circles around types of mailing lists.) So the purpose of pointing to 5598 was simply to explain to Alessandro that redistribution of messages through the transport system does not ipso facto make something a publisher. whereas I'm pressing it as a business decision I'm not really sure what that means or how it is relevant to the discussion, but again, I think we've been talking past eachother for the last two messages. not something inherent in the nature of mailing list behavior. No, sorry. I meant to simply point out the converse: That becoming a publisher is not in the nature of mailing list behavior. That said, I do disagree with the reasoning given with regard to why 5321.MailFrom has changed: It's not because of the authorship, but rather because it is responsible for the submission onto the network, just as the ReSender is in 5.2. I did not anything about MailFrom, or for that matter anything about any field with an identifier. I didn't say you had. I brought it up only because I re-read the section in 5598 on mailing lists, and it makes this claim. Just objecting in passing (because it seems to support Alessandro's view), not because I thought you were making some claim about it. I'm guessing that your reference is to the fact that a mailing list service might put its own address into the MailFrom, so it gets handling error messages? That issue and behavior predates DMARC by a lot. Probably two decades. Maybe more. I agree. Which is why I thought it relevant to the overall discussion. It was not directed at a particular statement of yours. But in terms of the layer above (the 5322 layer), it is usually the same message; see the second Note: in RFC 5322 section 3.6.4: Note: There are many instances when messages are "changed", but those changes do not constitute a new instantiation of that message, Except that there are many instances when messages might be changed that DO constitute a new instantiation of that message, and 5322 gives no guidance about what determine one versus the other. That's not true. In what you elided: In all cases, it is the meaning that the sender of the message wishes to convey (i.e., whether this is the same message or a different message) that determines whether or not the "Message-ID:" field changes, not any particular syntactic difference that appears (or does not appear) in the message. It doesn't give any algorithmic guidance, if that's what you meant. None of which is relevant to the point that a mailing list service has its own agency and is free to do what it wishes to and with the messages it is re-posting. Well, it seems exactly to that point. See above. That most seek to preserve essentially all of the author's text is fine, but whether and how much is more of a 'business' decision than a technical one. We appear to be in violent agreement, as the quip goes. Importantly, I think we agree that if a mailing list decides to preserve the original From: field, in an attempt to preserve all of the author's semantics, they are not "doing it wrong", as Alessandro's message appears to claim. I didn't mean anything so nit-picky. I mean that they are providing a value-added se
Re: [dmarc-ietf] Mediation (was: Re: Header munging, not ARC, can solve the mailing list problem)
On 19 Jun 2020, at 13:38, Dave Crocker wrote: The description of what a Mediator might do is not incompatible with also viewing it as having characteristics of a publisher: ### [5.3](<https://tools.ietf.org/html/rfc5598#section-5.3>). Mailing Lists ... In addition to sending the new message to a potentially large number of new Recipients, the Mailing List can modify content, for example, by deleting attachments, converting the format, and adding list- specific comments. Fair enough, but as you mention below, in the case of the common mailing list, the intent is simply to redistribute the message with minimal change (hence the retention of the Message-ID: and the From:). That said, I do disagree with the reasoning given with regard to why 5321.MailFrom has changed: It's not because of the authorship, but rather because it is responsible for the submission onto the network, just as the ReSender is in 5.2. Note that in terms of email transport, it is posting a new message. Strictly in terms of transport, yes. But in terms of the layer above (the 5322 layer), it is usually the same message; see the second Note: in RFC 5322 section 3.6.4: Note: There are many instances when messages are "changed", but those changes do not constitute a new instantiation of that message, and therefore the message would not get a new message identifier. For example, when messages are introduced into the transport system, they are often prepended with additional header fields such as trace fields (described in section 3.6.7) and resent fields (described in section 3.6.6). The addition of such header fields does not change the identity of the message and therefore the original "Message-ID:" field is retained. In all cases, it is the meaning that the sender of the message wishes to convey (i.e., whether this is the same message or a different message) that determines whether or not the "Message-ID:" field changes, not any particular syntactic difference that appears (or does not appear) in the message. Mediators really have complete freedom to do whatever they want. If describing the full range of what a publisher might do, it would cover the same range. Well, "complete freedom" in the sense that no Internet police prevent such actions. But for most mediators, large substantive (for interesting definitions of "substantive") changes are outside of the scope of their definitions, and would probably invite someone to say, "That's not being a mediator." Certainly that would happen in the case of an alias or a resender. But typical mediators are trying to maintain a sense and ability for the original author and the final recipient to experience an end-to-end message exchange. Yep. That's the point I was trying to make. The degree to which the mediator asserts itself more visibly to the recipient is probably the degree to which it looks more like a publisher and less like a simple relaying service. And eventually, I would contend, less like a mediator. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On 19 Jun 2020, at 11:40, Pete Resnick wrote: The presumption of all Mediator-type transactions was that the receiving email client was to deal with the message (the thing with the identical Message-ID) with its original semantics, adding only Resent-*: or List-*: fields to add the semantic of the mediation event. That sentence got munged due to cuts and pastes that didn't all add up. It should read: "The presumption of all Mediator-type transactions was that the receiving email client was to deal with the message (the thing with the identical Message-ID) with its original semantics, with the sender adding only Resent-*: or List-*: fields to add the semantic of the mediation event." -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
ith. You have to understand the long time pov of developers that have been at this for 40 years. Every system I have worked, the different networks, it was the same thing -- leave the from field alone! Do not make it "anonymous" or capable of being an "unknown." Its the same for Instant Messaging, for Chatting, the TELEPHONE, the Caller ID, etc, it is a TABOO to change the "From" entity. If you want to continue your line of logic to rationalize Rewriting, then you need to make it "protocol complete" to help keep the association of the From field with the original source intact. But more importantly, it should have get permission from the original domain in order to rewrite. This can be done with a DMARC tag extension: DMARC p=reject|quarantine ... rewrite=0|1 The default sides with highest security -- No Rewriting. But if the domain wishes to allow for rewriting, then it should explicitly state it in this policy record, rewrite=1. This is something I could possibly support IFF the originating domain allows it. There would other things to consider to tie the loose ends, but the #1, would be the rewrite=1 tag. -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On 17 Jun 2020, at 13:27, Dave Crocker wrote: On 6/17/2020 9:56 AM, Pete Resnick wrote: No, the semantics of From: have not changed generally. It's that some mailing lists have to change the semantics of From: in the face of the inability of DMARC to express the semantics that they want. The two sentences seem to be in conflict. If there is a degree of practice that creates a different semantic for the field, then its semantics have changed, at least for the portion of email traffic. You'll note the word "generally". Most of my email carries the same semantics it always has in From:. There is a small subset that doesn't. But (and not to get too philosophical here), even when the semantics aren't the same, it is often a surprise: I find that something didn't match my expectations, only to discover that the originator of the email didn't use the same semantics I was expecting as recipient. That doesn't necessarily constitute a change in semantics for the email, but a mismatch: The originator said "sunny" and I thought that meant "without clouds". Even if I figure out the mismatch, I might not agree to "the semantics changed"; I might prefer to go with, "The originator made a mistake." In the present case, some mailing lists are using the same old semantics and some are using a new set; that doesn't convince me that we have an interoperable semantics to which we have "changed". Here's a simple operational test: MUAs typically can aggregate messages 'from' the same author. After all, that's always been the primary role of From, to indicate who created the content. Such aggregation is usually found to be helpful. Historically -- for 40+ odd years -- this has worked for mail going through mailing lists. Now it usually doesn't. I'd appreciate an explanation of how that does not constitute a change in semantics. Of course, I'd be interested in the "usually" part. It's not true of my mailstore, but my mailstore is far from average. I do know that even on the local non-profit board to which I belong (and had no hand in setting up), the Outlook server uses the semantics to which I am accustomed, though maybe having a smaller list where most people using their gmail addresses makes it equally "not average". Have a folder with a variety of messages from correspondents, where some of a person's messages are sent directly to you and some of their messages are sent through mailing lists that adapt the From: field content in order to avoid DMARC rejection. The MUA will handle mail from the same person, but that went through these two different paths, as being from different sources. I'm sure that happens. DMARC relies on From: because it is the only field with an identifier that is always present. Sender is not reliably present, except virtually. The nature of what DMARC is actually doing looks more like relying on the operations-related Sender: field than the author-related From: field. DMARC has nothing to do with display of author information to a recipient, and everything to do with differential handling by a receiving filtering engine. Were the Sender: field always present, that would be the one that DMARC should have used. It could have chosen the more complicated, "Sender unless not present, in which case From". But yes, this bit I get. That said, there are people who have argued that From: was chosen because Sender: was not displayed. I think that's a silly argument, but it's one that people still believe. So, really, DMARC has altered the semantics of the From: field to be the Sender: field. Wait a minute: I think this point needs some clarification. We know that the pre-DMARC semantics of the From: field are "the entity that authored the message". Originators were expressing that meaning and recipients were interpreting that meaning. My understanding of the meaning that DMARC added was, "The author of this message, as expressed in the From: field, always has their messages properly signed by the domain in the From: address." You seem to be saying that, no, what DMARC did was changed the semantic to be, "The From: field now represents the transmitter of the message (as used to be expressed in the Sender: field when present), not the author, and that transmitter always has their messages properly signed by the domain in the From: address". Do I have that right? (And I presume that either way, these are de facto semantics, not intentional ones that are documented anywhere, right?) The nature of the hack that mailing lists do, when altering the From: field, makes this clear: They alter information about the operator handling the message, destroying the original information about content authorship. Mailing lists that make other choices (throwing away messages from DMARC reject senders, deny
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On 17 Jun 2020, at 4:23, Alessandro Vesely wrote: There are a few shortcomings of From: rewriting, which could be mitigated adopting suitable conventions. For example, MUAs' replying to author, or storing rewritten addresses in address books. As soon as you start down that path, you have eliminated one of the purported values of From: alignment: MUAs will start using those conventions (X-Original-From:, decoding encoded Froms) and display that information to the user instead of what's in the From: field, in which case you're going to need X-Original-From: alignment, and down the spiral we go. (For those who are amused by such things, do a web search for "X-X-Sender".) I am not convinced by many of the arguments for From: alignment, and think the problems lie with the lack of semantics able to be conveyed by a DMARC record in these cases, but I seem to be in the rough on these points. But there is no magic bullet in "suitable conventions". Now, if we make a semantic effort, we must recognize that the address of From: as a matter of fact refers to the "managing editor" of the corresponding mail flow, whereas the display name may indicate the actual author. No, the semantics of From: have not changed generally. It's that some mailing lists have to change the semantics of From: in the face of the inability of DMARC to express the semantics that they want. I can get together with a group of my friends and decide that the word "sunny" really means "cloudy", but unless the whole English-speaking world is on board with me, communication is bound to have problems. To say nothing of the Sender: field, which wasn't designed for that role anyway. Sender: has had pretty much the same definition back to RFC 733. It was perfectly designed for "the thing that sent the message, independent of the author." That's how email has evolved after introducing authentication. For most email, the meanings haven't changed at all. For a certain class of mail, authentication of a certain sort has forced arbitrary changes that have made the semantics ambiguous as compared to the past. I'd hope rfc5322bis will recognize those changes. I sure hope not. Meanwhile, if we gather consensus on how to do it better, it'd be fair to write it down, no? Assuming you can gather consensus. I'm not convinced you can. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best ___ 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
On 2 Jun 2020, at 13:29, Dave Crocker wrote: On 6/2/2020 11:12 AM, Pete Resnick wrote: On 2 Jun 2020, at 13:01, Dave Crocker wrote: There's no reason that DMARC couldn't have included the sender or tried to have some kind of PRA like spf v2... but that's not the goal. But the Sender: field is not reliably present and, of course, DMARC needs an identifier that is reliably present. Dave, could you explain that? Coding-wise, there's surely no reason that an implementation can't say, "if 5322.sender is present then sender = 5322.sender else sender = 5322.from". So you could say that the identifier of sender is reliably present, since it's taken from 5322.from if 5322.sender isn't present. But maybe I'm missing something. Please explain. Not sure what you are asking. What I mean is that it isn't always present. If Sender: contains the same address as From:, then Sender does not have to be present, and often/usually isn't. Well, that's the field, not its value. So when someone comes along and changes From: -- such as to hack around the DMARC problem for intermediaries -- the semantic of the Sender information is lost. If you do change the From, you should always add a Sender. (Or is your point that implementer's don't, and that's the problem?) What I'm missing is why the lack of an actual Sender: header field is problematic. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best ___ 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
On 2 Jun 2020, at 13:01, Dave Crocker wrote: There's no reason that DMARC couldn't have included the sender or tried to have some kind of PRA like spf v2... but that's not the goal. But the Sender: field is not reliably present and, of course, DMARC needs an identifier that is reliably present. Dave, could you explain that? Coding-wise, there's surely no reason that an implementation can't say, "if 5322.sender is present then sender = 5322.sender else sender = 5322.from". So you could say that the identifier of sender is reliably present, since it's taken from 5322.from if 5322.sender isn't present. But maybe I'm missing something. Please explain. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?
On 15 May 2020, at 23:54, Hector Santos wrote: On 5/15/2020 2:26 PM, Seth Blank wrote: Should we consider adding JSON formatting to DMARC? Protocols should be flexible. Adding it doesn't mean replace. Flexible sometimes means less interoperable. You've already got to get the XML right. Adding another format that you've got to get right sounds like it increases the odds that an implementer is going to get one of them wrong, and you've got to make sure that the XML and JSON semantics match each other. As Dave said, unless there's a compelling reason to add JSON, the potential for decreased interoperability says to me this isn't a good idea. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Milestones changed for dmarc WG
On 8/30/14 12:52 AM, Stephen J. Turnbull wrote: Pete Resnick writes: Good point: Mar 2015Complete draft specification on DMARC improvements to better support indirect email flows Up to this point the discussion on the dmarc mailing list has focused on alternative channels (Otis's TPA-labels, Kucherawy-Crocker's DKIM-Delegate) for communicating authorization, not changes to DMARC. Given that *all* of these specifications focus on authorization rather than denial with the single exception of DMARC's p=reject/quarantine, it's not obvious to me that improvements to DMARC are needed/feasible beyond acknowledging existence of other authorization protocols to which recipient policy may give precedence. How about s/DMARC improvements/protocol improvements/ ? If necessary, a nod to including changes to DMARC could be added. While I agree in principle, this is a distinction that is likely to be lost on people outside of the WG. DMARC improvements in the charter was meant to encompass possible changes to the DMARC spec, deletions from the DMARC spec, and additions to the DMARC spec (e.g., extra header fields in the message meant to indicate to implementations to do something different than the current DMARC spec says to do). I think most folks would understand all of those to be DMARC improvements, whether or not they actually call out a change in the base spec. We in the WG understand what we mean, and we can certainly be clear about it in the wiki. But I see no need for a change to the milestone text. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Milestones changed for dmarc WG
On 8/28/14 8:52 AM, IETF Secretariat wrote: URL: http://datatracker.ietf.org/wg/dmarc/charter/ Tim/Ned [Ccing WG]: While I think the milestones that appear in the wiki are great for internal WG management (and in fact I think you could even add more of them), I think for the external-facing milestones on the charter page, you should have the more common externally visible milestones like initial draft of X or submission of completed document Y to the IESG, etc. That work for you? pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Milestones changed for dmarc WG
On 8/29/14 12:35 PM, Tim Draegen wrote: On Aug 29, 2014, at 12:50 PM, Pete Resnickpresn...@qti.qualcomm.com wrote: Tim/Ned [Ccing WG]: While I think the milestones that appear in the wiki are great for internal WG management (and in fact I think you could even add more of them), I think for the external-facing milestones on the charter page, you should have the more common externally visible milestones like initial draft of X or submission of completed document Y to the IESG, etc. That work for you? Yes it does. I'll rework the external-facing milestones to perhaps remove some confusion. Are you OK with the following edits? Dec 2014Complete draft on DMARC interop issues + possible methods to address Mar 2015Complete draft on DMARC improvements to better support indirect email flows May 2015Complete draft on DMARC Usage Guide May 2015Complete draft on changes to DMARC base spec (That is, separating out the two documents from the May date, and rewording them a bit.) If so, I can make the changes as I approve them. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Milestones changed for dmarc WG
On 8/29/14 1:09 PM, Dave Crocker wrote: Not clear to me what draft on DMARC improvements... means. Is it a spec, a design discussion, or what? Good point: Mar 2015Complete draft specification on DMARC improvements to better support indirect email flows I'm also wondering about the implied overlap of work, cased on the close proximity of the final milestones. The dates I will leave to the WG and the chairs to work out how they wish to manage. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Milestones changed for dmarc WG
On 8/29/14 1:08 PM, Ned Freed wrote: Is complete draft the usual way these things are done now? It used to be that you list WGLC, LC, RFC published for each. Different groups do them different ways. I'm partial to just listing the complete draft, since LC and RFC published are dependent on parties other than the WG. I take complete draft to mean WGLC complete and submitted to the IESG. The other thing I like about complete draft in this case is that it leave it to the WG whether to publish a particular draft or not. For example, I can imagine the WG deciding, You know what: We're going to include enough of the discussion of interop issues and why we chose particular methods in the actual specification document, so there's no point in actually submitting the first draft as an RFC; it can just be an internal document. Or obviously the WG could choose to publish it because it *does* have important info for the community. Either way, you can make that decision independent of the milestone. I have to say I like this approach a lot better. Less bureaucracy. Me too. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Milestones changed for dmarc WG
On 8/29/14 1:19 PM, Dave Crocker wrote: Merely as a possible tool for figuring out the major milestones, perhaps the external choices should wait for the more detailed inward set of dates? Those will give a clearer sense of the wg focus on different topics at different times. I do prefer to have *something* listed on the charter page now, even if those dates are spitballs and likely to be updated once the WG gets its legs under it. With the current tools, the chairs can update those dates any time they see fit without having to go back to the AD, so they are by no means set in stone (or even very wet cement). pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Start of DMARC WG + proposed milestones
On 8/24/14 9:09 PM, Tim Draegen wrote: So, the WG will maintain an official focus that will track the milestones to allow for wider participation. That said, work on items that are ahead of the official focus (or even behind if something is overlooked and important) is most definitely encouraged, because it doesn't make sense to nip constructive work in the bud just to follow process. The only caveat I can think of is that topics/work-items will necessarily remain open until the WG officially focuses on them (again with the aim of inviting wide participation). Sure, but When the IESG reviewed this charter, we agreed to the three different phases for a reason: Dealing with the Indirect Mail Flow issue is a pretty contained task. We were inclined not to have the WG start diving into ratholes right out of the gate. The Usage Guide is a bit more of an open-ended discussion than Indirect Mail Flow, and the Spec Review could be a *big* discussion. Having a huge thread trying to sort a really juicy issue for a later phase can really suck the energy out of work on a current topic. So we wanted to give the chairs the ability to say, Thanks, that issue is definitely something we need to consider for the Spec Review, but let's toss that in the issue list for now and delay discussion of it until we're done with the current discussion. I definitely don't want work on future phase stuff ignored, but I also hope that we'll all be willing to hold off when the chairs say, Not right now. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] WG Review: Domain-based Message Authentication, Reporting Conformance (dmarc)
Folks, can I ask that you please remove i...@ietf.org from the recipient list if you want to have discussion that doesn't pertain to the charter itself. I'm hoping to recruit a prospective chair in the next few days to start moderating the discussion on the DMARC list itself while we're still dotting i's and crossing t's of the charter. I'm happy to have free-wielding discussion go on a bit, but please let's try and keep it to a dull roar while we're getting organized. Thanks. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Joel Jaeggli's No Objection on charter-ietf-dmarc-00-00: (with COMMENT)
On 7/10/14 12:36 AM, Joel Jaeggli wrote: -- COMMENT: -- The existing base specification is being submitted as an Independent Submission to become an Informational RFC. This implies the action is in the present when in fact the submission already occured and in the future still will have. The existing base specification (draft-kucherawy-dmarc-base) was submitted as a draft Independent Submission. I think summarizes what happened. I can adjust the verb tense in the sentence when I get to other nits. I think I prefer present perfect for this particular one. :-) pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Draft DMARC working group charter
On 7/5/14 7:59 PM, Hector Santos wrote: On 7/3/2014 11:04 PM, Pete Resnick wrote: As the working group develops solutions to deal with indirect mail flows, it will seek to maintain the end-to-end nature of existing identifier fields in mail, in particular avoiding solutions that require rewriting of originator fields. It is simply important that when solutions get discussed, if a proposal is made for one that involves rewriting originator fields, those of us who feel that it is a show stopper need to clearly, concisely, and professionally lay out the arguments for why doing so is very problematic. And there is where my concern lies. This puts an unnecessary heavy burden on proving why... Well, let's be clear: The current charter text says that the WG is going to avoid such solutions. So the *initial* burden of proof (so to speak) is going to be on those proposing a solution that rewrites originator fields. It is only once they make a case that it *is* reasonable to do such a thing, both at a technical level and as a matter of doing something against the charter, that folks might be asked to explain why it is still problematic in light of the new information brought forth by the proponents. At least that's the way I read the current charter text. We don't need to waste time in waiting for the obviously bad thing to go wrong before action is taken and with the IETF appeal process, its generally too late. Many tend to forget that the appeal process does not start with an appeal to the IESG at Last Call or later. In fact, it doesn't start with an appeal at all. If anyone disagrees with a WG decision, whether a strictly technical objection or because the WG simply failed to properly consider an alternative view, that should get brought to the chair immediately. No waiting. I am absolutely worried that indirect endorsement or redesign considerations for rewrites... I don't see this indirect endorsement or redesign considerations for rewrites in the charter text. So do I understand you to say that you think the text is not strong enough? Probably. Whats stronger than strong? Outlawed? The current text is now in front of the IESG for internal review. Assuming we approve it for external review on Thursday, you will see a announcement soliciting comments. A simple comment, with specific suggested textual changes, would be welcomed. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Draft DMARC working group charter
On 7/5/14 11:09 PM, Hector Santos wrote: On 7/5/2014 3:20 PM, Pete Resnick wrote: The current text is now in front of the IESG for internal review. Assuming we approve it for external review on Thursday, you will see a announcement soliciting comments. A simple comment, with specific suggested textual changes, would be welcomed. Rewrites of 5322.From headers are a serious security problem that will damage the efficacy and purpose of mail security goals of the DMARC protocol and also set a dangerous precedence for the mail framework as a whole. It is therefore out of scope. The WG will not justify nor promote rewrite proposals and will consider them as security problem to mitigate in the security section. Your suggestion will be taken into consideration. I will certainly forward it to the IESG during external review if you don't. (I should say that I *personally* don't think it's necessary to make such a strong statement, as I don't think it's going to change the outcome. So if others think that the statement needs strengthening along these lines, do speak up at external review time. Either way, I will make the IESG aware of the comment.) pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Draft DMARC working group charter
On 7/3/14 at 11:26 AM, Andrew Sullivan wrote: On Thu, Jul 03, 2014 at 11:22:18AM -0500, Pete Resnick wrote: Oh, I forgot one thing: The working group will seek to maintain the viability of stable domain-level identifiers in mail, and will document existing mail streams that do not conform to the DMARC model. I'm not sure what this means. Can someone explain? I still don't understand. Can we just strike this text? I'll bet a pretty good lunch that it's the way of saying, Rewriting localp...@example.tld to localp...@example.tld.invalid is not allowed. That's something that people have started doing for mailing lists. But I can't say for sure that's what it means. Oh. If so, perhaps we could come up with a slightly less obscure way of saying it? pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Draft DMARC working group charter
On 7/3/14 12:20 PM, Pete Resnick wrote: On 7/3/14 at 11:26 AM, Andrew Sullivan wrote: On Thu, Jul 03, 2014 at 11:22:18AM -0500, Pete Resnick wrote: Oh, I forgot one thing: The working group will seek to maintain the viability of stable domain-level identifiers in mail, and will document existing mail streams that do not conform to the DMARC model. I'm not sure what this means. Can someone explain? I still don't understand. Can we just strike this text? I'll bet a pretty good lunch that it's the way of saying, Rewriting localp...@example.tld to localp...@example.tld.invalid is not allowed. That's something that people have started doing for mailing lists. But I can't say for sure that's what it means. Oh. If so, perhaps we could come up with a slightly less obscure way of saying it? Well, nobody has stepped up to the plate to help, so I'm going to go with the following: As the working group develops solutions to deal with indirect mail flows, it will seek to maintain the end-to-end nature of existing identifier fields in mail, in particular avoiding solutions that require rewriting of originator fields. If you've got concerns with that, we'll take them up as comments to the IESG on the proposed charter. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Draft DMARC working group charter
On 7/3/14 9:15 PM, Hector Santos wrote: On 7/3/2014 8:32 PM, Pete Resnick wrote: As the working group develops solutions to deal with indirect mail flows, it will seek to maintain the end-to-end nature of existing identifier fields in mail, in particular avoiding solutions that require rewriting of originator fields. First an off topic comment, but I am doing so on list because everyone should make sure that they take care about this as well: I know this is just being all being ignored. Maybe you are reading it. But it has to go on the record. If you feel you are being ignored or otherwise mistreated on this list (or anyone else feels that they are), by me or by another participant, posting to the list is *exactly* the wrong way to say something about it. It's completely inappropriate. It's disruptive, and it sets a terrible tone for everyone else. Send personal mail to me, or to the list moderator, or to the IETF Chair if need be. But doing it here is wrong and must stop. End of admonition. Deleting the rest of the color commentary and sticking to the specific issue you've brought up: There should not be any advocation for any form of 5322.From tampering, ever, especially as a justification for bypassing a security protocol, EVER. [...] I don't understand: Are you saying that the text I have above in some way *advocates* for changes to the originator fields? I thought it is saying exactly the opposite. This is a shop stopper (ignore this work) and also put pressures on IETF appeals. Are you saying, This is a show stopper. If we end up with a protocol that requires the rewriting of originator fields, this work will be ignored (by me? by others?), and the decision to do so will be appealed (by me? by others?).? If you're saying any of those things, let's not get ahead of ourselves. There's no need to threaten appeals. It is simply important that when solutions get discussed, if a proposal is made for one that involves rewriting originator fields, those of us who feel that it is a show stopper need to clearly, concisely, and professionally lay out the arguments for why doing so is very problematic. A good chair should recognize the technical issues and will not call consensus if they are not satisfactorily addressed. Appeals are for when things go wrong, not when we're worried about things going wrong. [...]As a core mail principle, it MUST NEVER be valid to tamper with 5322.From, especially as a way to bypass a security protocol. The entire idea needs to be out of scope. So do I understand you to say that you think the text is not strong enough? pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Draft DMARC working group charter
On 7/1/14 11:00 AM, Dave Crocker wrote: I've looked over the small amount of mail posted about the draft charter and do not see any changes mandated. Nothing mandated, but here are some changes that I think clarify and/or simplify. You can find a diff here: https://www.ietf.org/rfcdiff?url1=http%3A%2F%2Fresnick1.qualcomm.com%2Fdmarc-charter-00.txtdifftype=--htmlsubmit=Go%21url2=http%3A%2F%2Fresnick1.qualcomm.com%2Fdmarc-charter-00a.txt Details below (including a question). Let me know if you've got any concerns. I think we can get this to the IESG for review before Toronto. Domain-based Message Authentication, Reporting Conformance (DMARC) extends stable, domain-level validation to the RFC5322.From field. DMARC builds upon existing mail authentication technologies (SPF and DKIM), using DNS records to add policy-related requests for receivers and defining a feedback mechanism from receivers back to domain owners. This can allow a domain owner to advertise that mail, which does not authenticate use of the domain name in the From field, can safely receive differential handling, such as rejection. Existing deployment of DMARC has demonstrated utility at internet scale, in dealing with significant email abuse, and has permitted simplifying some mail handling processes. Simplifying: Domain-based Message Authentication, Reporting Conformance (DMARC) uses existing mail authentication technologies (SPF and DKIM) to extend validation to the RFC5322.From field. DMARC uses DNS records to add policy-related requests for receivers and defines a feedback mechanism from receivers back to domain owners. This allows a domain owner to advertise that mail can safely receive differential handling, such as rejection, when the use of the domain name in the From field is not authenticated. Existing deployment of DMARC has demonstrated utility at internet scale, in dealing with significant email abuse, and has permitted simplifying some mail handling processes. Then move this bit up: The existing base specification is being submitted as an Independent Submission to become an Informational RFC. and put a paragraph break. The working group will seek to preserve interoperability with the installed base of DMARC systems, and will provide careful justification for any non-interoperability. I think we can strike the word careful. It doesn't add anything. The working group will seek to maintain the viability of stable domain-level identifiers in mail, and will document existing mail streams that do not conform to the DMARC model. I'm not sure what this means. Can someone explain? Working group activities will pursue three tracks: 1. Inter-Specification -- Organize and document DMARC interoperability issues, developing suggestions for improvements 1. Addressing the issues with indirect mail flows It wasn't clear precisely what was being talked about. The working group will document the effects of DMARC on indirect mail flows, including deployed behaviors of many different intermediaries, such as mailing list managers, automated mailbox forwarding services, and MTAs that perform enhanced message handling that results in message modification. The working group will consider mechanisms for reducing or eliminating the DMARC's effects on indirect mail flows. Among the choices are: We can make this smaller: The working group will specify mechanisms for reducing or eliminating the DMARC's effects on indirect mail flows, including deployed behaviors of many different intermediaries, such as mailing list managers, automated mailbox forwarding services, and MTAs that perform enhanced message handling that results in message modification. Among the choices for addressing these issues are: The specific work items appear below, so I think we can keep it simple here. 2. Intra-Specification -- Audit each part of the DMARC specification (reporting, policy, auth), making improvements as appropriate. 2. Reviewing and improving the base DMARC specification The base specification relies on the ability of an email receiver to determine the organizational domain responsible for sending mail. An organizational domain is the basic domain name obtained through a public registry, such as example.com or example.co.uk. While the common practice is to use a public suffix list to determine organizational domain, it is widely recognized that this solution will not scale, and that the current list often is inaccurate. The task of defining a standard mechanism for identifying organizational domain is out of scope for this working group. However the working group can consider extending the base DMARC specification to accommodate such a standard, should it be developed during the life of this working group. I think we can strike the second sentence. Other than reducing this being marked as spam ;-), I don't think it adds
[dmarc-ietf] Mailing lists - assumptions
[Bcc'ing dmarc, but directed to ietf-822, since that's where we appear to be having the discussion for the moment.] These ideas about mailing lists have been rattling around in my head these past couple of days, and they're based on a bunch of design assumptions. So I figured I'd post my list of assumptions and see if anybody thought any of them were off in space. 1. The mailing list itself is going to have to participate in this in some way. There's no point in trying to design something for mailing lists that simply will not make any modifications. 2. In the end, we want mailing lists to be able to send messages that say From: u...@originatingdomain.example.com and not have to say From: l...@listdomain.example.net. 3. If an originator sends mail to a mailing list, the originator is implicitly giving permission for the list to re-distribute the message From: the originator. 4. If an originating site allows its users sending mail to mailing lists at all, the site is OK with *any* mailing list re-distributing mail from its users. so long as the mailing list received the mail directly from the originating user through the originating site. That is, originating sites don't care about pre-vetting mailing lists; they just care that the mail sent by mailing lists came directly from their users. 5. For a recipient of mailing list mail, their site cares about whether the message they got came directly from the mailing list site, cares that the mailing list got the mail directly from the originating user's site, and cares that the mailing list got the mail relatively recently. For the most part, the recipient's site doesn't care how much has changed about the content of the message. The eventual recipient might care if the changes are in the extreme, but from a is this spoofed spam perspective, that really doesn't matter. 6. The mailing list cares about whether it got the message directly from the originating user's site. 7. An originating site would be willing to query (through a DNS lookup or otherwise) the first hop recipient for any message and stick something in the message that indicates, This message came from originating user's site and was sent to recipient at such-and-so time, in order to facilitate #4 and #5. 8. The mechanism we use might need to chain: If I send to a mailing list A, which itself sends to another mailing list B, the eventual recipient will be able to see that the message it got came directly from B, which it got from A, which it got from me. Anything I screwed up there? Any assumption I'm missing? pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
