On Nov 22, 2014, at 12:43 AM, Stephen J. Turnbull <[email protected]> wrote:
> Douglas Otis writes:
>
>> There are serious concerns being ignored regarding email captured in
>> DMaRC feedback. Things like Intuit invoices or mailing-list
>> conversations are being misdirected simply because DMaRC incorrectly
>> assumes a sender/recipient relationship when general use email
>> providers assert restrictive DMaRC policies.
>
> So do you propose something like
>
> Author Domains which impose policies that can result in failure
> reports being sent MUST have Terms of Service in which mailbox
> users agree that content of messages which fail DMARC checks may
> be forwarded to the Author Domain as part of failure reports.
> This includes messages that they have originated which are
> unauthorized according to the definition of DMARC.
Dear Stephen,
Consider invoices sent by Intuit on behalf of users who have an email address
obtained in conjunction with their Internet access who are seeking financially
related services. These messages are not spoofing the source accurately
indicated by Sender header fields as defined by RFC5322. Why assume these
entities assigned an email address by their access provider intended their
service related messages be insecurely mis-directed to access providers instead
of the intended recipients?
In the case of legitimate third-party services, these messages are not the
property of the access provider. They are owned by the author assigned the
email address seeking these services. Failing DMaRC with a message that has a
valid and reputable domain aligned with the Sender header field domain is
unlikely malicious or in violation of any recognized protocol standard. DMaRC
related redirection of these valid and legitimate messages disrupts vital
services, such as forwarding and use of third-party services in common use for
decades. The disruption of these services clearly indicates DMaRC is
incompatible with SMTP by neglecting consideration for sender agents not
aligned with the email-address provider.
Rather than issuing click through agreements to in essence say "All your email
must represent direct transactions from the provider." they could offer users a
friendly SMTP compatible and safe solution that provides MUA configurations
that expose aligned Sender header fields in lieu of aligned From header fields.
This could be coupled with DMaRC record that offers this exception. With a
simple change, their customers are protected and afforded the agility SMTP
normally allows. This could be signaled by making specific authorizations such
as those proposed in TPA-Label or by defining an a DMaRC assertion which
indicates TP=PSS or TP=PSR for Sender header field strict and relaxed, or
defines an excepted group syntax which safely permits a highly visible
exception made using group syntax indicated with DMaRC assertions TP=G and
perhaps combined with TP=PSR,G.
> Or however you say that in IETF-ese?
>
>> DMaRC policies that require From header field alignment with the
>> sender inhibit the forwarding of email and dismiss Sender header
>> field contents as being potentially deceptive to justify ignoring
>> this field in the determination of direct "mail flows".
>
> Isn't that backward? DMARC focuses on From alignment *because* in
> typical MUA configurations Sender is not visible to the receiving
> user, and in any case would be unlikely to be useful in counteracting
> phishing and recommended-by-a-friend spam. That is, I don't see how
> verifying Sender would be useful. True, if you verify Intuit as the
> sender of mail on behalf of a billing company, the user seeing Intuit
> in Sender would likely come to an appropriate conclusion. But if you
> verify example.com as Sender, the user doesn't know who they are, and
> in most cases I would expect them to simply ignore that information
> and rely on From and any clues in the message content.
DMaRC makes an erroneous assumption incompatible with SMTP in the case of user
email accounts. Besides, DMaRC can not prevent all spoofing and makes future
improvement problematic. It would be wrong to characterize Mailing-list
traffic as being spam friendly or something most users are unable to recognize
and properly handle. Where the user sending a message is critical, they can be
S/MIME or OpenPGP signed, but nevertheless these safer solutions are not
recognized by DMaRC.
>> However this often relied upon agility is seriously damaged by
>> DMaAC's short-cut of ignoring the defined role of the Sender header
>> field.
>
> It's not a shortcut. Sender has the wrong semantics for combatting
> phishing and recommended-by-friend spam.
We have handled a fair amount of DKIM related malicious traffic exploiting
trivial spoofing DKIM permits. This was giving users a false sense of security
where the problem was clearly noted in the Won't Fix DKIM ticket 24 in May of
2011. It took until May of 2014 for a fix to be implemented by one of the
world's largest providers. Those following DKIM deployment documents along
with those waiting to be published for DMaRC seem destine to ensure mistakes
remain likely because logical processing errors are never admitted, given clear
warning, or directly fixed without added overhead.
A false sense of assurance remains a concern for SPF heavily exploited by
Kelihos botnets, for example. Neither SPF nor DKIM can be used to hold domains
sending malicious email accountable because neither authenticates actual
sources. Authenticating the source by domain is the only practical way to
combat phishing that remains impractical when using just DKIM or SPF.
Misguided DMaRC requirements are attempting to force standardization on weak
protocols destined to prolong abuse and associated damage. Lawsuits related to
abuse blocking often involve substantial sums where evidence must be rock solid.
>> this does not include redirecting accepted messages to destinations
>> neither specified by senders nor recipients.
>
> This is not a problem restricted to DMARC. Any protocol that involves
> forwarding a message to a third party (eg, the Sender field or
> Return-Path) raises this issue (eg, in the case of a typo in the
> recipient mailbox name). It's true that DMARC seems designed to cause
> such problems.
DMaRC along with DKIM and SPF were carefully designed to avoid authenticating
domains often well compensated for having sourced abuse. Despite such an
obvious defect in these plutocratic schemes, almost every related authorization
reporting method erroneously includes Authentication in their title. What is
standing the the way of DANE deployment for both client and server?
Regards,
Douglas Otis
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
