Douglas Otis wrote:
Viktor Dukhovni <ietf-dane(_at_)dukhovni(_dot_)org> 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