> The Sender header field when present has been defined for > decades to represent the sending agent!
Maybe, maybe not. Outlook desktop client shows the Sender: header as "<sender> on behalf of <5322.from>", but neither Hotmail/outlook.com nor Gmail do. They just show the 5322.From address regardless of whether or not there is a Sender: header. This Sender: DMARC fix requires a change in the way these clients render email. Given the marginal additional benefit to receiving mailing list traffic that won't implement any of the published workarounds (not modifying content, fiddling around with Reply-To and From addresses, changing the From: domain to be the mailing list domain), I can't see why Gmail or Hotmail would want to make a change like that. I agree with Murray that it isn't worth pursuing, the cost/benefit ratio isn't there. > Again, we will happily help any large ESP configure and > maintain their services to make use of this scheme and even > offer the needed resources. Doug, who is this "we" you keep referring to who will happily maintain someone else's DNS zone? Your employer? Are you volunteering them on their behalf? Is this a free service of theirs? If not, why would anyone agree to a solution that is hard to manage at scale but, lucky for you, just so happens to benefit your employer? The TPA authorization DNS zone publishing has been pushed by yourself and another board participant and has received universally negative feedback, or at best neutral feedback. The people here are smart and have as much experience as anyone else and they understand what you are saying. But they still don't agree, including me. I think it's time to make like the movie Frozen and let it go. -- Terry -----Original Message----- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Douglas Otis Sent: Thursday, May 14, 2015 4:06 PM To: dmarc@ietf.org Subject: [dmarc-ietf] Simple authorization offers reasonable control over messaging resources On 5/14/15 4:54 AM, Murray S. Kucherawy wrote: > On Thu, May 14, 2015 at 12:51 AM, Stephen J. Turnbull <step...@xemacs.org> > wrote: > >> > What gets added from here forward really needs to be as innocuous >> > as possible. I believe we're in a position where things like SPF >> > and DKIM are still young enough that their implementations are >> > malleable, >> >> I'm not sure what you mean. Now that I actually know what those >> protocols do (and DMARC itself, for that matter), I don't really see >> how they can be much improved. Do you mean the policy engines that >> make decisions based on the output of SPF and DKIM implementations? >> > I'm saying that incremental changes to DKIM, SPF, and DMARC are far more > likely to succeed than anything along the lines of "Everyone start using > and paying attention to Sender", "Let's register yet another Sender-type > field", or "Registration scheme X". The operational changes required for > those three families of solutions are too enormous and involve too many > wildcards for me to believe they stand a chance of success. Dear Murray, The Sender header field when present has been defined for decades to represent the sending agent! DMARC improved delivery registration accuracy for TRANSACTIONAL messages based on the SMTP MailFrom parameter (bounce address) or DKIM (unrelated to any field) where either is allowed to fail. For TRANSACTIONAL email, combining these two marginal authorization schemes easily adjusted to relate with the From header field offered a low percentage authorization failure to better ensure compliance with a restrictive policy. The expediency this allowed did not justify disrupting valid and legitimate exchanges not limited to transactional or direct messaging configurations. Neither DKIM nor SPF authenticate an actual message source, but simple authorization offers reasonable control over messaging resources. DMARC is fine when messages are limited to direct exchange, but fail badly when exchanges make use of the Sender header field that may signify use of mediators or other resources. At one time DMARC even recommended against issuing non-transactional messages, but acknowledgement of DMARC's potential disruption of normal email interchange was dropped. Commercially available products for years have been able to clearly indicate the entity trusted at providing a message. It seems DMARC assumes recipients are too easily misled and can't be trusted to deal with S/MIME, OpenPGP, or MUAs that verify and display the Sender header field and think everyone is better able to deal with munged From header fields. The TPA-Label is able to thwart wildcards simply by publishing a negative wildcarded label. A practice that won't work with DNS-SD. A sender must have reasonable control over the resources they authorize. Any double signing scheme relaying authorization to a third-party via DKIM can not control the authorized resources since the entire message body may change and DKIM can be replayed to any destination by design. Without adequate control, authorization protections fail simply because neither SPF or DKIM are able to authenticate the source, nor can DKIM offer an expedient authorization retraction in say a 5 to 15 minute range. While I commend efforts made at fleshing out your version of the ATPS protocol, due to the inherent hurdles introduced for third-parties it was unlikely this scheme would be adopted. The lesson is DKIM offers a poor method to signal changes beyond those already expected. There was no reason to change how a third-party is verified since they too can use DKIM and SPF or even DANE or the HELO parameter for that matter. The correct place to signal such change is at the DMARC assertion. See Third-Party Authorization example of: "sam=tpa; and tpa=third-party-authority.example.com;" https://tools.ietf.org/html/draft-otis-dmarc-escape-02#section-4 This scheme involves a simple DNS server operating an isolated zone separated from other domain services and can even be published by a different domain. This approach allows the _tpa zone to be maintained as a community effort or as a specialty service to ensure the sender has reasonable and nearly immediate control over the resources they authorize. By being able to include policy for the Sender header field, DMARC can become compatible with RFC5322. While some might describe this a complex authorization scheme, it can be combined with <https://tools.ietf.org/html/draft-levine-dkim-conditional-01> draft-levine-dkim-conditional to offer a resource record where only the base portion of the domain might be included to guard against domain hash collisions. TPA-Label that had the goal of reducing collateral damage caused by compromised accounts or resources, can be combined with draft-levine-dkim-conditional to signal when this limited signature should be included and which domain needs to be authorized. Because this uses very simple resource records, is should scale far better than SPF and yet permit a means to establish an informal federation scheme to better protect email infrastructure with low latency abuse responses. TPA-Label does not make handling third-party messages harder. Instead, TPA-Label offers a simple way to signal which domains require exceptional handling. Without such a feature, DMARC can not be seen as being compatible with RFC5322. Again, we will happily help any large ESP configure and maintain their services to make use of this scheme and even offer the needed resources. Regards, Douglas Otis _______________________________________________ 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