Douglas Otis wrote: > > Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> 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. 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. 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. 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? -Martin