Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback

From: [email-masked]
Date: Wed, 03 Dec 2014 12:16:15 -0800 (PST)

Apologies for the very late response, but since you asked me a direct question
about this I figured I owed you an answer.

"Murray S. Kucherawy" <[email-masked]> wrote:

> On Fri, Nov 7, 2014 at 8:57 PM, <[email-masked]> wrote:

> > Trent Adams writes:
> >
> > > -----
> > > It is important to note that identifier alignment cannot occur, and
> > > DMARC determination applied, with a message that is not valid per RFC
> > > 5322 [MAIL].  This is particularly true when a message has a malformed
> > > or absent RFC5322.From field.
> > > -----
> >
> > I occasionally see non-ASCII octets introduced by spam/virus checkers in
> > X-Spam-* fields in the header or in the (non-8-bit) message body, due to
> > copying message content into those contexts.  The From field is perfectly
> > valid, however.  Does that really mean that identifier alignment cannot
> > occur?
> >
> > (I think that is a plausible policy choice, since in an invalid message
> > "anything can happen".  But I don't see that it's a no-brainer.)
> >

> Do you have another suggestion?

> Note that there's nothing normative in Trent's suggestion.  If a receiver
> thinks it can continue with the X-Spam-* fields malformed as described,
> then it can continue on that basis.

> > > Starting off, we can ignore a <null> address in the RFC5322.From field
> > > as DMARC will have no bearing in that case.  Similarly, when there is
> > > exactly one address in the RFC5322.From field, application of DMARC is
> > > reasonably straight forward.
> >
> > By "DMARC", you really mean "DMARC policy", right?  DMARC the protocol
> > does need to say something about what happens if alignment fails or no
> > policy can be discovered.

Right, and the "no policy can be discovered" case breaks down into
two subcases, one where you have a valid message that simply doesn't
specify any domains with an associated DMARC policy in the right places, 
and an invalid message you can't make sense of.

My original point was that DMARC shouldn't make it a matter of compliance
to reject anything in the former space. The latter case is trickier, and
careful wording is required to deal with it.

> That's how I understood what he said.

> > > That leaves taking some action based on the DMARC policies associated
> > > with the set of domains represented in the RFC5322.From field.  It seems
> > > that the most reasonable approach is to gather the DMARC policies for
> > > all addresses, and then apply the most strict.
> >
> > I wouldn't call that "reasonable".  It's the only plausible option, but
> > here's the problematic use case:
> >
> > Co-Chairs Trent and Stephen decide to hold a meeting of The Committee.
> > For organizational political reasons it is necessary that (a) both names
> > appear on the memo and (b) Stephen has to do the dirty work.  Stephen
> > sends the mail "From: [email-masked], [email-masked]", with proper
> > SPF and DKIM setups.  Unfortunately, example.com publishes p=reject,
> > example.com alignment fails because Stephen sent the message, the MTAs
> > reject the message, and nobody except Trent and Stephen shows up to the
> > meeting.  I see two ways this message could pass DMARC: Stephen has the
> > keys for example.com, or the Japanese "ringi" system, where I write and
> > sign the message, send it to Trent, who then signs the message but
> > otherwise forwards it verbatim.  Both seem fragile to me.

> > OTOH, only checking policies of aligned SPF source domains and DKIM
> > signers means that Stephen (or any scammer) can add "[email-masked]"
> > to the From field and pass DMARC.  It's obvious what the Felons of April
> > would do with that.

> > I guess the most plausible approach to this issue is to say that if you
> > want to use DMARC and have multiple authors, you must contrive to give all
> > the authors mailboxes in the same domain.  In the example, I could create
> > the-committee.example.org for committee members, or give trent a
> > forwarding mailbox at example.org itself.

> Ned, do you concur with this analysis?  Is Trent's proposal coupled with
> this caveat a valid remedy for your point?

Again, my point was in regards to cases of valid RFC 5322 mail where no DMARC
policy attached to anything. You're talking about a case where it does attach
here. So this isn't really a remedy for the issue I raised, but as a solution
to the problem posed, it seems like about the only one that makes sense.

That's not to say I like it, but the realities are what they are.

> > > Given all that, here's my suggested revision to Section 5.6.1.:
> > >
> > > -----
> > > 5.6.1.  Extract Author Domain
> > >
> > > In order to be processed by DMARC, the domain(s) must be extracted from
> > > the domain of the email address(es) within the addr-spec portion of the
> > > RFC5322.From field. If the domain is encoded with UTF-8, the domain name
> > > must be converted to an A-label for further processing. If no domain is
> > > found, the message SHOULD be rejected (as it is forbidden under RFC 5322
> >
> > I still don't think a null From filed is any business of DMARC the
> > protocol.  That's really an issue for (a) the security considerations
> > section or (b) the planned BCP.
> >

> I think we're all in agreement on that point so far.

> > > [MAIL]).  If more than one domain identifier is found, the full set of
> > > domains MAY be collected as a set of identifiers for DMARC processing.
> >
> > But this seems to be the insecure approach I describe above:
> >
> > >    5.  Conduct identifier alignment checks.  With authentication checks
> > >        and policy discovery performed, the Mail Receiver checks if
> > >        Authenticated Identifiers fall into alignment as described in
> > >        Section 3.  If one or more of the Authenticated Identifiers align
> > >        with an identifier extracted from the addr-spec of the
> > >        RFC5322.From domain, the message is considered to pass the
> > >        DMARC mechanism check.
> >
> > AFAICS this allows me (using a throwaway mailbox at a throwaway domain) to
> > send spam that passes DMARC on your behalf, as long as my mailbox appears
> > in From, too.  Am I misunderstanding your proposed algorithm?

> No, because in (6) the strictest rule applies.  Your throwaway domain might
> pass, but the other advertised author's would not.

Agreed.

> > >        All other conditions (authentication
> > >        failures, identifier mismatches) are considered to be DMARC
> > >        mechanism check failures.

> > Bottom line, I think both messages where no Authenticated Identifiers can
> > be extracted and those where multiple Authenticated Identifiers can be
> > extracted should be defined to be mechanism check failures.  In the former
> > case, policy discovery is impossible, in the latter, the strictest policy
> > should be applied.

> Right, I think that's what Trent is also saying.

> And everyone seems to agree on just dropping STARTTLS as well.

Good.

				Ned