Re: [dmarc-ietf] alignment and parsing logic as optionals
On 04/21/2014 12:37 PM, Vlatko Salaj wrote: > I think Franck wrote: >>> That doesn't seem to me like a shocking level of trust. >> Yes indeed, but then, the recent breaches shows too much trust >> has been sprinkled all around. Many ESP will provide you with >> dedicated IPs for your sends, this allows you to control your >> deliverability, the email security, etc... They come at a price, >> but you have what you pay for. > should i read this as: if u want DMARC 3rd party support, please > pay? No, this was a concern and for many a best practice well before DMARC arrived. Using a large pool of vendor/ESP IP addresses leaves the sending organization (ABC) exposed to: - IP reputation impacted by all other customers - Another ESP customer's account being used to send email as ABC (depends on ESP controls) - Security of entire ESP infrastructure versus a small subset (dev systems, disaster recovery, etc) In other cases it's part of a more general policy that the vendor/ESP not use shared infrastructure when handling any of the contracting company's (customers') data. --S. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Monday, April 21, 2014 9:01 PM, "dmarc-requ...@ietf.org" wrote: >> That doesn't seem to me like a shocking level of trust. > Yes indeed, but then, the recent breaches shows too much trust > has been sprinkled all around. Many ESP will provide you with > dedicated IPs for your sends, this allows you to control your > deliverability, the email security, etc... They come at a price, > but you have what you pay for. should i read this as: if u want DMARC 3rd party support, please pay? maybe we should then just forget about making DMARC an open standard, instead just paying for proprietary solutions in the same area. that's about much better security overall. faulty thinking, if u ask me. i have no problem with making a standard as flexible as possible and let the domain owners' decide what and how much security they like. introducing authorised alignment doesn't essentially break DMARC. it just makes it more natural to email today and also adds support for things we, obviously, need and use. -- Vlatko Salaj aka goodone http://goodone.tk ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
- Original Message - > From: "Joseph Humphreys" > To: dmarc@ietf.org > Sent: Monday, April 21, 2014 9:01:16 AM > Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals > > On Fri, Apr 18, 2014 at 2:00 PM, Franck Martin > wrote: > > > >> If you are willing to accept additional DNS lookups, you actually > >> could use this to alleviate the mailing list problem, just by adding > >> an include syntax for aligned domain lists. That would create a > >> mechanism for people to make public, curated MLM whitelists. I > >> hesitate to bring that up because I imagine some people won't like the > >> idea of more DNS lookups, and I don't want the entire idea to get shot > >> down by association. > >> > > > > Not delving in the details, but I may be off base... > > > > It seems this solution is akin to have to add to your SPF record the whole > > of Google cloud or Salesforce cloud, with a "trust us" we don't allow any > > of our other members to send email on your behalf on any of our > > applications... > > Yes, it is, unless the sender sets aside a more SPF-restricted domain > to use for sending customers' mail. In fact it is very similar to > including another organization's SPF record in your own, which does > not seem uncommon. That doesn't seem to me like a shocking level of > trust. Yes indeed, but then, the recent breaches shows too much trust has been sprinkled all around. Many ESP will provide you with dedicated IPs for your sends, this allows you to control your deliverability, the email security, etc... They come at a price, but you have what you pay for. > > > > > https://dmarcian.com/spf-survey/google.com 212,996 authorized individual > > IPv4 addresses > > https://dmarcian.com/spf-survey/salesforce.com 228,934 authorized > > individual IPv4 addresses > > > > I prefer that 3rd parties relay our mail mail through our servers. > > That is eminently reasonable, considering that your organization sends > email as part of its core business, and is well prepared to take on > that responsibility. Obviously, there are a lot of organizations out > there who are not in that position. > > So I think the question is, does adding an "aligned domains list" > feature encourage policies that are inherently unsafe? I would argue > that authorizing a service provider to send for you on all of their > IPs is not substantially different from authorizing them on one IP. > Once you've authorized someone to send mail on your behalf at all, you > are essentially trusting them to do it safely. > I wish this would be that simple, more often than not, you are pushed into an agreement and can only negotiate mitigating factors as to lower the risk. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Fri, Apr 18, 2014 at 2:00 PM, Franck Martin wrote: > >> If you are willing to accept additional DNS lookups, you actually >> could use this to alleviate the mailing list problem, just by adding >> an include syntax for aligned domain lists. That would create a >> mechanism for people to make public, curated MLM whitelists. I >> hesitate to bring that up because I imagine some people won't like the >> idea of more DNS lookups, and I don't want the entire idea to get shot >> down by association. >> > > Not delving in the details, but I may be off base... > > It seems this solution is akin to have to add to your SPF record the whole of > Google cloud or Salesforce cloud, with a "trust us" we don't allow any of our > other members to send email on your behalf on any of our applications... Yes, it is, unless the sender sets aside a more SPF-restricted domain to use for sending customers' mail. In fact it is very similar to including another organization's SPF record in your own, which does not seem uncommon. That doesn't seem to me like a shocking level of trust. > > https://dmarcian.com/spf-survey/google.com 212,996 authorized individual IPv4 > addresses > https://dmarcian.com/spf-survey/salesforce.com 228,934 authorized individual > IPv4 addresses > > I prefer that 3rd parties relay our mail mail through our servers. That is eminently reasonable, considering that your organization sends email as part of its core business, and is well prepared to take on that responsibility. Obviously, there are a lot of organizations out there who are not in that position. So I think the question is, does adding an "aligned domains list" feature encourage policies that are inherently unsafe? I would argue that authorizing a service provider to send for you on all of their IPs is not substantially different from authorizing them on one IP. Once you've authorized someone to send mail on your behalf at all, you are essentially trusting them to do it safely. Regards, Joe H ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Fri, 18 Apr 2014 13:04:08 -0400, Joseph Humphreys wrote: > Again, I have not been proposing this as a solution for mailing lists. > It solves at least two other problems: third-party bounce handlers, > and using your own domain with some large mail providers like gmail. > In either case, the domain owner can use DMARC without requiring any > support from the sender. This is not theoretical -- we have customers > who are currently stalled on DMARC implementations and who could move > forward if this were included in the spec. u can easily guess my standing on this, from my previous messages. +1 > If you are willing to accept additional DNS lookups, you actually > could use this to alleviate the mailing list problem, just by adding > an include syntax for aligned domain lists. That would create a > mechanism for people to make public, curated MLM whitelists. I > hesitate to bring that up because I imagine some people won't like the > idea of more DNS lookups, and I don't want the entire idea to get shot > down by association. this seems promising, but i doubt it will have big support here. however, this could solve issues with mailing lists that do not want to adopt a DMARC-compatible way of doing things, which i absolutely support. DMARC should be adapted to account for our world, not the other way around. that said, and having examined Sender-ID spec better, all these issues could be solved just by having Sender-ID in DMARC. Sender-ID passes alignment where SPF fails, no matter what's DKIM status. so, we have two working solutions. do we have any will to actually solve the problem? or is status quo and finding excuses of higher priority? -- Vlatko Salaj aka goodone http://goodone.tk ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
- Original Message - > From: "Joseph Humphreys" > To: dmarc@ietf.org > Sent: Friday, April 18, 2014 10:04:08 AM > Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals > > On Fri, Apr 18, 2014 at 4:50 AM, Murray S. Kucherawy > wrote: > >> > >> The alignment domain-list solution seems trivial to me, and it works > >> without active support from the sender, which is nice. > > > > > > How does it work without active support from the sender? Doesn't the > > sender > > first have to ensure it's in that list? That's kind of an important step > > for a list operator with a new subscriber from a "p=reject" domain. > > > > Again, I have not been proposing this as a solution for mailing lists. > It solves at least two other problems: third-party bounce handlers, > and using your own domain with some large mail providers like gmail. > In either case, the domain owner can use DMARC without requiring any > support from the sender. This is not theoretical -- we have customers > who are currently stalled on DMARC implementations and who could move > forward if this were included in the spec. > > If you are willing to accept additional DNS lookups, you actually > could use this to alleviate the mailing list problem, just by adding > an include syntax for aligned domain lists. That would create a > mechanism for people to make public, curated MLM whitelists. I > hesitate to bring that up because I imagine some people won't like the > idea of more DNS lookups, and I don't want the entire idea to get shot > down by association. > Not delving in the details, but I may be off base... It seems this solution is akin to have to add to your SPF record the whole of Google cloud or Salesforce cloud, with a "trust us" we don't allow any of our other members to send email on your behalf on any of our applications... https://dmarcian.com/spf-survey/google.com 212,996 authorized individual IPv4 addresses https://dmarcian.com/spf-survey/salesforce.com 228,934 authorized individual IPv4 addresses I prefer that 3rd parties relay our mail mail through our servers. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Fri, Apr 18, 2014 at 4:50 AM, Murray S. Kucherawy wrote: >> >> The alignment domain-list solution seems trivial to me, and it works >> without active support from the sender, which is nice. > > > How does it work without active support from the sender? Doesn't the sender > first have to ensure it's in that list? That's kind of an important step > for a list operator with a new subscriber from a "p=reject" domain. > Again, I have not been proposing this as a solution for mailing lists. It solves at least two other problems: third-party bounce handlers, and using your own domain with some large mail providers like gmail. In either case, the domain owner can use DMARC without requiring any support from the sender. This is not theoretical -- we have customers who are currently stalled on DMARC implementations and who could move forward if this were included in the spec. If you are willing to accept additional DNS lookups, you actually could use this to alleviate the mailing list problem, just by adding an include syntax for aligned domain lists. That would create a mechanism for people to make public, curated MLM whitelists. I hesitate to bring that up because I imagine some people won't like the idea of more DNS lookups, and I don't want the entire idea to get shot down by association. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Friday, April 18, 2014 10:44 AM, Murray S. Kucherawy wrote: > So you don't want the authentication enforcement, only the reports? no, i do want authentication enforcement. i do not want alignment enforcement. i want parsing of both SPF and DKIM in AND-based logic and i want it standardized, and standardized rejection based on failure of such parsing, and standardized reporting, and standardized introduction in anti-spam filters. hint: "standardized" is the point here. if that, somehow, isn't obvious. > Isn't that what "p=none" does? nope. "p=none" simply excludes my email from DMARC completely. i do get reporting, but i don't get standardized parsing, or standardized rejection on failure, or standardized anti-spam filtering introduction, or whatever else builds on DMARC in the future. > So you're saying both need to pass (in the AND case), but it doesn't > matter which domains they validated? > Again, that means I can send any mail I want as your domain and that > would pass DMARC, and I'm not clear about why you want that. cause u r not fixing alignment problems u introduced in DMARC, and i have no other choice but to disregard alignment completely, yet i also don't care about possible phishing that much, cause either my domain doesn't get phished much or SPF/DKIM/anti-spam filtering on receivers' side works well in such cases, which brings me back to alignment again and how i don't care about alignment or how u don't want to fix it, so i decide i'll just turn it off, instead of bickering on DMARC mailing list about fixing the alignment problem, which u don't want to fix, cause u keep saying it's a feature. and came the time when google started defending problems as features. however, as i said, DMARC is way more than just alignment, and i do care about those other things, especially if there's AND-logic in the standard. 10 goto _top > Right, that's the third-party case discussed above. > There are a bunch of limitations, assuming this is something that's > actually in enough demand to add. and what does "enough demand to add" mean? who decides about what's enough, in this, adhoc something which isn't even an ietf approved wg? > For starters: (1) sticking the list in a DNS TXT field will not scale > (suppose you want to authorize a thousand third parties), and i just love how u r gonna authorize a 1000 3rd parties with DKIM-key sharing, instead. nice discussion we have here. maybe next time i can make ridiculous contra argument like this on some of ur new ideas, just to be fair. > (2) you have to keep the list current, which will need automation and > security around it as users seek to add entries (by subscribing to lists, > for example). i guess u r intentionally missing the point here. i have no other idea why it is so hard to read when i write "small players", few domains, or whatever else i wrote while trying to paint this "small" picture for everybody here. so, it's not 1000 domains, 4000 IPs, 5 servers. it would be, on average, imo, 2 domains [for those who actually use the setting, which is already a special case, not a common practice]. > Of course, since DMARC is about keeping control over that, > maybe it's an expected scaling problem, but it's still something that > needs to be handled. which isn't enough of a reason against. >>> I totally agree there, especially since Sender-ID got almost no adoption >>> (see RFC 6686), and that seems unlikely to change now. >> it would change quite fast if we would make it part of DMARC. > What would be the value in doing so? alignment-pass in various special cases i'm trying to cover here with my proposals, which currently have alignment-fail status. if Sender-ID was part of DMARC, my "goodone.tk email stream coming from yahoo mail use case" would be solved instantly. it would also cover mailing lists, and whatnot, just because of benefits Sender-ID has over SPF. so, if Sender-ID was a part of DMARC-underlying mechanisms, i would drop all my proposals, cause my troubling case scenarios would be solved, as well as many others. > The fact that in several years nobody adopted Sender-ID > speaks pretty loudly to me. this is like saying that there r no business politics in protocol world. right. it's pretty obvious Sender-ID was a collateral victim of general displeasure with Microsoft's business model. who knows, we may soon see the same happening to Google too... if it haven't started already. > It seems to me more like you're talking about a way to extend specific > other domains to be allowed to send mail as your domain and still pass. > SPF and DKIM already have mechanisms to do that, not to mention > experimental extensions like ATPS. DMARC's alignment problem isn't SPF's or DKIM's problem. and if u r suggesting i should use DKIM extensions, which r rarely supported, or other tools, to fix problems DMARC introduces, then i'll just quit this mailing list, and ignore the entire protocol, cause it's broken and u
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Friday, April 18, 2014 10:44 AM, Murray S. Kucherawy wrote: > Assuming they're all dumb or lazy because they're "missing the point" > seems like a pretty bad place from which to start. didn't happen. > If all people get is snark when they probe your ideas, I'm pretty sure > they'll just stop answering. also didn't happen. why do u exactly defend someone who promoted google's commercial services? -- Vlatko Salaj aka goodone http://goodone.tk ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Thu, Apr 17, 2014 at 12:37 PM, Tomki Camp wrote: > What about a scenario where a user would like to > - receive DMARC reporting > - request DMARC-aware receivers reject email which does not pass base > authentication measures (SPF or DKIM), but not apply the next step of > alignment enforcement > What's the next step part? If you've rejected the message because it passes neither SPF or DKIM, it seems like you're done with that message irrespective of alignment. > This could still be beneficial in cutting off illegitimate email which > does not pass SPF or DKIM at all, but provides the allowance which some > domain owners could find a useful middle or even final step in their DMARC > deployment. > Shooting from the hip, I'm inclined to say this is out of scope for DMARC. DMARC has as one of its core tenets the notion of From: field alignment, because what the user sees comes from the From: field for most (almost all?) MUAs. If you take that out of the equation, it seems like we're talking about stuff a layer below DMARC, not DMARC itself. > Could it be set up as allowing aspf=n for “align SPF = none” and adkim=n? > If you're going to say "either has to pass but I don't care about alignment", then I can use my own domain in the MAIL FROM or sign with my own domain and send mail with your domain in the From:, and it'll pass the DMARC test. Is that really an attractive alternative? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Thu, Apr 17, 2014 at 10:01 AM, Joseph Humphreys < jhumphr...@salesforce.com> wrote: > The alignment domain-list solution seems trivial to me, and it works > without active support from the sender, which is nice. > How does it work without active support from the sender? Doesn't the sender first have to ensure it's in that list? That's kind of an important step for a list operator with a new subscriber from a "p=reject" domain. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Thu, Apr 17, 2014 at 11:20 PM, Vlatko Salaj wrote: > > I think if you want to get your ideas understood and thus adopted, > > you're going to have to set your patience and politeness thresholds > > a lot higher than they are now. > > i do not have much patience for ppl that have no time to read step by step > example, but do have time to write a lengthy response, while missing the > point > and promoting commercial services. > Reaching consensus requires dialog and patience, and sometimes needs more than just one example. There's a lot of smart people here who have been working on this for a long time, probably with very different perspectives and experience than you have. Assuming they're all dumb or lazy because they're "missing the point" seems like a pretty bad place from which to start. If all people get is snark when they probe your ideas, I'm pretty sure they'll just stop answering. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Thu, Apr 17, 2014 at 7:51 AM, Vlatko Salaj wrote: > making DMARC strictly based on OR-logic will get it obsolete as soon as > someone finds a way to exploit any of the underlying mechanism, and that's > already possible, either through DKIM replay attack, or through spoofed SPF > authentication, whichever serves an attacker better. > The DKIM replay attack assumes that either (a) the entire content is signed, in which case the only replay is the re-sending of a complete original (which is presumably valid), or (b) there's partial content signing going on, which is strongly discouraged practice anyway. What's an example of spoofed SPF authentication? > "I do not want alignment" is exactly the same as "I don't use DMARC" > > since DMARC is pretty much all about alignment. So, again, I don't > > understand why that's a useful thing to add. > > it's not the same. DMARC is not just authentication, it's also about > reporting > and conformance. i would be perfectly happy to get my email checked against > SPF and DKIM and processed in a standard-defined way, and receive reports > on > which i can then act. otherwise, DMARC has no benefits for me at all. > So you don't want the authentication enforcement, only the reports? Isn't that what "p=none" does? You would get reports of unaligned mail and SPF/DKIM results in that case already. > >> and it's a common practice, absolutely. whether it's formal or informal. > > What's an example? > > i've already written about it. someone using yahoo or google email service > to send their own domain email. i actually do that. and i imagine, a great > deal of ppl. > > it also covers various 3rd party services, such as ones that deliver > greeting > cards, process petitions... > It seems to me more like you're talking about a way to extend specific other domains to be allowed to send mail as your domain and still pass. SPF and DKIM already have mechanisms to do that, not to mention experimental extensions like ATPS. The problem is that you need to know ahead of time which senders will do so, which has the obvious scaling problem. Of course, since DMARC is about keeping control over that, maybe it's an expected scaling problem, but it's still something that needs to be handled. >> as i said: combined, alignment OFF and AND processing logic would work > great > >> in cases where alignment isn't possible, yet email is fully legitimate. > > For the "off" case, isn't that just the same as "p=none"? > > it isn't. if we accept the idea about making alignment optional, i would > gladly expand the idea to more than just turning alignment on/off. > I still don't understand this. What's the difference between "p=none" and what you're calling "alignment off"? > actually, such alignment field would, in my proposal, include a > three-state: > > 1. alignment ON, in which case from: header gets checked against. > > 2. alignment OFF, in which case domain owner specifies they have no benefit > from DMARC alignment checks, but do want other checks performed, such as > AND-logic mechanism evaluation, for example. > But the AND-logic is "SPF and DKIM have to pass, and be aligned". So you're saying both need to pass (in the AND case), but it doesn't matter which domains they validated? Again, that means I can send any mail I want as your domain and that would pass DMARC, and I'm not clear about why you want that. 3. alignment domain-list value to include in alignment check: list of > domains > the domain owner wants to have included in DMARC alignment check, > complementing > from: header domain; this will cover almost all cases DMARC breaks now, > such > as 3rd party infrastructure, mailing lists that do not wish to make changes > for DMARC-compatibility, forwarders that process their mail, but can't be > controlled by domain owner, etc. it's somewhat similar to SPF domain > definition, > but different, since it affects DMARC-alignment process. > Right, that's the third-party case discussed above. There are a bunch of limitations, assuming this is something that's actually in enough demand to add. For starters: (1) sticking the list in a DNS TXT field will not scale (suppose you want to authorize a thousand third parties), and (2) you have to keep the list current, which will need automation and security around it as users seek to add entries (by subscribing to lists, for example). > I totally agree there, especially since Sender-ID got almost no adoption > > (see RFC 6686), and that seems unlikely to change now. > > it would change quite fast if we would make it part of DMARC. > What would be the value in doing so? > PRA could actually be a better way to determine owner's domain for > alignment > purposes than some undefined public-suffix list, especially in the light of > newest moves by ICANN, introducing bunch of new top-lvl domains, which will > probably host a bunch of sub-domains with registration capabilities by 3rd > parties, etc. > I don't think we really w
Re: [dmarc-ietf] alignment and parsing logic as optionals
> I think if you want to get your ideas understood and thus adopted, > you're going to have to set your patience and politeness thresholds > a lot higher than they are now. i do not have much patience for ppl that have no time to read step by step example, but do have time to write a lengthy response, while missing the point and promoting commercial services. i was tired and i apologize for the tone, but not for the point i was making. -- Vlatko Salaj aka goodone http://goodone.tk ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Thu, Apr 17, 2014 at 1:42 PM, Vlatko Salaj wrote: > > wrong conclusion, but i'm not gonna repeat myself. > one example should be enough to everybody. > > I think if you want to get your ideas understood and thus adopted, you're going to have to set your patience and politeness thresholds a lot higher than they are now. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Thursday, April 17, 2014 9:38 PM, Tomki Camp wrote: > Could it be set up as allowing aspf=n for “align SPF = none” and adkim=n? i find this a convenient way of introducing alignment-OFF logic, yes. also, aspf and adkim tags would be a best place for alignment domain-list, imo. for example "aspf=n,r:yahoo.com,s:google.com" would mean none alignment for from: header domain, relaxed alignment for yahoo.com and strict alignment for google.com. the domain in this question uses yahoo and google mail services to send mail, and doesn't use its own servers at all. -- Vlatko Salaj aka goodone http://goodone.tk ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Thursday, April 17, 2014 10:14 PM, "Popowycz, Alex" wrote: > But if your ESP is where your email originates, then citing them in your > SPF is appropriate. wrong conclusion, but i'm not gonna repeat myself. one example should be enough to everybody. > As for small domains being able to send DMARC compliant mail, > (not trying to market Google's capability... but) that's easily > accomplished with Gmail using your own DKIM key that's published > on your own DNS entry for your personal/small business domain. which isn't free. thus, u r trying to market google's capabilities, while missing the point. -- Vlatko Salaj aka goodone http://goodone.tk ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
But if your ESP is where your email originates, then citing them in your SPF is appropriate. If you're worried about the impact of DMARC then: a) Don't publish a DMARC record b) Publish a DMARC record with p=none or c) Publish any DMARC policy but use an SPF record like "v=spf1 ip4:0.0.0.0/0 ~all As for small domains being able to send DMARC compliant mail, (not trying to market Google's capability... but) that's easily accomplished with Gmail using your own DKIM key that's published on your own DNS entry for your personal/small business domain. -Original Message- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Vlatko Salaj Sent: Thursday, April 17, 2014 1:33 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals On Thursday, April 17, 2014 6:53 PM, John Levine wrote: >> I don't see any scaling problem for the case of a domain used by a single >> entity that wants to authorize a few service providers to send email on >> its behalf. > Is that really a problem? I was under the impression that a sender either > adds the providers' IPs to their SPF record, or gives them a DKIM signing key. wrong: 1. DKIM key sharing requires such a support, which is usually not there. 2. SPF policy check doesn't evaluate ur SPF policy at all, but ur ESP's. On Thursday, April 17, 2014 6:53 PM, John Sweet wrote: >> I am still curious what's wrong with this proposal. > How is this not covered by SPF "include:"? If your message has both MAILFROM > and RFC822 From: aligned on your domain, and the connecting IP is in the > range of the included domain, it's all good. it isn't covered by SPF's "include:". seems not many understand this problem, let me make an example: if i use yahoo email for my goodone.tk domain, yahoo will send my email with yahoo.com DKIM key and with yahoo.com SPF MailFrom [my yahoo account address]. and i can't do anything about it. yahoo doesn't support key-sharing, nor it will. so, my domain-email sent from yahoo mail isn't aligned. however, it is legitimate, it is DKIM-signed and it has proper SPF. out of my 15 small-business customers, 12 use exactly this usage scenario. usually google. and when i said it would be a problem, that was not the best way, trying to force them to send mail through their own server, they didn't want to hear it. and i imagine, it is a pretty common practice in the wild for small players. -- Vlatko Salaj aka goodone http://goodone.tk ___ 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] alignment and parsing logic as optionals
On Thu, Apr 17, 2014 at 3:04 PM, John Levine wrote: > On 4/17/14, 1:03 PM, Joseph Humphreys wrote: > >> >> The alignment domain-list solution seems trivial to me, and it works >> without active support from the sender, which is nice. > > > As I understand it, it requires a domain to enumerate every mailing list > domain in which any of its users participate in its DMARC record. That's > probably doable for a tiny domain like mine, but not for someone like Yahoo. > Agreed -- I am absolutely not suggesting that this solves the mailing list problem. I believe it does solve the bounce-processing ESP problem, and the piggybacking on gmail problem. I also believe it's easier to implement than delegated subdomains or 3d-party DKIM. Regards, Joe Humphreys ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
While I do not think that Yahoo! would have opted for this level of enforcement, I do think the variation in alignment requirement could be interesting, and useful in some cases. What about a scenario where a user would like to - receive DMARC reporting - request DMARC-aware receivers reject email which does not pass base authentication measures (SPF or DKIM), but not apply the next step of alignment enforcement This could still be beneficial in cutting off illegitimate email which does not pass SPF or DKIM at all, but provides the allowance which some domain owners could find a useful middle or even final step in their DMARC deployment. Could it be set up as allowing aspf=n for “align SPF = none” and adkim=n? Could the application be considered when the request is given as “adkim=n;aspf=r”, meaning “DKIM alignment not required; if the DKIM signature passes at all, this is a pass. SPF alignment required in relaxed mode; to pass DMARC-SPF, SPF must pass and be in alignment” -- Tomki -Original Message- From: "J. Trent Adams" Date: Thursday, April 17, 2014 at 11:02 To: Vlatko Salaj , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals > >Vlatko - > >On 4/17/14 11:32 AM, Vlatko Salaj wrote: > >[ snip ] >> so, my domain-email sent from yahoo mail isn't aligned. however, it is >> legitimate, it is DKIM-signed and it has proper SPF. >> >> out of my 15 small-business customers, 12 use exactly this usage >>scenario. >> usually google. and when i said it would be a problem, that was not the >>best >> way, trying to force them to send mail through their own server, they >>didn't >> want to hear it. >> >> and i imagine, it is a pretty common practice in the wild for small >>players. >> > >I see your use case, and why the alignment issue is problematic. > >And you've prompted me to wonder if we need to layer in the concept of >"authorized use" in addition to how we've been talking about technical >email authentication. In this flow, your email is authenticating with >SPF and DKIM, but you're running into an issue where Yahoo no longer >authorizes their domain to be used in that flow. > >To start, we need to agree that a domain owner is permitted to authorize >how it's domain can be used. Then, when a domain owner publishes a DMARC >record, they're announcing to the world that their domain can only be >used to send email in a specific way (i.e. "aligned"). > >It's this concept of authorized use that we may be missing in the >conversation. Heavily abused domain owners have empirical evidence to >prove that alignment is a key factor to blocking spoofed domain abuse. >And they are now in a position to authorize those methods they >determined to be less susceptible to abuse. > >That's not to say that other uses are invalid, just that they fall >outside what the domain owner is authorizing. And, in the use cases >you're suggesting, it sounds like mailbox providers such as Yahoo are >telling the world, "Due to being heavily abused, we are no longer >authorizing the practice of using our domains in that way." > >I'm not sure that gets us closer to a workable solution, but perhaps the >shift in perception helps shake loose some ideas. > >HTH, >Trent > >-- >J. Trent Adams > >Profile: http://www.mediaslate.org/jtrentadams/ >LinkedIN: http://www.linkedin.com/in/jtrentadams >Twitter: http://twitter.com/jtrentadams > >___ >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] alignment and parsing logic as optionals
The ISP rewrites the MAIL FROM to deflect bounces. This passes SPF (IP matches MAIL FROM), and also passes DMARC's aligned SPF (RFC822 From has the original sender domain, which includes the ISP's IP range). Please tell me what I'm missing. A DMARC SPF pass requires that the MAIL FROM domain be the same as the From: header domain, or in less strict mode a subdomain. The subdomain is probably doable, after considerable coordination between the sender and its ESP. The sender publishes MX records for the subdomain that point at the ESP's bounce handler. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
On 4/17/14, 1:03 PM, Joseph Humphreys wrote: The alignment domain-list solution seems trivial to me, and it works without active support from the sender, which is nice. As I understand it, it requires a domain to enumerate every mailing list domain in which any of its users participate in its DMARC record. That's probably doable for a tiny domain like mine, but not for someone like Yahoo. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Thu, Apr 17, 2014 at 2:04 PM, Miles Fidelman wrote: > Not sure who wrote this anymore: >>> >>> At one time I suggested adding a feature to list domains that could >>> be considered "in alignment" with yours. So if a domain owner wanted >>> to authorize an email service provider, they could just add something >>> to their DMARC policy to specify the domain the ESP uses for SPF/MailFrom >>> and/or DKIM signing. I am still curious what's wrong with this proposal. >>> It seems to me to cover Vlatko Salaj's use case, and would certainly be >>> easier to implement than arranging to share a DKIM key. > > > That seems like it would only work if one is designating only one, or a > small number of ESPs. It doesn't seem to address the mailing list case - > Yahoo's subscribers, en masse, belong to a huge number of lists, hosted all > over the place. Which scales about as poorly as SPF (if you do mailing > lists, you end up back at v= +all. > > So we're back to managing whitelists. > I agree that it does not solve the mailing list case. It solves at least two other cases. If someone has a solution that solves all cases, I will gladly forget about this solution. Regards, Joe H ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
Not sure who wrote this anymore: At one time I suggested adding a feature to list domains that could be considered "in alignment" with yours. So if a domain owner wanted to authorize an email service provider, they could just add something to their DMARC policy to specify the domain the ESP uses for SPF/MailFrom and/or DKIM signing. I am still curious what's wrong with this proposal. It seems to me to cover Vlatko Salaj's use case, and would certainly be easier to implement than arranging to share a DKIM key. That seems like it would only work if one is designating only one, or a small number of ESPs. It doesn't seem to address the mailing list case - Yahoo's subscribers, en masse, belong to a huge number of lists, hosted all over the place. Which scales about as poorly as SPF (if you do mailing lists, you end up back at v= +all. So we're back to managing whitelists. -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
Vlatko - On 4/17/14 11:32 AM, Vlatko Salaj wrote: [ snip ] > so, my domain-email sent from yahoo mail isn't aligned. however, it is > legitimate, it is DKIM-signed and it has proper SPF. > > out of my 15 small-business customers, 12 use exactly this usage scenario. > usually google. and when i said it would be a problem, that was not the best > way, trying to force them to send mail through their own server, they didn't > want to hear it. > > and i imagine, it is a pretty common practice in the wild for small players. > I see your use case, and why the alignment issue is problematic. And you've prompted me to wonder if we need to layer in the concept of "authorized use" in addition to how we've been talking about technical email authentication. In this flow, your email is authenticating with SPF and DKIM, but you're running into an issue where Yahoo no longer authorizes their domain to be used in that flow. To start, we need to agree that a domain owner is permitted to authorize how it's domain can be used. Then, when a domain owner publishes a DMARC record, they're announcing to the world that their domain can only be used to send email in a specific way (i.e. "aligned"). It's this concept of authorized use that we may be missing in the conversation. Heavily abused domain owners have empirical evidence to prove that alignment is a key factor to blocking spoofed domain abuse. And they are now in a position to authorize those methods they determined to be less susceptible to abuse. That's not to say that other uses are invalid, just that they fall outside what the domain owner is authorizing. And, in the use cases you're suggesting, it sounds like mailbox providers such as Yahoo are telling the world, "Due to being heavily abused, we are no longer authorizing the practice of using our domains in that way." I'm not sure that gets us closer to a workable solution, but perhaps the shift in perception helps shake loose some ideas. HTH, Trent -- J. Trent Adams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Thursday, April 17, 2014 6:53 PM, John Levine wrote: >> I don't see any scaling problem for the case of a domain used by a single >> entity that wants to authorize a few service providers to send email on >> its behalf. > Is that really a problem? I was under the impression that a sender either > adds the providers' IPs to their SPF record, or gives them a DKIM signing key. wrong: 1. DKIM key sharing requires such a support, which is usually not there. 2. SPF policy check doesn't evaluate ur SPF policy at all, but ur ESP's. On Thursday, April 17, 2014 6:53 PM, John Sweet wrote: >> I am still curious what's wrong with this proposal. > How is this not covered by SPF "include:"? If your message has both MAILFROM > and RFC822 From: aligned on your domain, and the connecting IP is in the > range of the included domain, it's all good. it isn't covered by SPF's "include:". seems not many understand this problem, let me make an example: if i use yahoo email for my goodone.tk domain, yahoo will send my email with yahoo.com DKIM key and with yahoo.com SPF MailFrom [my yahoo account address]. and i can't do anything about it. yahoo doesn't support key-sharing, nor it will. so, my domain-email sent from yahoo mail isn't aligned. however, it is legitimate, it is DKIM-signed and it has proper SPF. out of my 15 small-business customers, 12 use exactly this usage scenario. usually google. and when i said it would be a problem, that was not the best way, trying to force them to send mail through their own server, they didn't want to hear it. and i imagine, it is a pretty common practice in the wild for small players. -- Vlatko Salaj aka goodone http://goodone.tk ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Thu, Apr 17, 2014 at 10:01 AM, Joseph Humphreys < jhumphr...@salesforce.com> wrote: > It's a problem if the service provider wants to offer bounce processing by > using their own domain for the return path, which I think is not uncommon. > That puts SPF out of alignment. > I think the difference is that the sender's domain can include the ISP's ranges in their own SPF record. You can't reasonably do that for every domain of every mailing list your users may post to. The ISP rewrites the MAIL FROM to deflect bounces. This passes SPF (IP matches MAIL FROM), and also passes DMARC's aligned SPF (RFC822 From has the original sender domain, which includes the ISP's IP range). Please tell me what I'm missing. J ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Thu, Apr 17, 2014 at 12:52 PM, John Sweet wrote: > On Thursday, April 17, 2014 5:44 PM, Joseph Humphreys wrote: >> >> At one time I suggested adding a feature to list domains that could be >> considered "in alignment" with yours. So if a domain owner wanted to >> authorize an email service provider, they could just add something to their >> DMARC policy to specify the domain the ESP uses for SPF/MailFrom and/or DKIM >> signing. I am still curious what's wrong with this proposal. > > > How is this not covered by SPF "include:"? > > If your message has both MAILFROM and RFC822 From: aligned on your domain, > and the connecting IP is in the range of the included domain, it's all good. > I just replied to a similar question from John Levine, that I'm trying to support a use case where SPF will not be in alignment: a third-party sender that wants to handle bounces on behalf of the author. Vlatko Salaj also brought up the case of using gmail to send mail with a From header in your own domain. (Gmail seems to use your gmail address as the MAILFROM address.) Just to generalize the point: requiring alignment for the purpose of using SPF to authenticate the From header has the unintended (I think) consequence of restricting the Return-Path to the same domain. An aligned-domain list would not have this consequence. Regards, Joe Humphreys ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Thu, Apr 17, 2014 at 12:49 PM, John Levine wrote: >> > 3. alignment domain-list value to include in alignment check: >> >> >> It doesn't scale as a complete solution for mailing lists. I don't see >> any scaling problem for the case of a domain used by a single entity >> that wants to authorize a few service providers to send email on its >> behalf. > > > Is that really a problem? I was under the impression that a sender > either adds the providers' IPs to their SPF record, or gives them a DKIM > signing key. > > This seems quite different from the mailing list problem, where it's > unlikely that it is practical to track exactly which lists its users > subscribe to. It's a problem if the service provider wants to offer bounce processing by using their own domain for the return path, which I think is not uncommon. That puts SPF out of alignment. Sharing a DKIM key is a solution, but is not trivial. The alignment domain-list solution seems trivial to me, and it works without active support from the sender, which is nice. Regards, Joe Humphreys ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Thursday, April 17, 2014 5:44 PM, Joseph Humphreys wrote: > At one time I suggested adding a feature to list domains that could be > considered "in alignment" with yours. So if a domain owner wanted to > authorize an email service provider, they could just add something to their > DMARC policy to specify the domain the ESP uses for SPF/MailFrom and/or > DKIM signing. I am still curious what's wrong with this proposal. > How is this not covered by SPF "include:"? If your message has both MAILFROM and RFC822 From: aligned on your domain, and the connecting IP is in the range of the included domain, it's all good. J ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
> 3. alignment domain-list value to include in alignment check: It doesn't scale as a complete solution for mailing lists. I don't see any scaling problem for the case of a domain used by a single entity that wants to authorize a few service providers to send email on its behalf. Is that really a problem? I was under the impression that a sender either adds the providers' IPs to their SPF record, or gives them a DKIM signing key. This seems quite different from the mailing list problem, where it's unlikely that it is practical to track exactly which lists its users subscribe to. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Thursday, April 17, 2014 5:44 PM, Joseph Humphreys wrote: > At one time I suggested adding a feature to list domains that could > be considered "in alignment" with yours. So if a domain owner wanted > to authorize an email service provider, they could just add something > to their DMARC policy to specify the domain the ESP uses for SPF/MailFrom > and/or DKIM signing. I am still curious what's wrong with this proposal. > It seems to me to cover Vlatko Salaj's use case, and would certainly be > easier to implement than arranging to share a DKIM key. finally, somebody that sees things from perspective other than a big sender. also, plz notice, working with DKIM 3rd party support is not only pretty messy, but usually not a supported option. so, DMARC badly needs its own solution for this alignment problem. On Thursday, April 17, 2014 5:42 PM, MH Michael Hammer (5304) wrote: > Third party services such as greeting cards are actually a much different > use case than mailing lists. if, and only if, it's built in DMARC-compatible way. and this isn't all that natural or intuitive. it seems DMARC wants to change everything to have it compatible with itself. i can understand how this benefits big players. it's just pity big players don't understand how this doesn't work for small players, aka 90% of the net. >> 2. alignment OFF, in which case domain owner specifies they have no benefit >> from DMARC alignment checks, but do want other checks performed, such >> as AND-logic mechanism evaluation, for example. > If I were evil I could consistently defeat this every day of the week > without much effort. domain owner publishing alignment-OFF policy wants such policy. who cares if anyone can beat it? it's their decision and they r ready to suffer consequences for whatever reason. at least they have an option. maybe they just want to process SPF and DKIM in a standard way, as defined by DMARC. without DMARC "reject" rule, they lose that. >> 3. alignment domain-list value to include in alignment check: list of domains >> the domain owner wants to have included in DMARC alignment check, >> complementing from: header domain > This doesn't scale. it scales the same way it scales for SPF. i see no problem there. also, scaling isn't rly an issue for big ESP. they will just use alignment-ON and force everyone to adapt. just like yahoo did recently. alignment domain-list is of great value to small domains. i'm quite sure this would be one of the most used tags in DMARC policy, if included in spec. >> actually, Sender-ID isn't all that bad at all. it was way ahead of its time. > Microsoft dropped support for Sender-ID in favor of SPF. merely cause it's not widely adopted. not because it's completely broken. > When I sent them crafted emails showing that I could consistently get > a neutral under PRA checking for ANY From domain (abusing the sender field) > they agreed that this was a problem. neutral result isn't a pass, under current DMARC evaluation rules. so, it's not the same situation as with plain Sender-ID check. > Could you identify any specific instances where public-suffix has been > a significant (or non-significant) problem in the wild? yes, i can. almost any new free domain service will have issues with this, until such public-suffix picks it up... which is yet another nightmare of infrastructure support. as i said, we r opening a can of worms here, especially where ICANN is moving with top-lvl domains. i saw it happening with Symantec's SafeWeb as well as all other URL checking services developed in recent years. it's a mess and needs high maintenance. -- Vlatko Salaj aka goodone http://goodone.tk ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Thu, Apr 17, 2014 at 11:41 AM, MH Michael Hammer (5304) wrote: > > > 3. alignment domain-list value to include in alignment check: list of > domains > > the domain owner wants to have included in DMARC alignment check, > > complementing > > from: header domain; this will cover almost all cases DMARC breaks now, > > such as 3rd party infrastructure, mailing lists that do not wish to make > > changes for DMARC-compatibility, forwarders that process their mail, but > > can't be controlled by domain owner, etc. it's somewhat similar to SPF > > domain definition, but different, since it affects DMARC-alignment > process. > > > > This doesn't scale. How many domains would a large mailbox provider have > to include in the list to account for all domains subscribed to by their > users? How short would the TTL have to be in order to work for newly > subscribed to domains? Where would this list live? The DNS folks would > freak even if the list weren't too long to be put in a DNS record. > > It doesn't scale as a complete solution for mailing lists. I don't see any scaling problem for the case of a domain used by a single entity that wants to authorize a few service providers to send email on its behalf. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
> -Original Message- > From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Vlatko Salaj > Sent: Thursday, April 17, 2014 10:51 AM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals > > On Thursday, April 17, 2014 8:22 AM, Murray S. Kucherawy wrote: > > > For the "and" case, yes, that's possible to add if there's enough > > demand to add it. So far the people that have tried this are satisfied > > with the "or" logic. > > making DMARC strictly based on OR-logic will get it obsolete as soon as > someone finds a way to exploit any of the underlying mechanism, and that's > already possible, either through DKIM replay attack, or through spoofed SPF > authentication, whichever serves an attacker better. > There isn't much that someone can do with a DKIM replay attack in a DMARC context because the entire body and key headers are signed. For spoofed SPF authentication, the answer is DNSSEC. If DNSSEC is broken/exploited then the community will have larger issues than DMARC. > and if DMARC gets expanded by any additional mechanism, it will just make it > weaker, with OR-dependency. This may or may not be true. It depends on the specific additional mechanism. > > > > "I do not want alignment" is exactly the same as "I don't use DMARC" > > since DMARC is pretty much all about alignment. So, again, I don't > > understand why that's a useful thing to add. > > it's not the same. DMARC is not just authentication, it's also about reporting > and conformance. i would be perfectly happy to get my email checked > against SPF and DKIM and processed in a standard-defined way, and receive > reports on which i can then act. otherwise, DMARC has no benefits for me at > all. > Then just publish p=none. You get your email checked and you get your reports. The discussion is about those domain owners that are seeking a higher level of protection. > > >> and it's a common practice, absolutely. whether it's formal or informal. > > What's an example? > > i've already written about it. someone using yahoo or google email service to > send their own domain email. i actually do that. and i imagine, a great deal > of > ppl. > > it also covers various 3rd party services, such as ones that deliver greeting > cards, process petitions... > Don't drag greeting cards into this fight. We've sent billions of greeting card notifications on behalf of our customers in a DMARC conformant way (and as I've pointed out, even before DMARC was a gleam in anyone's eye) without any problems whatsoever. Other greeting card companies have followed our lead in publishing SPF and DKIM signing but I'm not in a position to comment on their specific implementations and configurations. Third party services such as greeting cards are actually a much different use case than mailing lists. > > >> as i said: combined, alignment OFF and AND processing logic would > >> work great in cases where alignment isn't possible, yet email is fully > legitimate. > > For the "off" case, isn't that just the same as "p=none"? > > it isn't. if we accept the idea about making alignment optional, i would > gladly > expand the idea to more than just turning alignment on/off. > > > actually, such alignment field would, in my proposal, include a three-state: > > 1. alignment ON, in which case from: header gets checked against. > > 2. alignment OFF, in which case domain owner specifies they have no benefit > from DMARC alignment checks, but do want other checks performed, such > as AND-logic mechanism evaluation, for example. > If I were evil I could consistently defeat this every day of the weak without much effort. This was the same problem with PRA and the use of Sender. When I first pointed this out to Microsoft (this is not intended to pick on them) back in the 2006 timeframe, they told me it was my implementation that was the problem. When I sent them crafted emails showing that I could consistently get a neutral under PRA checking for ANY From domain (abusing the sender field) they agreed that this was a problem. > 3. alignment domain-list value to include in alignment check: list of domains > the domain owner wants to have included in DMARC alignment check, > complementing > from: header domain; this will cover almost all cases DMARC breaks now, > such as 3rd party infrastructure, mailing lists that do not wish to make > changes for DMARC-compatibility, forwarders that process their mail, but > can't be controlled by domain owner, etc. it's somewhat similar to SPF &g
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Thursday, April 17, 2014 8:22 AM, Murray S. Kucherawy wrote: > For the "and" case, yes, that's possible to add if there's enough demand > to add it. So far the people that have tried this are satisfied with the > "or" logic. making DMARC strictly based on OR-logic will get it obsolete as soon as someone finds a way to exploit any of the underlying mechanism, and that's already possible, either through DKIM replay attack, or through spoofed SPF authentication, whichever serves an attacker better. and if DMARC gets expanded by any additional mechanism, it will just make it weaker, with OR-dependency. > "I do not want alignment" is exactly the same as "I don't use DMARC" > since DMARC is pretty much all about alignment. So, again, I don't > understand why that's a useful thing to add. it's not the same. DMARC is not just authentication, it's also about reporting and conformance. i would be perfectly happy to get my email checked against SPF and DKIM and processed in a standard-defined way, and receive reports on which i can then act. otherwise, DMARC has no benefits for me at all. >> and it's a common practice, absolutely. whether it's formal or informal. > What's an example? i've already written about it. someone using yahoo or google email service to send their own domain email. i actually do that. and i imagine, a great deal of ppl. it also covers various 3rd party services, such as ones that deliver greeting cards, process petitions... >> as i said: combined, alignment OFF and AND processing logic would work great >> in cases where alignment isn't possible, yet email is fully legitimate. > For the "off" case, isn't that just the same as "p=none"? it isn't. if we accept the idea about making alignment optional, i would gladly expand the idea to more than just turning alignment on/off. actually, such alignment field would, in my proposal, include a three-state: 1. alignment ON, in which case from: header gets checked against. 2. alignment OFF, in which case domain owner specifies they have no benefit from DMARC alignment checks, but do want other checks performed, such as AND-logic mechanism evaluation, for example. 3. alignment domain-list value to include in alignment check: list of domains the domain owner wants to have included in DMARC alignment check, complementing from: header domain; this will cover almost all cases DMARC breaks now, such as 3rd party infrastructure, mailing lists that do not wish to make changes for DMARC-compatibility, forwarders that process their mail, but can't be controlled by domain owner, etc. it's somewhat similar to SPF domain definition, but different, since it affects DMARC-alignment process. > That probably means the benefit of adding SRS support wasn't obvious to > the people responding. This may be obvious to you, but it's apparently > not obvious to others. SRS has benefits. but not for big ESPs, mainly cause of infrastructure requirements. so, i'm done with advocating for that, cause it won't get supported by the most influential actors here, that's obvious. >> include sender-id as another DMARC supported check algorithm. >> yeah, i better not start this topic... we don't want another MARID. > I totally agree there, especially since Sender-ID got almost no adoption > (see RFC 6686), and that seems unlikely to change now. it would change quite fast if we would make it part of DMARC. actually, Sender-ID isn't all that bad at all. it was way ahead of its time. PRA could actually be a better way to determine owner's domain for alignment purposes than some undefined public-suffix list, especially in the light of newest moves by ICANN, introducing bunch of new top-lvl domains, which will probably host a bunch of sub-domains with registration capabilities by 3rd parties, etc. DMARC's dependance on a concept of "public-suffix list" is a can of worms i can't wait to see what will make of DMARC's usability at the end. it will be a mess for sure. i'm not rly sure how this isn't obvious to DMARC's authors, given all that experience in the domain. On Thursday, April 17, 2014 1:42 PM, "Popowycz, Alex" wrote: > Perhaps I'm missing something, but eliminating alignment essentially > nullifies the authentication value for a given domain. which, in some cases, has no value at all. as i mentioned up, alignment-OFF works well only with other options i'm proposing, and only in special cases. -- Vlatko Salaj aka goodone http://goodone.tk ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
At one time I suggested adding a feature to list domains that could be considered "in alignment" with yours. So if a domain owner wanted to authorize an email service provider, they could just add something to their DMARC policy to specify the domain the ESP uses for SPF/MailFrom and/or DKIM signing. I am still curious what's wrong with this proposal. It seems to me to cover Vlatko Salaj's use case, and would certainly be easier to implement than arranging to share a DKIM key. Regards, Joe Humphreys On Thu, Apr 17, 2014 at 7:42 AM, Popowycz, Alex wrote: > Perhaps I'm missing something, but eliminating alignment essentially > nullifies the authentication value for a given domain. If, for example, I > disable alignment then I'm essentially saying that anyone can > hijack/spoof/misappropriate my domain as long as they have a validspf > record for the sending mta or DKIM sign their message. > > Example. My domain is legitimatemail.com. I have a DMARC record that has > set alignment to OFF. > Someone, either known to me out not, now sends using the FROM address of > legitimatemail.com but signs with d=badmail.com. It seems with the > proposal below that would "pass" DMARC processing and be delivered (or at > least not get rejected due to DMARC). I guess I fail to see how this works > towards reducing/eliminating fraudulent email. > > -Original Message- > *From: *Vlatko Salaj [vlatko.sa...@goodone.tk] > *Sent: *Thursday, April 17, 2014 01:50 AM Eastern Standard Time > *To: *dmarc@ietf.org > *Subject: *Re: [dmarc-ietf] alignment and parsing logic as optionals > > On Wednesday, April 16, 2014 11:39 PM, Murray S. Kucherawy wrote: > > > > I wouldn't take the lack of answers terribly personally. > > i rly don't. i just found it rly lolable how everybody is whining about > ietf's purpose here, while list's main aim is about technical contributions > to the dmarc standard, which of, i saw none. > > > >> include an option in dmarc dns policy, so that domain owners could turn > >> dmarc alignment check on/off. > > One way of viewing DMARC is that it seeks to allow a domain owner to have > > better control of how its domain is used, so I don't know what this would > > accomplish. If alignment is optional, what does DMARC do policy-wise that > > DKIM and SPF don't already do? > > let me ask u: how exactly r u allowing a domain owner to have better > control > of how its domain is used, when u do not allow it to say: i do not want > alignment? i imagine, domain owners may actually prefer to send their email > through 3rd party infrastructure. DMARC has no provisions for such > practice. > > and it's a common practice, absolutely. whether it's formal or informal. > > > >> include an option in dmarc dns policy, so that domain owners could turn > >> dmarc processing logic either to OR or AND. > > That might be useful, but isn't that more restrictive, and not less > > restrictive? > > as i said: combined, alignment OFF and AND processing logic would work > great > in cases where alignment isn't possible, yet email is fully legitimate. > and in such case, considering alignment requirement is gone, it's actually > less restrictive, while still providing better authentication. and blah > blah, > u can see the benefit, i'm sure. > > also, it should be strict AND, meaning, all dmarc mechanism must exist and > pass, for DMARC to pass, making such DMARC evaluation almost as reliable as > alignment-based one, if not more, while still encompassing much wider > range of > email usage cases, in situation where it works better than alignment-based > one. > > also, there may be other algorithms in the future which will become part of > DMARC. allowing domain owners to have control of how these get evaluated is > a right thing to do. my proposal is even stronger if u consider that some > of > these algorithms may get exploited in the future, which would completely > annihilate OR-based DMARC, with no remedy. having AND-based option would > fix > that in advance. > > > > How would it help your use case, for example? > > it would do wonders for me. my personal email stream would pass DMARC. > > DMARC policy "reject", alignment OFF, logic AND, reporting ON and "fo=d:s" > would actually fix many of customer domains that i service, which use > google > or yahoo mail for their domain-based email. considering both google and > yahoo > use DKIM and SPF, those emails would pass such DMARC, even thought they are > being sent through 3rd party services. and if DKIM and SPF get supported by > other services, it
Re: [dmarc-ietf] alignment and parsing logic as optionals
Perhaps I'm missing something, but eliminating alignment essentially nullifies the authentication value for a given domain. If, for example, I disable alignment then I'm essentially saying that anyone can hijack/spoof/misappropriate my domain as long as they have a validspf record for the sending mta or DKIM sign their message. Example. My domain is legitimatemail.com. I have a DMARC record that has set alignment to OFF. Someone, either known to me out not, now sends using the FROM address of legitimatemail.com but signs with d=badmail.com. It seems with the proposal below that would "pass" DMARC processing and be delivered (or at least not get rejected due to DMARC). I guess I fail to see how this works towards reducing/eliminating fraudulent email. -Original Message- From: Vlatko Salaj [vlatko.sa...@goodone.tk<mailto:vlatko.sa...@goodone.tk>] Sent: Thursday, April 17, 2014 01:50 AM Eastern Standard Time To: dmarc@ietf.org Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals On Wednesday, April 16, 2014 11:39 PM, Murray S. Kucherawy wrote: > I wouldn't take the lack of answers terribly personally. i rly don't. i just found it rly lolable how everybody is whining about ietf's purpose here, while list's main aim is about technical contributions to the dmarc standard, which of, i saw none. >> include an option in dmarc dns policy, so that domain owners could turn >> dmarc alignment check on/off. > One way of viewing DMARC is that it seeks to allow a domain owner to have > better control of how its domain is used, so I don't know what this would > accomplish. If alignment is optional, what does DMARC do policy-wise that > DKIM and SPF don't already do? let me ask u: how exactly r u allowing a domain owner to have better control of how its domain is used, when u do not allow it to say: i do not want alignment? i imagine, domain owners may actually prefer to send their email through 3rd party infrastructure. DMARC has no provisions for such practice. and it's a common practice, absolutely. whether it's formal or informal. >> include an option in dmarc dns policy, so that domain owners could turn >> dmarc processing logic either to OR or AND. > That might be useful, but isn't that more restrictive, and not less > restrictive? as i said: combined, alignment OFF and AND processing logic would work great in cases where alignment isn't possible, yet email is fully legitimate. and in such case, considering alignment requirement is gone, it's actually less restrictive, while still providing better authentication. and blah blah, u can see the benefit, i'm sure. also, it should be strict AND, meaning, all dmarc mechanism must exist and pass, for DMARC to pass, making such DMARC evaluation almost as reliable as alignment-based one, if not more, while still encompassing much wider range of email usage cases, in situation where it works better than alignment-based one. also, there may be other algorithms in the future which will become part of DMARC. allowing domain owners to have control of how these get evaluated is a right thing to do. my proposal is even stronger if u consider that some of these algorithms may get exploited in the future, which would completely annihilate OR-based DMARC, with no remedy. having AND-based option would fix that in advance. > How would it help your use case, for example? it would do wonders for me. my personal email stream would pass DMARC. DMARC policy "reject", alignment OFF, logic AND, reporting ON and "fo=d:s" would actually fix many of customer domains that i service, which use google or yahoo mail for their domain-based email. considering both google and yahoo use DKIM and SPF, those emails would pass such DMARC, even thought they are being sent through 3rd party services. and if DKIM and SPF get supported by other services, it would cover them too. also, making alignment and logic selectable, would not make additional pressure on big ESPs infrastructure, but it would cover much of failure cases current version has. it may even be worthwhile for big ESPs to use this type of DMARC policy: "reject", alignment OFF, logic AND, reporting ON. it would surely make reports they receive much more informative too, helping with data mining on other domain practices, which could be used in anti-spam etc. and any potential abuse would simply be dealt with by switching to alignment ON policy, when it's required for a particular domain. >> i already mentioned including SRS in check logic. unfortunately, no dmarc >> author rly added much to the topic > I seem to remember there was in fact discussion of your SRS advocacy. none rly taking the discussion to next lvl, but merely acknowledging i mentioned SRS, and dismissing it without much ado. also, i have anothe
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Wed, Apr 16, 2014 at 10:50 PM, Vlatko Salaj wrote: > > One way of viewing DMARC is that it seeks to allow a domain owner to have > > better control of how its domain is used, so I don't know what this would > > accomplish. If alignment is optional, what does DMARC do policy-wise that > > DKIM and SPF don't already do? > > let me ask u: how exactly r u allowing a domain owner to have better > control > of how its domain is used, when u do not allow it to say: i do not want > alignment? i imagine, domain owners may actually prefer to send their email > through 3rd party infrastructure. DMARC has no provisions for such > practice. > "I do not want alignment" is exactly the same as "I don't use DMARC" since DMARC is pretty much all about alignment. So, again, I don't understand why that's a useful thing to add. > and it's a common practice, absolutely. whether it's formal or informal. > What's an example? >> include an option in dmarc dns policy, so that domain owners could turn > >> dmarc processing logic either to OR or AND. > > That might be useful, but isn't that more restrictive, and not less > > restrictive? > > as i said: combined, alignment OFF and AND processing logic would work > great > in cases where alignment isn't possible, yet email is fully legitimate. > and in such case, considering alignment requirement is gone, it's actually > less restrictive, while still providing better authentication. and blah > blah, > u can see the benefit, i'm sure. > For the "off" case, isn't that just the same as "p=none"? For the "and" case, yes, that's possible to add if there's enough demand to add it. So far the people that have tried this are satisfied with the "or" logic. What do others think? > also, it should be strict AND, meaning, all dmarc mechanism must exist and > pass, for DMARC to pass, making such DMARC evaluation almost as reliable as > alignment-based one, if not more, while still encompassing much wider > range of > email usage cases, in situation where it works better than alignment-based > one. > Sure, if that's what the community wants to do. This is the first time I've heard anyone say this would be a useful thing to support. If anyone else agrees that it's needed, DMARC can easily be extended to include this capability. It's built that way. > also, there may be other algorithms in the future which will become part of > DMARC. allowing domain owners to have control of how these get evaluated is > a right thing to do. my proposal is even stronger if u consider that some > of > these algorithms may get exploited in the future, which would completely > annihilate OR-based DMARC, with no remedy. having AND-based option would > fix > that in advance. > Yes, that extensibility is already built into DMARC. > > How would it help your use case, for example? > > it would do wonders for me. my personal email stream would pass DMARC. > By turning off alignment, I bet it would. > DMARC policy "reject", alignment OFF, logic AND, reporting ON and "fo=d:s" > would actually fix many of customer domains that i service, which use > google > or yahoo mail for their domain-based email. considering both google and > yahoo > use DKIM and SPF, those emails would pass such DMARC, even thought they are > being sent through 3rd party services. and if DKIM and SPF get supported by > other services, it would cover them too. > What would that look like, exactly? From: your domain, a passing DKIM signature for a domain other than yours, a passing SPF test for a domain other than yours? If that's what you mean, then I can make any message I want that passes DMARC for your domain by sending it from my own box and signing it. Are you sure you want that? If that's not what you mean, then you'll have to build an example, because I don't get it. > also, making alignment and logic selectable, would not make additional > pressure on big ESPs infrastructure, but it would cover much of failure > cases current version has. > Actually I think if you advertise something that is substantially weaker than what DMARC has now, I suspect ESPs will be less likely to trust your stream because it's basically unprotected. none rly taking the discussion to next lvl, but merely acknowledging i > mentioned SRS, and dismissing it without much ado. > That probably means the benefit of adding SRS support wasn't obvious to the people responding. This may be obvious to you, but it's apparently not obvious to others. also, i have another suggestion: > include sender-id as another DMARC supported check algorithm. > > sender-id is different enough from SPF to cover many usage scenarios, > and would just add to dmarc strengths. i don't rly understand why ppl take > sender-id for 2nd generation SPF, since it isn't. > > yeah, i better not start this topic... we don't want another MARID. > I totally agree there, especially since Sender-ID got almost no adoption (see RFC 6686), and that seems unlikely to change now. -MS
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Wednesday, April 16, 2014 11:39 PM, Murray S. Kucherawy wrote: > I wouldn't take the lack of answers terribly personally. i rly don't. i just found it rly lolable how everybody is whining about ietf's purpose here, while list's main aim is about technical contributions to the dmarc standard, which of, i saw none. >> include an option in dmarc dns policy, so that domain owners could turn >> dmarc alignment check on/off. > One way of viewing DMARC is that it seeks to allow a domain owner to have > better control of how its domain is used, so I don't know what this would > accomplish. If alignment is optional, what does DMARC do policy-wise that > DKIM and SPF don't already do? let me ask u: how exactly r u allowing a domain owner to have better control of how its domain is used, when u do not allow it to say: i do not want alignment? i imagine, domain owners may actually prefer to send their email through 3rd party infrastructure. DMARC has no provisions for such practice. and it's a common practice, absolutely. whether it's formal or informal. >> include an option in dmarc dns policy, so that domain owners could turn >> dmarc processing logic either to OR or AND. > That might be useful, but isn't that more restrictive, and not less > restrictive? as i said: combined, alignment OFF and AND processing logic would work great in cases where alignment isn't possible, yet email is fully legitimate. and in such case, considering alignment requirement is gone, it's actually less restrictive, while still providing better authentication. and blah blah, u can see the benefit, i'm sure. also, it should be strict AND, meaning, all dmarc mechanism must exist and pass, for DMARC to pass, making such DMARC evaluation almost as reliable as alignment-based one, if not more, while still encompassing much wider range of email usage cases, in situation where it works better than alignment-based one. also, there may be other algorithms in the future which will become part of DMARC. allowing domain owners to have control of how these get evaluated is a right thing to do. my proposal is even stronger if u consider that some of these algorithms may get exploited in the future, which would completely annihilate OR-based DMARC, with no remedy. having AND-based option would fix that in advance. > How would it help your use case, for example? it would do wonders for me. my personal email stream would pass DMARC. DMARC policy "reject", alignment OFF, logic AND, reporting ON and "fo=d:s" would actually fix many of customer domains that i service, which use google or yahoo mail for their domain-based email. considering both google and yahoo use DKIM and SPF, those emails would pass such DMARC, even thought they are being sent through 3rd party services. and if DKIM and SPF get supported by other services, it would cover them too. also, making alignment and logic selectable, would not make additional pressure on big ESPs infrastructure, but it would cover much of failure cases current version has. it may even be worthwhile for big ESPs to use this type of DMARC policy: "reject", alignment OFF, logic AND, reporting ON. it would surely make reports they receive much more informative too, helping with data mining on other domain practices, which could be used in anti-spam etc. and any potential abuse would simply be dealt with by switching to alignment ON policy, when it's required for a particular domain. >> i already mentioned including SRS in check logic. unfortunately, no dmarc >> author rly added much to the topic > I seem to remember there was in fact discussion of your SRS advocacy. none rly taking the discussion to next lvl, but merely acknowledging i mentioned SRS, and dismissing it without much ado. also, i have another suggestion: include sender-id as another DMARC supported check algorithm. sender-id is different enough from SPF to cover many usage scenarios, and would just add to dmarc strengths. i don't rly understand why ppl take sender-id for 2nd generation SPF, since it isn't. yeah, i better not start this topic... we don't want another MARID. -- Vlatko Salaj aka goodone http://goodone.tk ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Wednesday, April 16, 2014 7:44 PM, MH Michael Hammer (5304) wrote: > I haven't seen any other post from you with this subject line. http://www.ietf.org/mail-archive/web/dmarc/current/msg00749.html -- Vlatko Salaj aka goodone http://goodone.tk ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
