Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support
On Wed, Apr 29, 2015 at 10:16 AM, Hector Santos hsan...@isdg.net wrote: I downloaded OpenDKIM source code to see whats it offers. I believe I saw: o ADSP was no longer supported, pulled. Grep showed one instance of an inline comment referring to ADSP. Correct. o ATPS was offered, but I failed to see how it was hooked into ADSP because it ADSP was pulled. It has nothing to do with ADSP. o DMARC was offered. OpenDKIM doesn't know anything about DMARC other than the fact that dmarc= is an Authentication-Results field is not a syntax error. OpenDKIM runs in the milter stream before OpenDMARC does, and OpenDMARC consumes the results OpenDKIM provides. ATPS was suppose to be based off the ADSP record with the optional tag atps=y I believe that is how it worked. If the atps=y was present in the ADSP record, then ATPS was supported and an ATPS_Hash(ADID, SDID) lookup was done. Nope. See RFC6541. If OpenDKIM is popular among many big systems, it would make sense to slightly update OpenDKIM so that the atps=y option is based off a DMARC lookup. The change is small. Sure, if that's consensus. That would also involve promoting ATPS to the Standards Track, but to do that we'd need to see some hope that widespread deployment is likely. But we still have that pesky registration problem to deal with. Maybe Murray can explain how its setup and triggered in OpenDKIM. If you enable it, you just have to name which domains you authorize to sign for you. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Mon, Apr 27, 2015 at 12:27 PM, J. Gomez jgo...@seryrich.com wrote: The question to me is whether the message that the MLM software emits is the same as the original message. If it is, then the Author ought to be preserved across the MLM. If it is not, then the MLM emits a new message, and it actually SHOULD NOT keep the Author the same, as described above. So we get to argue about same, and of course the specs aren't particularly rigorous about this. RFC5598's definitions, in Section 5.3 (and indirectly 5.2) say that it doesn't change From, from which I infer it doesn't change Author, although it does say it's a new message that's emitted. It seems RFC5598 says 3 things: 1. That the Author and only the Author goes in the Header-From. Period. 2. That mailing lists keep the original Author (sic) in the Header-From. 3. That mailing lists also become an Author when they retransmit a message (Section 5.3: Because a Mailing List can modify the content of a message in any way, it is responsible for that content; that is, it is an Author.). I see point 1 as normative, point 3 as an arrived conclusion (logical deduction) and therefore also normative as long as it is logically valid, and point 2 as documenting customary practice at the time that document was written. So it seems, as per RFC5598, that a message mediated by a mailing list which alters its content has, at least, to Authors: the original Author, and the mailing list itself. Keep in mind that RFC5598 is Informational. It doesn't prescribe or proscribe anything. It just describes the current (at the time) email architecture. RFC5322 and its ilk are Standards track, and thus normative. Even if we were all to concur that altering the From by adding the list is the right way forward here (an intriguing idea at the moment), the question of ordering would need to be addressed, and then how that applies to all the standards we're talking about, and how MUAs need to be nudged to make use of such things. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Mon, Apr 27, 2015 at 1:23 PM, J. Gomez jgo...@seryrich.com wrote: Couldn't the DMARC specification spell out that Receivers claiming to be DMARC-compliant, when choosing to *accept* incoming messages from Senders publishing p=reject (irrespective of whether such accepted messages passed or not the DMARC checks), CANNOT after-the-fact reinject such received messages into the public email infrastructure in any way that could render them (or reveal them to be) DMARC-rejectable? So that if any Receiver-turned-Originator (i.e., Mediator) does otherwise, they CANNOT claim to be DMARC-compliant? That would force DMARC-compliant Mediators to reject (or accept but not resend) incoming email from p=reject domains, irrespective of whether such mail passes or not the initial incoming DMARC checks. Then, if the market deems DMARC valuable by itself, pressure would be applied by the invisible hand there were it needs to be applied (so that reputable actors in the email ecosystem could claim to be DMARC-compatible). Apart from the CANNOT bit, is that different from where we are today? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Mon, Apr 27, 2015 at 4:17 AM, Michael Jack Assels mjass...@encs.concordia.ca wrote: On Sun, 26 Apr 2015 12:21:04 +0200, J. Gomez jgo...@seryrich.com wrote: On Sunday, April 26, 2015 2:25 AM [GMT+1=CET], Stephen J. Turnbull wrote: The From header field is not in the public domain, and not available for appropriation. Taking ownership of something that isn't yours is properly called theft Is the message Subject in the public domain? Is the message Body in the public domain? Why are many mailing lists taking liberties with them? Sorry, but I think your analogy of email vs property does not compute. Whether any header field is in the public domain is a legal question on which I won't venture an opinion, but the From header stands out as one that is treated specially by RFC5332, section 3.6.2: [...] The From: field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The Sender: field specifies the mailbox of the agent responsible for the actual transmission of the message. For example, if a secretary were to send a message for another person, the mailbox of the secretary would appear in the Sender: field and the mailbox of the actual author would appear in the From: field. If the originator of the message can be indicated by a single mailbox and the author and transmitter are identical, the Sender: field SHOULD NOT be used. Otherwise, both fields SHOULD appear. [...] In all cases, the From: field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message. [...] It seems clear to me that, at the very least, the mailbox of the message's author ought not to be and replaced by the mailbox of an automaton that added a subject tag and a list trailer. If the mailing list software has made DKIM-breaking changes, it may make sense for it to *add* its own mailbox to the From header (as a coauthor), and make itself the Sender. The question to me is whether the message that the MLM software emits is the same as the original message. If it is, then the Author ought to be preserved across the MLM. If it is not, then the MLM emits a new message, and it actually SHOULD NOT keep the Author the same, as described above. So we get to argue about same, and of course the specs aren't particularly rigorous about this. RFC5598's definitions, in Section 5.3 (and indirectly 5.2) say that it doesn't change From, from which I infer it doesn't change Author, although it does say it's a new message that's emitted. That document is not a proposed standard and merely documents current use (as I understand it), so it's merely recording the fact that MLMs technically violate the SHOULD NOT. So it seems to me the points of contention here are: 1) Is the MLM violation of the SHOULD NOT cited above the kind of violation that we accept based on how SHOULD NOT is defined in RFC2119? It seems to me that it is, especially given how long they've been doing it without objection (until now). One could argue they've been getting away with it for too long, but we can't change history. 2) Is the MLM emitting a new message? I would agree with Michael and contend that it is if there have been any content changes at all, in the same way that someone making a compilation of a series of independent works (a mix tape) owns the copyright on the mix, though not on the original material. Now, MLMs do that with digests already -- who else could one legitimately put in the From of a digest? -- but typically not for resent messages. To the point of Message-IDs, I would say that should follow the same rule as the From change: If the content changes, it's a new message, and it gets a new Message-ID. Might it be sufficient to declare an Original-Message-ID or Author-Message-ID or List-Original-Message-ID field that contains the author-generated Message-ID, allowing for the duplicate suppression that's done now? If MUAs do unpredictable things with multimailbox From headers, it may be because they don't see them often enough. I'm sure they'll fix their errors if list mail begins to arrive with heretofore unusual but RFC5322-compliant headers. I would far rather have MUA developers work with us directly, but the IETF has a persistent allergy to us tampering in user space. As I understand it, our desire in general tends to be to create well-defined interfaces (not APIs, mind you) at which MUAs can meet us on their own, and let them take it from there. Thus, the best we can do is be very clear about what information is presented by a multi-From message and perhaps why, and hope they'll adapt. The sad legacy is that different mail operators have historically done different things, which has led to MUAs doing different things, which has in turn led to a global system that interoperates enough to be useful but not enough to be able to lock
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Thu, Apr 16, 2015 at 9:31 AM, John Levine jo...@taugh.com wrote: The most tedious and unhelpful discussions here have implicitly (or perhaps explicitly) assumed that receiver nontechnical costs don't matter, then repeatedly pointed out the true but useless fact that there are single party mediator changes with trivial technical costs. Useless because it presumes the non-technical costs of those changes are high? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Thu, Apr 16, 2015 at 11:34 AM, John R Levine jo...@taugh.com wrote: At least, we need to look at what non-technical costs they push onto other parties. Some changes have insignificant non-techincal costs and are not controversial, e.g., adding a List-ID header for the benefit of recipients who know how to use it. Changes that seem similar may have quite different costs, e.g., adding a List-ID and removing subject tags, forcing recipients to change the way they sort and organize their incoming messages. Rolf kind of said what I'm thinking here: I agree that we need to look at the costs. But are we willing, or not willing, to accept costs that are not zero? For example, asserting that all parties should have to take on zero non-technical cost here seems like it might leave us dead in the water before we even start. I don't have a good non-zero suggestion though, because it's hard (or maybe even impossible) to be specific. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Publishing and Registration Concerns
On Tue, Apr 14, 2015 at 3:41 PM, Terry Zink tz...@exchange.microsoft.com wrote: 1. For Hotmail, every mailing list that our users are signed up for would result in a new DNS entry. How do we manage the lifecycle around that? Should we automate its addition? Should we automate its removal? Do we delay email before the DNS entries are published? Should we thereby bypass the change review process? If so, how do we audit what's going in and what's coming out of the Hotmail zone? 2. For Office 365, we can't publish DNS entries for most of our customers. We could tell them what to publish but I guarantee you almost none of them would for every single mail list their users signed up for, if they had to do it every day. Most of them probably wouldn't even do it once. That's the part that doesn't scale. +1. The mechanism of generating DNS records is not the issue; we even have an RFC that shows how that could be done in theory. It's the processes themselves that simply won't scale or would fail to thrive. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Publishing and Registration Concerns
On Wed, Apr 15, 2015 at 1:39 PM, Scott Kitterman skl...@kitterman.com wrote: For the umpteenth time, the issue isn't managing a DNS zone. That's the easy part. The hard part is knowing what to put in it. Many companies, not even the really big ones, have thousands of domains. Go publish SPF, DKIM key, and DMARC records for 4,000 domains and then tell me it's all easy to then figure out what the right list of authorized forwarders should be for each one. +1. Also, if one were to interpret the Pareto Principle correctly, it actually favors the idea that the only things we should consider are the ones the large operators are willing to adopt, which means it's abundantly clear that registration protocols -- all of them -- are non-starters at this point. P.S. I'm done on the topic of is keeping a list of forwarders a useful solution for the group to work on. No matter how you wrap it up, it's not. +1. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Fwd: WG Action: Formed Domain Boundaries (dbound)
Colleagues, The DBOUND working group has officially formed. We will be working on the question of what to do about our concerns with the Public Suffix List, which is an important component of DMARC, so it's relevant here. The chairs will be announcing to that list soon what our plan of attack is. Feel free to subscribe if interested. -MSK, one of the DBOUND chairs -- Forwarded message -- From: The IESG iesg-secret...@ietf.org Date: Fri, Apr 10, 2015 at 9:26 AM Subject: WG Action: Formed Domain Boundaries (dbound) To: IETF-Announce ietf-annou...@ietf.org Cc: dbound WG dbo...@ietf.org A new IETF working group has been formed in the Applications Area. For additional information please contact the Area Directors or the WG Chairs. Domain Boundaries (dbound) Current Status: Proposed WG Chairs: Pete Resnick presn...@qti.qualcomm.com Murray Kucherawy superu...@gmail.com Assigned Area Director: Barry Leiba barryle...@computer.org Mailing list Address: dbo...@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dbound Archive: http://www.ietf.org/mail-archive/web/dbound Charter: Various Internet protocols and applications require some mechanism for determining whether two domain names are related. The meaning of related in this context is not a unitary concept. The DBOUND working group will develop one or more solutions to this family of problems, and will clarify the types of relations relevant. For example, it is often necessary or useful to determine whether example.com and foo.example.com, or even example.net, are subject to the same administrative control. To humans, the answer to this may be obvious. However, the Domain Name System (DNS), which is the service that handles domain name queries, does not provide the ability to mark these sorts of relationships. This makes it impossible to discern relationships algorithmically. The right answer is not always compare the rightmost two labels. Applications and organizations impose policies and procedures that create additional structure in their use of domain names. This creates many possible relationships that are not evident in the names themselves or in the operational, public representation of the names. Prior solutions for identifying relationships between domain names have sought to use the DNS namespace and protocol to extract that information when it isn't actually there. See the Additional Background Information section of the working group wiki for more details: https://trac.tools.ietf.org/wg/dbound/trac/wiki/AdditionalBackgroundInformation For the purpose of this work, domain names are identifiers used by organizations and services, independent of underlying protocols or mechanisms, and an organizational domain is defined as a name that is at the top of an administrative hierarchy, defining transition from one outside administrative authority to another that is inside the organization. The current way most of this is handled is via a list published at publicsuffix.org (commonly known as the Public Suffix List or PSL), and the general goal is to accommodate anything people are using that for today. However, there are broadly speaking two use patterns. The first is a top ancestor organization case. In this case, the goal is to find a single superordinate name in the DNS tree that can properly make assertions about the policies and procedures of subordinate names. The second is to determine, given two different names, whether they are governed by the same administrative authority. The goal of the DBOUND working group is to develop a unified solution, if possible, for determining organizational domain boundaries. However, the working group may discover that the use cases require different solutions. Should that happen, the working group will develop those different solutions, using as many common pieces as it can. Solutions will not involve the proposal of any changes to the DNS protocol. They might involve the creation of new resource record types. This working group will not seek to amend the consuming protocols themselves (standards for any web, email, or other such protocols) under this charter. If such work is desirable, it will be assigned to another appropriate working group or defined as a work item in an updated charter. Rechartering will only be considered after completion of the base work. The working group has a pre-IETF draft to consider as a possible starting point: draft-sullivan-dbound-problem-statement Milestones: TBD ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
On Tue, Apr 14, 2015 at 1:24 PM, Rolf E. Sonneveld r.e.sonnev...@sonnection.nl wrote: Remembering to what great lengths the ietf-dkim group went to make sure that every bit of a message was covered by the signature (and with the l= discussions in mind) I would really be surprised if adding the @fs= for all outbound mail would be an acceptable solution for the problem. I agree in general, but I'm not sure that's a valid comparison. A bare l=0 is a lot less restricted than one that also includes @fs= and, perhaps, something like a short expiration. It could well be that's a tolerable risk when compared with the cost of doing nothing here. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Publishing and Registration Concerns
On Tue, Apr 14, 2015 at 12:03 PM, Terry Zink tz...@exchange.microsoft.com wrote: Getting someone to add anything to DNS doesn't work well [3] unless it is automated because the majority of people that I work with in the customer space don't feel comfortable managing DNS; it is rare that I encounter someone who does and these are people who are in charge of email infrastructure. This is the exact opposite of most people on this discussion list, many of which manage their own zones. For many large organizations, there is a slow change-review process. For medium and small businesses, they just want it to work and therefore don't change much in their DNS unless they are experts, of which there aren't that many in real life. Just to pile on: There are probably security people many large organizations who would be unthrilled with the notion of automating an authorization process, which is really what this is. It might feel to them a lot like an injection attack, and I would argue they're correct. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
On Tue, Apr 14, 2015 at 7:56 AM, Stephen J. Turnbull step...@xemacs.org wrote: If I misunderstood the proposal and it requires someone to be keeping a list of mailing lists used (either globally or by individual users), then I think this is not a good idea at all. I don't think any tracking/whitelisting design is going to succeed at scale. I can't speak for Murray, but I can't see that his proposal does. Sorry, I've lost context. I assume you're talking about dkim-list-canon. You could apply it only when you know the mail is going to a list, maybe if you're worried about overall header size or crypto cost, but it's designed to be used generally. Since it's a signature that covers the whole message, it's not replayable (any more than basic DKIM is). Really, isn't the question whether Yahoo! and AOL are willing to do *anything* to mitigate? We need some participation from them or it's useless, and if at least one does participate, it's a win. What are they willing to think about implementing? At least one of them is subscribed, but I've no idea if they're actively monitoring. At the same time, I think the feedback we're getting from MS and Google is equally valuable, and they're active. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
On Mon, Apr 13, 2015 at 12:58 AM, Stephen J. Turnbull
turnb...@sk.tsukuba.ac.jp wrote:
Douglas Otis writes:
If the DMARC domain fails to step up, then a reasonable fallback
could require the display of the Sender header offering the needed
alignment.
I don't understand this. We already see that most professional
spammers exhibit From alignment on much of their traffic. Sender
alignment is just as easy to implement, even if we could expect MUAs
to conform to the required display of Sender field. Users do not
understand the Sender field as far as I can tell.
To the extent comprehensible, TPA is meant to allow author A to tell
receiver B that mail that has C in (for example) the List-ID field should
be treated as though it came from A. However, I concur that it means an
impostor can simply do what the TPA record says and thereby succeed; few of
the properties TPA identifies are authenticated in any way. It might be
helpful to get alignment working through paths that invalidate SPF or DKIM,
but compared to the fact that it basically advertises how to get a pass
in an invisible way, it's more scary to me than not. Now, if that isn't
the case, then I suggest the document falls short of explaining how this is
not an attack vector.
Also, Doug insists that this is not registration, but I don't know how he
can claim this since it requires a DNS entry for every {A, C} pair that
exists which must then be queried by every B that might receive mail from
C. Unless I'm not understanding use of the term, that's exactly how I
believe we've been using registration lately, and the argument on the
table is that any registration scheme is basically a non-starter for
operators for which the cardinality of AxC is or could be large.
As I've pointed out before, ATPS, DSAP, and all other earlier proposals
that required a registration step have also been non-starters. I'm not
picking on TPA here; I'm saying this entire family of solutions is probably
not the best use of our time, and I suggest there's empirical evidence to
support that claim.
-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
On Apr 13, 2015 2:22 PM, Rolf E. Sonneveld But, if this 'registration' does not apply to the 'mandatory tag draft', that means that every sender will always add the weak signature + 'fs=initial domain' and a replay attack is reduced to breaking the weak signature? You can't reuse the weak signature without a proper signature from the fs domain on the same message. I imagine short expiration times mitigate that risk. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
On Thu, Apr 9, 2015 at 10:47 PM, Stephen J. Turnbull step...@xemacs.org wrote: TPA is still on the table for other 3rd party services (invoicing etc), because conditional signatures do nothing for them. I suggest that TPA or ATPS are way too complicated for third party services like invoicing, because in that case the relationship between the parties is solid enough that one could just give the other a signing key and be done with it. We can do that today. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
On Wed, Apr 8, 2015 at 7:06 PM, John Levine jo...@taugh.com wrote: It seems to me that this addresses the same issues that the list mutation stuff does with a lot less complication, and without having to enumerate all of the ways that a list might change the message. It only assumes that the list won't change To, From, Date, or Message-ID, which matches my list experience. The list can make arbitrary changes to the message body, but if it does, you know who to blame. That last sentence is basically what I said about both of my drafts, and that logic was shot down. Once you've decided you don't like the arbitrary changes, you know who to blame, but you still have to decide what you like and what you don't. As a lazy list operator, I also like the fact that it doesn't require lists to do anything different from what they should be doing now, sign their outgoing mail. Senders put additional weak signatures on mail sent to addresses that might be mailing lists, verifiers have to upgrade to understand new signatures. Note that smelling like a mailing list is not the same as whitelisting mailing lists. might be mailing lists sounds like a place for heuristics. How would you identify an address that might be a list, or content that's likely destined for a list? The -l suffix isn't that common these days. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
On Thu, Apr 9, 2015 at 11:25 AM, John Levine jo...@taugh.com wrote: Yeah, now that I look at your drafts again, I see that we are both making the same assertion that this message is a mutated version of one that someone else sent. I still like mine better because trying to enumerate all of the possible kinds of changes doesn't work very well, e.g., subject tags and per-recipient S/MIME encryption. (Sympa can do the latter.) What we're claiming is slightly different. Your approach is to trust that the fs domain isn't malicious; mine is to claim responsibility for only the original content and allow the second domain to claim its modifications. I guess it depends on which side we want to mess with more. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ideas for list handling
On Wed, Apr 8, 2015 at 9:19 AM, John Levine jo...@taugh.com wrote: Comments on either or both are welcome. They both have the same problem: the list says: Here's what I did. Whadda ya think? Every recipient system has to come up with its own heuristics to decide what combinations of changes are or are not acceptable, which means that the exact same message will be accepted by one 100% conformant implementation and rejected by another. This does not seem to me to be a major improvement over the current situation. But I think that's true of every protocol we have now. For example, independent of DMARC, a valid DKIM-signed message might be rejected by A and not by B because of its content based on local policy and filtering. Local heuristics about acceptable content will always be there regardless of what we do. The goal here is not acceptance, but deterministic results from the authentication layer. Or, more generally, we need to be able to recover a validated identifer that aligns in a way that doesn't degrade the integrity of that validation. Being able to have the author signature cover the original content and the list signature cover any changes seems like a win to me. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
On Wed, Apr 8, 2015 at 7:06 PM, John Levine jo...@taugh.com wrote: I updated my conditional signature draft, which is now (thanks to a suggestion from Ned Freed) the mandatory tag draft. https://tools.ietf.org/html/draft-levine-dkim-conditional-01 [...] Well, I'm game to try. Adjustments to the parsing engine should be fairly simple, and a couple of extra steps to notice and resolve the forward reference will be needed. And maybe some extra return codes. I'd use ! instead of @, I think, as an indication of their importance when observed visually, but that's rather a minor point. The first thing that hits me: Do we have to be specific about what's meant by weak? How does the verifier decide if it's weak enough or perhaps too weak? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Ideas for list handling
Colleagues, I've posted a new version of draft-kucherawy-dkim-list-canon, which had expired. It was one of several we were considering a while back as a way of dealing with some indirect mail flows. https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/ Also, I've posted a new one that proposes a way to include in the signature some information about message transformations that happened at a Mediator, allowing the Verifier to undo said changes and re-try the author signature. Something else to consider: https://datatracker.ietf.org/doc/draft-kucherawy-dkim-transform/ Comments on either or both are welcome. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Third Party Sender DMARC Adaptations
On Thu, Apr 2, 2015 at 12:42 PM, Rolf E. Sonneveld r.e.sonnev...@sonnection.nl wrote: if DMARC is really the succes that dmarc.org claims it is [1] and with so many of the big ESPs around here [2] I fail to see why it would be so difficult to involve the MUA developers of these same ESPs? Several of them are here. If they have better experience understanding what actually gets through to users in terms of message safety that doesn't reduce to, as John Levine put it, Where do I click to make this warning go away?, they have yet to say so. :-) -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Third Party Sender DMARC Adaptations
On Thu, Apr 2, 2015 at 11:42 AM, Murray S. Kucherawy superu...@gmail.com wrote: If the input is the message and the output is a set of zero or more SDIDs representing domains whose signatures validated, then I don't think it matters if we go the v=2 route or the new header field name route, because the multiplexing happens on the inside of the processing machine thus described. As I read RFC6376 sections 3.8 and 3.9, this is a valid perspective. (I may be biased.) -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Third Party Sender DMARC Adaptations
On Thu, Apr 2, 2015 at 6:25 PM, John R Levine jo...@taugh.com wrote: So receipt of a message signed in the new form will likely produce an incorrect signature validation, ... I wondered about that, too, so before I proposed a version bump, I took a look at the code that people use: * Murray's opendkim C library: checks that the version is 0.5 or 1, fails otherwise. That's the code in the milters that sendmail and postfix use, and I believe it's the library that everyone else with custom C code (including me) uses or adapts. It replaces the older libdkim. It won't accept 0.5 unless configured to do so, and that's off by default. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Third Party Sender DMARC Adaptations
On Thu, Apr 2, 2015 at 9:18 AM, Dave Crocker d...@dcrocker.net wrote: The main difference I see is that if we call v2 something else, we now have a tedious administrative exercise of finding every place something refers to DKIM and change it to DKIM or DKIM-plus. This does not strike me as a good use of anyone's time. That task you characterize as tedious is, in fact, the discipline of making sure the documentation is careful to distinguish between the two different (ie, non-interoperable) protocols. Efforts to do that with a single specification wind up confusing things and confusing readers and implementers. I'm using API terminology here but I think the comment generalizes to the protocol: If the input is the message and the output is a set of zero or more SDIDs representing domains whose signatures validated, then I don't think it matters if we go the v=2 route or the new header field name route, because the multiplexing happens on the inside of the processing machine thus described. However, and perhaps unfortunately, RFC5672 changed it so that the output of DKIM is a single SDID. That means either (a) RFC5672 got it wrong, because this doesn't allow for the whole message to be the input and multiple domain names (for passing signatures) to be the output, or (b) the above definition is wrong, because it means a single DKIM signature _plus_ the whole message is the input, and the algorithm picks apart the message as needed to complete the verification and thus produce the single SDID (or an error). OpenDKIM certainly implements the first definition I've used above at its API level, though I could argue that it satisfies either of the two definitions and just happens to do the latter one in a parallel way. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Third Party Sender DMARC Adaptations
On Wed, Apr 1, 2015 at 6:00 PM, Michael Jack Assels mjass...@encs.concordia.ca wrote: The case of a syntactically valid multi-valued RFC5322.From field presents a particular challenge. The process in this case is to apply the DMARC check using each of those domains found in the RFC5322.From field as the Author Domain and apply the most strict policy selected among the checks that fail. (The word fail leaves me confused. Shouldn't that be pass?) DMARC's p= describes the action to take when the evaluation mechanism fails. There is no policy to apply (other than, I suppose, an implicit accept action) when DMARC passes. At any rate, it seems to me that if DMARC would be satisfied by a Mediator making substantial modifications to my message, changing the RFC5322.From to From: Michael Jack Assels mjass...@porn-list.example.xxx and signing appropriately, it ought to be similarly happy with From: Michael Jack Assels mjass...@encs.concordia.ca, dmarc no-re...@ietf.org Sender: dmarc dmarc-boun...@ietf.org signed by IETF's sending MTA. Assuming that the usual change is made to the Subject line and the usual trailer is appended to the message body, only the ietf.org identity ought to align with the RFC5322.From domain, and I can't see a reason why DMARC wouldn't be happy. Yes, someone could have spoofed my address, but IETF's receiver will have had an opportunity to check that, so it's either IETF's fault for accepting the original message or my MTA's fault for not being DMARC compliant. In this case, the mailing list would be doing what's asked of it by DMARC, but keeping (most of) it's time honoured values intact. This could work, except that if this yields favorable treatment by the receiver, then that's all an attacker needs to do to get to your inbox (i.e., double up the From: using an arbitrary domain name, and make sure the message satisfies the DMARC test for the latter). The exception to that is some expression, which the receiver can confirm, that domain2 and domain1 have some kind of relationship that's interesting to this process. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Third Party Sender DMARC Adaptations
On Wed, Apr 1, 2015 at 11:11 AM, John Levine jo...@taugh.com wrote: Has anyone looked at my double signing draft? The idea is the the original sender (which we'll call, oh, Yahoo) puts on a very weak signature probably only on From, Date, and Message-ID, with l=0 and a new tag that says the signature is only valid if the message is also signed by a specific other domain, call it ietf.org. It probably also puts on an ordinary strong signature, too, and sends the message to a list forwarder such as dmarc@ietf.org. The list does what it does, and signs the message normally with d=ietf.org. That breaks the strong yahoo signature, but the weak one is now valid in combination with the normal ietf.org signature, so there's a valid d=yahoo signature and DMARC is happy. The forwarder could of course do naughty things, but only the specific forwarder to whom the message was sent, which greatly limits the scope of damage. It's even more limited in the common case that the original sender has a reasonably good idea who are likely to be the well behaved forwarders and only puts the weak signatures on mail sent to them. Didn't we stalemate on the question of whether this has to be a whole new header field, or a v= increase? I seem to recall someone (Dave?) thinking both were horrible. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-01.txt
On Mon, Mar 23, 2015 at 7:27 AM, Franck Martin fra...@peachymango.org wrote: Looking better... Special thanks to Elizabeth for improving the document after I integrated (all?) previous comments. Please see this revision and post comments/reviews against it. It sure seems better. :-) A few comments on this version: Section 1 and the Abstract use an impersonal writing style (this document does this, this section does that) while in Section 2 it changes to using we. I suggest sticking with the former style. OLD: What do we mean by interoperability issues? We say that DMARC introduces interoperability issues or problems, when conformance to the DMARC specification leads an implementation to reject a message that is both compliant with the architecture as specified in [RFC5598 http://tools.ietf.org/html/rfc5598] and would have been viewed as legitimate in the eyes of the intended recipient. Therefore, we can already conclude that DMARC poses no interoperability problems when legitimate messages properly validate through its specified processes. The rest of this section delves into how legitimate messages may get rejected. NEW: Interoperability issues are introduced when conformance to the DMARC specification leads an implementation to reject a message that is both compliant with the architecture as specified in [RFC5598] and would have been viewed as legitimate in the eyes of the intended recipient. Therefore, it can already be concluded that DMARC poses no interoperability problems when legitimate messages properly validate through its specified processes. The rest of this section delves into how legitimate messages can be rejected. ...etc. The last paragraph of Section 2.1 opens with a run-on sentence. Also, since that chapter is entirely about SPF, all of the [RFC7208] references can be omitted; they make an already-long sentence rather cluttered. Also, this paragraph (and I think the one before it as well) talk about alignment being defined as the two identifiers sharing the same Organizational Domain, but in fact that depends on whether relaxed or strict mode is active, right? It also has this: Even when an SPF record exists for the domain in RFC5322 http://tools.ietf.org/html/rfc5322.From, SPF will not authenticate it unless it is also the domain SPF checks. I'm confused. When is the SPF record for the RFC5322.From domain ever checked? Shouldn't that be the DMARC policy, not the SPF policy? In Section 2.3, the RFC6376 [RFC6376] is redundant and can be cleaned up. What does Furthermore, the use of the length flag is by no means universal. mean? Does that mean not everyone uses it, or not all software implements it? DKIM has two canonicalizations: simple and relaxed. ...is true for both the header and the body. The relaxed canonicalization used to be computing intensive and may not have been preferred in the early deployment of DKIM. It's still true that relaxed requires more processing than strict, but I've never heard that used as a basis for not using it. It's not a heavyweight process. Section 3.1.1: marked by an inherent difficulty in modifying -- It's not modifying that's hard, it's establishing alignment that's hard. A pure syntax point: All the entries in that bullet list end in periods, but are not capitalized; either make them phrases (drop the period) or make them sentences (capitalize) Section 3.1.2.1: Should 8-bit mail be 8-bit MIME? I don't know what a mail section is. Also, I think RFC6376 has some discussion about this. Might be useful to refer to it. Section 3.1.2.2: In addition, group syntax will remove the ability for the DMARC mechanism to find an Organizational Domain that aligns with any authenticated domain identifier from SPF or DKIM. Is that strictly true? Didn't we say in DMARC (I forget now) that a receiver could evaluate all such domains? Or am I thinking of the wrong problem? Section 3.1.3 talks about application of SIEVE, but wouldn't that sort of thing happen after SPF and DKIM have already been evaluated? Section 3.2.3, same earlier syntax point about the bullet list. Also, RFC6377 contains a more detailed description of the third-party bounce problem and how it can be destructive. Would it be worth pointing out that the typical MLM changes are not only common, but perfectly valid within the context of email? Or that declaring those things as no-longer-permitted is not likely to succeed? Section 3.2.4: acquired companies domains should be acquired company's domains. Also To: header should be RFC5322.To header field. Section 3.2.5 should mention that whether a boundary filter introduces an interop problem depends on where the DKIM and SPF evaluations are done. If they're inside a modifying filter, there's a problem, but not otherwise. Section 4: proper handling multiple DKIM signatures should be proper handling of multiple DKIM signatures Also Section 4: What are the DMARC headers?
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Thu, Mar 26, 2015 at 11:59 PM, Murray S. Kucherawy superu...@gmail.com wrote: There are those among you that disagree, I know. Does anyone have actual data (not theory, not passion, but data) that any of the policy or third-party solutions we've discussed before can work, work just about everywhere, and work at scale? If the answer to that is no (or, as usual, silence), then I suggest this (still!) isn't a productive use of our precious time or energy. ...by which I mean we should really not spend any more time re-hashing the past, and instead focus on figuring out the future. I'm all for learning from our past mistakes, but I think we've gotten all the blood we're going to get out of that particular stone. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Wed, Mar 25, 2015 at 12:58 PM, J. Gomez jgo...@seryrich.com wrote: No. It is unreliable for Receivers to apply it. Sure, for the Sender p=reject is perfectly reliable, if he happens to have all his ducks neatly in a row. But the Receiver cannot know if the Sender has all his ducks neatly in a row when said Sender publishes p=reject. Question that the Receiver asks to himself: Is the Sender aware of p=reject drawbacks and can therefore the Receiver rely on the Sender's declared p=reject? Answer to that question: The Receiver has no way to know, therefore p=reject is unreliable from the point of view of the Receiver, irrespective of what the Receiver ultimately decides to do with the Sender's declared p=reject. I think you're actually saying exactly what I thought you meant. Thanks for confirming. I just wanted to be clear for context. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Tue, Mar 24, 2015 at 2:19 PM, Anne Bennett a...@encs.concordia.ca wrote: But yes, the ideal situation is where we sort every message correctly and unambiguously. Meanwhile... Even if we grant that p=quarantine is a problem WE cause, the fact is that until we have a *good* solution for mailing lists, most of us don't dare publish p=reject, which leaves us with p=none, or no DMARC records at all. Which means that (a) many of us cannot benefit from using DMARC under the current circumstances, and (b) many sites don't have the resources to implement it yet, but we still have to deal with their mail. I'm not willing to throw the baby out with the bathwater. +1. To be a bit flippant about it: Now that we have everyone's attention, possibly moreso than ever before, maybe it's possible to come up with a compromise that all corners of the email ecosystem can accept. But that doesn't mean we need to settle for creating schisms in that ecosystem. Entrenching is not the answer. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] interoperability issues around gateway-transformation
On Tue, Mar 24, 2015 at 6:46 PM, Stephen J. Turnbull step...@xemacs.org wrote: OK, but is it folly to consider a header canonicalization that can handle this? DKIM is designed to accommodate incremental improvements, after all. Sec. 5.3 isn't, though. :-( As I read 5.3, it says you need to make sure what you sign is what the verifier will receive. It seems to me a signer that gets 8-bit header fields can RFC2047-ize them before signing, presuming the MTA will make the same conversion before putting the signed message out on the wire. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] interoperability issues around gateway-transformation
On Tue, Mar 24, 2015 at 8:17 AM, Stephen J. Turnbull step...@xemacs.org wrote: An mta could opt to send a message with unencoded utf8 headers (display name, subject, etc) to another peer advertising SMTPUTF8 even if none of the envelope were internationalized addresses. If the recipient then needed to relay the message on to a site that didn't support SMTPUTF8, it would have to encode the headers. You're right, it doesn't. AFAICS use of the SMTPUTF8 extension is incompatible with DKIM signatures. See sec. 5.3 of RFC 6376. Do you have a suggestion in mind? Conform to RFC 6376.wink / OK, but is it folly to consider a header canonicalization that can handle this? DKIM is designed to accommodate incremental improvements, after all. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] interoperability issues around gateway-transformation
So, maybe a header canonicalization that has as one of its steps conversion of all Subject fields to something RFC2047-compatible? On Tue, Mar 24, 2015 at 1:39 PM, John Bucy jb...@google.com wrote: The scenario I had in mind was: - B advertises SMTPUTF8 but relays to C which does not - A sends a message to B with an unencoded utf8 Subject: invoking the SMTPUTF8 extension - B could opt to encode the Subject: header using rfc2047 to produce a message acceptable to C On Tue, Mar 24, 2015 at 12:22 PM, Murray S. Kucherawy superu...@gmail.com wrote: On Tue, Mar 24, 2015 at 8:17 AM, Stephen J. Turnbull step...@xemacs.org wrote: An mta could opt to send a message with unencoded utf8 headers (display name, subject, etc) to another peer advertising SMTPUTF8 even if none of the envelope were internationalized addresses. If the recipient then needed to relay the message on to a site that didn't support SMTPUTF8, it would have to encode the headers. You're right, it doesn't. AFAICS use of the SMTPUTF8 extension is incompatible with DKIM signatures. See sec. 5.3 of RFC 6376. Do you have a suggestion in mind? Conform to RFC 6376.wink / OK, but is it folly to consider a header canonicalization that can handle this? DKIM is designed to accommodate incremental improvements, after all. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Tue, Mar 24, 2015 at 1:38 PM, J. Gomez jgo...@seryrich.com wrote: I know for sure I will publish only p=none for my client's domains, and use DMARC only as a reporting tool, as long as DMARC's p=reject cannot be reliably relied on. But I would love to be able to reliably rely on DMARC's p=reject. I'm not sure I agree with the claim that p=reject is unreliable. It seems to me that it's working as designed, and the results are deterministic. It's not flaky. How receivers use it is the mushy part, but that's really outside of the protocol. Even if DMARC didn't have these mediator problems, there still would be no ultimate compulsion for receivers to do what domain owners ask. It might be a lot more likely that they would comply without reservations, but there would still be some operators that don't. So just to be clear, are you using reliable here to talk about how receivers apply it? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] interoperability issues around gateway-transformation
On Mon, Mar 23, 2015 at 5:25 PM, John Bucy jb...@google.com wrote: Based on a quick glance, it doesn't look like draft-kucherawy-dkim-list-canon-00 addresses encoded headers like rfc2047. An mta could opt to send a message with unencoded utf8 headers (display name, subject, etc) to another peer advertising SMTPUTF8 even if none of the envelope were internationalized addresses. If the recipient then needed to relay the message on to a site that didn't support SMTPUTF8, it would have to encode the headers. You're right, it doesn't. It's only meant to address body modifications that lists might do. In fact it is specifically a body canonicalization. I hadn't done any work on list-sensitive header canonicalization yet. Do you have a suggestion in mind? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Fri, Mar 20, 2015 at 4:40 PM, Dave Crocker d...@dcrocker.net wrote: On 3/19/2015 12:52 PM, Murray S. Kucherawy wrote: And since the From field is the only one users really see every time, I'm not sure that declaring and supporting yet another no-seriously-this-is-the-author field would be of benefit. I'd like to try to get us to phrase this differently. In particular, it does not matter what user's 'see'. The information is processed by a filtering agent, independent of the user. So what matters is that the From: field domain is the only field certain to be provided by the author. Isn't it important that this information is also the most likely to be presented to the end user as the author of the content that's also shown to the user? Why do you claim it doesn't matter? There would be a lot less incentive to be concerned about From: alignment if that were not the case. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] interoperability issues around gateway-transformation
Not yet. I don't think there are any implementations. We were just banging the idea around. I'm looking at doing one soon for OpenDKIM as an experimental add-on. On Fri, Mar 20, 2015 at 10:25 AM, John Bucy jb...@google.com wrote: Hadn't seen that ID, cool! Is there any test data available? cheers john On Thu, Mar 19, 2015 at 6:28 PM, Murray S. Kucherawy superu...@gmail.com wrote: There was one proposed: https://tools.ietf.org/html/draft-kucherawy-dkim-list-canon-00 This working group will be discussing this and other options before long. -MSK On Thu, Mar 19, 2015 at 1:45 PM, John Bucy jb...@google.com wrote: I was glad to see mention of content-transfer-encoding issues in draft-ietf-dmarc-interoperability since gateway-transformation breaks dkim signatures. Is there any interest in trying to develop a mime-aware canonicalization for dkim? cheers john ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Fri, Mar 20, 2015 at 1:56 PM, J. Gomez jgo...@seryrich.com wrote: Why is it better for DMARC to be adapted to indirect email flows, instead of indirect email flows to be adapted to DMARC? What does provide more value to end users at large: indirect email flows to be kept old-style, or the extra notch of trustworthiness that DMARC alignment provides? How big is the volume of DMARC-problematic indirect email flows, compared to the general volume of email which can readily benefit from DMARC? I'm pretty sure volumes are not the problem as much as the painful side effects, most notably unsubscription of uninvolved users from mailing lists when someone protected by DMARC posts to the list. (See Section 5.2 of RFC6377, which describes the same problem in the context of ADSP. RFC7372 might help with this, if and when it ever gets widely implemented.) My own view is that we should pursue whichever of the two avenues is the lower-hanging fruit. The problem at the moment is that it's not at all clear to me which of the two that is. We have among us implementers of both MLM packages and DKIM/SPF packages and standards, so at least the right people are in the room. There are, however, substantial barriers in both directions. We definitely have our work cut out for us. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] interoperability issues around gateway-transformation
There was one proposed: https://tools.ietf.org/html/draft-kucherawy-dkim-list-canon-00 This working group will be discussing this and other options before long. -MSK On Thu, Mar 19, 2015 at 1:45 PM, John Bucy jb...@google.com wrote: I was glad to see mention of content-transfer-encoding issues in draft-ietf-dmarc-interoperability since gateway-transformation breaks dkim signatures. Is there any interest in trying to develop a mime-aware canonicalization for dkim? cheers john ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Wed, Mar 18, 2015 at 4:38 PM, Terry Zink tz...@exchange.microsoft.com wrote: If bulk email providers have shown no interest in promoting a solution, why do we think they'd latch onto this new non-aligned header field as a solution? +1. And since the From field is the only one users really see every time, I'm not sure that declaring and supporting yet another no-seriously-this-is-the-author field would be of benefit. Rather, I think it would just confuse things further. The closest thing I can see is considering use of Sender somehow, since there are even a few MUAs that do pay vague attention to it. But that's extremely hand-wavy to start with. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] RFC 7489 on Domain-based Message Authentication, Reporting, and Conformance (DMARC)
On Wed, Mar 18, 2015 at 1:19 PM, Tim Draegen t...@eudaemon.net wrote: Hi Murray Elizabeth, thanks for wrestling this through the process. The Working Group can now adopt this as input. /goes off to figure out which buttons need to be pushed =- Tim I have to resubmit it as draft-ietf-dmarc-base and then you guys have to approve it in, assuming you still want me to act as editor. Did you want to do that right away or wait until the earlier milestones have been met? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Fwd: RFC 7489 on Domain-based Message Authentication, Reporting, and Conformance (DMARC)
FYI: -- Forwarded message -- From: rfc-edi...@rfc-editor.org Date: Wed, Mar 18, 2015 at 1:04 PM Subject: RFC 7489 on Domain-based Message Authentication, Reporting, and Conformance (DMARC) To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org Cc: drafts-update-...@iana.org, rfc-edi...@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7489 Title: Domain-based Message Authentication, Reporting, and Conformance (DMARC) Author: M. Kucherawy, Ed., E. Zwicky, Ed. Status: Informational Stream: Independent Date: March 2015 Mailbox:superu...@gmail.com, zwi...@yahoo-inc.com Pages: 73 Characters: 162707 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-kucherawy-dmarc-base-12.txt URL:https://www.rfc-editor.org/info/rfc7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse. DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Formal specification, URI
On Tue, Mar 17, 2015 at 8:23 AM, Alessandro Vesely ves...@tana.it wrote: Right, which is why things like semi-colon don't need to be percent-encoded; they're already special characters in the context of a URL. So are comma and exclamation. What puzzles me is that DMARC spec treats them differently while RFC3896 does not. Comma and semicolon seem to behave the same; e.g.: Ah, that's true. I was looking specifically at one and not all three. At this point, since RFC7489 has just been published, I suggest you choose (perhaps with direction from the co-chairs) how to record this discrepancy for handling when the base draft gets updated. You could open an erratum report, or you could add it to the WG's tracker, or maybe they have another suggestion. They aren't formally imported, and I'm not sure that's necessary here. The ABNF we have should be comprehensive over DMARC tag-value sets. The prose you cited is merely meant to convey that they follow the same style. Right. The question is if implementations can reuse DKIM parsers. Without studying the ABNF again, I believe so. DKIM parsers separate tag-value entities at unencoded semicolons, after which the tag name and tag value are separated at unencoded equal signs. DMARC records are the same up to that point, and it's below there for ruf and rua in the DMARC case that things get interesting. Just like in the case of b= for DKIM, those two have special rules for value interpretation: make up a list of URIs using an unencoded comma as the separator. Your question is Are they equivalent? I believe they are. Although it might be ideal to have a specification so tight that there's exactly one way to do something, in the end I don't think it's harmful to have two ways to say the same thing. It's more of a concern if there's to ways to interpret a single thing; that's when we arguably have something to fix. I tried the NOT RECOMMENDED syntax quoted above. Dmarcian[1] doesn't raise a brow, and RFC3896-compliant uriparser[2] ingests it smoothly. However, although I sent a test message to a gmail account, I received no report. I guess Google's implementation doesn't deploy a proper URI parser, but just looks for mailto:; followed by a plain path consisting of a single[3] addr-spec (as defined in RFC6068, i.e. w/o comments) with no query nor fragment --that's what I'd do myself, but I find no arguments in the spec that help proving that that record is bad. I think we've wandered into implementation comparisons rather than getting the ABNF right in the specification. Or maybe a better way to say that is: I don't think fixing the discrepancy you've raised would resolve the disparity you're observing. The spec says a report is normally sent to each. How can a publisher express that two URIs are meant to be either-or alternatives to each other? Is that a capability you require? I don't think that's a use case I've ever encountered. It may also be worth to require domain in addr-spec to be A-label, as that simplifies verification and improves dn_ compression. Such idea apparently conflicts with the example at the end of Section 6.3 of RFC6068, where the IDN is percent-encoded instead. That is a completely different topic, something that should be taken up when we do a standards track version. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Formal specification, URI
On Mon, Mar 16, 2015 at 3:51 AM, Alessandro Vesely ves...@tana.it wrote: Section 2.2 of RFC3986 lists semi-colon as a reserved character that has to be percent-encoded in these URLs. We don't need to repeat it here, I think. If the spec is going to be read by ignorants like me, it's better to repeat than to omit. RFC3986 has a very wide scope, and uses phrases like may (or may not) be defined as delimiters. It says: If data for a URI component would conflict with a reserved character's purpose as a delimiter, then the conflicting data must be percent-encoded before the URI is formed. Right, which is why things like semi-colon don't need to be percent-encoded; they're already special characters in the context of a URL. Commma and exclamation (which are sub-delims like semicolon) are apparently used in dmarc-uri's rule. The preceding DMARC section says: DMARC records follow the extensible tag-value syntax for DNS-based key records defined in DKIM [DKIM]. However, DKIM production rules don't seem to be formally imported. If they are imported, semicolon exclusion is implied by the definition: VALCHAR = %x21-3A / %x3C-7E ; EXCLAMATION to TILDE except SEMICOLON They aren't formally imported, and I'm not sure that's necessary here. The ABNF we have should be comprehensive over DMARC tag-value sets. The prose you cited is merely meant to convey that they follow the same style. How about the other two questions? I didn't survey but a few DMARC records, but RFC6068 exemplifies the following: Also note that it is syntactically valid to specify both to and an hfname whose value is to. That is, mailto:addr1@an.example,addr2@an.example is equivalent to mailto:?to=addr1@an.example,addr2@an.example is equivalent to mailto:addr1@an.example?to=addr2@an.example However, the latter form is NOT RECOMMENDED because different user agents handle this case differently. In particular, some existing clients ignore to hfvalues. Yahoo instead uses 1st level syntax: rua=mailto:dmarc-yahoo-...@yahoo-inc.com, mailto:dmarc_y_...@yahoo.com; Your question is Are they equivalent? I believe they are. Although it might be ideal to have a specification so tight that there's exactly one way to do something, in the end I don't think it's harmful to have two ways to say the same thing. It's more of a concern if there's to ways to interpret a single thing; that's when we arguably have something to fix. The goal in allowing a comma-separated list of URLs is that you might conceivably want to put an http and a mailto URL in there, in the try A first, then try B sense. We need to allow for that possibility. We also need to account for the possibility of a comma that is inside of a URL; those are the ones that need to be encoded. Outside of a URL, they're delimiters. Unless I'm missing something, the ABNF for DMARC allows all three of the cited examples, as well as Yahoo's use, and all four of them mean the same thing. That doesn't strike me as a bug. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Formal specification, URI
On Mon, Mar 16, 2015 at 12:57 PM, Steven M Jones s...@crash.com wrote: Just to be explicit, it also allows for multiple mailto: URIs - something that is seen in the wild, though perhaps not if one looks up a half dozen DMARC records at random. But at the end of January multiple mailto: URIs could be seen in ten of the Alexa Top 100 domains, in both rua and ruf tags. Right, and there might be some operational reason why you want to send one message to A and B, versus a message to A and then a message to B. (Fewer calls to fork()/exec(), perhaps.) -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Formal specification, URI
On Mon, Mar 16, 2015 at 12:22 PM, Murray S. Kucherawy superu...@gmail.com wrote: Your question is Are they equivalent? I believe they are. Although it might be ideal to have a specification so tight that there's exactly one way to do something, in the end I don't think it's harmful to have two ways to say the same thing. It's more of a concern if there's to ways to interpret a single thing; that's when we arguably have something to fix. Sigh. s/to ways/two ways/ -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Formal specification, URI
On Sun, Mar 15, 2015 at 11:53 AM, Alessandro Vesely ves...@tana.it wrote: This seems to be a bug: OLD: dmarc-uri = URI [ ! 1*DIGIT [ k / m / g / t ] ] ; URI is imported from [URI]; commas (ASCII ; 0x2c) and exclamation points (ASCII 0x21) ; MUST be encoded; the numeric portion MUST fit ; within an unsigned 64-bit integer NEW: dmarc-uri = URI [ ! 1*DIGIT [ k / m / g / t ] ] ; URI is imported from [URI]; commas (ASCII ; 0x2c), exclamation points (ASCII 0x21), and ; semicolons (ASCII 0x3b) MUST be percent-encoded; ; the numeric portion MUST fit within an unsigned ; 64-bit integer Is it equivalent to have, say, rua=mailto:a...@example.com%...@example.com and rua=mail...@example.com, mailto:b...@example.com? Is the following meant to to be allowed? mailto:dmarc@ietf.org?subject=Formal%20specification%2c%20URI Section 2.2 of RFC3986 lists semi-colon as a reserved character that has to be percent-encoded in these URLs. We don't need to repeat it here, I think. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Comments on draft-ietf-dmarc-interoperability
That diff format is a little challenging. You might try using rfcdiff, which eliminates a lot of the reporting of changes that amount to just moving across page breaks and the like. Anyway, I'll give it a thorough review this evening. Thanks for the quick turnaround! -MSK On Fri, Jan 30, 2015 at 4:05 PM, Franck Martin fra...@peachymango.org wrote: -- *From: *Murray S. Kucherawy superu...@gmail.com *To: *dmarc@ietf.org *Sent: *Friday, January 30, 2015 1:23:48 AM *Subject: *[dmarc-ietf] Comments on draft-ietf-dmarc-interoperability Thanks for putting this together. Here are the results of a late-night first-time reading: Thanks for suggestions after late-night reading Section 2: The sentence starting This the secondary appears to be mangled. I can't parse it. Me neither yet, it is Friday, asking co-authors for suggested text, will fix later... :P Section 2.1, paragraph 1: Fixed all the rest, you can see a diff at https://github.com/dmarc-ietf/id/commit/24ccb9507086e05732ff477ec7330a481bebcee9#diff-8b30e28a625f335e70d97d9b89dcd243 if you are ok, and when I have section 2, I'll push as -01. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Comments on draft-ietf-dmarc-interoperability
Thanks for putting this together. Here are the results of a late-night first-time reading: Section 2: The sentence starting This the secondary appears to be mangled. I can't parse it. Section 2.1, paragraph 1: The first sentence reads like a basic tautology: A fundamental aspect of X is the method of X. I think you could strike that sentence, and add to message source validation to the next one, and it's more readable while saying the same thing. Also, I believe it should be DKIM and SPF, not DKIM or SPF. organizational domain should be defined before first use here. I suggest capitalizing it (Organizational Domain) and indicating, perhaps in Section 1, that the definition of it is in dmarc-base. Section 2.3: MIME should be at least an informative reference given the discussion here. Section 3.1.1: 5322.From header should be 5322.From header field. Also, I suggest calling it the RFC5322.From header field (including RFC) to align with what's in dmarc-base, though that's not strictly necessary. (This appears throughout the document, not just this section.) There's a reference to authenticated domain identifiers, but also a reference earlier to Authenticated Identifiers. Should we just pick one and stick to it? The latter seems better since we have an existing definition in dmarc-base to reference. Suggest aligned with instead of related to, to use consistent terminology. Section 3.1.2.1: s/8bits/8-bit/ s/7bits/7-bit/ Section 3.1.2.2: s/transfers message,/transfers a message/ Section 3.2.1: s/alternate/alternative/ The list of ways aliasing can happen isn't complete; for example, an MTA's alias table isn't covered. The way one sets up forwarding in Outlook/Exchange is probably something else again. I suggest including such as. The local-part of the addr-spec -- Which addr-spec are you referring to? Section 3.2.3: Might want to mention that RFC7372 was produced to help this, but it's too early to tell if it's going to be successful. The unsubscribe problem is described in RFC6377, and I think also in dmarc-base. A reference from here might be helpful. Section 3.3: Change to etc. Section 4: I think we need to say something here about the uphill battle of getting any or all of these suggestions into widespread adoption. Section 4.1: I wouldn't call dkim-list-canon light transformations, but rather something like constrained transformations. You could add a gigantic MIME part under that proposal and still be able to recover some valid content. Section 4.3: RFC6648 discourages the use of X- header field names, and I don't think X-Original-From was ever registered or otherwise permanently described, so is it a good idea to include it here? In the next paragraph you refer to Original-From. Is that one registered? Section 4.3.1: This isn't a complete sentence. Section 4.4.1.3: There's too much comma splicing going on here. Suggest a rewrite. Also, I don't understand the point about considering that syntax suspicious. Section 4.5.1: Some mitigations are described in RFC6377, if that might be helpful to reference here. Also, it looks like another place where RFC7372 might be useful. Section 4.6: s/alignement/alignment/ Section 5: More traditionally: This document contains no actions for IANA. [RFC Editor: Please delete this section prior to publication.] Section 6: More traditionally: This document is an analysis of DMARC's impact on indirect email flows. It describes the possibility of accidental denial-of-service that can be created by false rejections of messages by DMARC-aware Mail Receivers. However, it introduces no new security issues to Internet messaging. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
On Tue, Jan 20, 2015 at 6:14 PM, John Levine jo...@taugh.com wrote: Do people concur with this change, or something close to it? I'm OK with it, but to the meta-question, I realize the practical issues involved with yanking something out of the production queue, but in this case I wonder if that's not the right thing to do. There's no great hurry in getting the DMARC document published, since nothing currently depends on it, and if reasonable people are finding holes in it that make it hard to write interoperable code, I'd rather fix the holes than add lengthy errata or recycle later. I am asking the IESG and the ISE what the process is for making such adjustments now. Mainly my resistance to further change comes from the fact that we've done last calls of varying kinds on this document more times than I can count. It really is time to put the non-IETF version to bed and hand it off, even with its weaknesses, and let the standards process take it from there. There's a working group already chartered to do exactly that; in fact, that was one of the premises of creating that working group. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it
On Tue, Jan 20, 2015 at 1:44 PM, Anne Bennett a...@encs.concordia.ca wrote: I apologize for my inadvertently poor timing; I was catapulted into all this last week when my parent domain (also my Organizational Domain) published an SPF record and a DKIM record, and we became concerned that they might implement DMARC, which could have a very negative impact on our mail services unless we take action quickly and become prepared to publish our own DMARC record. Thus, my sudden plunge into all these RFCs and this draft. :-/ Well, shoot. Timing notwithstanding, I also apologize if I came across as dismissing your use case as unimportant. I thought you were merely providing reviews as an interested party, not actually addressing a production problem. Since, as pointed out by Tim Draegen, DMARC implementations are already in the wild and deployed, one would expect to be able to determine what those implementations do, based on this spec. Sadly this hasn't been possible (so far) for me and my colleague Michael Jack Assels, despite our being two fairly smart cookies, with nearly a half-century of e-mail experience between us. I can't speak for most of the operators you're probably dealing with, many of whom have their own implementations. I can say that OpenDMARC consumes the Authentication-Results field, or the Received-SPF field if the former isn't there, but it prefers a result based on MAIL FROM over one based on HELO if both are present. But it will use both. I'm pretty sure Gmail people are on, or at least following, this list; hopefully someone there will comment. I want to emphasize that I think that the documents in question (at least this draft and RFC7208 - I've barely skimmed RFC6376 on DKIM yet) individually are well written, but trying to understand them in context together is proving to be quite a challenge, and the lack of clarity on the HELO issue is the biggest part of the problem. This is certainly useful feedback to the WG. In addition to considering it as a topic for a Proposed Standard version of the DMARC specification, there might be a need to explore some kind of interim statement about what's supposed to happen here (if necessary). But on the off-chance that it's not impossible to clarify this now, and assuming that my growing suspicion that HELO is ignored is correct, then I would propose: [...] Do people concur with this change, or something close to it? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it
On Mon, Jan 19, 2015 at 6:30 AM, Tim Draegen t...@eudaemon.net wrote: No objection — please do use the WG’s tracker for these items. Anne’s thorough review will be picked up (and not rediscovered!) if we’ve got an obvious place to start from. Done for Anne's points, and I'll do so for Jim Fenton's remaining ones as well. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it
On Mon, Jan 19, 2015 at 6:43 AM, Tim Draegen t...@eudaemon.net wrote: DMARC implementations are already in the wild and deployed. Input to the existing specification will be largely based on working implementations. You might have your own reasons for waiting for this WG to review the DMARC base draft, but if you want to provide input based on operational implementation experience, it's probably best to not wait. Indeed, -12 represents what's been deployed, and that was always the intent of this ISE submission. One could thus conclude that it is solid enough for everyone that has already deployed it, and that's not exactly a small or obscure list. Still, as has been said before: If there's more work to be done on this document, the working group is chartered to generate a Standards Track version using this document as a starting point once its other deliverables have been completed. We can record issues we'd like to see addressed in the tracker if there are some, and, if and when the WG gets there, we'll be off to the races. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it
Hello Anne, On Fri, Jan 16, 2015 at 4:41 PM, Anne Bennett a...@encs.concordia.ca wrote: Having just spent several hours poring over this document (-12), I might as well send my additional minor observations. I suspect that some of you will consider these items trivial, but they gave me pause as I went back and forth through several sections of the text to make sure I understood correctly. So... [...] I think all of the points in your three messages are good input for a more solid specification, but the timing is unfortunate as we just got publication approval for -12 a week ago. Making more changes post-approval would probably not be a good idea, and by my reading none of them rise to the level of being urgent to correct. The plan for the DMARC working group is to consider, among other things, whether it wants to produce a new version of the base document on the Standards Track (because of its path to publication, -12 will be Informational). Your points here are ideal for consideration when the working group reaches that juncture. Would the co-chairs object to beginning to track these items using the WG's tracker? If and when we do decide to crack open the base document for a Proposed Standard revision, we'd already have an inventory of topics to consider. It would also help to keep the discussion on this list focused on active topics now that the base draft is done. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] -10 (was: Jim Fenton's review of -04)
On Thu, Jan 1, 2015 at 1:02 PM, Kurt Andersen kander...@linkedin.com wrote: I'm OK with the new wording, but would have liked to see the -09 statement about reporting temp errors carried over: When otherwise appropriate due to DMARC policy, receivers MAY send feedback reports regarding temporary errors. Restored. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base updated (-06)
On Mon, Dec 29, 2014 at 2:29 PM, Rolf E. Sonneveld r.e.sonnev...@sonnection.nl wrote: 3.1.3 Flow diagram The box titled 'User Mailbox' could give the impression that there's only one choice for delivery. However, quarantining can be done without delivery to a mailbox. I'd suggest to label this box 'rMDA'. That's already done in -08. OK. Well, it's MDA, but that's OK. One typo in the diagram. When: sMTA is the sending MTA, and rMTA is the receiving MTA. is correct, the box in the diagram should be labelled 'sMTA', not 'oMTA'. Fixed. The part within parentheses of step 6: 6. Recipient transport service conducts SPF and DKIM authentication checks by passing the necessary data to their respective modules, each of which require queries to the Author Domain’s DNS data (when identifiers are aligned; see below). might indicate that SPF and DKIM authentication checks need not be performed when identifiers are not aligned. However, for sake of reporting, SPF and DKIM authentication checks will in general always be done, or am I missing something? I can envision a DMARC implementation that skips SPF or DKIM checks if the corresponding identifiers are not aligned, because they won't be interesting to DMARC in that case. Whether or not to generate reports in the case of non-alignment is not clear from the text, or am I missing something? Par. 3.1.3: 8. If a policy is found, it is combined with the Author's domain and the SPF and DKIM results to produce a DMARC policy result (a pass or fail), and can optionally cause one of two kinds of reports to be generated (not shown). and par. 6.2 goes right into the format of reports, not the conditions under which a report is to be sent. Added an item at the end of the bullet list in 3.1.3. 5.7 Last sentence: Mail Receivers SHOULD also implement reporting instructions of DMARC in place of any extensions to SPF or DKIM that might enable such reporting. Not sure what this means. But it seems to me DMARC cannot claim priority over other options/extensions in other IETF protocols. This is another spot where the SHOULD gives the operator the choice to do both if it wishes. I can't remember off the top of my head what the use case is here, but essentially the absence of a request for DKIM or SPF reporting (as developed by the MARF working group some time ago) should not preclude DMARC reporting, nor should their presence interfere with DMARC reporting. Then, borrowing from your text, may I suggest the following text: Mail Receivers SHOULD implement reporting instructions of DMARC, even in the absence of a request for DKIM or SPF reporting [MARF]. Furthermore, the presence of such requests SHOULD NOT interfere with DMARC reporting. Done, with slight changes. And as a general statement: thanks for all the work, Murray! Anything to get this thing put to bed! -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
OK, seriously, I hope I don't have to crack this open again. Conflict review is slated for the 1/8 telechat, and a flurry of last minute edits might not sit well with the IESG. We need to leave actual work, as much as at all possible, to the WG, and not to hacking on the ISE version. Diffs to -09 which will be in -10 within the next few days: http://blackops.org/~msk/dmarc/diff.html -MSK On Mon, Dec 29, 2014 at 11:38 AM, Scott Kitterman skl...@kitterman.com wrote: On December 29, 2014 2:32:27 PM EST, Dave Crocker d...@dcrocker.net wrote: On 12/29/2014 10:40 AM, Scott Kitterman wrote: TO: DMARC evaluation can only complete and yield a pass result when one of the underlying authentication mechanisms passes for an aligned identifier. If neither passes and one or both of them failed due to a temporary error, the Receiver evaluating the message is also unable to conclude that the DMARC mechanism had a permanent failure and thereby can apply the advertised DMARC policy. This looks good to me. Shouldn't it be cannot apply the advertised DMARC policy? Actually, no, but I also was confused. It took me some serious effort to decide that the current wording was correct. And a spec should not require that sort of linguistic diligence, IMO. Looks like a small change can make your form correct... So I suggest: DMARC evaluation can only yield a pass result after one of the underlying authentication mechanisms passes for an aligned identifier. If neither passes and one or both of them fails due to a temporary error, the Receiver evaluating the message is unable to conclude that the DMARC mechanism had a permanent failure; they therefore cannot (yet) apply the advertised DMARC policy. d/ I think that's better. I'd prefer to leave out the parenthetical yet as I think it raises ambiguity rather than reduces it. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On Thu, Dec 25, 2014 at 1:08 AM, Scott Kitterman skl...@kitterman.com wrote: I don't think it does. What I was trying to say is that if you already got an aligned pass from one method, you're done. It doesn't matter if they other one gets a DNS error, you already have a definitive result. I don't think your text says that, but I may be wrong. I think it's close. I see the distinction you're making, and I've adjusted. Have a look at the diff now: http://www.blackops.org/~msk/dmarc/diff.html Also, I don't like the change from MUST NOT to cannot. Receivers can do whatever they want, so cannot isn't correct. This bit is meant to say that receivers aren't free to use DMARC as an excuse to throw away messages every time there's a DNS hiccup. Applying policy in an inappropriate way does have an interoperability impact (messages quarantined/rejected that should not be), so I think the MUST NOT is appropriate. I think cannot does do that, actually. We're saying here that DMARC can't complete for the case you describe, namely where both SPF and DKIM suffered some kind of transient error. In that case, if you're rejecting, you aren't legitimately doing it in the name of DMARC. I'm deliberately avoiding using new RFC2119 language here because it's way too late to be adding major normative goo. These are supposed to be corrections to existing text, not addressing oversights in the protocol itself. If we got this wrong in the base spec, then it's potential material for a standards track revision. Otherwise, if we start down the path of fixing things, we're never going to be done with this version. (Pete and Barry would also point out here that it's possible for normative language to exist without using RFC2119's key words...) -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On Thu, Dec 25, 2014 at 10:15 PM, Dave Crocker dcroc...@gmail.com wrote: One could argue either way about the multi-valued From:, but at least it has an essential relationship to DMARC, since DMARC evaluates From:. If DMARC were required to handle multi-valued From:, it would alter DMARC noticeable, as was evident in the debate about this issue. The MX requirement has no such linkage. I'm afraid the glue is still too thick. Fortunately at this point, this is all academic. I'm staring at this and not understanding how the two are all that different. They both seek to ensure that a DMARC evaluation can be done on the From: domain, and thus both seek to ensure that the From: that lands in the inbox can be trusted by end users to be valid. In both cases, as you put it, DMARC evaluates From:. The only difference I can see is that one is a self-contained syntactical check while the other requires consulting another data source (the DNS, in this case) for a simple validity test. If the MX/A/ test fails, then there's no policy to apply. We [used to] reject on the basis that it's impossible for that message to legitimately exist. If the single-value From: test fails, then which domain's policy is to be applied is potentially indeterminate. We [still, typically] reject on the basis that it's impossible to be sure which domain the end user will see, and thus decide which policy should apply. DMARC participants don't like that case and (we claim) protected mail streams never use that syntax anyway, so we disallow its use for those cases. To me they have approximately identical goals. If the MX test can legitimately be dismissed because it aspires to world peace, why shouldn't the other? Anyway, I'm content at this point to leave this for the standards track discussion when the WG gets around to it. I'll remain quietly confused until then. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On Wed, Dec 24, 2014 at 4:09 AM, Scott Kitterman skl...@kitterman.com wrote: 5.6.2 promises 5.6.3 addresses the question and it doesn't. At the very least, 5.6.2 should be fixed not to over promise what 5.6.3 will provide. I'm not clear why you say it doesn't. 5.6.3 describes two options for handling a message when the query for the DMARC policy fails due to transient DNS errors. Is your issue that it doesn't prescribe one specific action? I also don't understand why you say the reference is dangling. 5.6.2 says that transient DNS errors for SPF and DKIM can occur and says the handling for that case is left to receiver discretion, but also points out that what 5.6.3 says can also be applied when that happens. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On Wed, Dec 24, 2014 at 4:04 AM, Scott Kitterman skl...@kitterman.com wrote: The draft strongly encourages DMARC implementers to ignore SPF policy, so I don't think assuming messages will be deferred due only due to SPF or DKIM results indicating a temporary DNS error is appropriate. If there's a transient DNS error getting the SPF policy, then there's no SPF policy to be ignored. That's quite a different situation. I think that in the case of a temporary DNS error in one of the lower level protocols, insufficient inputs are available to conclude a message has failed DMARC tests. I agree. Receivers can either ignore DMARC for this message due to incomplete evaluation or they can defer the message in the hope that the temporary error will be resolved when the message is retried. Receivers MUST NOT apply DMARC policy and reject or quarantine because the DMARC evaluation is incomplete. Can you provide specific changes, with section numbers, that you'd like to see applied to resolve this? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On Wed, Dec 24, 2014 at 10:22 AM, Dave Crocker d...@dcrocker.net wrote: I disagree. DMARC operators all seem to apply this practice, so it's correct to say that if you play this game, you reject mail from non-existent domains. Essentially in this way DMARC is a profile of RFC5321/RFC5322, which is perfectly acceptable. We are not updating those standards here, merely profiling them. The fact that its use happens to correlate with DMARC use is a distraction. For example, there are plenty of operators who use apply this check but do not use DMARC. If the test is documented in a specification, it should be in /one/ specification. Putting it into the DMARC spec means it has to be documented somewhere else, for the folk who don't use DMARC. This paragraph appears in the DMARC spec because the operators participating all agreed that it should be part-and-parcel of this operating profile of email. It's not as happenstance as this sounds so far; the very thrust of DMARC is to make the From: content believable, and permitting a nonexistent domain name to make it to the inbox contradicts that goal. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On Wed, Dec 24, 2014 at 5:48 PM, Scott Kitterman skl...@kitterman.com wrote: Messages for which SPF and/or DKIM evaluation encounters a temporary DNS error have not received a definitive result for steps 3 and/or 4 above. If the message has not passed the the DMARC mechanism check due to an SPF or DKIM check that did not have a DNS error, receivers can either ignore DMARC for this message due to incomplete evaluation or they can defer the message in the hope that the temporary error will be resolved when the message is retried. Receivers MUST NOT apply DMARC policy and reject or quarantine the message because the DMARC evaluation is incomplete. When otherwise appropriate due to DMARC policy, receivers MAY send feedback reports regarding temporary errors. Handling of messages for which SPF and/or DKIM evaluation encounters a permanent DNS error is left to the discretion of the Mail Receiver. How's that? I think it pretty much says what's there, but is a lot more clear about it. I also think the second sentence is a bit convoluted, so I reworked it into this. Does it match what you're trying to say? t Messages for which SPF and/or DKIM evaluation encounters a temporary DNS error have not received a definitive result for steps 3 and/or 4 above. When such an evaluation is done in conjunction with an aligned identifier, completion of the DMARC algorithm is not possible. In this case, receivers can either skip DMARC for this message due to incomplete evaluation, or they can arrange to defer handling of the message in the hope that the temporary error will be resolved when the message is retried. In any case, Receivers cannot apply DMARC policy and reject or quarantine the message because the DMARC evaluation is incomplete. When otherwise appropriate due to DMARC policy, receivers MAY send feedback reports regarding temporary errors. /t -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On Wed, Dec 24, 2014 at 11:23 AM, Dave Crocker d...@dcrocker.net wrote: The goal, as you state it, is at the level of seeking world peace. It is very laudable and and very, very broad. It covers vastly more than the scope of DMARC. DMARC is a specific bit of technology working towards that broader goal. That something happens to fall within this very broad scope does not automatically justify documenting it within the much narrower scope of a detailed specification, unless it is part of that specification's technology. The MX record check has no /technical/ relationship to the /technical/ details of DMARC. Please note that I'm not commenting on the efficacy of the record check, but on the need to document it in a place that makes sense for the full range of its implementers. There are, and will continue to be, plenty of operators using that check but not DMARC. That simple fact provides a very pragmatic reason for moving its specification into some document outside of DMARC. I'm surprised we're not hearing more passionate voices in favor of keeping it given the genesis of the paragraph we're discussing. At any rate, I'm going to take it out in -09, because I just discovered that it's actually directly contradicting what Appendix A.4 says. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base updated (-06)
Hi Rolf, getting back to your review (thanks for the nudge): On Wed, Nov 12, 2014 at 6:26 PM, Rolf E. Sonneveld r.e.sonnev...@sonnection.nl wrote: Abstract: This lack of cohesion has several effects: receivers have difficulty providing feedback to senders about authentication, senders therefore have difficulty evaluating their authentication deployments, and as a result neither is able to make effective use of existing authentication technology. This focuses on the reporting function of DMARC, leaving out the policy part of it. Suggested text: This lack of cohesion has several effects: senders have difficulty providing information about their use of an authentication policy and receivers have difficulty determining a disposition preferred by senders. Vice versa, mail receivers have difficulty providing feedback to senders about authentication, senders therefore have difficulty evaluating their authentication deployments, and as a result neither is able to make effective use of existing authentication technology. The Abstract appears to have been rewritten since you reviewed it, so a straight text swap won't work anymore. The new text focuses on what's being provided, not what was missing. Do you want to take another run at it? Introduction: [...] mail receivers have tried to protect senders [...] Suggested: [...] mail receivers have tried to protect senders and their own users/customers [...] This text no longer appears in the draft. Starting with DMARC allows domain owners and receivers to collaborate by, the terms 'domain owners', 'receivers', 'senders' and 'SMTP receivers', 'Mail Receivers', 'mail receivers' are used throughout the document. I'd suggest to add a definition of the term ' Mail Senders' to the introduction part of chapter 3 and then use only the terms as defined in 3., throughout the document. Suggested text for the term Mail Sender: - Mail Sender: the sender of mail with a domain for which the Domain Owner may have published a DKIM public key and/or an SPF authentication record and/or a DMARC policy; (although we may want to not mention DKIM or SPF here). It looks like that got cleared up; -08 has no reference to Mail Sender. 2.2 Out of Scope Add: ocousin domain attacks Covered in Section 2.4 of -08. 3.1.2 Key Concepts Last sentence: add a reference to this 'other referenced material'. Good idea; added. 3.1.3 Flow diagram The box titled 'User Mailbox' could give the impression that there's only one choice for delivery. However, quarantining can be done without delivery to a mailbox. I'd suggest to label this box 'rMDA'. That's already done in -08. The part within parentheses of step 6: 6. Recipient transport service conducts SPF and DKIM authentication checks by passing the necessary data to their respective modules, each of which require queries to the Author Domain’s DNS data (when identifiers are aligned; see below). might indicate that SPF and DKIM authentication checks need not be performed when identifiers are not aligned. However, for sake of reporting, SPF and DKIM authentication checks will in general always be done, or am I missing something? I can envision a DMARC implementation that skips SPF or DKIM checks if the corresponding identifiers are not aligned, because they won't be interesting to DMARC in that case. 3.1.4.1 DKIM-authenticated Identifiers remove (or change) the 'Cousin Domain' example: it doesn't hold when a bad actor is signing the mail with d=cousindomain and RFC5322.From=localpart@cousindomain It's not there in -08. 4 Use of RFC5322.From Last bullet (The DMARC mechanism ...). It seems the other bullets provide reasons why RFC5322.From is chosen while the last one does not. It looks to me as a circular reasoning. It's not there in -08. 5.2 DMARC URIs It is not clear from the text what the report originator must do when the report payload exceeds the maximum size as indicated by the record. Should it not send anything, should it split up reports, should it notify the requester that there was a report exceeding the maximum size? Section 6.2.2 in both versions explains what to do here. 5.3 General Record Format adkim and aspf do not provide a list of all possible options (like is done for fo and p). Of course it is pretty obvious that for 'strict' the 's' must be used, but it's not clear from the text. They're there in -08. Next, the P: and pct: tags: they show that (in hindsight) the policy part and the reporting part of DMARC might have been better off, when they were defined in different specs. Now we need to complicate the text to say that the policy tag p: is required, but not for third-party reporting records. And for pct, that it MUST NOT be applied to the DMARC-generated reports. Well, I believe this has been discussed before, no need to redo this discussion. I'd suggest to synchronize the short
Re: [dmarc-ietf] DMARC and TEMP errors was: Re: Jim Fenton's review of -04
On Mon, Dec 22, 2014 at 3:18 PM, Scott Kitterman skl...@kitterman.com wrote: As I read -08 what to do in that case is undefined. There's a dangling pointer to 5.6.3. It's dangling because nothing in that section addresses the question of how to handle DKIM/SPF temporary errors. 5.6.3's final paragraph makes it clear that the action taken is at the discretion of the mail receiver, and gives two examples of non-destructive ways to handle that case. Do we need to say more than that? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On Mon, Dec 22, 2014 at 10:44 AM, Scott Kitterman skl...@kitterman.com wrote: There was a recent thread on postfix-users about DMARC rejections when there are DNS errors that caused me to review -08 to see what it says on the matter. At the end of section 5.6.2, it says: Handling of messages for which SPF and/or DKIM evaluation encounters a DNS error is left to the discretion of the Mail Receiver. Further discussion is available in Section 5.6.3. My reading of 5.6.3 though is that it only discusses DNS errors in the context of failing to retrieve the DMARC record. Any discussion about handling DNS errors for SPF/DKIM seems to be missing. Yes, DMARC punts on what to do when SPF or DKIM encounter transient failures. I imagine that's because those modules would arrange to temp-fail a message that has that problem. I suppose my experience is that messages don't even get to the point of DMARC evaluation when that happens, because the message has already been temp-failed. If you think about DKIM and SPF as being part of a layer below DMARC, then I'm not sure it's wise of us to be making any kind of normative statement about what to do when the lower layers fail. What do you suggest? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-04
Covering the stuff Dave didn't cover: On Wed, Apr 16, 2014 at 3:11 PM, Jim Fenton fen...@bluepopcorn.net wrote: Top of page 6: The receiver reports to the domain owner... The receiver actually sends reports to a report receiver designated by the domain owner. Fixed. 2.4 Out of Scope I still find the double negatives to be confusing, e.g., DMARC will not make a distinction It's the making of a distinction that's out of scope, not the not making a distinction (forgive my own double negative, please!). That text is apparently gone. Bullet 10: Again, DMARC doesn't do authentication, even for domains; it relies on other authentication mechanisms. 3. Terminology and Definitions Domain Owner: This definition refers to the domain owner as being the registrant of a DNS domain. But as used elsewhere in the spec, it can also be a delegate of that registrant that is given control over a subdomain. The document frequently refers to a domain owner publishing a DMARC record, so it's worth clarifying who has that capability. Report Receiver: reports about the messages claiming to be from a third party We're talking about the reports here, not the messages themselves, so I would suggest reports from a third party about their messages. Fixed and fixed. 3.1.2 General Concepts Paragraph 2: provide feedback to the Domain Owner. Should this say a Report Receiver designated by the Domain Owner, or is that too much information at this point? Fixed. Paragraph 3 doesn't quite capture the sense of alignment properly, especially for SPF. A message that is authorized by SPF might have an unaligned envelope-from address, so the validity of SPF for such messages is moot. This appears to have been rewritten already. 3.1.3 Flow Diagram Item 1: Author constructs and Author also configures - Domain Owner constructs and Domain Owner also configures (I missed this last time) Item 7: 'e.g., a pass or fail' Are there other results? If not, remove the e.g. Fixed and fixed. 3.1.4 Identifier Alignment Paragraph 5: Although this document makes it clear that strict and relaxed are different from their usage in DKIM, I'm still having trouble with those words. strict means that only this specific domain is affected; relaxed means that this domain and its subdomains are affected. So relaxed is really more strict in that it enforces more. I find the terms to be confusing, and would recommend something that more directly describes whether the policy applies to subdomains. Since we're documenting deployed infrastructure here, it's way too late to be renaming these. 3.1.4.1 DKIM-authenticated identifiers Paragraph 4: Include section reference (3.2) to public suffix lists since the section describing it has moved after this text. Added. 5.2 General Record Format fo: A colon-separated list of options is supported, but 0 and 1 conflict with each other so that either needs to be prohibited or it needs to define which wins. Previously addressed (Scott Kitterman brought it up). fo:d: a signature: In the case of a message with multiple DKIM signatures, does that mean if any signature failed evaluation, a message is sent? Is a separate message sent for each failed signature? Clarified. p:quarantine: What does suspicious mean? It sounds like it means something other than place into spam folder and scrutinize with additional intensity Clarified. pct: DMARC-generated reports...must be sent and received unhindered. How does one identity a DMARC-generated report to make sure it's unhindered, especially if a bad actor tries to make their messages look like reports? The syntax of a DMARC report is defined elsewhere in the document. Shouldn't it be easy to identify one? 5.3 Formal Definition dmarc-rfmt: Should allow a colon-separated list as described in 5.2. Fixed. 7.2 Aggregate Reports The list of what SHOULD be in the reports seems like it belongs in the definitions of the report formats themselves. The report formats, defined in MARF RFCs, present the syntax you would use to report those values if you have them. For DMARC, we're saying that all of those are a SHOULD. 7.3 Failure reports Paragraphs 1 and 2 conflict -- it looks like a change to include [IODEF] in the text was incompletely applied. Cleaned up. 7.3.1 Reporting Format Update Operators implementing this specification also implement: Is that a SHOULD or MUST before also implement? It's an implied MUST. We're being trained lately that use of RFC2119 words is not always mandatory. In essence, this is saying If you're a DMARC site, this is what you do. 7.4 Utility of Failure Reports Paragraph 1: detects an authentication failure - detects a DMARC failure (since authentication can succeed but DMARC fail because of alignment) Fixed (new location). Paragraph 2 is not relevant to utility of failure reports and probably belongs in 7.3.1. It's
Re: [dmarc-ietf] Jim Fenton's review of -04
On Wed, Dec 24, 2014 at 2:13 AM, Franck Martin fra...@peachymango.org wrote: I think we should recommend something here, not sure if it needs to be normative. We do say to ignore the SPF policy when p!=none, though I think we can be normative on the lower layers. I see 2 options here: 1)tempfail the message is either SPF and DKIM have a tempfail status 2)tempfail the message if both SPF and DKIM have a tempfail status 1) is my preferred and is aggressive, therefore not sure people will like it. I'll settle for 2) As explained in another post, I'm worried I can run a DNS attack (or just a self inflicted DNS bad config) and get DMARC to reject emails it should have accepted (has the DMARC policy in cache, but cannot assert SPF and DKIM). I think it's reasonably clear from 5.6.3 that the fail open choice is possibly dangerous, as is anything that fails open. But more importantly, I'm also worried about making a normative decision now about something we deliberately haven't specified up to this point for whatever reason. We are supposed to be documenting current practice with this effort, not establishing something new. Might this something best left for the standards track WG effort? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On Wed, Dec 24, 2014 at 2:40 AM, Franck Martin fra...@peachymango.org wrote: -- *From: *Murray S. Kucherawy superu...@gmail.com *To: *Franck Martin fra...@peachymango.org *Cc: *dmarc@ietf.org, Scott Kitterman skl...@kitterman.com *Sent: *Tuesday, December 23, 2014 11:20:30 PM *Subject: *Re: [dmarc-ietf] Jim Fenton's review of -04 On Wed, Dec 24, 2014 at 2:13 AM, Franck Martin fra...@peachymango.org wrote: I think we should recommend something here, not sure if it needs to be normative. We do say to ignore the SPF policy when p!=none, though I think we can be normative on the lower layers. I see 2 options here: 1)tempfail the message is either SPF and DKIM have a tempfail status 2)tempfail the message if both SPF and DKIM have a tempfail status 1) is my preferred and is aggressive, therefore not sure people will like it. I'll settle for 2) As explained in another post, I'm worried I can run a DNS attack (or just a self inflicted DNS bad config) and get DMARC to reject emails it should have accepted (has the DMARC policy in cache, but cannot assert SPF and DKIM). I think it's reasonably clear from 5.6.3 that the fail open choice is possibly dangerous, as is anything that fails open. But more importantly, I'm also worried about making a normative decision now about something we deliberately haven't specified up to this point for whatever reason. We are supposed to be documenting current practice with this effort, not establishing something new. Might this something best left for the standards track WG effort? Fair enough, but curious about standard practice. For instance what openDMARC do? and others? I think DMARC got us to be stricter and less lenient with email. OpenDMARC gets the message only after OpenDKIM is done with it, so if OpenDKIM temp-fails, OpenDMARC never even sees it. Thus, the case we're concerned about here can't ever happen. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Jim Fenton's review of -04
Colleagues, draft-kucherawy-dmarc-base is nearing IESG conflict review, and it's been pointed out that a review from back in April has not been properly attended to. Could I get the WG (forgive me, co-chairs!) to comment on this so that I can see what changes might be appropriate here? Having this resolved before the telechat in the first week of January would be truly delightful. Note that some amount of this may have already been addressed (it was about -04; -08 is current, and at least the ABNF issue Jim raises will be handled in -09), so please at least check -08 when considering your responses. The posting: http://www.ietf.org/mail-archive/web/dmarc/current/msg00764.html Thank you! -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect email flows
On Wed, Nov 12, 2014 at 2:22 PM, Franck Martin fra...@peachymango.org wrote: I'm just asking for this list to be set up exactly like the i...@ietf.org list. If Elizabeth ensures she emails in txt only, everything will be fine. i...@ietf.org is the outlier, actually. Every other IETF list that I'm on appears to do subject tagging. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] draft-kucherawy-dmarc-base updated (-06)
I've posted an update to the base draft, based on recent feedback from Ned and others. Hopefully I've resolved all of the concerns (especially the major ones), as the ISE would like to send the draft to the IESG for conflict review in the next day or two. It also has to begin formal review of its IANA Considerations section as soon as possible. Thanks to all who provided recent comments to lead us to this version. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
On Fri, Nov 7, 2014 at 10:06 AM, John Levine jo...@taugh.com wrote: 1) Evaluate all the domains you find, and if any of them have published DMARC policies, apply the strictest one ... Given the anti-phishing goals of DMARC, I don't see how anything else makes any sense. Or you could skip a step, say that DMARC doesn't permit multi-address From headers, assume that validation failed on all of the domains and proceed directly to the punishment phase. Right, that's also an option, and it at least accommodates the no-address From field that RFC6854 permits. Another option I can think of is one where we just admit the conflict with RFC6854 and observe that streams likely to be DMARC-protected don't use this format, so if you see a multi-valued From where any domain has a DMARC policy, it's invalid and the receiver should act accordingly. For From: headers with address-free groups, recall that the motivation for this was EAI downgrades at delivery time. The un-downgraded message had a normal From: header, so normal DMARC applies. If the address is smashed in the downgrade I don't see any reason that the DMARC result needs to change. I don't know much at all about EAI, but if the address is smashed, which DMARC result could you possibly use? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
On Fri, Nov 7, 2014 at 8:57 PM, turnb...@sk.tsukuba.ac.jp wrote: Trent Adams writes: - It is important to note that identifier alignment cannot occur, and DMARC determination applied, with a message that is not valid per RFC 5322 [MAIL]. This is particularly true when a message has a malformed or absent RFC5322.From field. - I occasionally see non-ASCII octets introduced by spam/virus checkers in X-Spam-* fields in the header or in the (non-8-bit) message body, due to copying message content into those contexts. The From field is perfectly valid, however. Does that really mean that identifier alignment cannot occur? (I think that is a plausible policy choice, since in an invalid message anything can happen. But I don't see that it's a no-brainer.) Do you have another suggestion? Note that there's nothing normative in Trent's suggestion. If a receiver thinks it can continue with the X-Spam-* fields malformed as described, then it can continue on that basis. Starting off, we can ignore a null address in the RFC5322.From field as DMARC will have no bearing in that case. Similarly, when there is exactly one address in the RFC5322.From field, application of DMARC is reasonably straight forward. By DMARC, you really mean DMARC policy, right? DMARC the protocol does need to say something about what happens if alignment fails or no policy can be discovered. That's how I understood what he said. That leaves taking some action based on the DMARC policies associated with the set of domains represented in the RFC5322.From field. It seems that the most reasonable approach is to gather the DMARC policies for all addresses, and then apply the most strict. I wouldn't call that reasonable. It's the only plausible option, but here's the problematic use case: Co-Chairs Trent and Stephen decide to hold a meeting of The Committee. For organizational political reasons it is necessary that (a) both names appear on the memo and (b) Stephen has to do the dirty work. Stephen sends the mail From: tr...@example.com, step...@example.org, with proper SPF and DKIM setups. Unfortunately, example.com publishes p=reject, example.com alignment fails because Stephen sent the message, the MTAs reject the message, and nobody except Trent and Stephen shows up to the meeting. I see two ways this message could pass DMARC: Stephen has the keys for example.com, or the Japanese ringi system, where I write and sign the message, send it to Trent, who then signs the message but otherwise forwards it verbatim. Both seem fragile to me. OTOH, only checking policies of aligned SPF source domains and DKIM signers means that Stephen (or any scammer) can add po...@whitehouse.gov to the From field and pass DMARC. It's obvious what the Felons of April would do with that. I guess the most plausible approach to this issue is to say that if you want to use DMARC and have multiple authors, you must contrive to give all the authors mailboxes in the same domain. In the example, I could create the-committee.example.org for committee members, or give trent a forwarding mailbox at example.org itself. Ned, do you concur with this analysis? Is Trent's proposal coupled with this caveat a valid remedy for your point? Given all that, here's my suggested revision to Section 5.6.1.: - 5.6.1. Extract Author Domain In order to be processed by DMARC, the domain(s) must be extracted from the domain of the email address(es) within the addr-spec portion of the RFC5322.From field. If the domain is encoded with UTF-8, the domain name must be converted to an A-label for further processing. If no domain is found, the message SHOULD be rejected (as it is forbidden under RFC 5322 I still don't think a null From filed is any business of DMARC the protocol. That's really an issue for (a) the security considerations section or (b) the planned BCP. I think we're all in agreement on that point so far. [MAIL]). If more than one domain identifier is found, the full set of domains MAY be collected as a set of identifiers for DMARC processing. But this seems to be the insecure approach I describe above: 5. Conduct identifier alignment checks. With authentication checks and policy discovery performed, the Mail Receiver checks if Authenticated Identifiers fall into alignment as described in Section 3. If one or more of the Authenticated Identifiers align with an identifier extracted from the addr-spec of the RFC5322.From domain, the message is considered to pass the DMARC mechanism check. AFAICS this allows me (using a throwaway mailbox at a throwaway domain) to send spam that passes DMARC on your behalf, as long as my mailbox appears in From, too. Am I misunderstanding your proposed algorithm? No, because in (6) the strictest rule applies. Your throwaway domain might pass, but the
Re: [dmarc-ietf] draft-kucherawy-dmarc-base
On Wed, Nov 5, 2014 at 10:35 AM, Terry Zink tz...@exchange.microsoft.com wrote: Since SPF authorizes an often _shared_ outbound IP address, it has been accurately described as an authorization method. DMaRC permits a DKIM signature to be spoofed and still allow a message to be accepted solely on the basis of SPF. What magic turns authorization into authentication??? This is a good point and I can share some of our own experiences in Microsoft's Office 365. [...] Terry, In terms of the base draft's content, I think the salient question is: Does the base draft's use of the term authentication mislead you or your customers in any way? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base
On Sun, Nov 2, 2014 at 6:28 AM, Scott Kitterman skl...@kitterman.com wrote: On Sunday, November 02, 2014 01:42:49 Murray S. Kucherawy wrote: ... As was done with the DKIM deployment RFCs, the same has been done for DMARC. It seems neither DKIM nor DMARC follow the path of least astonishment. Not quite. There was an actual DKIM working group that produced standards track documents that, due to an actual technical issue they found, broke backward compatibility with existing DK key records. DMARC was developed outside the IETF and submitted via the ISE. Not at all the same (nor the least astonishing from my PoV). Not that it's going to change at this point, but let's not overdo the claims of business as usual. Just to get the citation right, it was Doug who said this, not me. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base-04 issue
Just noticed that I never replied to this: On Fri, Aug 29, 2014 at 8:39 PM, Scott Kitterman skl...@kitterman.com wrote: Since this is the WG list, I'm not sure if this is still the right list for issues with the base spec or not, but here goes ... The definition of fo in Section 5.2, General Record Format, allows both values of 0 and 1 to be specified. It was suggested to me offlist that this might not be appropriate, so I thought it worth a discussion. Does anyone who's implemented fo have a problem with both 0 and 1 being specified? If it is somehow problematic, then the base spec ought to say so. How about this? 1: Generate a DMARC failure report if any underlying authentication mechanism produced something other than an aligned pass result. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] draft-kucherawy-dmarc-base revision submitted
Colleagues, With apologies once again that it's taken so long, I have submitted the base draft again to the datatracker. It underwent what Eliot Lear calls a haircut, which is to say I spent a good chunk of time rearranging the material, consolidating redundant sections, removing unnecessarily verbose or unimportant text. His sketch of a roadmap to doing so was very helpful indeed. There was only one technical change, and that was to remove all references to IODEF since that's an aspect of the reporting component that is completely unimplemented. In the hopes of keeping the spec simple, it's now gone. Since we're past the I-D deadline, the ISE or Pete will have to approve its addition to the datatracker, so it will magically appear at some point soon, and then move forward in the publication process. My thanks to all of you that took time to make haircut suggestions. Onward, -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] wiki vs. list?
On Sat, Oct 25, 2014 at 9:57 AM, Dave Crocker d...@dcrocker.net wrote: On 10/25/2014 12:34 PM, J. Gomez wrote: DMARC is a DKIM Policy Framework. According the marketing, it has gain widespread adoption especially among your list users domains. Isn't why you are here, to stop it? If by widespread adoption you mean that major mailbox providers (Gmail and others) are ignoring the Sender's DMARC policy (Yahoo, AOL and others), then yes: DMARC defines a DKIM policy which has widespread adoption. DMARC defines DMARC-related 'policies'. It does not affect DKIM in any way. It is an overlay to DKIM and/or SPF use. Yes, this. +1, etc. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] wiki vs. list?
On Thu, Oct 23, 2014 at 11:04 AM, Hector Santos hsan...@isdg.net wrote: I'm already lost of whats going on. It seems we are waiting of Murray. Its all Murray. Geez, Its all really Murray's framework to all this. Not a negative, but there has to be more. There is more. There has always been more, that is why we are lost here after 9 years. Sorry, but I have no idea what this is about. The only thing I think anyone's waiting on me for is a revision to draft-kucherawy-dmarc-base for publication as an RFC through the ISE. It will contain no technical changes, so either way, this WG shouldn't be blocked waiting on me for anything. Confused, -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Modeling MLM behavior
On Tue, Oct 7, 2014 at 1:41 PM, Tim Draegen t...@eudaemon.net wrote: The intention is to have something in place -- the MLM model -- that can be used to quickly identify issues that are related to DMARC interoperability with any given piece of MLM software. I read Alessandro's model as a way to generically describe MLMs, which would make comparing and contrasting of MLMs a lot easier. IOW, fleshing out a matrix of interoperability issues with respect to MLMs is made easier (possible?) if we have a generic way to describe MLM behavior. This is not meant to be a robust exercise in crafting the ideal MLM. If something like this is NOT in place, my concern is that the WG will only look at the big MLM packages. If the WG does not spend time collecting input, the WG will not be able to make informed decisions regarding solutions. What I believe you're saying is that you want to have a description of the current MLM model, generalized or in the aggregate, as a place from which to start talking about DMARC's impact. I'm totally fine with that and agree that it's probably useful to write it down. The way Alessandro made his proposal suggested to me that we were starting down the road of some kind of formal description of how the DMARC world wants MLMs to behave, as different from the current model. That was a red flag to me. Thanks for clarifying. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Modeling MLM behavior
On Mon, Oct 6, 2014 at 2:52 PM, Rolf E. Sonneveld r.e.sonnev...@sonnection.nl wrote: Can I get some clarification on the intent here? As worded, this paragraph suggests that we are looking to produce a model for MLMs to follow in a DMARC-aware world. I was under the impression that (a) this is a non-starter, and (b) we're not chartered to do so. I believe your impression is correct. Let's not start working on MLM's. Just to be clear, I think cataloging MLM interactions and all that stuff is potentially quite useful, but the suggestion was to specify a credible MLM model which to me sounds like we're going to propose something we have no business proposing; we're not chartered to do so, and history suggests there will be aggressive objection to any such effort even if we were. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Modeling MLM behavior
On Mon, Oct 6, 2014 at 4:15 PM, Hector Santos hsan...@isdg.net wrote: Murray, I think we need to make the distinction of two different concepts and acronyms; MLM Mailing List Manager and MLS Mail List Servers that serve the MLM market. There are some basic integration guidelines for both the MLS and MLM. I understand we don't want to make any changes, but the front-end, receivers, websites, i.e. Potential Entry Points, do need implementation change considerations. [...] I think this is unrelated to my point. It's my understanding that the idea of altering DMARC to better work with mailing lists is on the table, though later in our list of milestones. The idea of specifying how MLMs (or MLSes, or whatever) should operate in a DMARC world, however, is not. I just don't want any of us operating under the illusion that we can prescribe how extant MLMs need to change now that DMARC is in use if in fact we can't. There's obviously a lot of energy to be wasted in that direction. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: RFC 7372 on Email Authentication Status Codes
On Wed, Sep 17, 2014 at 1:43 AM, Sven Krohlas sven.kroh...@1und1.de wrote: RFC 7372 proposes to use a 550 response code for reverse DNS auth failures, see section 3.3. Reverse DNS checks are usually done early in the connection (like IP blocks) in the connection establishment stage of the SMTP dialog. RFC 5321 allows only a 554 error response there, see section 4.3.2. So, shouldn't a 554 code be used here? Or does RFC 5321 need an update? The definitions in 5321 are: 550 Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons) 554 Transaction failed (Or, in the case of a connection-opening response, No SMTP service here) 550 seems right to me. It's a rejection for policy reasons, not a general transaction failure or the total absence of SMTP service. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] draft-kucherawy-dmarc-base haircut
Colleagues, As you know, the DMARC base draft is being processed via the Independent Stream. Procedurally it's ready to move forward toward publication, with the caveat that the prose in it needs a serious haircut. (There is also the option to split the document before publishing it, but I don't think we're going to go that route.) I'm in the process of doing a pass through it to get rid of prose we don't really need, or be less verbose in other areas, etc., to give it the trimming it needs. If anyone has any suggestions or would like to help with this work, please let me know privately. Note that absolutely no technical additions, changes, or deletions will be entertained. This is just about the descriptive text and maybe the examples, or anything we can rework or remove to lean the document without touching the technology. Technical changes are a potential later work item for this working group. Thanks, -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider
Though I would never put such a thing in a standards document, OpenDKIM does have the capability to rewrite arriving header fields prior to signing/verifying to overcome things like this. Your ESP's verifier could be trained to ignore the added line prior to verifying, or better yet, do DKIM verification prior to AV processing. -MSK On Mon, Sep 15, 2014 at 12:31 PM, Henrik Schack henrik.sch...@gmail.com wrote: No it's not at all a free service. But they advertise anyway :-( Br Henrik On Mon, Sep 15, 2014 at 9:28 PM, Franck Martin fmar...@linkedin.com wrote: On Sep 15, 2014, at 7:39 PM, Henrik Schack henrik.sch...@gmail.com wrote: In Denmark we have a somewhat large (10K+ domains) anti-virus/spam provider breaking DKIM signatures. They break DKIM signatures on incoming email by adding a Virus scanned by line to the body of the email. Not sure how to fix this, but perhaps some day they'll get tired of my bi-monthly calls and emails complaining about how they do things. Is this a free service that they have to advertise themselves in the body of the email? If you pay for the service, may be you don’t want to get any advertisement? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc -- Mvh/Best regards Henrik Schack ICQ: 889295 http://henrik.schack.dk/ http://links.schack.dk/ ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider
How will most mail clients know not to display it if it's made part of the body? On Mon, Sep 15, 2014 at 4:39 PM, Terry Zink tz...@exchange.microsoft.com wrote: Having the Virus scanned by xxx defeats the purpose of advertising because most mail clients won't display it, and the point of adding this to the body is so that other people can see it. I think Murray's earlier suggestion to perform the DKIM check before A/V filtering is the best option. -- Terry -Original Message- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of John Levine Sent: Monday, September 15, 2014 2:16 PM To: dmarc@ietf.org Cc: hen...@schack.dk Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider In article CAGfQzLTvB9C97s=cGZ-k17ynv0=JUr6pygEbVnohhA= t00p...@mail.gmail.com you write: -=-=-=-=-=- -=-=-=-=-=- In Denmark we have a somewhat large (10K+ domains) anti-virus/spam provider breaking DKIM signatures. They break DKIM signatures on incoming email by adding a Virus scanned by line to the body of the email. Not sure how to fix this, but perhaps some day they'll get tired of my bi-monthly calls and emails complaining about how they do things. As other people have said, put the advertisement in a header, not in the body. R's, John -- This message is infected with annoying ads because it has been scanned by Avast! anti-virus. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Milestones changed for dmarc WG (public suffix exclusion)
On Fri, Aug 29, 2014 at 7:13 PM, Douglas Otis doug.mtv...@gmail.com wrote: While the PSL might be useful for offering some web related assertions, its current form is inappropriate for email policy. Those working on the web/email related issues might hope these common concerns will engender enough synergy to formalize a published list of registrar domains. Such a list would certainly minimize policy discovery overhead. Unfortunately, something this simple is not likely being discussed. A discussion that seems to be more behind closed doors. This is old news, I think. Nobody is advocating use of the PSL other than as a temporary measure until a more robust solution is available. Even the DMARC base draft says so, and has for a very long time. There's nothing happening behind closed doors here. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Milestones changed for dmarc WG (public suffix exclusion)
On Fri, Aug 29, 2014 at 12:37 PM, Tim Draegen t...@eudaemon.net wrote: Simply put, the public suffix concept is useful beyond what DMARC requires of it. The best that DMARC can do (as a piece of technology) is fully articulate 1 specific use case for the public suffix concept, and hope that other use cases get fleshed out enough so that a viable solution can be crafted by something other than this WG. There's also a mailing list where this is being discussed (dbo...@ietf.org) as a thing independent of DMARC, and it was the subject of a BoF in Atlanta (I believe) and at least a couple of APPSAWG presentations in the past, so I expect it will get its own Working Group once there's critical mass and a problem statement. This WG should adjust (or be able to adjust) to use whatever that group produces, but not go further than that. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Start of DMARC WG + proposed milestones
On Sat, Aug 23, 2014 at 7:34 AM, Miles Fidelman mfidel...@meetinghouse.net wrote: I did notice the absence of anything related to process. How are we going to get to a document (that) captures all known interoperability issue between DMARC and indirect email flows? If this were an RFC, there'd be an author or authors identified, maybe a draft to start from. Since in essence we're only talking about milestones, I disagree. I've never seen a set of milestones on a WG charter or otherwise that name specific people who will complete them. For some of these there is indeed a draft to start from, named in the charter. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] p= ordering
On Tue, Jul 29, 2014 at 4:42 PM, Tomki Camp tc...@agari.com wrote: 5.2 has 'A DMARC policy record MUST comply with the formal specification found in Section 5.3 http://www.blackops.org/%7Emsk/dmarc/draft-dmarc-base.html#dmarc_abnf in that the v and p tags MUST be present and MUST appear in that order.' In the spec at 5.3, we have 'components other than dmarc-version and dmarc-request may appear in any order' http://www.blackops.org/~msk/dmarc/draft-dmarc-base.html#dmarc_abnf Just to be clear, the authoritative version is here: https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ The cited link is an old one that is for private use and may not be current. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] ATPS, TPA-Label, etc.
[Changing Subject: to a new thread and dropping i...@ietf.org, since this is not charter discussion] On Sun, Jul 20, 2014 at 12:27 AM, Douglas Otis doug.mtv...@gmail.com wrote: ATPS is not the lite version of TPA-Label. This is explained in http://tools.ietf.org/id/draft-otis-tpa-label-04.html#rfc.appendix.C I disagree. I think that's exactly what it has turned out to be. ATPS requires DKIM signatures used by Third-Party Services to somehow determine different label encoding methods permitted by ATPS. ATPS also lacks any discovery or exchange method for this. In contrast, TPA-Label makes NO demands on third-Party services. None. Since there is only one encoding method, there is NO guesswork discovering the listing encoding method. There's no magic involved here (somehow? really?). The third-party selects a hash algorithm, or opts not to use one, and indicates this choice in the generated signature. The possible choices are enumerated in the specification. The verifier thus knows which hash (if any) was used. There is no discovery or exchange needed, since any DKIM implementation already includes support for all of the ones that ATPS specifies. Claiming there's some kind of burden ATPS has that TPA-Label does not have is simply false. If this truly is a burden (which I seriously doubt), selecting one hash or the none option and removing the other choices from ATPS is certainly possible, but first I think I'd like to see some evidence that this is a pain point either for implementers or operators, or that it creates an interoperability problem. The extra processing is only done when DMARC indicates non-complaince where the DMARC domain can then indicate whether they have informally federated the domain in question and what if any additional information must be included in the message. In comparison, processing a new DKIM-ike signature involves greater overhead than that needed to obtain a TPA-Label resource which happens only after the domain in question has been validated. It seems TPA-Label represents far easier deployment and far less overhead since the Third-Party makes no change to their process and only a single, small, cacheable TPA-Label resource is provided by the DMARC domain. Both methods start from a place of non-compliance of the basic case, namely non-authentication by the author domain. ATPS requires that the third-party have signed with DKIM (and thus as we say, taken some responsibility for) the message under evaluation; TPA-Label does not have this constraint by default, which means TPA-Label is cheaper to deploy. However, I'm at a loss to understand why X is an approved third-party for Y is meaningful when neither of those identifiers are authenticated. If Y is a high-value target, then an attacker can merely claim to be X; without authentication, TPA-Label still approves this. Just make X authenticate with DKIM, you say? Guess what, you're back to ATPS. All of the other options TPA-Label has about must have this header field or that one, or the value of this field must align with that one, are trivially satisfied by an attacker because the acceptance policy is made public, and I don't think they add any protection that isn't thus trivially defeated. They may help for a migration, for example, but not as an effective security mechanism against a bad actor. In terms of what's useful to DMARC, the ability to announce a third-party delegation approved by the author domain and authenticated by SPF is the only thing ATPS can't already do. And I'm not convinced that either of these methods is better than the ephemeral delegation idea. Anyway, all of that is for the working group to decide. Finally, Appendix C of the TPA-Label draft makes what I believe is a bogus claim about causes for the lack of ATPS adoption. The reason is far more general: Even though we made ATPS available for free, including deployment tools, there has never been any obvious evidence that a third-party mechanism is sufficiently secure, scalable, and above all, necessary. It is the main reason why TPA-Label, which is older than ATPS, has also seen no adoption to speak of. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Draft DMARC working group charter
On Wed, Jul 2, 2014 at 1:45 AM, Alessandro Vesely ves...@tana.it wrote: My question about the stance toward DKIM tweaks[1] was never answered. To re-state, while preclusion is apparent for the organizational domain issue, it is not clear for DKIM. The charter says: The working group will not develop additional mail authentication technologies, but may document authentication requirements that are desirable. It also says: The working group will consider mechanisms for reducing or eliminating the DMARC's effects on indirect mail flows. Among the choices are: - A form of DKIM signature that is better able to survive transit through intermediaries. - Collaborative or passive transitive mechanisms that enable an intermediary to participate in the trust sequence, propagating authentication directly or reporting its results. - Message modification by an intermediary, to avoid authentication failures, such as by using specified conventions for changing the aligned identity. Consideration also will be given to survivable authentication through sequences of multiple intermediaries. So I think you're covered. Clarity and comprehensibility are very important from my POV[2]. For that sake, I suggest the charter mention candidate solutions such as DKIM-Delegate and TPA-Labels explicitly. Some further wordsmithing may be advisable too. It probably wouldn't be harmful to list them as possible inputs to the work, so that people reviewing the charter have some context, so long as doing so doesn't also constrain the WG's options. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Draft DMARC working group charter
On Wed, Jul 2, 2014 at 9:59 AM, Douglas Otis doug.mtv...@gmail.com wrote: Agreed, as it seems such efforts have been excluded by the charter language. It would be a shame, since there needs to be a remedy permitting back-office services such as those offered by Intuit and the like. It seems such efforts are easily within the realm of being practical without effecting DKIM. To repeat: I disagree that they've been excluded. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] ***SPAM*** 8.001 (5) Re: ***SPAM*** 7.348 (5) Re: Re: Draft DMARC working group charter
On Thu, Jun 26, 2014 at 10:26 AM, Jim Fenton fen...@bluepopcorn.net wrote: 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 don't see how this can be considered out of scope without a viable alternative. The identification of the Administrative Domain is a normative requirement in DMARC, and if this problem is not solved, the specification will be stuck. Having tried and failed to solve this problem several years ago, I am convinced that this is a very difficult problem. I think this is the right way to go because (a) the task at hand is big enough as it is without taking on this as well, especially since (b) the question of identifying the Organizational Domain (to use DMARC's term) has appeared in several other contexts as well, and was the subject of a BoF in London (look up dbound), so if that work is going to be done elsewhere, we don't need to also do it here. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-01.txt
Playing around with ideas here. This one removes the l=0 signature stuff and instead makes DKIM-Delegate into a more self-contained thing, which I believe was suggested (or at least inspired) by Stephen's comments. There is still the potential for abuse during the ephemeral relationship period (i.e., prior to expiration), but it it is now an indirect attack on the author domain rather than a direct one. Perhaps that's more palatable in this scenario. Comments welcome. -MSK -- Forwarded message -- From: internet-dra...@ietf.org Date: Thu, Jun 19, 2014 at 11:08 PM Subject: New Version Notification for draft-kucherawy-dkim-delegate-01.txt To: Murray S. Kucherawy superu...@gmail.com, Dave Crocker dcroc...@bbiw.net A new version of I-D, draft-kucherawy-dkim-delegate-01.txt has been successfully submitted by Murray S. Kucherawy and posted to the IETF repository. Name: draft-kucherawy-dkim-delegate Revision: 01 Title: Delegating DKIM Signing Authority Document date: 2014-06-19 Group: Individual Submission Pages: 11 URL: http://www.ietf.org/internet-drafts/draft-kucherawy-dkim-delegate-01.txt Status: https://datatracker.ietf.org/doc/draft-kucherawy-dkim-delegate/ Htmlized: http://tools.ietf.org/html/draft-kucherawy-dkim-delegate-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-kucherawy-dkim-delegate-01 Abstract: DomainKeys Identified Mail (DKIM) permits a handling agent to affix a digital signature to an email message, associating a domain name with that message using cryptographic signing techniques. The digital signature typically covers most of a message's original portions, although the specific choices for content hashing are at the discretion of the signer. DKIM signatures survive simply email relaying but typically are invalidated by processing through Mediators, such as mailing lists. For such cases, the signer needs a way to indicate that a valid signature from some third party was anticipated, and constitutes an acceptable handling of the message. This enables a receiver to conclude that the content is legitimately from that original signer, even though its original signature no longer validates. This document defines a mechanism for improving the ability to assess DKIM validity for such messages. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-01.txt
On Fri, Jun 20, 2014 at 11:21 AM, John Levine jo...@taugh.com wrote: This looks an awful lot like my draft-levine-cdkim-00 and draft-levine-dkim-conditional-00 except that mine has more bits of DKIM in the cdkim signature so it can sign To and From to limit the range of spoofage. The difference is that this proposal doesn't change/extend/spin/fold/mutilate DKIM at all. The semantics are outside entirely. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version
On Thu, Jun 19, 2014 at 11:15 AM, Hector Santos hsan...@isdg.net wrote: While DKIM-BASE tried to clean up this separation of the author domain policy, it could not because of all the past existing ADSP or SSP references in the many DKIM related RFCs, see RFC6376, section 1.1. But conceptually, it didn't matter what you called it. It was an author domain signing policy protocol and today, it's called DMARC. DKIM has no payoff with just base signing analysis . It was separated but with all the intentions of sticking secondary author policy and signer trust layers on it before a payoff was realized. There are reputation systems -- I built one, and I know others exist -- that use DKIM as the identifier on which reputation is built, and they've been effective in experimental environments at identifying what's good and what's outside of good. The difference here is between active and passive determination of what's good and what's not good. If you want active, I agree that DKIM by itself isn't enough. But I disagree, with evidence, that DKIM has no payoff with just base signing analysis. If that's not convincing enough, consider that IP reputation has been largely successful, and the input to such systems is a verified identifier, which is the same class of output DKIM provides. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version
On Thu, Jun 19, 2014 at 12:36 PM, Douglas Otis doug.mtv...@gmail.com wrote: Our company has had extensive experience dealing with email spoofing. While reputation is able to deal with bulk spamming, it is ineffective at dealing with a phishing problem, the intent behind DMARC. It is a basic information issue. Those offering a reputation for a domain have no way to judge which of their identifiers are being spoofed for messages handled by third-parties. Only the spoofed domain can be considered authoritative. To suggest otherwise implies the sharing of PII, which is not acceptable in many regions. DKIM coupled with reputation can only tell you if a given message was handled by a source with a good reputation. It doesn't evaluate any visible identifiers. I don't really understand the rest of what you're talking about here. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
