[dmarc-discuss] multiple from
doug.mtview at gmail.com
Wed Jul 17 12:39:15 PDT 2013
On Jul 17, 2013, at 9:40 AM, Murray Kucherawy <msk at fb.com> wrote:
> On 7/16/13 8:46 PM, "Roland Turner" <roland.turner at trustsphere.com> wrote:
>> Any time an RFC and reality diverge, it it the RFC that is
>> reality-ignorant, not reality that is RFC-ignorant.
>> If it happens that the DMARC specification reflects reality better than
>> existing RFCs - even standards track ones - then once again, it is those
>> RFCs that are in error, not the DMARC specification.
> I don't agree with the first generalization. RFCs specifying the format
> of an Internet message have existed for a really long time. It's reality
> that decided to diverge, largely out of laziness: Email generating code
> would be sloppy and cut corners, and user pressure caused mail submission
> agents and other services to tolerate it rather than be strict about it.
> We're left with a system where lots of software now supports the lazy
> There's a draft making its way through the IETF now that describes this
> situation, pleads with software to become strict once again, and then goes
> into a list of common malformations and provides advice about how to
> handle or interpret them. But even that advice about safe handling
> doesn't render those messages compliant; they are still broken.
> DMARC's acknowledgement of reality doesn't make those RFCs wrong, nor does
> it excuse various components' lax enforcement of the rules.
The situation with SPF is a bit different as it represents an authorization of servers that handle the _entire_ message. When a server is trustworthy it can be reasonable to assume messages received can be trusted. DMARC changes this by basing acceptance on a DKIM signing domain where ANY latitude permitted by DKIM's partial message coverage MUST BE seen as an exploitable vulnerability. This is a problem created when for example DKIM ignores invalidly prefixed header fields, which unfortunately is normal with DKIM.
Your characterization is accurate but DKIM was intended to be safely deployable within what was already understood to be this situation. The DKIM deployment documentation even suggests when a DKIM signature is trusted, message content filtering can be bypassed. Neither DKIM nor the Results-Authentication header offers any status about whether invalidly prefixed header fields were checked and it is rare for DKIM signing domains to implement the double entry of singleton header fields. This situation leaves DKIM's status untrustworthy and this will not change significantly anytime in the near future.
Acceptance based upon server authorization or authentication will not create an incentive to invalidly prefix header fields aimed specifically at being deceptive. It is also foolhardy to describe bayesian spam filtering that can never represent a static implementation. Nor is it accurate to suggest any invalidly prefixed header is either malicious or spam when DKIM is not used. When acceptance is based on a DKIM signing domain where content filters are likely bypassed as described in DKIM's deployment RFC and implemented in Sendmail milters, this creates an environment ideal for phishing that ironically DKIM was intended to prevent as suggested in the deployment introduction.
There really needs to be an RFC that documents how to combine the status of checking for invalidly prefixed header fields with the status returned by DKIM since an easy solution of declaring the signature invalid has been rejected. Perhaps this check could also include checks against use of invalid UTF code points when internationalized header fields are being used. Avoid the rabbit hole of describing how spam or phish is detected.
DMARC should not over reach and attempt to dictate what can be accepted from domains not directly related with policy domains above the public suffix. Perhaps it would be better to describe this as apex of the "registered" domains.
More information about the dmarc-discuss