Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D
On Fri 05/Jun/2020 13:45:18 +0200 Hector Santos wrote: > On 6/5/2020 6:34 AM, Alessandro Vesely wrote: >> > >> For completeness, I'd also mention conditional signatures, as a fifth point. >> They were specified, implemented and then abandoned in lieu of ARC. > > h, interesting. Where was the "Conditional Signature" proposal > implemented? OpenDKIM implemented it "conditionally", that is configure --enable-conditional > I have never come across a conditional signature header. I was not aware ARC > was a "conditional signature" or "3rd Party Authorization" protocol. IMO, ARC > has a high barrier of entry with an awful amount of complexity to implement in > order to authorize a 3rd party domain. ARC has nothing to do with conditional signatures, except for the fact that it seemed to contend by which end, sending or receiving, should the mailing list problem be tackled. In May 2016 John wrote: One approach to what we can oversimplify as the mailing list problem is to do it from the sending end, with the sender using something like conditional double signatures to say mutated messages are OK. The other is to provide data that the recipient can use to decide these mutations are OK. ARC is definitely in the latter camp, and it would be painful to have both ends arguing about how OK stuff is. [https://mailarchive.ietf.org/arch/msg/dmarc/BUmNmm9aODMhY_6jdM7Y52S-o7E/] Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D
On 6/5/2020 6:34 AM, Alessandro Vesely wrote: 4) Require all recipient systems to make special policy accommodations to grant trust to messages from List B, simply because it comes from List B. This is feasible, but specific to each participants incoming email filter. This is a hindrance to DMARC adoption. The need to catch and mark all the mailing list domains that don't rewrite From: can prevent an MTA from blindly conforming to all DMARC policies. Alternatively, an MTA can mark highly abused domains and conform to DMARC policies in those cases only. It doesn't have to be all mailing list, just the ones authorized to resign on your behalf. Of course, there are scalability issue with the "bigger guy" but that should not preclude the "smaller guy" from leveraging this method. For completeness, I'd also mention conditional signatures, as a fifth point. They were specified, implemented and then abandoned in lieu of ARC. h, interesting. Where was the "Conditional Signature" proposal implemented? I have never come across a conditional signature header. I was not aware ARC was a "conditional signature" or "3rd Party Authorization" protocol. IMO, ARC has a high barrier of entry with an awful amount of complexity to implement in order to authorize a 3rd party domain. -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D
On 6/4/2020 6:31 AM, Douglas E. Foster wrote: MAILING LISTS. The mailing list problem can be stated as follows: * Domain B wants to operate a mailing list. * The list owner will accept messages from domain A, alter them, then re-transmit the altered message to member C. * List owner B wants the mail filter for member C to guarantee that his list messages are granted the same trust level as a message sent directly from A to C without alteration. This problem is unsolvable because it is unreasonable. Hi Douglas -1. I have to respectfully disagree with this. Using the proper protocol, Domain A can reasonably declare, with certainty, to explicitly and deterministically authorize the Domain B resigner where the Domain C receiver can verify whether Author Domain A 3rd party policy allows Domain B to resign. It is done with DMARC with the add-on ATPS by adding an extended tag "atps=y" to your DMARC record. My DMARC record for my domain isdg.net is: v=DMARC1; p=reject; atps=y; rua=mailto:dmarc-...@isdg.net; ruf=mailto:dmarc-...@isdg.net;; The isdg.net domain zone has authorized the following domains with the ATPS records: e4qssg6j6f6vggflfwk56n6ppxlbglmu._atps TXT ( "v=atps01; d=megabytecoffee.com;" ) jchjykxmwknbyfge2bg4td6add264olh._atps TXT ( "v=atps01; d=winserver.com;" ) kjshf2duqstols65zbhuytbbyr3zdecf._atps TXT ( "v=atps01; d=gmail.com;" ) lykm653kj7yxeia665va7lszzthcx7jj._atps TXT ( "v=atps01; d=beta.winserver.com;" ) n3lsehml2wgbfxov7hsak2qzsubsefhb._atps TXT ( "v=atps01; d=mipassoc.org;" ) pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT ( "v=atps01; d=ietf.org;" ) rni5mcktu7c46wfgxg4mhhnv4t62bi3y._atps TXT ( "v=atps01; d=mapurdy.com.au;" ) tudfisabn5dz3vjm2kxcehc5attdbqh6._atps TXT ( "v=atps01; d=santronics.com;" ) It works very well. If you wish to explore this, this wizard is available: https://secure.winserver.com/public/wcDmarc Use the simulator in the wizard to show proof of concept. The options for creating trust in indirect mail have been discussed in another RFC. Which one? With the exception of VBR, I am not aware of any IETF-based Signer Domain DKIM Trust/Vouching Protocol. Until we have a 3rd party authorization system in play, the Signer Trust can not be established. It would be unreasonable for Domain C to blindly use some unknown Trust Authority to all incoming domain As coming from Domain Bs. On the other hand, if the Domain A, explicitly said something in the DMARC record such as: v=DMARC1; p=reject; trust=trust1.example,trust2.example; . Then Domain C can check for some "trust" protocol where it will look up poll a trust service, trust1.example or trust2.example. Maybe the trust service will give DOMAIN A some zone records specific to the trusted resigners. Either way, the process model would be: trust.result = DKIM_TRUST(Author.Domain, Sender.Domain[, User.Agent.Identity]) Is this unreasonable? I don't think so, but we don't have it. Again, VBR is similar to this. It has a lookup method where you combine the author domain with the signer domain plus other spam-based tags specific to the type of mail, or something like that. Note, it was always my technical opinion, DKIM std incorrectly attempted to remove the Author Domain Identity from the DKIM base protocol, but instead it attempted to replace the DKIM Policy model was a DKIM Trust model, so the process prototype would be: trust.result = DKIM_TRUST(Sender.Domain[, User.Agent.Identity]) But as expected, this trust model never materialize but instead the self-signing DKIM Policy model was too strong to eliminate from the DKIM picture. Add ATPS or a similar 3rd party authorization protocol, and we will get a lot further than we have been since DMARC replaced ADSP without addressing and resolving the 3rd party resigner issue. Finally, my DKIM modeling contention has always been, DKIM is a two pass layer model: - Pass 1, DKIM Policy check using the Author Domain - Pass 2, iff pass 1 is successful, check the signer domain trust. I believe that is what the DKIM Service Overview attempt to depict, by combining two assessment inputs - signing practice/policy and trust info. DomainKeys Identified Mail (DKIM) Service Overview https://tools.ietf.org/html/rfc5585#page-14 -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D
On Thu 04/Jun/2020 12:31:51 +0200 Douglas E. Foster wrote: > MAILING LISTS. > > The mailing list problem can be stated as follows: > > * Domain B wants to operate a mailing list. > * The list owner will accept messages from domain A, alter them, then > re-transmit the altered message to member C. > * List owner B wants the mail filter for member C to guarantee that his list > messages are granted the same trust level as a message sent directly from > A > to C without alteration. > > This problem is unsolvable because it is unreasonable. Starting a message by posing an ill-defined problem does not help clarity. > The options for creating trust in indirect mail have been discussed in > another RFC. Applied to this issue, the options are: > > 1) Make List B the originator by changing the RFC 5321 sender address as well > as the RFC 5322 Message From. Ideally add a DKIM signature for B, in case > the > message is forwarded downstream. This is the IETF list behavior and the only > one that is feasible in practice. This is the *de-facto* standard. As the OP noted, the agent responsible for the transmission should be set in the Sender: field. Instead, mailing lists are forced to rewrite the From: field because of DMARC. IOW, DMARC hijacked From: thereby violating RFC 5322. I agree this point should be fixed, making a real standard of it. I think that would take more than one RFC. > 2) Require all submitting domains to make List B a trusted sender for their > domain by including B in their SPF record This never was an option. Mailing lists used to practice some form of VERP long before SPF. > 3) Configure the list to make no changes, then require all senders to include > DKIM signatures for their own domain. Many lists do so, for example opendkim-users, that some of us are subscribed to. Note that this set-up does not prevent posters from writing "[opendkim-users]" in the Subject: of new messages. Nobody does so, since posts are accepted even without a subject tag, yet it could be easily enforced. > 4) Require all recipient systems to make special policy accommodations to > grant > trust to messages from List B, simply because it comes from List B. This is > feasible, but specific to each participants incoming email filter. This is a hindrance to DMARC adoption. The need to catch and mark all the mailing list domains that don't rewrite From: can prevent an MTA from blindly conforming to all DMARC policies. Alternatively, an MTA can mark highly abused domains and conform to DMARC policies in those cases only. For completeness, I'd also mention conditional signatures, as a fifth point. They were specified, implemented and then abandoned in lieu of ARC. > [...] > > I still do not understand how DMARC does anything other than enhance prior > work > on SPF and DKIM, or how there is any conflict with prior standards. The OP quoted the passage of RFC 5322 where the roles of From: and Sender: are specified. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D
MAILING LISTS. The mailing list problem can be stated as follows: Domain B wants to operate a mailing list.The list owner will accept messages from domain A, alter them, then re-transmit the altered message to member C.List owner B wants the mail filter for member C to guarantee that his list messages are granted the same trust level as a message sent directly from A to C without alteration. This problem is unsolvable because it is unreasonable. The options for creating trust in indirect mail have been discussed in another RFC. Applied to this issue, the options are: 1) Make List B the originator by changing the RFC 5321 sender address as well as the RFC 5322 Message From. Ideally add a DKIM signature for B, in case the message is forwarded downstream. This is the IETF list behavior and the only one that is feasible in practice. .. 2) Require all submitting domains to make List B a trusted sender for their domain by including B in their SPF record 3) Configure the list to make no changes, then require all senders to include DKIM signatures for their own domain. 4) Require all recipient systems to make special policy accommodations to grant trust to messages from List B, simply because it comes from List B. This is feasible, but specific to each participants incoming email filter. DKIM and IDENTIFIERS A large portion of legitimate mail is generated by third parties acting as agents. The problem being addressed by SPF / DKIM / DMARC is: "How can a sender provide information so that a recipient can distinguish between an authorized agent and an unauthorized identity thief?" A subset of this issue is "How do we expect recipient systems to behave?" This is a rather important detail which this group has explicitly chosen to not pursue. But I can provide these observations based on experience with mail filtering: To avoid false positives on desired messages, messages from some senders must be given some filtering exceptions. For those exceptions to be applied safely, the sender must be verified to a degree acceptable to the recipient. Depending on the situation, there are multiple ways that a sender can be identified. These include, but are not limited to, SPF, DKIM, and DMARC.. In the general case, SPF, DKIM, and DMARC simplify this problem for the recipient. Although SPF, DKIM, and DMARC are often assumed to be tools for discarding fraudulent messages, this is extraordinarily difficult to implement in practice. Too many senders have errors in their SPF / DKIM / DMARC configurations, and too many legitimate senders do things that violate a domain owner's SPF / DKIM / DMARC policies. Policy failure has not proven to be a reliable indicator of unwanted content. Without DMARC, SPF and DKIM configuration errors persist because the sender obtains no feedback about those errors. DMARC fixes the feedback problem. I still do not understand how DMARC does anything other than enhance prior work on SPF and DKIM, or how there is any conflict with prior standards. Doug Foster ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D
On 6/2/2020 8:45 PM, Douglas E. Foster wrote: Someone said that the Sender Address is all we can trust. Nonsense. +1 As to identifiers: The RFC 5321 MAILFROM sender is intended, at least in my understanding, to represent the login account used to create the message, while the RFC 5322 From Header represents the "speaker", the person whose ideas are being represented by the content. It matters if someone puts words in someone else's mouth, and From fraud is exactly that type of fraud. You bring up a basic fundamental reason what the 5322.From field is the only signature binding requirement for DKIM. When it comes to exclusive mail, it is the anchor that is associated with: - Login Account - The Alias or Display Name, - The Default From name for local messages and if the message is exported for a network mail system then we have the additional related identities: - 5322.From - 5321.Mail From In the restrictive DKIM Policy Model, all these identities are closely tied together. They are usually represented and traceable to one person and thus illustrating the long time "Proof Of Concept" that a restrictive DKIM Policy is so powerful, "It's Scary!" A break or deviation from this expectation is a strong candidate for rejection. I simply cannot grasp how DMARC conflicts with RFC 5321 or RFC 5322, inhibits authorship, or creates any other attribution problem. This assertion was simply not explained. I believe they are simply catching up with the list problem. Thats all. The problem was recognized long ago with SSP, ADSP. But when ADSP was abandoned for these lists problem and replaced with DMARC, the list problem was no longer a concern but DMARC did not resolve the list problem and it appears DMARC "Proposed Standard" will not try to address it. -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D
I don't understand why this topic is debatable. We are faced with a constant stream of mail which we do not want. We need to block the nuisance stuff as well as the dangerous stuff, so that the important stuff gets processed in a timely manner, and so that our labor efforts can be spent on things more productive than reading nuisance emails. Ergo, if a message contains a lie, I want to block it. If the identifier is a lie, the content will not be any better. IETF settled on standards for filtering identifiers because it is simply more feasible than filtering free-form text. As to consequences: Was no one present during the 2016 election cycle, when a phony GMAIL password reset compromised a U.S. Presidential campaign? I'll admit that I have not seen that specific message's From header, but supposedly it convinced John Podesta and his I.T. person, so I am pretty confident the From domain was "@gmail.com", not sstealyourd...@badguys.r.us" Someone said that the Sender Address is all we can trust. Nonsense. The only thing that is "true" in an email header is the IP Address, and that is true only if the recipient assumes that no nation state has a NAT-translating device in front of their internet connection. Everything else can and will be fraudulent at times. As to identifiers: The RFC 5321 MAILFROM sender is intended, at least in my understanding, to represent the login account used to create the message, while the RFC 5322 From Header represents the "speaker", the person whose ideas are being represented by the content. It matters if someone puts words in someone else's mouth, and From fraud is exactly that type of fraud. It is reasonable to require senders to demonstrate authority to speak on behalf of someone else. DMARC provides two ways to demonstrate that authority: if there is domain alignment, the implication is that the security environment of the sender domain has chosen to allow one sender to act as agent for another, because it would be in their power to prevent him from doing so.. Therefore intra-domain agency is not a significant concern to the recipient. However, when the sender address (login account) represents a different security domain than the sender address, the recipient has no reason to ignore the discrepancy. The DKIM signature is the alternative credential which demonstrates authority to send on behalf of the From address entity.. I simply cannot grasp how DMARC conflicts with RFC 5321 or RFC 5322, inhibits authorship, or creates any other attribution problem. This assertion was simply not explained. Feel free to do this test to see if From address matters: Start sending inflammatory stuff with a From address @WHITEHOUSE.GOV to major news organizations or foreign governments around the world. See how long it takes the Secret Service to pay you a visit. As to visibility: The business world still runs on Microsoft Outlook, and Outlook presents the From Address when a message is read. So it is odd to assert that no one ever sees that data. The real scandal is that the Sender Address is never displayed. It would be very interesting if MUAs would say From: market...@bigretailer.com by: bigretai...@massmailer.com Whose ideas was it to keep the sender secret? If the integrity of identifiers does not matter, why are we here? Doug Foster ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
