Murray, et al,

On 12/25/2014 8:30 PM, Murray S. Kucherawy wrote:
> On Thu, Dec 25, 2014 at 10:15 PM, Dave Crocker <[email protected]
> <mailto:[email protected]>> wrote:
> 
>     One could argue either way about the multi-valued From:, but at least it
>     has an essential relationship to DMARC, since DMARC evaluates From:.  If
>     DMARC were required to handle multi-valued From:, it would alter DMARC
>     noticeable, as was evident in the debate about this issue.
> 
>     The MX requirement has no such linkage.
> 
> I'm afraid the glue is still too thick.  Fortunately at this point, this
> is all academic.
> 
> I'm staring at this and not understanding how the two are all that
> different.  They both seek to ensure that a DMARC evaluation can be done
> on the From: domain, and thus both seek to ensure that the From: that
> lands in the inbox can be trusted by end users to be valid.

When informed, serious participants have a basic difference in their
understanding of the scope of a specification, it's difficult to ensure
proper focus for the work.  It makes interpretations amongst the larger
community likely to be problematic.

So I think this exchange is important to pursue as a matter of
clarifying basic principles...


Good wg charters help understanding of what is in scope but also what is
out of scope.

A specification needs to do the same.  Otherwise, it's content can
wander randomly and -- typically -- defeating the efficacy of the spec.

I think the DMARC spec is somewhere between good and excellent at
stating its scope, which is offered as:

> However, there has been no single widely
>    accepted or publicly available mechanism to communication of domain-
>    specific message handling policiies for receivers, or to request
>    reporting of authentication and disposition of received mail.

So while there is obviously the larger goal of fighting abuses, it is
the publication mechanism of DMARC that is the focus.

But more explicit detail is also provided:

> DMARC allows domain owners and receivers to collaborate by:
> 
>    1.  Providing receivers with assertions about domain owners' policies
> 
>    2.  Providing feedback to senders so they can monitor authentication
>        and judge threats
> 
>    The basic outline of DMARC is:
> 
>    1.  Domain owners publish policy assertions about domains via the
>        DNS.
> 
>    2.  Receivers compare the RFC5322 From: address in the mail to the
>        SPF and DKIM results, if present, and the DMARC policy in DNS.
> 
>    3.  These receivers can use these results to determine how the mail
>        should be handled.
> 
>    4.  The receiver sends reports to the domain owner or its designee
>        about mail claiming to be from their domain.

So, we ought to be able to take any proposed technical point for the
spec and ask whether the above sufficiently informs whether to include
or exclude the point.


> In both cases, as you put it, DMARC evaluates From:.  The only
> difference I can see is that one is a self-contained syntactical check
> while the other requires consulting another data source (the DNS, in
> this case) for a simple validity test.

The presence of a multi-valued From: isn't explicitly ok or not ok,
given the above.

However as we saw during the debate about this issue, having a
multi-valued from makes #2, above, significantly more complex and in
fact makes the semantics of DMARC more challenging.  So a decision to
simplify things by restricting DMARC's use to From: fields with only one
address has a direct benefit on the basic DMARC mechanism.

(For clarity, let's remember that this is not a change to RFC5322, in
that domains not asserting DMARC are still free to use multi-valued From:.)

And now let's look at the MX issue:  How does it related to the above
list of goal/scope statements?

IMO, it is entirely independent.

A From: field that does not support a reply can still be valid.   By way
of pressing this point further, note that an email address isn't just an
email address.  It is a unique identifier.  Hence it's possible that the
From: address could be meant solely to uniquely identify the author,
even without being able to directly reply to their address.

It would be an unusual case, of course, but there is nothing in DMARC
mechanism or semantics that requires that a reply reach the author and
hence there is no reason for DMARC to impose this particular restriction.

Note also the point I cited in the previous message:  Domains that do
not participate in DMARC are just as likely to want to assert the MX
requirement.  Hence it should be documented independently of DMARC.


> If the MX/A/AAAA test fails, then there's no policy to apply.  

I will claim that this is not a correct assessment.  If there is a DMARC
record for the domain, there is policy to apply.


> We [used
> to] reject on the basis that it's impossible for that message to
> legitimately exist.

Some/many sites apply that rule.  Some do not.  The MX/A/AAAA rule is
entirely independent of other anti-abuse mechanisms, and it should
remain independent.


> If the single-value From: test fails, then which domain's policy is to
> be applied is potentially indeterminate. 

Exactly.  And that's why the decision for DMARC constraints to simplify
From: makes sense.

d/

-- 
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to