Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
Dear J. Gomez, Oops. Multi-tasking too much between conversations it seems. This is what was intended in the last paragraph. The basic goal is to devise a means to establish informal federations of domains with a goal of not altering messages. With this goal, it can therefore be assumed to protect the underlying identities. Once a message is re-written by a third-party with an unknown relationship, nothing can be trusted. Very soon, domains will be the only practical means to follow chains of trust. Domains that are making use of DMARC are receiving valuable feedback that should help avoid any need to ask users about which services they are using, especially those reported as not passing an alignment test. Before throwing the switch to p=reject, the provider should make their best effort to ensure no legitimate email is lost and that no message is modified just to suit a non-compliant DMARC scheme. A fully transparent informal federation scheme will provide this feature by making use of TPA-Labels. Regards, Douglas Otis___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
On Jun 4, 2014, at 3:07 PM, J. Gomez wrote: > On Wednesday, June 04, 2014 10:56 PM [GMT+1=CET], Douglas Otis wrote: > >> On Jun 4, 2014, at 12:16 PM, J. Gomez wrote: >> >>> On Wednesday, June 04, 2014 12:14 AM [GMT+1=CET], Hector Santos >>> wrote: >>> I prefer to update my software with the above script for our MTA receiver rather to add logic to rewrite the 5322.From to bypass a security protocol >>> >>> Rewriting the Header-From field in mailing list traffic is not >>> "bypassing a security protocol", because the rewritten Header-From >>> itself still is subject to the security protocol (in this case, >>> DMARC checking) at the Receiver's side, so the security protocol in >>> question is not bypassed. >> >> Customers seeing From headers changed will not have a practical means >> to understand who sent the message. Of course, this assumes who >> initiated content in an exchange is a critical aspect of any security >> related goal. For mailing-lists, this understanding is critical to >> being able to review conversations as well. > > If the rewritten Header-From references the remote author Name in its > description and carries the mailing list Mailbox address (i.e., the immediate > author who invalidated the remote author's DKIM signature) in the > Header-From, I posit customers will have a practical means to understand who > sent the message through said mailing list. In fact, many MUAs only display > de Header-From description/name and not the Header-From mailbox address to > the user, so even less confusion would be possible in those cases. > > Plus, a mailing list is an opt-in device. If the user chooses to be part of > it, he accepts the mailing list terms of service, and if those terms involve > rewriting Header-From in a DMARC-interoperable way, then that's what it is. > The user is free to not use the mailing list service operated thusly if he > objects to such a practice. What tools will recipients have for relating a plethora of re-writing techniques to then review both current and prior conversations? In addition, this may take once secure messages that may have had alignment with the Sender header field and damage a DKIM signature which MUST include the From header field. Once the From header field is "rewritten" to comply with a "non-compliant DMARC scheme" unable to accommodate perfectly legitimate RFC conforming messages, the receiver and recipient alike are left guessing. IMHO, re-writing schemes to not represent practical solutions, just very poorly considered bandaids. >> If it is critical, have the TPA-Label require the OAR be checked. >> This can be quickly added if that is the hold-up > > I, as a domain owner, do not want to go chasing my users around demanding > them to declare to me what mailing lists they subscribe to, in order to > publish them as whitelists/exceptions for my domain as a Sender. What if I > have a user subscribed to a transgender/whatever mailing list? Do I want to > know? Does he want to tell me? I as a domain owner either trust my user, or > fire my user, but I don't want to have to preemptively monitor my user not do > I want him to disclose to me the minutiae of his email usage. If TPA-label > involves this, I see no future in it.[*] As a domain owner, you would be doing your users a valuable service by making an effort to exclude rogue sources while avoiding what should be clearly evident normal use. If you feel this opens the door too wide, a ORA condition in TPA-Label can be added for when such problems occurs. One might assume there is a desire to ensure delivery of 100% legitimate AND desired messages and not NOT alter messages. > [*] But it may well be that TPA-label works in a completely different way, I > tried to read the draft but I could not understand much of it (therefore my > Klingon joke, for which I apologize to you). I have made a few changes to the draft hoping to make it easier to understand. If you read it again and still have trouble, please indicate where and I'll make another pass. The basic goal is to devise a means to establish information federations of domains with the goal of not altering messages. With this goas and therefore can be assumed to protect the underlying identities. Once a message is re-written by an unknown third-party, nothing can be trusted. Very soon, domains will be the only practical means to follow chains of trust. Domains that are making use of DMARC are receiving valuable feedback that should help avoid any need to ask users about which services they are using, especially those reported as not passing an alignment test. Before throwing the switch to p=reject, the provider should make their best effort to ensure no legitimate email is lost and that no message is modified just to suit a non-compliant DMARC scheme. A fully transparent informal federation scheme will provide fCall this the emailmen's credo. :^) Regar
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
On Wed, Jun 4, 2014 at 10:43 AM, Stephen J. Turnbull wrote: > Nor does DMARC say it's nonconforming; in fact, it automatically > passes identity alignment, because there's nobody who is allowed to > create domains under .invalid, so there can be no _dmarc.x.y.invalid. > Actually, it does not and can not pass alignment. The alignment status is undefined which is neither a pass nor a fail. --Kurt Andersen ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
John Levine writes: > From what I can see on the mailman lists, looking for the internal > DKIM signatures won't work too well, since mailman sometimes > removes parts from multipart/alternative to fix to some formatting > issue. Mailman implements certain MIME structure manipulations as a per-list policy setting. Specifically, as a simple antivirus and resource conservation measure, disallowed MIME types are removed. I think this is a deal-breaker for DKIM signatures, as MTAs aren't supposed to break into MIME structure, and I don't think most sites want their users doing signatures in the MUA. But there is exactly one case where Mailman tries to fix up content for formatting: at the list owner's option, if the only text part is text/html, an external utility (usually lynx) may be used to convert it to atext/plain. There are third party patches that actually try to manipulate formatted text. A typical example is one to allow the footer to be added *inside* the BODY element of a text/html part. But AFAIK none have made into the mainline. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
Franck Martin writes: > Anyhow... my point is that moving an human decision to the machine > is difficult, this is why we rely on protocols Sure. That's why the U.S. military relies on landmines, too. "Smart bombs" aren't perfect, obviously, but they're better than landmines! DMARC "p=reject" isn't life-threatening when used by Yahoo!, of course, but it has collateral damage in the same way. And also in the same way, eventually you get to a point where the filtering decisions need to be made by a human. Unconditional reliance on protocols is irresponsible. > principle in the malformed emails RFC. John said (maybe?): if the > protocol is vague, be lenient, but if the protocol is clear then be > strict. He did not say "accept anything, the user will sort it out" Indeed he did not say "accept anything". But no, he did not refer to the clarity of the protocol. He said (paraphrased), if you're producing output according to a protocol, conform strictly (implying: even if it's stupid). If you're accepting input according to a protocol, use your judgment (implying: give the end user what they want). I think Google's treatment of DMARC "p=reject" is in exemplary conformance to Postel's principle. In some cases (often indicated by an obs- production in ABNF), we even explicitly specify a certain degree of leniency as SHOULD. But that's not always possible; often it must be left up to implementations. > From the discussion I have this question: How an MTA knows the > email is from a mailing list? Because List-Post and/or List-Id is signed with a known key. > Also looking at bayesian implementations in say spamassassin/amavis > (I looked quickly) it does not seem the bayesian rules are > organised around authentication identifiers. No, because the rules labeled "Bayesian" are only part of the system. However, stuff like SPF and DKIM have add-on modules to generate auth results and assign them to variables, and then you can create rules which assign spam points according to the values of those variables, and thus take advantage of those facilities. Strictly speaking not an application of Bayes rule, but a sort of hybrid classifier. > the From for that? May be, may be not It seems going forward, > there should be different baeysian learning, depending on the > authenticated domain attached to the email. I don't think we are > fully there yet. We never will be "there". But I have to wonder if our time might not be better used in building a better Bayes rather than trying to repair the DMARC protocol (which for some use cases just ain't broke). > For instance, the simplified rule should be if this is an email > looking like made only by X, but not authenticated by X, junk > it. I'm not sure there is any rule like this out there for lot of > MTAs. Of course there is. I've never used it, but SpamAssassin has had an SPF verifier for something like 10 years. You can add a rule that says if SPF fails, give it 100 spam points, and that will cause it to be junked. > So to close this long tirade, I think we are moving towards a > domain authenticated world of emails, using valid domains as > identifiers of source. If you mean using valid domains with valid signatures as the *only* identifier, "I don't think I want to be part of that 'we'." I think a lot of your feeling about this is that (1) you just don't trust classifiers (and yes, there are plenty of real examples where they've been fooled badly), and so (2) you're really not up on the classifier technology. > And yes, MUA have their role to play, in filtering according to > user preferences, but the tendency, is for the MUA to pass the user > preferences to the MTA, so it can work on received emails even when > the MUA is not connected. I don't want my mobile to do the > filtering, but tell the MTA what emails I like/don't like. I don't blame you. I don't know any decent mobile MUAs. But consider the GMail app. The MUA may actually be integrated with the MTA (any Google Mail devs want to comment), I don't know, but in principle GMail is an MTA. The "advanced" version of the MTA part of GMail is a *distributed system*: much of it is implemented in Javascript in your browser, but the filter rules and so on are implemented in the Google cloud. I don't see any reason not to implement filtering in the mobile MUA when mobile MUAs are actually such distributed systems. Regards, ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
J. Gomez writes: > On Wednesday, June 04, 2014 9:34 PM [GMT+1=CET], John R Levine wrote: > > > Obfuscating the domain is quite suspicious because then, what > > > entity is taking responsibility for that email? What abuse > > > help-desk can the potential receiver recourse to? > > > > The one whose DKIM signature is on the mail, of course. Sigh. > > But DKIM signatures are not mandatory, not even to be able to get a > pass in DMARC checking. If there's no DKIM signature, John's rule doesn't apply, and you fall back to whatever your rule for unsigned mail is. Seriously, you guys have to give up on the idea that the whole world will follow arbitrarily strict protocols just because it makes spam fighting simpler. If a big ESP tries to impose them on receipt, and the users don't receive their mail, the users will vote with their feet and the ESP will cave. Conversely, if you try to impose them and a big ESP finds them inconvenient, the ESP will disobey (just as AOL and Yahoo! have done, implicitly, with "p=reject"). The best you can do is use protocols to gather information about the messages you receive, and use that information appropriately (for example, discounting the presence of a DKIM signature from a domain you have independent reason to believe is hacked and under the control of the Black Hats). So, if there is a valid DKIM signature, then you know who to complain to. Don't you? What's the problem? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
>I'm beginning to lean towards liking the "embedded message" solution that >mailman has, though. In my testing, it works mostly fine in Gmail, though >it assumes (and prefixes with) "forwarded message". YMail's handling isn't >that pretty, however, as it ignores the headers of the embedded message >completely. I meant to ask, what's your spear phish strategy here? Do you expect to see a valid DKIM signature on the internal message? Or do you just treat it as a digest and not look inside the wrapper? Or something else? >From what I can see on the mailman lists, looking for the internal DKIM signatures won't work too well, since mailman sometimes removes parts from multipart/alternative to fix to some formatting issue. Yahoo's mail is apparently particularly likely to need this. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
>I'm beginning to lean towards liking the "embedded message" solution that >mailman has, though. In my testing, it works mostly fine in Gmail, though >it assumes (and prefixes with) "forwarded message". YMail's handling isn't >that pretty, however, as it ignores the headers of the embedded message >completely. It gets delivered fine, but it's basically a MIME digest, and most MUAs don't handle them very nicely. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
On Wednesday, June 04, 2014 10:56 PM [GMT+1=CET], Douglas Otis wrote: > On Jun 4, 2014, at 12:16 PM, J. Gomez wrote: > > > On Wednesday, June 04, 2014 12:14 AM [GMT+1=CET], Hector Santos > > wrote: > > > > > I prefer to update my software with the above script for our MTA > > > receiver rather to add logic to rewrite the 5322.From to bypass a > > > security protocol > > > > Rewriting the Header-From field in mailing list traffic is not > > "bypassing a security protocol", because the rewritten Header-From > > itself still is subject to the security protocol (in this case, > > DMARC checking) at the Receiver's side, so the security protocol in > > question is not bypassed. > > Customers seeing From headers changed will not have a practical means > to understand who sent the message. Of course, this assumes who > initiated content in an exchange is a critical aspect of any security > related goal. For mailing-lists, this understanding is critical to > being able to review conversations as well. If the rewritten Header-From references the remote author Name in its description and carries the mailing list Mailbox address (i.e., the immediate author who invalidated the remote author's DKIM signature) in the Header-From, I posit customers will have a practical means to understand who sent the message through said mailing list. In fact, many MUAs only display de Header-From description/name and not the Header-From mailbox address to the user, so even less confusion would be possible in those cases. Plus, a mailing list is an opt-in device. If the user chooses to be part of it, he accepts the mailing list terms of service, and if those terms involve rewriting Header-From in a DMARC-interoperable way, then that's what it is. The user is free to not use the mailing list service operated thusly if he objects to such a practice. > If it is critical, have the TPA-Label require the OAR be checked. > This can be quickly added if that is the hold-up I, as a domain owner, do not want to go chasing my users around demanding them to declare to me what mailing lists they subscribe to, in order to publish them as whitelists/exceptions for my domain as a Sender. What if I have a user subscribed to a transgender/whatever mailing list? Do I want to know? Does he want to tell me? I as a domain owner either trust my user, or fire my user, but I don't want to have to preemptively monitor my user not do I want him to disclose to me the minutiae of his email usage. If TPA-label involves this, I see no future in it.[*] [*] But it may well be that TPA-label works in a completely different way, I tried to read the draft but I could not understand much of it (therefore my Klingon joke, for which I apologize to you). Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
On Jun 4, 2014, at 12:16 PM, J. Gomez wrote: > On Wednesday, June 04, 2014 12:14 AM [GMT+1=CET], Hector Santos wrote: > >> I prefer to update my software with the above script for our MTA >> receiver rather to add logic to rewrite the 5322.From to bypass a >> security protocol > > Rewriting the Header-From field in mailing list traffic is not "bypassing a > security protocol", because the rewritten Header-From itself still is subject > to the security protocol (in this case, DMARC checking) at the Receiver's > side, so the security protocol in question is not bypassed. Dear J Gomez, Customers seeing From headers changed will not have a practical means to understand who sent the message. Of course, this assumes who initiated content in an exchange is a critical aspect of any security related goal. For mailing-lists, this understanding is critical to being able to review conversations as well. For invoicing, it is the client of a service likely to be recognized by recipients. In both of these cases, TPA-Labels offer a practical and safe solution. If it is critical, have the TPA-Label require the OAR be checked. This can be quickly added if that is the hold-up Bayesian probabilities are not very reliable when dealing with clever malefactors since they can lead email into the proverbial ditch by offering irrelevant keying of transient elements. TPA-Labels help provide a clear trust relationships only author-domains are best able to determine. To ensure accuracy, this domain related information needs to be conveyed to receivers. Regards, Douglas Otis ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
On 6/4/2014 3:16 PM, J. Gomez wrote: On Wednesday, June 04, 2014 12:14 AM [GMT+1=CET], Hector Santos wrote: I prefer to update my software with the above script for our MTA receiver rather to add logic to rewrite the 5322.From to bypass a security protocol Rewriting the Header-From field in mailing list traffic is not "bypassing a security protocol", because the rewritten Header-From itself still is subject to the security protocol (in this case, DMARC checking) at the Receiver's side, so the security protocol in question is not bypassed. H, thats a clear protocol security hole. The problem has always been that the middleware was intentionally ignorant of the proposed author domain DKIM signing protocol in order to allow it to offer an open-ended 3rd party DKIM signing service. It was not recognized, and the author of ADSP was not shy to advocate to everyone to not support it. The impact of this ignorance was real, proven and demonstrated by me to highlight the fact that we needed 3rd party semantics and MLS support. But it was yet to be felt and to close the deal, the ADSP proposal was make historic. That is until YAHOO enabled a strong policy via the alternative DMARC and now you feel it. Now, today, the list service is aware of the DMARC protocol but remains ignorant to follow it, honor it and knowing full well, DKIM+DMARC compliant downlink receivers will reject it, it violates the intent of RC2606 by using a ".invalid" TLD in order to bypass and preempt downlink rejections. That was not the intent of RFC2606. So rather than support DMARC fully, update it for 3rd party semantics to allow the resigner to exist in a DKIM+DMARC world, it proposes a hack to bypass the security. This is a major security loophole so the good news is that it was highlighted and now mail receivers will be aware of needing to add new ".invalid" check and rejection scripts. -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
Obfuscating the domain is quite suspicious because then, what entity is taking responsibility for that email? What abuse help-desk can the potential receiver recourse to? The one whose DKIM signature is on the mail, of course. Sigh. That would be the no-longer valid (assuming it ever was) and non-aligned DKIM string? Why would you trust something that is not valid and can't *be* validated? Also, if there are multiple such strings - which one? No, it's the valid signature from the mailing list that signed the mail on the way out. If there are multiple valid DKIM signatures, you can use any or all of them, since that is the way DKIM works. Here, for example, is the signature from your message to the dmarc list to which this is a response: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1401910901; bh=Ss7UP6fdlg/Nn7B/DiNdPNOOAEUDmP2bqWwILrhzH7s=; h=MIME-Version:Date:Message-ID:From:To:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=MG+QM40OoHTFFfoMx4ONQNlBZ4J63pI0KWkBEeXuDB+t1owHvEYV7svNAo9F0uIwd6LQIIVb+6kfy10c4nzZYkt1uSEFZ8uRnqN8x/yOa+SMy4OrHY+zMERFuxQnwW3cTUB LOpGzXqDnf5TZGgwPPhk4SES64N0dko/8gcZzlGo= And here is the A-R header that showed it was valid: Authentication-Results: iecc.com; spf=pass spf.mailfrom=dmarc-boun...@ietf.org spf.helo=mail.ietf.org; dkim=pass header.d=ietf.org header.b="MG+QM40O"; dkim=fail (bad signature) header.d=drkurt.com header.b="Kof3SYv1"; dmarc=fail.none header.from=drkurt.com policy=none DKIM has been a standard for over seven years. Why are we still dealing with these elementary questions about the way it works? Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
On Wednesday, June 04, 2014 9:34 PM [GMT+1=CET], John R Levine wrote: > > That is true, but it is not the same to obfuscate the local part in > > the ReturnAddress/FromHeader, than to obfuscate the domain. > > > > Obfuscating the domain is quite suspicious because then, what > > entity is taking responsibility for that email? What abuse > > help-desk can the potential receiver recourse to? > > The one whose DKIM signature is on the mail, of course. Sigh. But DKIM signatures are not mandatory, not even to be able to get a pass in DMARC checking. I see holes in that remedy. Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
On Wed, Jun 4, 2014 at 12:34 PM, John R Levine wrote: > That is true, but it is not the same to obfuscate the local part in the >> ReturnAddress/FromHeader, than to obfuscate the domain. >> >> Obfuscating the domain is quite suspicious because then, what entity is >> taking responsibility for that email? What abuse help-desk can the >> potential receiver recourse to? >> > > The one whose DKIM signature is on the mail, of course. Sigh. > That would be the no-longer valid (assuming it ever was) and non-aligned DKIM string? Why would you trust something that is not valid and can't *be* validated? Also, if there are multiple such strings - which one? --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
That is true, but it is not the same to obfuscate the local part in the ReturnAddress/FromHeader, than to obfuscate the domain. Obfuscating the domain is quite suspicious because then, what entity is taking responsibility for that email? What abuse help-desk can the potential receiver recourse to? The one whose DKIM signature is on the mail, of course. Sigh. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
On Wednesday, June 04, 2014 5:44 AM [GMT+1=CET], John Levine wrote: > > Yes the email is legitimate, but how does the MTA knows it? > > > > Well a bayesian filter has learned that this type of content is > > legitimate, and then one day a spammer uses the same content, but > > change one link... > > That could happen to any mail feature you care to name. > > Big companies send buckets of mail with return addresses like > "donotrespond". A non-deliverable or non-replyable From: line has > never had much connection to whether to deliver the mail. That is true, but it is not the same to obfuscate the local part in the ReturnAddress/FromHeader, than to obfuscate the domain. Obfuscating the domain is quite suspicious because then, what entity is taking responsibility for that email? What abuse help-desk can the potential receiver recourse to? Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
On Wednesday, June 04, 2014 12:14 AM [GMT+1=CET], Hector Santos wrote: > I prefer to update my software with the above script for our MTA > receiver rather to add logic to rewrite the 5322.From to bypass a > security protocol Rewriting the Header-From field in mailing list traffic is not "bypassing a security protocol", because the rewritten Header-From itself still is subject to the security protocol (in this case, DMARC checking) at the Receiver's side, so the security protocol in question is not bypassed. Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
- Original Message - > From: "Stephen J. Turnbull" > To: "Hector Santos" > Cc: "Tony Hansen" , dmarc@ietf.org, "Kurt Andersen" > , "Franck Martin" > > Sent: Wednesday, June 4, 2014 10:43:16 AM > Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't > change) > > Hector Santos writes: > > > [Mail From: a domain under .INVALID] is not legitimate mail per the > > proposed security protocol. > > Sorry, in this subthread, "legitimate", as used by Franck and myself, > means "delivery desired by the addressee". If you want to insist on a > different definition, go ahead, but that's very rude to the previous > posters and confuses other readers. As we are in semantics... There are two versions of legitimate and people will choose one or the other depending on context. May be we need a glossary to separate the two... May be there is legitimate in the sense of "follow the protocols and security" and legitimate in the sense "I want that email". Anyhow... my point is that moving an human decision to the machine is difficult, this is why we rely on protocols and we need to refuse more and more emails that are not following the protocols. Once again see the paragraph about the John Postel principle in the malformed emails RFC. John said (maybe?): if the protocol is vague, be lenient, but if the protocol is clear then be strict. He did not say "accept anything, the user will sort it out" >From the discussion I have this question: How an MTA knows the email is from a >mailing list? Also looking at bayesian implementations in say spamassassin/amavis (I looked quickly) it does not seem the bayesian rules are organised around authentication identifiers. The bayesian is left to figure what is relevant in an email. Will it pick the domain in the From for that? May be, may be not It seems going forward, there should be different baeysian learning, depending on the authenticated domain attached to the email. I don't think we are fully there yet. For instance, the simplified rule should be if this is an email looking like made only by X, but not authenticated by X, junk it. I'm not sure there is any rule like this out there for lot of MTAs. My experience is that a phishing campaign using an email content of X will impact all emails that look the same regardless of source. So to close this long tirade, I think we are moving towards a domain authenticated world of emails, using valid domains as identifiers of source. And yes, MUA have their role to play, in filtering according to user preferences, but the tendency, is for the MUA to pass the user preferences to the MTA, so it can work on received emails even when the MUA is not connected. I don't want my mobile to do the filtering, but tell the MTA what emails I like/don't like. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
Kurt Andersen writes: > On Wed, Jun 4, 2014 at 10:43 AM, Stephen J. Turnbull > wrote: > > > Nor does DMARC say it's nonconforming; in fact, it automatically > >> passes identity alignment, because there's nobody who is allowed to > >> create domains under .invalid, so there can be no _dmarc.x.y.invalid. > >> > > > Actually, it does not and can not pass alignment. The alignment status is > undefined which is neither a pass nor a fail. Urk. Thanks for the correction. Leaving-foot-in-mouth-until-brain-starts-working-ly y'rs, ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
On Wed, Jun 4, 2014 at 10:43 AM, Stephen J. Turnbull wrote: > Nor does DMARC say it's nonconforming; in fact, it automatically >> passes identity alignment, because there's nobody who is allowed to >> create domains under .invalid, so there can be no _dmarc.x.y.invalid. >> > Actually, it does not and can not pass alignment. The alignment status is undefined which is neither a pass nor a fail. --Kurt Andersen > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
Hector Santos writes: > [Mail From: a domain under .INVALID] is not legitimate mail per the > proposed security protocol. Sorry, in this subthread, "legitimate", as used by Franck and myself, means "delivery desired by the addressee". If you want to insist on a different definition, go ahead, but that's very rude to the previous posters and confuses other readers. Nor does DMARC say it's nonconforming; in fact, it automatically passes identity alignment, because there's nobody who is allowed to create domains under .invalid, so there can be no _dmarc.x.y.invalid. I suppose it's nonconforming to RFC 5322, but I wouldn't reject mail merely because From contains a mailbox at an invalid domain. Of course you can do what you want in your domain. Like you, I think it violates the spirit of the security protocol -- but so do all mitigations that preserve the address in From in such a way as to indicate that is the mailbox of the author, and so lend the message whatever prestige the author may have with the recipient. Such mitigations are clearly desired by the users of mailboxes at AOL and Yahoo!, and some such mitigation recommended (and in the case of Yahoo!, practiced) by the ESPs publishing "p=reject". You can take a letter-of-the-law stance (I believe you do), and as far as I can tell that means banning those domains from your lists (unless the lists preserve signatures). But that's not acceptable to our users. > The problem and conversation should be focused on resolving the 9 > years old mail integration dilemma -- the dearth of resigners not > wanting to check for bad DKIM-secured transactions via a policy > layer protocol. Keep in mind that the suggested rewrite > applicability for p=reject domains implies that a DNS lookup is > presumed to be part of the DKIM framework. If we can get to that > level, we are home free. But unfortunately, the concept has been > killed by the IETF when it decided to make ADSP historic. DMARC resurrected the concept of a DNS lookup to discover policy, no? But I don't think it's as easy as you say. It may be trivial to publish records authorizing third parties to sign message with your mailboxes in From:, but I doubt it will be done, at least not for the thousands of tiny lists out there with no personal contact with the big ESPs. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
John, I doubt these aol and yahoo users give a hoot of what u snuck into your small local site. The odds are high these kind of addresses were first used for junk, aliases, "throw away" addresses like most people did with these public email service bureaus. Sure, for many, these public addresses have become more of their mainstream contact address, i.e. I use my junk gmail account more for today's sign ups. But they are probably not even aware of what u did and I would lean towards the reasonable presumed fact that most people, including myself and maybe you, will not like the idea that your mail is being displayed with "invalid" indicators on a wide spread set of mail reading devices. -- Hector Santos http ://www.santronics.com On Jun 4, 2014, at 10:39 AM, "John Levine" wrote: >> But that is not equivalent to putting non-resolvable gibberish on the right >> side of the @ sign. That's >> a reliable way of assuring that such messages do not get queued on my >> server. As a matter of >> practicality, I highly doubt that I'm unique in requiring that the sender >> domain (envelope and header) >> resolve. > > I've been using the .invalid hack on my lists for the past month, and > I haven't seen any failure reports at all that seem to have anything > to do with it. (Only AOL and Yahoo get the .invalid, so it's not hard > to tell if recipients are treating the mail differently.) > > As I've said before, it's a user-hostile crock, but so is everything > else other than the various forms of DMARC-bypass whitelisting. > > R's, > John > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
But it does know. It is not legitimate mail per the proposed security protocol. The problem and conversation should be focused on resolving the 9 years old mail integration dilemma -- the dearth of resigners not wanting to check for bad DKIM-secured transactions via a policy layer protocol. Keep in mind that the suggested rewrite applicability for p=reject domains implies that a DNS lookup is presumed to be part of the DKIM framework. If we can get to that level, we are home free. But unfortunately, the concept has been killed by the IETF when it decided to make ADSP historic. -- HLS > On Jun 4, 2014, at 7:28 AM, "Stephen J. Turnbull" wrote: > > Franck Martin writes: > >> Yes the email is legitimate, but how does the MTA knows it? > > Aha! Precisely where this conversation should go. > > The MTA *doesn't* know. A mailing list knows more, though. And an > MUA knows a lot more than that. Or they could. > > For bandwidth reasons, it's important (especially at Humongous ESP) to > catch abusive mail as much as you can at the boundary MTA. But that > doesn't mean you should abdicate all responsibility to the MTA. > >> Well a bayesian filter has learned that this type of content is >> legitimate, and then one day a spammer uses the same content, but >> change one link... > > Bad, bad, bad Bayesian filter! No dessert for you tonight! > > But, while that kind of failure *does* happen, it should be rare. In > a well-designed filter, you also need to use header features, like the > content of the From: field and DKIM signature. > > The recipient is also an important feature, which should be part of > the filter. I've heard of mailing lists where the topic word (eg, on > this list "DMARC") is used: if the word is not present, the message > goes straight to 4.5 on a "5 is spammy enough to quarantine" scale. > In the old days (2007 or so) it apparently worked quite well, dunno if > it still does. > > A conventional MTA *can't* be expected to know that kind of thing > (Google and Yahoo! work differently, I'd guess). But an MUA easily > could, and at least for PC users, there's enough storage and CPU power > to do the analysis. > >> I know that an email is legitimate when I see one, is not really a >> practical rule... > > Why not? As long as it's the last rule in a long chain! It worked > against spam for quite a few years, with no other help. But more > seriously, personal filters that learn what you like and what you > think is spammy could probably do a lot more than they currently do. > > The other thing that MUAs could do to help mailing lists out here is > allow signatures of MIME parts instead of the whole message. > > Unfortunately that doesn't help "on behalf of" services, but I'm not > sure what to do for them. Somebody suggested OAuth2, if that works > (for typical non-technical users) that would be very cool. > > Regards, > > ___ > 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] DKIM through mailing lists (rebutting MLs won't change)
>But that is not equivalent to putting non-resolvable gibberish on the right >side of the @ sign. That's >a reliable way of assuring that such messages do not get queued on my server. >As a matter of >practicality, I highly doubt that I'm unique in requiring that the sender >domain (envelope and header) >resolve. I've been using the .invalid hack on my lists for the past month, and I haven't seen any failure reports at all that seem to have anything to do with it. (Only AOL and Yahoo get the .invalid, so it's not hard to tell if recipients are treating the mail differently.) As I've said before, it's a user-hostile crock, but so is everything else other than the various forms of DMARC-bypass whitelisting. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
Franck Martin writes: > Yes the email is legitimate, but how does the MTA knows it? Aha! Precisely where this conversation should go. The MTA *doesn't* know. A mailing list knows more, though. And an MUA knows a lot more than that. Or they could. For bandwidth reasons, it's important (especially at Humongous ESP) to catch abusive mail as much as you can at the boundary MTA. But that doesn't mean you should abdicate all responsibility to the MTA. > Well a bayesian filter has learned that this type of content is > legitimate, and then one day a spammer uses the same content, but > change one link... Bad, bad, bad Bayesian filter! No dessert for you tonight! But, while that kind of failure *does* happen, it should be rare. In a well-designed filter, you also need to use header features, like the content of the From: field and DKIM signature. The recipient is also an important feature, which should be part of the filter. I've heard of mailing lists where the topic word (eg, on this list "DMARC") is used: if the word is not present, the message goes straight to 4.5 on a "5 is spammy enough to quarantine" scale. In the old days (2007 or so) it apparently worked quite well, dunno if it still does. A conventional MTA *can't* be expected to know that kind of thing (Google and Yahoo! work differently, I'd guess). But an MUA easily could, and at least for PC users, there's enough storage and CPU power to do the analysis. > I know that an email is legitimate when I see one, is not really a > practical rule... Why not? As long as it's the last rule in a long chain! It worked against spam for quite a few years, with no other help. But more seriously, personal filters that learn what you like and what you think is spammy could probably do a lot more than they currently do. The other thing that MUAs could do to help mailing lists out here is allow signatures of MIME parts instead of the whole message. Unfortunately that doesn't help "on behalf of" services, but I'm not sure what to do for them. Somebody suggested OAuth2, if that works (for typical non-technical users) that would be very cool. Regards, ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
Brandon Long writes: > You're being a bit free with the "we" there. Sorry if you understood it that way. I'm here as a delegate of the Mailman project, and in this case I believe my views are representative of a working consensus of the core developers and some influential users. So I wrote "we" rather than "I". ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
Elizabeth Zwicky writes: > But I do, in fact, have data, and that data tells me that the attackers > forging our users based on stolen addressbooks have never stopped; we are > still blocking them now. Interesting. No perceptible change at all? I am going to have to dig up that graph of the AOL attack. *They* show the attack on their users stopping dead in its tracks and returning to the pre-onslaught level. > By the way, yahoo.co.jp is an independent company with a separate mail > system and a separate account database. Sure, Japanese law means it almost *has* to be that way. But how am I to know whether the "independent" Japanese company takes its lead from the US parent/trademark licensor, or not? And, as I say, the bureaucrats (who should know that as well as you or I) chose to ignore it. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
- Original Message - > From: "Matt Simerson" > To: dmarc@ietf.org > Sent: Tuesday, June 3, 2014 10:01:37 PM > Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't > change) > > > On Jun 3, 2014, at 8:44 PM, John Levine wrote: > > >> Yes the email is legitimate, but how does the MTA knows it? > >> > >> Well a bayesian filter has learned that this type of content is > >> legitimate, and then one day a spammer > >> uses the same content, but change one link... > > > > That could happen to any mail feature you care to name. > > > > Big companies send buckets of mail with return addresses like > > "donotrespond". A non-deliverable or non-replyable From: line has > > never had much connection to whether to deliver the mail. > > I agree that From addresses such as these will suffer no adverse > deliverability issues: > > nore...@github.com, donotre...@etrade.com > > But that is not equivalent to putting non-resolvable gibberish on the right > side of the @ sign. That's a reliable way of assuring that such messages do > not get queued on my server. As a matter of practicality, I highly doubt > that I'm unique in requiring that the sender domain (envelope and header) > resolve. > You are not. I can't recall if it is in security considerations, but should likely go in the BCP, if you do DMARC you need to reduce some of the workarounds possible. Multiple From: headers is one Invalid or known bad domains in From: is the other one Otherwise it is easy to send an email with a domain that contains an extra letter and bypass DMARC. Granted, you can buy domains with a stolen credit card, or even better, just use a nearly untraceable prepaid credit card from your local store to buy domains, but this may require a bit more organization than a 15 year old may be willing to do... With a legit domain, you have 2 investigative/complain paths: the sending IP and the From: domain. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
On Jun 3, 2014, at 8:44 PM, John Levine wrote: >> Yes the email is legitimate, but how does the MTA knows it? >> >> Well a bayesian filter has learned that this type of content is legitimate, >> and then one day a spammer >> uses the same content, but change one link... > > That could happen to any mail feature you care to name. > > Big companies send buckets of mail with return addresses like > "donotrespond". A non-deliverable or non-replyable From: line has > never had much connection to whether to deliver the mail. I agree that From addresses such as these will suffer no adverse deliverability issues: nore...@github.com, donotre...@etrade.com But that is not equivalent to putting non-resolvable gibberish on the right side of the @ sign. That's a reliable way of assuring that such messages do not get queued on my server. As a matter of practicality, I highly doubt that I'm unique in requiring that the sender domain (envelope and header) resolve. Matt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
>Yes the email is legitimate, but how does the MTA knows it? > >Well a bayesian filter has learned that this type of content is legitimate, >and then one day a spammer >uses the same content, but change one link... That could happen to any mail feature you care to name. Big companies send buckets of mail with return addresses like "donotrespond". A non-deliverable or non-replyable From: line has never had much connection to whether to deliver the mail. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
- Original Message - > From: "Stephen J. Turnbull" > To: "Franck Martin" > Cc: "Tony Hansen" , dmarc@ietf.org, "Kurt Andersen" > > Sent: Tuesday, June 3, 2014 7:16:04 AM > Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't > change) > > Franck Martin writes: > > > But why would you accept emails from invalid domains in the first > > instance? > > Because the email is legitimate, of course. I've seen people use > "example.com" in their addresses on list posts to ensure they won't > get personal replies. I've seen people use "nore...@personal.dom" as > their valid return address. > Yes the email is legitimate, but how does the MTA knows it? Well a bayesian filter has learned that this type of content is legitimate, and then one day a spammer uses the same content, but change one link... Like Symantec has claimed "outrageously" that anti-viruses are dead, same for content based filtering. It means more rules have to be put in the authentication of the emails, so they can be linked to domain names that do exists, so you have some form of recourse... I know that an email is legitimate when I see one, is not really a practical rule... ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
But why would you accept emails from invalid domains in the first instance? Because the email is legitimate, of course. Until it isn't. The purpose of the ".invalid" TLD was not for bypassing a proposed security protocol. This is a malicious hack that will ultimately help break down one of the last remaining mail communications "inherent trust" headers we have left that is expected by ALL parties, all software, the world, in any language, society, etc, MUST NEVER be changed -- the 5322.From header. You just don't do it and those that do, well, I consider them the Enemy of Mail. It opens up loopholes. In fact, I think I will add a DATA filter script to check for this TLS and immediately reject it. A single line rule: if mail.from TLD is ".invalid" then REJECT "550 Invalid From Address" This rule can be added to our existing incoming DATA 5322 Validation script that checks for such things as multiple 5322.From headers violation, something that DKIM needs done by all receivers to protect against fraudulent fake 5322.From headers. I prefer to update my software with the above script for our MTA receiver rather to add logic to rewrite the 5322.From to bypass a security protocol in our list server. I think I can sleep better with that. -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
On Tue, Jun 3, 2014 at 12:43 PM, Brandon Long wrote: > > Remember, we think *all* of the mitigations should be discouraged in >> favor of not permitting posts from "p=reject" domains. But we also >> know that will be unacceptable to most of our list operators. > > > You're being a bit free with the "we" there. > > I don't think I wish to be included in the "just exclude a billion people > from mailing ilsts" category. > I think "we" there refers to Mailman users, given Stephen's context. He's free to correct me if I'm wrong. I didn't get the impression he's speaking for all operators everywhere. I do agree that we may be straying a bit off topic. I really think this group needs to focus on where we go from here. We are all aware of the predicament in which we find ourselves and how we got here. Re-analyzing the past might be interesting or cathartic, but I don't think it will identify a new path forward. I'm excited that we have representatives from Mailman, Yahoo, Gmail, and several other critical players engaged. I'd rather we take advantage of that opportunity than waste it. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
On 6/3/14, 4:26 AM, "Stephen J. Turnbull" wrote: >Elizabeth Zwicky writes: > > > At this point, I do not see going to p=quarantine in the hope > > that attackers won't exploit data they already have exactly the same > > way > >Has Yahoo! has already tried 'p=quarantine', or is that merely your >expert opinion? (Nothing against expertise, but "experiment" beats >"expertise" 10 letters to 9 in my dictionary.) > >Obviously, there is a risk to Yahoo! in experimenting. That risk is not one my management team is willing to accept. But I do, in fact, have data, and that data tells me that the attackers forging our users based on stolen addressbooks have never stopped; we are still blocking them now. So I don't need to turn on p=quarantine to see what will happen -- I know at least one thing that will happen. The only question is how the volume will change. By the way, yahoo.co.jp is an independent company with a separate mail system and a separate account database. Elizabeth Zwicky zwi...@yahoo-inc.com ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
Franck Martin writes: > I'm not sure it is wise to encourage the use of "invalid" domains > in any of the email headers. Remember, we think *all* of the mitigations should be discouraged in favor of not permitting posts from "p=reject" domains. But we also know that will be unacceptable to most of our list operators. > The use of the .INVALID is likely to create problems in the future, > if not already with reputation systems. We'll warn our users (list operators) of the troubles we know of. Corrupting an existing mailbox in the header of a post in any way is at the bottom of the list of the things we think a mailing list should do, of course (unless it's part of the terms of service of the list -- eg, anonymous lists). BTW, I'm not particularly worried about reputation systems for spam- fighting. I believe it's a fundamentally unsound idea, aiming at the one resource that we *know* spammers put zero value on: reputation of Internet addresses. Both their own (because they keep those carefully hidden), and the reputations of the hosts, individuals, and services they parasitize. Regards, ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
Franck Martin writes: > But why would you accept emails from invalid domains in the first > instance? Because the email is legitimate, of course. I've seen people use "example.com" in their addresses on list posts to ensure they won't get personal replies. I've seen people use "nore...@personal.dom" as their valid return address. That kind of thing may not happen on your lists, and you may not care to play along with the game. Fine. But remember, the domain, or even the whole mailbox, in From: is only one consideration in making that judgment of legitimacy. Steve ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
Elizabeth Zwicky writes: > At this point, I do not see going to p=quarantine in the hope > that attackers won't exploit data they already have exactly the same > way Has Yahoo! has already tried 'p=quarantine', or is that merely your expert opinion? (Nothing against expertise, but "experiment" beats "expertise" 10 letters to 9 in my dictionary.) Obviously, there is a risk to Yahoo! in experimenting. Nevertheless, DMARC is a *private* agreement among parties using the *public* Internet, and Yahoo!'s use of DMARC is *demonstrably* harming Yahoo! users as well as 3rd parties in no way participating in DMARC. Perhaps "corporate social responsibility" requires that Yahoo! accept those risks as an experiment. > what will happen then is that they go very aggressive at 2:00 in > the morning my time, Which is, I remind you, exactly what Yahoo! did to list subscribers and operators. The difference is that you will know to expect it, and you can probably arrange for an automatic tripwire to return to "p=reject" much more quickly than you responded to the last attack. You can also make an additional, even more private, agreement with AOL, Google, and Hotmail (which should cover the vast majority of very-vulnerable-to-fraudulent-recommendations-from-yahoo-mailboxes users out there) to give messages failing identity alignment with yahoo.com a more-thorough-than-usual spam check. > followed by a great deal of bad press. Yahoo's good press doesn't make our ugly mitigations any prettier, and we're not brimming over with good will toward Yahoo! now -- i.e., we're not happy that Yahoo! gets less bad press at our subscribers' expense. Does that matter? I don't know, but I can tell you that there is a "friends don't let friends use Yahoo!" meme spreading -- not just from disgruntled MLM developers! -- and Yahoo! could probably use more friends. For example, the Japanese Ministry of Education immediately broadcast warnings to dependent organizations that Yahoo! mailboxes will have trouble with unreliable delivery and cause bounces that upset mailing lists and sysadmins. They explicitly recommended avoiding use of Yahoo! accounts in connection with academic activity. Ironically enough, this was pure FUD. :-( yahoo.co.jp did not publish a 'reject' (or even 'quarantine') policy (AFAIK they never have, and as of this writing they don't). I don't know what MEXT thought they were doing (although I suspect what the US Trade Representative would call "structural impediments"). Do I tell my colleagues that truth? Oh, over beers (but I don't drink with the departmental computer committee), of course, and my local LUG has heard all about it and we all had a good laugh. I am not going to waste words on the bureaucracy, though. For one, trying to teach our Computer Center (forget the central bureaucrats) what they don't know is worse than dealing with sophomores. But this is also very useful to me, as on my educational lists I had few Yahoo! users (all with Asian domains), now I have none, and I just ban them going forward -- no RFC-violating mitigation necessary. I've told my subscribers, too, but they don't understand the difference between MEXT FUD about Yahoo! and the draconian policies on file-sharing software imposed by Japanese universities, so most had already switched anyway, and none consider my ban an imposition. So AFAICT, MEXT's FUD has been effective. Ban unnecessary? For now, but I don't feel like trying to figure out how closely Yahoo! Japan is going to follow the lead of the parent company, or when. Your own words make me sure that Yahoo! cannot be trusted to behave with consideration to 3rd parties or to give warning. Furthermore, it establishes a precedent: "p=reject" is grounds for banning a whole domain. I'll never need to use ugly mitigations on my university lists, even if this practice spreads beyond Yahoo! and AOL, and I have MEXT authority for it. So this misunderstanding suits me perfectly. I doubt I'm alone in that. One more note: all but one of my former Yahoo! users are Chinese, and they tell me the same meme is spreading there. If you think Japanese "structural impediments" are annoying, just wait until you have to deal with the Chinese version. Regards, ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
- Original Message - > From: "Kurt Andersen" > To: "Stephen J. Turnbull" , "Tony Hansen" > > Cc: dmarc@ietf.org > Sent: Monday, June 2, 2014 12:55:39 PM > Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't > change) > > On 2014-06-02, 00:28 , "Stephen J. Turnbull" > wrote: > > >Thanks to John Levine, we'll eventually have a 2c option: append > >.INVALID to the poster's mailbox in From:. > > And how long do you think it will be before some clever organization buys > the .INVALID TLD? > Invalid is a reserved TLD for “invalid” domains. http://en.wikipedia.org/wiki/Top-level_domain#Reserved_domains But why would you accept emails from invalid domains in the first instance? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
- Original Message - > From: "Stephen J. Turnbull" > To: "Tony Hansen" > Cc: dmarc@ietf.org > Sent: Monday, June 2, 2014 12:28:21 AM > Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't > change) > > Tony Hansen writes: > > > I would love to see that list of multiple mitigations shared with the > > broader community. That would be useful information for people in the > > IETF, > > I've shared it here in various levels of detail more than once, and > sooner or later it will be in the Mailman FAQ as I'm sure that the > brief descriptions in the admin UI will need amplification. > Basically, Mailman provides two orthogonal features: > > 1. Whether to mitigate, and when to mitigate, that is the question > > a. Don't. > b. Always. > c. Only for posters from DMARC "p=reject" domains. > > 2. How to mitigate: > > a. Replace poster with list in From:, and diddle Reply-To so that > reply-to-poster is as convenient as possible. > b. Wrap the message in a MIME message/rfc822 body. > > Thanks to John Levine, we'll eventually have a 2c option: append > .INVALID to the poster's mailbox in From:. > I'm not sure it is wise to encourage the use of "invalid" domains in any of the email headers. The tendency is to become more strict with malformed emails (for instance: reject if none or more than one From field), not more loose. The use of the .INVALID is likely to create problems in the future, if not already with reputation systems. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
I'm a list software product developer. I believe our list package was among the first to implement domains controls with restrictive domains. In our case, we used the then IETF Proposed Standard ADSP. It followed the guidelines written in the 2006 DSAP (DKIM Signature Authorization Protocol) I-D section 3.3: 3.3. Mailing List Servers Mailing List Servers (MLS) applications who are compliant with DKIM and DSAP operations, SHOULD adhere to the following guidelines: Subscription Controls MLS subscription processes should perform a DSAP check to determine if a subscribing email domain DSAP policy is restrictive in regards to mail integrity changes or 3rd party signatures. The MLS SHOULD only allow original domain policies who allow 3rd party signatures. Message Content Integrity Change List Servers which will alter the message content SHOULD only do so for original domains with optional DKIM signing practices and it should remove the original signature if present. If the List Server is not going to alter the message, it SHOULD NOT remove the signature, if present. The main point is that there should be no advocation or promoting what is effectively violating a security protocol, especially of that being advocated with a 5322.From rewrite. I think its an unethical practice to be bypassing a security protocol, intentionally. Its bound to bite you. And what about the domains that don't want you to do this? Unless there is a permission based concept to do this, it is a terrible mistake to open up this door. You won't be able to trust any domain and From rewrites would cause the lost of any protective value the message originally had. What is to suggest that the receiving domains won't learn to adapt to detect these "rewrite/rewrap" loopholes and begin to give such senders bad reputation blocks? Overall, the hurdle to is to get systems to do a LOOKUP in order to get permission to resign. If you assume this is going to be the case, then we don't to be kludging radical methods simply to bypass a security the originating domain does not want you to do anyway. Thats a pretty risky thing to do. I certainly can't support these ideas to rewrite lacking permission to do considerations and against the wishes of the originating domain. -- HLS [1] http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-01.html#anchor14 On 6/2/2014 3:28 AM, Stephen J. Turnbull wrote: Tony Hansen writes: > I would love to see that list of multiple mitigations shared with the > broader community. That would be useful information for people in the > IETF, I've shared it here in various levels of detail more than once, and sooner or later it will be in the Mailman FAQ as I'm sure that the brief descriptions in the admin UI will need amplification. Basically, Mailman provides two orthogonal features: 1. Whether to mitigate, and when to mitigate, that is the question a. Don't. b. Always. c. Only for posters from DMARC "p=reject" domains. 2. How to mitigate: a. Replace poster with list in From:, and diddle Reply-To so that reply-to-poster is as convenient as possible. b. Wrap the message in a MIME message/rfc822 body. Thanks to John Levine, we'll eventually have a 2c option: append .INVALID to the poster's mailbox in From:. > as well as other MLM teams not involved wherever those discussions > occurred. AFAIK there is no particular place where MLM teams meet up; there are very few interoperation considerations. I would think other MLM teams would be here now if they cared (cf John Levine's comment on your post). > Perhaps there is one or more of those solutions that we SHOULD be > recommending. The only solution currently available I can see recommending is banning domains that DoS third parties. However, that isn't going to fly on many, probably the great majority, of Mailman and ListServ lists. (Majordomo, smartlist, and whatever is used with qmail may have a rather different user population, as is suggested by John's observation.) All the others have defects that some people consider severe, so will have to be chosen by the list's administration. > And perhaps broader discussions will provide an AHA moment where we see > a way to solve BOTH MLM's problems AND DMARC's problems with MLMs in the > face of a p=reject policies. My personal belief (as previously mentioned) is that that is a logical impossibility. But we can hope I'm wrong! > Are the current p=reject semantics totally correct? As has been pointed > out by others, even with mail sent out from banks, there are legitimate > uses of mailing lists or things like mailing lists where you want copies > to be received by multiple people. The important thing is that the banks' problems with "p=reject" can be solved (worked around, if you prefer) by the banks, without cooperation of
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
Tony Hansen writes: > I would love to see that list of multiple mitigations shared with the > broader community. That would be useful information for people in the > IETF, I've shared it here in various levels of detail more than once, and sooner or later it will be in the Mailman FAQ as I'm sure that the brief descriptions in the admin UI will need amplification. Basically, Mailman provides two orthogonal features: 1. Whether to mitigate, and when to mitigate, that is the question a. Don't. b. Always. c. Only for posters from DMARC "p=reject" domains. 2. How to mitigate: a. Replace poster with list in From:, and diddle Reply-To so that reply-to-poster is as convenient as possible. b. Wrap the message in a MIME message/rfc822 body. Thanks to John Levine, we'll eventually have a 2c option: append .INVALID to the poster's mailbox in From:. > as well as other MLM teams not involved wherever those discussions > occurred. AFAIK there is no particular place where MLM teams meet up; there are very few interoperation considerations. I would think other MLM teams would be here now if they cared (cf John Levine's comment on your post). > Perhaps there is one or more of those solutions that we SHOULD be > recommending. The only solution currently available I can see recommending is banning domains that DoS third parties. However, that isn't going to fly on many, probably the great majority, of Mailman and ListServ lists. (Majordomo, smartlist, and whatever is used with qmail may have a rather different user population, as is suggested by John's observation.) All the others have defects that some people consider severe, so will have to be chosen by the list's administration. > And perhaps broader discussions will provide an AHA moment where we see > a way to solve BOTH MLM's problems AND DMARC's problems with MLMs in the > face of a p=reject policies. My personal belief (as previously mentioned) is that that is a logical impossibility. But we can hope I'm wrong! > Are the current p=reject semantics totally correct? As has been pointed > out by others, even with mail sent out from banks, there are legitimate > uses of mailing lists or things like mailing lists where you want copies > to be received by multiple people. The important thing is that the banks' problems with "p=reject" can be solved (worked around, if you prefer) by the banks, without cooperation of third parties, and without (much) harm to third parties (it's unlikely that there are Mailman lists where 314 bank reps will post to the same list in a week and so knock all subscribers into disabled state). While it would be as nice as getting a pony for the banks' tech staff to be able to post to this list from the well-known domain, I don't think that's very high on their list of tasks for their techies. Just registering a "somebank-inc.com" domain is satisfactory, I suppose. > Or alternatively, perhaps p=reject needs to be redefined slightly to > take advantage of specific recommended practices for mailing lists. Perhaps. I'm a fan of "simple protocols used judiciously" vs. "complex protocols that try to forestall all problems" myself. If complexity would make it possible for Yahoo! to use "p=reject" without DoS'ing mailing list subscribers and their own posters, it would be worth it, I suppose. > > SPF and DKIM are now ancient history, at least as far as Mailman > > development goes. We've already done what's technically > > possible. > > Since I'm not privy yet to what all GNU Mailman has chosen to do in > the face of SPF and DKIM, so I don't know how to evaluate that > statement. Sorry. > > If you're saying that you've thrown out all use of DKIM, I consider that > a sorry state of affairs. No. What we've done is (1) Put up a FAQ encouraging re-signing by MTAs hosting lists. (2) Added an option to strip the (presumably broken, we don't check for it) original DKIM signature. There's no real point in MLMs doing more than that as it requires cooperation from the domain's DNS. OAR (which I don't think is worth it) could be done, but I think this probably is better done by the MTA (local MUAs and admins might wish to refer to it). ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
It is true that when attackers can't use our From: lines, they try other things. Empirically, it's also clear that the attackers do not like From: "Victim Name" as much as they like From: "Victim Name" based on lowered volume when the second form is unavailable. Given that, I see no reason to believe they won't go back to the second form if it becomes available. And, taking into account Murphy's law, previous tactics of these attackers, and the reasonable expectations of the public, what will happen then is that they go very aggressive at 2:00 in the morning my time, followed by a great deal of bad press. At this point, I do not see going to p=quarantine in the hope that attackers won't exploit data they already have exactly the same way they did before, even though nothing is stopping them, as a reasonable approach. Elizabeth zwi...@yahoo-inc.com On 5/31/14, 7:37 AM, "Stephen J. Turnbull" wrote: >Elizabeth Zwicky writes: > > > So changes that maintain effective protection for users who are > > being targeted by attackers with addressbook information, with less > > disruption to email that people want, are of great interest to us. > >How about trying "p=quarantine" with a real short TTL just in case? >After a while you crank it back up to the current level (which is only >1800 in any case). > >The argument is that, seriously, since the attackers have addressbook >information, you're done for anyway. They're already hard at work on >Plan B, using "I'm writing this from my friend's account" with self in >Sender: (should work well on Outlook users despite having on-behalf-of >point the wrong direction), and ... Heck, I've already thought of a >dozen of these dodges and my name isn't even Laurence Canter. > >I think it's worth a check to see if the miscreants will bother to >come back at you with the previous style of spam shot even though they >should expect that the vast majority of their spam will get rejected >anyway (messages apparently from a "p=quarantine" domain should be >given a rough time as encouraged by the DMARC protocol), and the rest >will end up in spam folders. I would think trying to avoid DMARC >entirely would now be the best use of their resources, so maintaining >quarantine should be enough. There may be some directly relevant >recent evidence on this, since GMail is evidently promoting mailing >list traffic from "p=reject" domains to "quarantine". If the spammers >know this, they could continue targeting GMail customers in their >stolen addressbook database. Dunno if GMail will tell Yahoo!, but you >could ask. > >BTW I hope you guys are basing "p=reject" (vs. "p=quarantine") on real >data on how often fraudulent mail that ends up in spam folders >actually succeeds in harming the targeted victim. > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
>That's okay -- it was just a thought. However, note that not all MLMs >are in as good a shape as GNU Mailman is, volunteer-wise. For *them*, it >might be useful. I wouldn't count on it. I did .invalid patches for majordomo2, which is largely abandonware but still used a fair number of places. People were surprisingly uninterested, one site said they had few enough AOL and Yahoo users that they just kicked them all off. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
Thanks for your comments Stephen. On 5/31/14, 1:51 PM, Stephen J. Turnbull wrote: Tony Hansen writes: >> That doesn't help the DMARC situation now, but DMARC could be >> given other options once that happens. > > I agree completely that a change to DMARC is needed in conjunction > with having clear ML specs. A change to the protocol? What? I don't see it. The protocol actually in use by many domains seems to actually do what it's designed for quite well. "p=reject" makes a lot of sense for banks, for example. I don't think it can be removed from the spec, and its proper use doesn't cause widespread problems for mailing lists. It's use outside the design space that causes problems. Those uses are by desperate organizations, and they'll ignore any change that attempts to prohibit them because they are desperate. See further below. > I've heard it said that the majority of the mailing lists out there > are managed by only a handful of ML management systems. I maintain > that these ML packages are in the same boat as openssl. It sure > would be nice if we could get some of that consortium money thrown > at that handful of ML management systems. I'm sorry, but that's nonsense for the volunteer-maintained MLMs like GNU Mailman. That's okay -- it was just a thought. However, note that not all MLMs are in as good a shape as GNU Mailman is, volunteer-wise. For *them*, it might be useful. We already have implemented multiple mitigations, and it doesn't take much code. We just hate them all and leave it up to mailing list operators to choose the one they dislike least. If other MLMs haven't done so already, I doubt it involves all that much effort for them. I would love to see that list of multiple mitigations shared with the broader community. That would be useful information for people in the IETF, as well as other MLM teams not involved wherever those discussions occurred. Perhaps there is one or more of those solutions that we SHOULD be recommending. Perhaps a broader discussion might come up with some additional better solutions. And perhaps broader discussions will provide an AHA moment where we see a way to solve BOTH MLM's problems AND DMARC's problems with MLMs in the face of a p=reject policies. Are the current p=reject semantics totally correct? As has been pointed out by others, even with mail sent out from banks, there are legitimate uses of mailing lists or things like mailing lists where you want copies to be received by multiple people. There might be an alternative to p=reject that we can come up with that *) WOULD work with mailing lists *) if mailing lists also were to take certain steps, and *) these organizations might be willing to switch to. Or alternatively, perhaps p=reject needs to be redefined slightly to take advantage of specific recommended practices for mailing lists. > That's a political solution for this current technical problem. Mailing lists don't have a *technical* problem. If DMARC were used as designed, we'd never have noticed. The problem is political: we have a wounded 800-lb gorilla on the loose (not to forget a wounded 500-lb gorilla joining the fun). > However, before it can happen: we NEED clear specs as to what > should be done by ML systems, at least in the face of DKIM and SPF > (and DMARC) SPF and DKIM are now ancient history, at least as far as Mailman development goes. We've already done what's technically possible. Since I'm not privy yet to what all GNU Mailman has chosen to do in the face of SPF and DKIM, so I don't know how to evaluate that statement. Sorry. If you're saying that you've thrown out all use of DKIM, I consider that a sorry state of affairs. We'll see what more our users want us to do about DMARC, if anything. There just isn't anything technical to be done AFAICS. I can't speak for other MLMs, but I think that if there's going to be real progress, the answer is with the MUAs. 1. If identity alignment fails, *all* links, scripts, and forms in the message should be deactivated, even if it's already in the spam folder. 2. If there's a type=password field in the message, *all* links and forms in the message should be deactivated, even if it's already in the spam folder. 3. Ditto misaligned MIME type and file name. 4. Ditto active or unknown attachments. 5. On activation of the message, all href and src URIs should be displayed clearly, along with an intrusive warning that ID theft is very common, so the user should check everything carefully (preferably call the author on the phone) before doing anything suggested by the message, even if it's already in the spam folder. I'm sure there are other things they could do, but those are off the top of my head. Finally, Tim Draegen is right, it's not just about mailing lists. Let's not forget all the other use cases that are stomped on by the inappropriate use of "p=
Re: [dmarc-ietf] DKIM through mailing lists
On May 31, 2014, at 8:49 AM, Stephen J. Turnbull wrote: > Douglas Otis writes: > >> https://community.intuit.com/questions/899989-please-make-quickbooks-pass-the-dmarc-evaluation-please-do-this-quickly > > Grr. Doesn't describe the problem! Is it that a QuickBooks client > using a mailbox at a "p=reject" domain is having QuickBooks send > invoices on their behalf? > > If that's it, I have a great deal for them. Register a domain and get > their company name, instead of Yahoo!'s, in From:. > > Or (cheaper), Quickbooks just checks for "p=", and if so > overrides any company-specific config, and puts QuickBooks in From: > (with a working "p=reject" policy, even!), "Your invoice from > " in subject, and the company address in Reply-To. > > Even supposing the company doesn't like either of those options, it's > not clear to me that the "p=reject" domain is going to necessarily be > happy trusting QuickBooks, even once TPA-Labels gets implemented. Placing the original From and Subject in the message body would be cleaner, but people will wonder what to believe with few tools to help them sort through the confusion. After having large numbers change providers, spoofing their prior recipients from anywhere can now accompany very believable reasons, such as "DMARC caused me to change to this provider...". Once TPA-Label is implemented by both sender and receivers applying requested DMARC policy, nothing in between would need to change. No one would be confused, and malefactors can be reliably blocked. >> I know of many small operations with similar services and >> previously working strategies. > > Much less so the effort required to vette a million small operations > (who could actually be the Yahoo! customer requesting a TPA-label for > a vendor they use -- how does TPA-label deal with collusion between > authors and relays?) The number of Sender use cases would likely be in the thousands. There would be no free lunch which is why our company has a large and trained abuse staff. :^) Cases reported by DMARC feedback should be reviewed in the same manner as any possible abuse would. In this case, the source domain will have been validated. If there is any evidence of abuse, they don't get authorized. I should have added scopes to indicate a decision has been made to squelch further processing. 'x' for See Abuse Desk. After that, blocked domains would need to contact the abuse desk. I'll add that feature. > So, yeah, I sympathize with the Mom & Pop shops whose kids go hungry > this month because the bills didn't go out, and with the small > operations tearing their hair out because they've got a thousand > paying customers at Yahoo! whose content isn't arriving at > destination, but I really don't see TPA-Labels as a solution to this > problem yet. In the case of Intuit, likely one TPA-Label would have solved the problem once DMARC evaluation confirms with the _smtp._tpa zone. With TPA-Label, kids won't go to sleep hungry. :^) >>> Again, I seem to require an additional clue. DMARC feedback is >>> working fine AFAICS. It may be costly, and we want to reduce those >>> costs, of course. But "p=reject" OTOH is a more or less legitimate >>> denial of service, a completely different issue. Are you talking >>> about a different kind of feedback? >> >> Rather than having a channel only between receiver-to-sender, there >> should also be a channel between sender-to-receiver. > > We already have such a channel (the _dmarc subdomain). What is this > new channel for? A single TXT record is hardly a reverse channel since it is unable to communicate the necessary range of exceptions DMARC really needs. In the case of PayPal and others, most initially made the mistake of posting to various mailing lists. They should have responded to these early signs a better scheme was needed to encompass actual use even when devised for only transactional email. That was not always the case then, and it clearly is not the case now. The TPA-Label, unlike SPF does not chain together a sequence of TXT resource records. All information is contained in a single small resource record at a single unique label which would represent a negligible overhead in comparison. Use of http would be much slower by adding a connection setup delay without any caching. We need to find an expedient and quick to implement solution where most of the burden is handled by the sender requesting the DMARC policy. That is only fair. Regards, Douglas Otis ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists
Douglas Otis writes: > https://community.intuit.com/questions/899989-please-make-quickbooks-pass-the-dmarc-evaluation-please-do-this-quickly Grr. Doesn't describe the problem! Is it that a QuickBooks client using a mailbox at a "p=reject" domain is having QuickBooks send invoices on their behalf? If that's it, I have a great deal for them. Register a domain and get their company name, instead of Yahoo!'s, in From:. Or (cheaper), Quickbooks just checks for "p=", and if so overrides any company-specific config, and puts QuickBooks in From: (with a working "p=reject" policy, even!), "Your invoice from " in subject, and the company address in Reply-To. Even supposing the company doesn't like either of those options, it's not clear to me that the "p=reject" domain is going to necessarily be happy trusting QuickBooks, even once TPA-Labels gets implemented. > I know of many small operations with similar services and > previously working strategies. Much less so the effort required to vette a million small operations (who could actually be the Yahoo! customer requesting a TPA-label for a vendor they use -- how does TPA-label deal with collusion between authors and relays?) So, yeah, I sympathize with the Mom & Pop shops whose kids go hungry this month because the bills didn't go out, and with the small operations tearing their hair out because they've got a thousand paying customers at Yahoo! whose content isn't arriving at destination, but I really don't see TPA-Labels as a solution to this problem yet. > > Again, I seem to require an additional clue. DMARC feedback is > > working fine AFAICS. It may be costly, and we want to reduce those > > costs, of course. But "p=reject" OTOH is a more or less legitimate > > denial of service, a completely different issue. Are you talking > > about a different kind of feedback? > > Rather than having a channel only between receiver-to-sender, there > should also be a channel between sender-to-receiver. We already have such a channel (the _dmarc subdomain). What is this new channel for? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
Tony Hansen writes: >> That doesn't help the DMARC situation now, but DMARC could be >> given other options once that happens. > > I agree completely that a change to DMARC is needed in conjunction > with having clear ML specs. A change to the protocol? What? I don't see it. The protocol actually in use by many domains seems to actually do what it's designed for quite well. "p=reject" makes a lot of sense for banks, for example. I don't think it can be removed from the spec, and its proper use doesn't cause widespread problems for mailing lists. It's use outside the design space that causes problems. Those uses are by desperate organizations, and they'll ignore any change that attempts to prohibit them because they are desperate. > I've heard it said that the majority of the mailing lists out there > are managed by only a handful of ML management systems. I maintain > that these ML packages are in the same boat as openssl. It sure > would be nice if we could get some of that consortium money thrown > at that handful of ML management systems. I'm sorry, but that's nonsense for the volunteer-maintained MLMs like GNU Mailman. We already have implemented multiple mitigations, and it doesn't take much code. We just hate them all and leave it up to mailing list operators to choose the one they dislike least. If other MLMs haven't done so already, I doubt it involves all that much effort for them. > That's a political solution for this current technical problem. Mailing lists don't have a *technical* problem. If DMARC were used as designed, we'd never have noticed. The problem is political: we have a wounded 800-lb gorilla on the loose (not to forget a wounded 500-lb gorilla joining the fun). > However, before it can happen: we NEED clear specs as to what > should be done by ML systems, at least in the face of DKIM and SPF > (and DMARC) SPF and DKIM are now ancient history, at least as far as Mailman development goes. We've already done what's technically possible. We'll see what more our users want us to do about DMARC, if anything. There just isn't anything technical to be done AFAICS. I can't speak for other MLMs, but I think that if there's going to be real progress, the answer is with the MUAs. 1. If identity alignment fails, *all* links, scripts, and forms in the message should be deactivated, even if it's already in the spam folder. 2. If there's a type=password field in the message, *all* links and forms in the message should be deactivated, even if it's already in the spam folder. 3. Ditto misaligned MIME type and file name. 4. Ditto active or unknown attachments. 5. On activation of the message, all href and src URIs should be displayed clearly, along with an intrusive warning that ID theft is very common, so the user should check everything carefully (preferably call the author on the phone) before doing anything suggested by the message, even if it's already in the spam folder. I'm sure there are other things they could do, but those are off the top of my head. Finally, Tim Draegen is right, it's not just about mailing lists. Let's not forget all the other use cases that are stomped on by the inappropriate use of "p=reject". Steve ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
Elizabeth Zwicky writes: > So changes that maintain effective protection for users who are > being targeted by attackers with addressbook information, with less > disruption to email that people want, are of great interest to us. How about trying "p=quarantine" with a real short TTL just in case? After a while you crank it back up to the current level (which is only 1800 in any case). The argument is that, seriously, since the attackers have addressbook information, you're done for anyway. They're already hard at work on Plan B, using "I'm writing this from my friend's account" with self in Sender: (should work well on Outlook users despite having on-behalf-of point the wrong direction), and ... Heck, I've already thought of a dozen of these dodges and my name isn't even Laurence Canter. I think it's worth a check to see if the miscreants will bother to come back at you with the previous style of spam shot even though they should expect that the vast majority of their spam will get rejected anyway (messages apparently from a "p=quarantine" domain should be given a rough time as encouraged by the DMARC protocol), and the rest will end up in spam folders. I would think trying to avoid DMARC entirely would now be the best use of their resources, so maintaining quarantine should be enough. There may be some directly relevant recent evidence on this, since GMail is evidently promoting mailing list traffic from "p=reject" domains to "quarantine". If the spammers know this, they could continue targeting GMail customers in their stolen addressbook database. Dunno if GMail will tell Yahoo!, but you could ask. BTW I hope you guys are basing "p=reject" (vs. "p=quarantine") on real data on how often fraudulent mail that ends up in spam folders actually succeeds in harming the targeted victim. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
On 05/30/2014 11:28 AM, Stephen J. Turnbull wrote: > I am of the opinion that the technical DMARC protocols (including > "p=reject") are fine. I have not heard of any complaint about use by > banks (Bank of America joined the ranks of "p=reject" banks some time > in the last 10 days AFAICT). Have there been any? Disclosure: Technically I could be considered on BofA payroll through tomorrow. In essence I stopped being their employee earlier this year. While BofA does have some domains with "p=reject" they had not, so far as I know, published such a policy on a domain that sent email as part of a product or service. There were at least two product teams that were working to do so, and one of them had a "p=quarantine" published but hadn't solidified plans of when they would start sending email. The fact that this hadn't happened by nearly two years after the first release of the DMARC spec was not because I wasn't pushing for it... If you really want to know, I would look for anecdotes around JPMChase, who managed to publish "p=reject" for many if not all of their most visible production domains over a year ago, if I have the timeframe right. But I'm not aware of any complaints about DMARC when used in the manner you're referring to. --Steve. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
Murray S. Kucherawy writes: > > DMARC change is even more off the table than MLM software change > > (which does, as you suggest, evolve over time). > > Are there changes people want to make? I am of the opinion that the technical DMARC protocols (including "p=reject") are fine. I have not heard of any complaint about use by banks (Bank of America joined the ranks of "p=reject" banks some time in the last 10 days AFAICT). Have there been any? I'm sure that the probability of technical bugs in the protocols remaining is not zero, but I imagine they'll be fixed as discovered. I believe that is also the opinion of the Mailman developers (specifically, they've seen a document where I expressed a similar opinion and generally expressed approval of the document as a whole). The issue is use of "p=reject" by ESPs whose users think they can send mail to anywhere they want. I would like the logical consequences of unilateral publication of "p=reject" without prior arrangement with *all* possible relays spelled out. Something like: Publishing a DMARC policy including "p=reject" has the following consequences. Users who attempt to 1. post to a mailing list 2. use QuickBooks 3. send content to a friend from the Wall Street Journal etc, etc may find their message bounces or is silently discarded. This is expected according to the DMARC specification when faithfully implemented, even when all services in all domains are functioning normally and in conformance to all relevant Internet standards. ESPs SHOULD notify their users of these consequences at the time of publishing a policy including "p=reject". N.B. I haven't discussed this with the Mailman community, but I suspect they would approve. As a technical specification of what the ESP refuses to fully support by publishing "p=reject", I think the list Franck Martin posted is a pretty good start. To ESPs who object, "But that's not what we meant!" I reply, "I know. But Code is Law, everything else is cheap talk. Those are the results *your* protocol and *your* policy say *your* users should expect. Why don't you want to tell them about it? After all, you're doing it for them. Your users will undoubtedly be overjoyed to discover how hard you are fighting spam on their behalf, right?" ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
On Friday, May 30, 2014 17:07:30 Elizabeth Zwicky wrote: > On 5/29/14, 8:44 PM, "Scott Kitterman" wrote: > >DMARC change is even more off the table than MLM software change (which > >does, > >as you suggest, evolve over time). > > DMARC changes are not off the table for Yahoo. Right now, the option that > best serves the majority of our customers is one that also has unpleasant > consequences for a significant number of people (our customers and > others). We would vastly, vastly prefer a world where that was not true, > or even where it was less true. > So changes that maintain effective protection for users who are being > targeted by attackers with addressbook information, with less disruption > to email that people want, are of great interest to us. Great. Then instead of submitting DMARC as is via a non-IETF process, let's have a working group chartered to do that work. I'm glad to hear it. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
On 5/29/14, 8:44 PM, "Scott Kitterman" wrote: >DMARC change is even more off the table than MLM software change (which >does, >as you suggest, evolve over time). DMARC changes are not off the table for Yahoo. Right now, the option that best serves the majority of our customers is one that also has unpleasant consequences for a significant number of people (our customers and others). We would vastly, vastly prefer a world where that was not true, or even where it was less true. So changes that maintain effective protection for users who are being targeted by attackers with addressbook information, with less disruption to email that people want, are of great interest to us. Elizabeth Zwicky zwi...@yahoo-inc.com ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
On May 30, 2014 3:37:28 AM EDT, "Murray S. Kucherawy" wrote: >On Thu, May 29, 2014 at 8:44 PM, Scott Kitterman >wrote: > >> The reason there is no IETF working group is that the people behind >DMARC >> were >> unwilling to entertain participation in a working group that had a >charter >> that allowed for any chance of a change to the DMARC protocol. >> > >I think that's a bit hyperbolic. There was perhaps too much emphasis >on >protecting the deployed base, but had they been confronted with actual >data >about something that wouldn't work (rather than the typical theory-only >assertions on which working groups like to rathole), there would have >been >ample justification for a change. > > >> DMARC change is even more off the table than MLM software change >(which >> does, >> as you suggest, evolve over time). >> > >Are there changes people want to make? So far all I've seen is >"something >needs to change", but nothing concrete, or at least nothing that has >garnered consensus of some sort. > > >> I wrote the other day asking what IETF work is there around DMARC and >> didn't >> get much of an answer. I think that's instructive. > > >I think that conclusion is premature. At this point, I could probably craft a reasonable problem statement. I don't know what the solution is, but the solution space is certainly different if DMARC changes to deal with the current mess are on the table. Currently such changes aren't up for consideration, so no one is expending much mental energy in that direction. It's not even an IETF specification. Change the potential solution space and you'll change the discussion. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
On Thu, May 29, 2014 at 8:44 PM, Scott Kitterman wrote: > The reason there is no IETF working group is that the people behind DMARC > were > unwilling to entertain participation in a working group that had a charter > that allowed for any chance of a change to the DMARC protocol. > I think that's a bit hyperbolic. There was perhaps too much emphasis on protecting the deployed base, but had they been confronted with actual data about something that wouldn't work (rather than the typical theory-only assertions on which working groups like to rathole), there would have been ample justification for a change. > DMARC change is even more off the table than MLM software change (which > does, > as you suggest, evolve over time). > Are there changes people want to make? So far all I've seen is "something needs to change", but nothing concrete, or at least nothing that has garnered consensus of some sort. > I wrote the other day asking what IETF work is there around DMARC and > didn't > get much of an answer. I think that's instructive. I think that conclusion is premature. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
Dear Tony, See comments inline: On May 29, 2014, at 8:11 PM, Tony Hansen wrote: > On 5/28/14, 6:46 PM, Barry Leiba wrote: >> Anything that requires mailing list software to change won't work. > > I'm going to push back on this statement. I think we keep getting stuck on > the mantra that "the mailing list software won't change". However, the > majority of the mailing list software packages that are out there now DO > generate proper List-* headers. It took some time, and it may not be 100% > coverage, but by gosh and by golly, most of them do so and do it correctly. I agree with Barry. It is not just getting tens of thousands of mailing-lists updated into something that offers what is surely going to be a substandard user interface. This also means ensuring the added list headers allow selecting a particular participant in a straight forward manner. And that this selection also operates in conjunction with MUAs. There is a sizable variation in this regard, many of which will not facilitate this ability. The next question that needs to be considered is the timeframe for such migration. How many years is reasonable? Secondly, what can be done to help facilitate various informal services to permit them to be effective at acting on behalf of their clients while still ensuring the From header field contains an identity the eventual recipient will recognize? It seems that in order to be able to do this, a way to make exceptions for Sender header fields is needed as well. If making exceptions for Sender header fields can be accommodated, then simply make this exception for List-ID headers too. Any effort at arranging domain alignments will be shuffling around where people must look to understand who substantially originated the content. Keeping these changes to a minimum would be ideal. After all, these changes will create a fair amount of confusion for recipients, where they then become vulnerable to a whole new range of deceptions. As it is now, most have already begun to ignore DMARC assertions placed against user accounts which then degrades even modest protections this may have initially offered. Perhaps you might also consider: https://community.intuit.com/questions/899989-please-make-quickbooks-pass-the-dmarc-evaluation-please-do-this-quickly I know of several other professional services sending email on behalf of their clients. It seems these situations also run afoul of this rather simplistic DMARC approach. > Why? There were a few things: 1) a well defined spec about what change was > desired, AND 2a) there was perceived benefit to adding those headers, or 2b) > there was perceived harm in not adding those headers. Hmmm. Perhaps we could call this new header "Sender". ;^) >> If mailing list software is changed, the right answer is for the mailing >> list to re-sign the message. > > I think this is exactly the correct solution for mailing lists to pursue. > This is an excellent start of a spec for what mailing lists should be doing > in a world where systems are using DKIM and SPF, and more systems are > expecting such mail to pass validation. (A post-DMARC world, if you will.) How many people have problems with mailing-lists? After all, problematic lists fade away rather quickly. The real issue was caused by millions of users accounts being compromised. The providers that even played a small role in that problem should contribute to what should also be an expedient solution. The described changes to lists and many many other services will never offer an expedient solution for several very difficult and important reasons. Mailing-lists have not caused this problem, and yet the same ESPs are expecting mailing-lists and the like to handle a major portion of the change. This change is to permit From header field alignment with the source or a replay-able signed message fragment. This rather dramatic change moves email a large distance into becoming a far less versatile peer-to-peer protocol. Perhaps it would be simpler to move SMTP to historic and adopt use of XMPP instead? After all, that service already offers the concept of federated services and does not offer any mailing list feature at this time. After all, it is hard to get ad impressions shipping around signed messages. ;^P > There may be alternative solutions that are less optimal that will also get > mailing list messages delivered more reliably. (For example, delete all DKIM > signatures and force the From: header to use the originator's name in the > comment but with the mailing list address instead of the originator's > address. It works, but isn't pretty.) It might be worth doing some > investigation of those alternatives, and showing their advantages and > disadvantages. I have setup and run systems that tracked email from several very large ISPs of all used IPv4 addresses. Taking in the entire inbound traffic and comparing it to what was hitting vari
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
On Thursday, May 29, 2014 23:11:28 Tony Hansen wrote: > On 5/28/14, 6:46 PM, Barry Leiba wrote: > > Anything that requires mailing list software to change won't work. > > I'm going to push back on this statement. I think we keep getting stuck > on the mantra that "the mailing list software won't change". However, > the majority of the mailing list software packages that are out there > now DO generate proper List-* headers. It took some time, and it may not > be 100% coverage, but by gosh and by golly, most of them do so and do it > correctly. > > Why? There were a few things: 1) a well defined spec about what change > was desired, AND 2a) there was perceived benefit to adding those > headers, or 2b) there was perceived harm in not adding those headers. > > > If mailing list software is changed, the right answer is for the mailing > > list to re-sign the message. > > I think this is exactly the correct solution for mailing lists to > pursue. This is an excellent start of a spec for what mailing lists > should be doing in a world where systems are using DKIM and SPF, and > more systems are expecting such mail to pass validation. (A post-DMARC > world, if you will.) > > There may be alternative solutions that are less optimal that will also > get mailing list messages delivered more reliably. (For example, delete > all DKIM signatures and force the From: header to use the originator's > name in the comment but with the mailing list address instead of the > originator's address. It works, but isn't pretty.) It might be worth > doing some investigation of those alternatives, and showing their > advantages and disadvantages. > > Mailing lists have an expectation of being able to get their mail > delivered. That is no longer the case. The benefit of them making > changes is that their messages will get delivered more reliably. The > harm in not making changes is that their service will continue to be > unreliable. > > But clear specs detailing what they CAN do and SHOULD do is the starting > point. > > > That doesn't help the DMARC situation > > now, but DMARC could be given other options once that happens. > > I agree completely that a change to DMARC is needed in conjunction with > having clear ML specs. > > > When HeartBleed came out recently, it was discovered that openssl had > rather poor support, even though everyone and their neighbor seems to > use it in some fashion or another. A consortium was then formed to > provide some needed support and to improve the quality control for openssl. > > I've heard it said that the majority of the mailing lists out there are > managed by only a handful of ML management systems. I maintain that > these ML packages are in the same boat as openssl. It sure would be nice > if we could get some of that consortium money thrown at that handful of > ML management systems. That's a political solution for this current > technical problem. > > However, before it can happen: we NEED clear specs as to what should be > done by ML systems, at least in the face of DKIM and SPF (and DMARC) The reason there is no IETF working group is that the people behind DMARC were unwilling to entertain participation in a working group that had a charter that allowed for any chance of a change to the DMARC protocol. DMARC change is even more off the table than MLM software change (which does, as you suggest, evolve over time). Yahoo's view, based on their public statements clearly seems to me to be that using DMARC p=reject is beneficial to them and they are big enough that 3rd parties will adapt rather than suffer the consequences of not adapting. I believe they are right on both counts. Mailing lists and other related systems that are affected by this are adapting. It's painful and the solutions inevitably involve regressions in functionality, but they are one of the few 800 pound gorillas and they can get away with it. I am entirely sympathetic to people that are unhappy about this state of affairs (I'm unhappy about it too), but it is what it is. I wrote the other day asking what IETF work is there around DMARC and didn't get much of an answer. I think that's instructive. I'm increasingly convinced that there isn't any. At this point, while there's value in a central point for operators and developers to exchange information about how to mitigate the damage caused by what is in my opinion irresponsible use of DMARC, I don't think there is anything to standardize. Eventually, there's probably a BCP in this, but it's premature. If the IETF tries to go off and write a BCP on DMARC work arounds now, we'll end up looking silly by the time the metaphorical ink is dry. We've all got lots of ideas on practices that would be a good idea, but many of them are new enough they can only barely be described as current and knowing what among them is best is premature. Scott K ___ dmarc mailing list dmarc@ietf.org
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
On 5/28/14, 6:46 PM, Barry Leiba wrote: Anything that requires mailing list software to change won't work. I'm going to push back on this statement. I think we keep getting stuck on the mantra that "the mailing list software won't change". However, the majority of the mailing list software packages that are out there now DO generate proper List-* headers. It took some time, and it may not be 100% coverage, but by gosh and by golly, most of them do so and do it correctly. Why? There were a few things: 1) a well defined spec about what change was desired, AND 2a) there was perceived benefit to adding those headers, or 2b) there was perceived harm in not adding those headers. If mailing list software is changed, the right answer is for the mailing list to re-sign the message. I think this is exactly the correct solution for mailing lists to pursue. This is an excellent start of a spec for what mailing lists should be doing in a world where systems are using DKIM and SPF, and more systems are expecting such mail to pass validation. (A post-DMARC world, if you will.) There may be alternative solutions that are less optimal that will also get mailing list messages delivered more reliably. (For example, delete all DKIM signatures and force the From: header to use the originator's name in the comment but with the mailing list address instead of the originator's address. It works, but isn't pretty.) It might be worth doing some investigation of those alternatives, and showing their advantages and disadvantages. Mailing lists have an expectation of being able to get their mail delivered. That is no longer the case. The benefit of them making changes is that their messages will get delivered more reliably. The harm in not making changes is that their service will continue to be unreliable. But clear specs detailing what they CAN do and SHOULD do is the starting point. That doesn't help the DMARC situation now, but DMARC could be given other options once that happens. I agree completely that a change to DMARC is needed in conjunction with having clear ML specs. When HeartBleed came out recently, it was discovered that openssl had rather poor support, even though everyone and their neighbor seems to use it in some fashion or another. A consortium was then formed to provide some needed support and to improve the quality control for openssl. I've heard it said that the majority of the mailing lists out there are managed by only a handful of ML management systems. I maintain that these ML packages are in the same boat as openssl. It sure would be nice if we could get some of that consortium money thrown at that handful of ML management systems. That's a political solution for this current technical problem. However, before it can happen: we NEED clear specs as to what should be done by ML systems, at least in the face of DKIM and SPF (and DMARC) Tony Hansen ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists
On May 29, 2014, at 7:07 AM, Stephen J. Turnbull wrote: > Douglas Otis writes: > >> There are many cases that are never originally signed by the DMARC >> domain. Such as an accounting package that sends out invoices on >> behalf of some company that wants their email address in the From >> header since this is what their customers will recognize. > > I don't understand this example. This use case seems quite compatible > with DMARC as it is. > > That is, company and accountant should have a substantial and > expensive to maintain trust relationship already. I would think that > the company could (a) provide an alias (subdomain) in its own domain > for the accountant's host, and advertise the accountant's policy via > _dmarc.invoices.example.com, or (b) maintain an authenticated channel > (ie, special purpose VPN) direct to a special host under its own > control in its own domain for the accountant to relay through, and the > company signs there. Sure, there'd be some additional cost, but not > prohibitive. Note that in either case the client can fire the > accountant in an instant by changing the DNS or shutting down the > authenticated channel. Dear Stephen, https://community.intuit.com/questions/899989-please-make-quickbooks-pass-the-dmarc-evaluation-please-do-this-quickly I know of many small operations with similar services and previously working strategies. With a low profit margin, no one wants to then be dealing with DNS or VPN configurations or deciding who is allowed to have access to their networks or their DKIM private keys. Think of the heating and air conditioning outfit given VPN access for the purpose of submitting invoices. That error in judgement cost hundreds of millions for a well known retailing outfit. There are also similar types of risks when anyone opens any MS Office document given to them by a spoofed party. http://krebsonsecurity.com/2014/05/the-target-breach-by-the-numbers/ The intent behind TPA-Label is to permit a secure scheme without ever asking anyone to share credentials. Not ever! Instead, everyone uses what they already have, perhaps even stronger schemes than what is offered by DKIM or SPF. Large ESPs that have had a major security breach should set aside a budget related to restoring order. A TPA-Label setup could be part of that effort. Two DNS servers (for redundancy) and some DMARC and MTA log processing scripts should offer a comprehensive and fairly complete starting point. Yes, even for a large ESP. Of course there will be ongoing support issues, but this should also pale in comparison to unsolvable email complaints of affected legitimate email use. For this, there should be web-based forms to supplement DMARC feedback. By setting up a TPA-Label extension, it would also allow their users to know when they have themselves been compromised, while also preventing unauthorized use by rogue servers. This added feature seems like a nice way of saying "Sorry, but we are now doing more to improve security." >>> I suspect that many parties that implement DMARC are "cheating" >>> by allowing things that look like mailing list or forwarded mail >>> through even if they fail auth and the domain is p=REJECT. >>> Providing a higher bar for when to "cheat" may be useful, then. > >> The hurdle that seems to be in everyone's mind is how to go about >> facilitating feedback that is not a lot of work. Again, TPA-Label also permits a way to squelch DMARC feedback already evaluated. Perhaps a flag could even be added that basically says. "Yes we know about this domain, and we think it cannot be trusted." This would be a change to the current draft. > Again, I seem to require an additional clue. DMARC feedback is > working fine AFAICS. It may be costly, and we want to reduce those > costs, of course. But "p=reject" OTOH is a more or less legitimate > denial of service, a completely different issue. Are you talking > about a different kind of feedback? Rather than having a channel only between receiver-to-sender, there should also be a channel between sender-to-receiver. The channel can represent a single DNS resource record. Such a single resource record would offer low latency, low cost, and cacheable near the receiver for even lower latency. I know that John and Tim would have little trouble setting up such a service. The real challenge is to have an ESP do this that really needs such a solution. Once in place, this opens up a range of services others could easily offer on behalf of those who simply desire greater email security. Regards, Douglas Otis ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists
Douglas Otis writes: > There are many cases that are never originally signed by the DMARC > domain. Such as an accounting package that sends out invoices on > behalf of some company that wants their email address in the From > header since this is what their customers will recognize. I don't understand this example. This use case seems quite compatible with DMARC as it is. That is, company and accountant should have a substantial and expensive to maintain trust relationship already. I would think that the company could (a) provide an alias (subdomain) in its own domain for the accountant's host, and advertise the accountant's policy via _dmarc.invoices.example.com, or (b) maintain an authenticated channel (ie, special purpose VPN) direct to a special host under its own control in its own domain for the accountant to relay through, and the company signs there. Sure, there'd be some additional cost, but not prohibitive. Note that in either case the client can fire the accountant in an instant by changing the DNS or shutting down the authenticated channel. > > I suspect that many parties that implement DMARC are "cheating" > > by allowing things that look like mailing list or forwarded mail > > through even if they fail auth and the domain is p=REJECT. > > Providing a higher bar for when to "cheat" may be useful, then. > The hurdle that seems to be in everyone's mind is how to go about > facilitating feedback that is not a lot of work. Again, I seem to require an additional clue. DMARC feedback is working fine AFAICS. It may be costly, and we want to reduce those costs, of course. But "p=reject" OTOH is a more or less legitimate denial of service, a completely different issue. Are you talking about a different kind of feedback? Steve ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists
On 5/28/2014 9:47 PM, Arvel Hathcock wrote: Anything that requires mailing list software to change won't work. If mailing list software is changed, the right answer is for the mailing list to re-sign the message. That doesn't help the DMARC situation now, but DMARC could be given other options once that happens. That's right. But maybe there could be a multipart/dkim type that lets several signatures exist in a message - all of which could potentially verify with different d=. Then the list only needs to sign what it adds to the end somehow and it leaves the rest of the message alone. Seems like we went over this way back years ago but I'm old now :) Yup, and the solution was policy. The problem is this group wants to skip doing any kind of policy lookup. We are also list developers. We don't have a free reign on resigning mail without permission, if any. Its irresponsible. It has to follow a policy framework. All software has to follow it. List systems are not the exception. No resigner is an exception and trying to get around this has not worked. Keep it simple -- lookup policy. But DMARC lacks 3rd party semantics, so you need extensions and that was done with ATPS for ADSP. See the wizard that supports it for ADSP and now a new beta using DMARC: http://www.winserver.com/public/wcADSP http://www.winserver.com/public/wcDMARC You can easily add ATPS support to your DKIM C/C++ library. -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists
On 5/28/2014 6:47 PM, Arvel Hathcock wrote: > That's right. But maybe there could be a multipart/dkim type that lets > several signatures exist in a message - all of which could potentially > verify with different d=. Hi Arvel. Great to see you re-entering the fray... Picking a nit: It's not a MIME level issue. It's in the main header. More substantive: Multiple signatures are ok now. And are sometimes done now. So the real challenge is who should sign what and how should it/they get used? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists
Anything that requires mailing list software to change won't work. If mailing list software is changed, the right answer is for the mailing list to re-sign the message. That doesn't help the DMARC situation now, but DMARC could be given other options once that happens. That's right. But maybe there could be a multipart/dkim type that lets several signatures exist in a message - all of which could potentially verify with different d=. Then the list only needs to sign what it adds to the end somehow and it leaves the rest of the message alone. Seems like we went over this way back years ago but I'm old now :) Arvel Disclaimer: This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists
On May 28, 2014, at 4:05 PM, Brandon Long wrote: > > > > On Wed, May 28, 2014 at 3:46 PM, Barry Leiba wrote: > > We could attempt to define a dkim canonicalization that would pass through a > > mailing list. > > This was beaten pretty severely during the DKIM work, and we couldn't > come up with anything that was workable. > > > It should include the subject, but have rules for stripping "standard" > > subject prefixes. It should obviously include other headers, but not List-* > > headers (since the RFC for those says the mailing list should strip the > > existing ones). > > > > The body is challenging. We could have it specify a length... that does > > allow for some weirdness with html positioning. We could require no-html > > part. > > > > We could optionally require footers to be added as separate parts, and have > > the canonicalization be for "first text part". > > Anything that requires mailing list software to change won't work. If > mailing list software is changed, the right answer is for the mailing > list to re-sign the message. That doesn't help the DMARC situation > now, but DMARC could be given other options once that happens. > > If the mailing list signs and verifies, that's OAR... and then the challenge > becomes knowing when to trust the OAR. Exactly. TPA-Label provides this answer. > Also, it seems to me that mailing lists without changes and DMARC are > basically incompatible, so I'm unclear of any solution that will allow them > to work unchanged. Again, TPA-Label provides this answer. By the way, the TPA-Label draft has been updated to include Original-Authentication-Results draft reference which also states this concern as well. > We discussed using l= at (um...) length, and no one liked that > approach. There were too many holes, yes: allowing arbitrary amounts > of data to be added to the message text, having it fail anyway if text > isn't added at the end (such as for multipart messages), and so on. > > Heuristics involved in tweaking the subject are problematic. > > Some of this could perhaps work if we had a canonicalization that was > *specific* to mailing list posts... but then how would the signing > domain know that the message it was signing was going to a mailing > list? > > Theoretically, a client could easily know its a mailing list in most cases, > but yes, where the signing often occurs, its unlikely to know. The easiest > thing to do would be to sign it both ways, and then the receiver might only > trust the mailing list canonicalization if it went through a mailing list... > and of course that can be forged as well. That is what spam-traps and DMARC feedback provides. When a problem is detected and reported to the DMARC domain, the response can be to withdraw authorization and report problems to third-party service providers. Fast and easy. Depending on the urgency, it would be nicer to report problems to the service provider and give then an opportunity to fix issues before causing an unnecessary disruption. The point is to ensure everyone has an incentive to cooperate. There are many cases that are never originally signed by the DMARC domain. Such as an accounting package that sends out invoices on behalf of some company that wants their email address in the From header since this is what their customers will recognize. > I really think this isn't a useful approach, but perhaps someone might > come up with the necessary "aha" to make it work. > > I think it depends on what the goal is. If the goal is "unforgeable messages > through a mailing list to pass DMARC", then yes, this is probably not going > to work. The only solution there is for the mailing lists to actually not > munge messages. > > I might argue that "if the mailing list is going to munge the message, then > it needs to munge From as well"... but there seems to be a fairly high > resistance to that. This would be an understatement which also ignores other valid uses. People might remember someone said something profound without recalling related details. Not being able to search through their message stream would be fairly frustrating. Not all mailing lists offer usable reference header fields for such use (perhaps to ensure user privacy). References: might not be something that can be used by most MUAs to review what someone said in the past, for example > I suspect that many parties that implement DMARC are "cheating" by allowing > things that look like mailing list or forwarded mail through even if they > fail auth and the domain is p=REJECT. Providing a higher bar for when to > "cheat" may be useful, then. > > Now, my anti-spam colleagues will say that any hole will eventually be > exploited... but given that I don't see how we can make this work with no > holes, and if we can't change mailing lists... and any sort of whitelisting > is adding a hole... I feel like I'm in a circular argument. The hurdle that seems to
Re: [dmarc-ietf] DKIM through mailing lists
> We could attempt to define a dkim canonicalization that would pass through a > mailing list. This was beaten pretty severely during the DKIM work, and we couldn't come up with anything that was workable. > It should include the subject, but have rules for stripping "standard" > subject prefixes. It should obviously include other headers, but not List-* > headers (since the RFC for those says the mailing list should strip the > existing ones). > > The body is challenging. We could have it specify a length... that does > allow for some weirdness with html positioning. We could require no-html > part. > > We could optionally require footers to be added as separate parts, and have > the canonicalization be for "first text part". Anything that requires mailing list software to change won't work. If mailing list software is changed, the right answer is for the mailing list to re-sign the message. That doesn't help the DMARC situation now, but DMARC could be given other options once that happens. We discussed using l= at (um...) length, and no one liked that approach. There were too many holes, yes: allowing arbitrary amounts of data to be added to the message text, having it fail anyway if text isn't added at the end (such as for multipart messages), and so on. Heuristics involved in tweaking the subject are problematic. Some of this could perhaps work if we had a canonicalization that was *specific* to mailing list posts... but then how would the signing domain know that the message it was signing was going to a mailing list? I really think this isn't a useful approach, but perhaps someone might come up with the necessary "aha" to make it work. Barry ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
