Re: [dmarc-ietf] alignment and parsing logic as optionals
On Fri, Apr 18, 2014 at 2:00 PM, Franck Martin fra...@peachymango.org 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 Monday, April 21, 2014 9:01 PM, dmarc-requ...@ietf.org 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
On Thu, Apr 17, 2014 at 1:42 PM, Vlatko Salaj vlatko.sa...@goodone.tkwrote: 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 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 Friday, April 18, 2014 10:44 AM, Murray S. Kucherawy superu...@gmail.com 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 Friday, April 18, 2014 10:44 AM, Murray S. Kucherawy superu...@gmail.com 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 r telling me u don't want
Re: [dmarc-ietf] alignment and parsing logic as optionals
On Fri, Apr 18, 2014 at 4:50 AM, Murray S. Kucherawy superu...@gmail.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. 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
- Original Message - From: Joseph Humphreys jhumphr...@salesforce.com 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 superu...@gmail.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. 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, 18 Apr 2014 13:04:08 -0400, Joseph Humphreys jhumphreys at salesforce.com 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
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.tkmailto: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 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
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 alex.popow...@fmr.comwrote: 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 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
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
On Thu, Apr 17, 2014 at 12:52 PM, John Sweet sw...@secondlook.com 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 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 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 3:04 PM, John Levine jo...@taugh.com 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
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 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
