Dear Martin, See comments inline: On Jul 17, 2014, at 12:57 PM, Martin Rex <[email protected]> wrote:
> Douglas Otis wrote: >> >> Viktor Dukhovni <[email protected]> wrote: >>> >>> This is a solved problem, the "Rfc822.Sender" field should have >>> from the outset trumped the "Rfc822.From" field when determining >>> message origin, and the DMARC policy should be that of the "Sender" >>> domain. Some MUAs already expose "Sender != From" by displaying >>> "From <sender> on behalf of <author>". This needs to become standard >>> MUA behaviour. > > Only the most clueless MUA programmers got this wrong in the first place. > From a probability standpoint, now counting on those to (a) take the > blame and (b) get it right this time may be somewhat optimistic. > > The main problem that I have is DMARC, is that the approach is > technically and morally wrong, and legally prohibited (=criminal) > in properly civilized countries. As it currently stands, it was disruptive for a domain to assert From/Source alignment 'reject' policy against domains granting Internet access while also offering conventional email services to facilitate their customer relationships. A safer approach would have been to request 'quarantine' to avoid diverting messages into feedback queues rather than their user's intended recipient's inbox queue, albeit their spam folder. With this being so disruptive, 'reject' quickly devolved into 'quarantine' in many cases. A feedback queue is unlikely given the same level of confidentiality while reciprocating for similar feedback services. > A better approach would be for the final MTA to perform DMARC (DNS) lookups > and prepend the results as new, standardized header lines to the message, > and have the MUA process these new header lines and **suppress** displaying > of the "rfc5322-From:" for messages that are supposed to verify but don't. Intuit, as evidenced in Sender header fields, has been sending invoices on behalf of their customers noted in the From header field. Recipients are more likely to recognize entities in the From header field. It is the From header field that recipients want to trust even when indirectly sourced. What is needed is a scheme to federate relationships to sustain desired results able to reject spoofed messages. A federation process can occur with negligible traffic and administration while directly benefiting user by mitigating messages attempting to spoof 'as-them' while also keeping their own inbox from being similarly stuffed with message spoofing. > And DMARC reporting needs to be killed. > >> You are right, but this provides a domain not always seen by recipients. >> Only the From header field is surely displayed. > > So you at least agree that it is the broken MUAs that cause the problem. No. It is the lack of email federation. Reputation alone will not offer a fix, nor will showing "purported responsible addresses". > When the details about the OpenSSL heartbeat vulnerability was published, > would it have been better to force all ISPs to detect and tear down > TCP connections that "exploit" the weakness, or to fix the broken software? While about 3/4 of vulnerable systems have been patched, about 1/7 of potentially compromised certs have been replaced. Security remains a major problem. Federating systems that attest known relationships will dramatically reduce threat exposures without causing a significant impact on how email related systems currently operate. Even in the Intuit case, confirming an email address is surely part of their service offering. The same should be true for mailing-lists and the like. Federation can boot-strap using third-party feedback, but eventually this should change into standardized request forms sent to DMARC feedback queues to request federation along with specifying additional details to further constrain related threats. http://tools.ietf.org/html/draft-otis-tpa-label Regards, Douglas Otis
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
