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

[Franck Martin <[e-mail]>]

See inline....

Printed on recycled paper!

> On Nov 6, 2014, at 23:16, Murray S. Kucherawy <[e-mail]> wrote:
> 
>> On Thu, Nov 6, 2014 at 11:06 AM, Ned Freed <[e-mail]> wrote:
>> In the step 7 in section 3.1.3, I think it would be helpful to add a sentence
>> about the determination of the organizational domain from the author domain.
>> Step 7 is also pretty large; you might want to consider breaking it up into
>> substeps or something along those lines.
> 
> OK.
>  
>> Another problem with step 7 is the statement "small number of further DNS
>> queries to the Organizational Domain" is incorrect. Per step 1 in section
>> 5.6.3, the author domain is queried first, then the organizational domain if
>> that fails to produce a viable result. This needs to be fixed, and adding a
>> reference to section 5.6.3 would be a good idea.
> 
> "small number" is "at most two", and "to the Organizational Domain" is meant to include its subdomains, so I guess what's meant is to the Organizational Domain's zone, or something like that.  I'll tidy it up.  Good suggestion on a forward reference.
> 
>> In section 3.1.4, the paragraph
>> 
>>    It is important to note that identifier alignment cannot occur with a
>>    message that is not valid per [MAIL], particularly one with a
>>    malformed or absent RFC5322.From field.  Handling of such cases is
>>    left to the discretion of the Mail Receiver.
>> 
>> doesn't really make sense to me. If the From: field is missing or is so
>> malformed that a domain cannot be extracted from it, it isn't a question of
>> alignment to other fields, but rather that there's no way to determine a DMARC
>> policy that applies to the message to begin with. Shouldn't that be the primary
>> reason invalid mail is problematic? Am I missing something here?
> 
> No, I think you've got it, but I'm not clear on how the paragraph you cited doesn't say that.  You have it exactly right: If From: is missing or so mangled that it's not possible to get a domain out, then there's nothing to which DKIM and SPF can align, and DMARC can't be applied.  There might be other mangling though, like multiple From: fields that are properly formed but contain distinct values, in which case we don't know to which one to apply alignment.

Note that an email with no RFC 5322 field is not valid, as well as one with more than 1. This header is mandatory as well as the Date header. These are the only 2 headers mandatory in an email.

So rejecting an email with no RFC 5322 or more than one is just following the RFC.

I'm not talking on how many mailboxes/domain there are in this header.

> 
>> I'm not sure the use of a cousin domain in the example given in paragraph 5 of
>> section 3.1.4.1 is a good idea. The point of using a cousin domain in an attack
>> is that users will confuse/conflate that domain with a legitimate domain. (And
>> this is important in the context of this document because DMARC doesn't do
>> anything to prevent this attack in a From: field.) But the reason identifier
>> alignment is important isn't that the use of a cousin domain in a DKIM
>> signature, MAIL FROM, or EHLO/HELO field could cause problems, it's that
>> without alignment a bad actor could freely use any domain whatsoever in these
>> places. Users generally don't see these fields so why bother using a similar
>> name? The way the section is written makes it sound like protecting against the
>> use of cousin domains in particular is important. Unless I'm missing something,
>> that's not the case.
> 
> I agree.  That paragraph should go.
>  
>> There's a bit of tension between section 5.5, which says that all you need to
>> do to "implement the DMARC mechanism" is publish DMARC records in the DNS, and
>> the diagram and list in section 3.1.3, which make it sound like deploying both
>> DKIM and SPF are a required part of DMARC setup and operation. I'm not sure
>> what, if anything, should be done about this, but I thought it worth noting.
> 
> I'll see if I can tidy it up.
>  
>> There's a big problem in section 5.6.1, where it says that any message with
>> more than one address or an empty group in an RFC5322.From field SHOULD be
>> rejected.
>> 
>> I have to say I find this recommendation to be completely inappropriate. Surely
>> it should be possible for me to a legitimate, syntactically valid message that
>> happens to employ the multiple-from/sender format defined in RFC 5322 with all
>> the domains under my personal control and none publish any sort of DMARC
>> policy, and not have the application of DMARC to the overall message flow mess
>> it up? Or alternately, one where the From: field contains an empty group,
>> something we actually recently went to the trouble of writing RFC 6854 to
>> allow?
> 
> As I recall, there were some surveys of some pretty large email streams, and not a single instance of a From: field containing other than a single mailbox could be found that wasn't also part of something either spammy or some kind of attempt to confound spam filters, or just grossly malformed and unusable.  This led the original DMARC community to what you see there now.  There was no deliberate rejection of the RFC 6854 format, but just rather no observed valid use of it.

Note that RFC 6854 format is a "transitional" RFC. The applicability statement clearly indicates this syntax is to be used for non SMTPUTF8 aware MTA when receiving mail from an upstream MTA SMTPUTF8 aware as a convenience and under security considerations left to the receiver. So in my view if your receiving MTA does SMTPUTF8 then there is little reason to accept this syntax.

I always had a problem with RFC 6854 and opposed it in last call as it surprised me the IETF would prefer convenience for security. The result was to strongly limit the applicability of this RFC.

> 
>> Sure, some clients may barf on such things, but that's a problem for whoever
>> opts to use the mechanisms, not DMARC.
>> 
>> I have no absolutely problem with rejecting messages with From: fields
>> containing any sort of domain identifier that has any sort of attached DMARC
>> policy because of how that From: field is constructed. But intruding on
>> legitate uses of email that choose not to employ DMARC in any capacity goes
>> much too far. And it isn't helped by the fact that the DMARC reporting
>> mechanisms are meaningless when there's no domain owner to report these
>> rejections to.
> 
> What sort of remedy would you suggest here?  Off the top of my head, here are some suggestions:
> 
> 1) Evaluate all the domains you find, and if any of them have published DMARC policies, apply the strictest one (by that I mean: if there are any with p=reject that fail, then reject it; if there are any with p=quarantine, quarantine it); if not, treat the message as if DMARC simply did not apply.
> 
> 2) Evaluate only the first domain you find, if any.
> 
> 3) Same as (1), but limit it to some fixed (configurable?) number of domains.

My solution is that if all the domains are part of the same organisational domain, then the task is easy, you apply the policy of the organizational domain, otherwise you reject the email.

I found .NET early version uses an invalid syntax, that creates the appearance of 2 mailboxes. If all domains are in the same organizational domain this prevent to reject a bunch of .NET generated emails.
> 
>> There's also a direct contradiction between the third bullet item in section
>> 5.6.1, which says that a message without a From: field SHOULD be rejected, and
>> the fourth paragraph of section 3.1.4, which leaves this same case to the
>> discretion of the mail receiver. Furthermore, does it really make sense to give
>> malformed From: fields a pass - someomthing which could easily contain an
>> identifier that has an attached DMARC policy - and require rejection of
>> completely legitimate stuff with no DMARC policy in sight?
> 
> We've covered the latter point above, but as to the point about malformation: Can you reliably extract a domain name from a malformed From: field?  That seems to be a vector for trying to confuse a DMARC filter if the advice is to try anyway.
>  
>> I could have missed it, but I don't see any place where the semantics of how
>> DKIM and SPF are combined (as an it's an OR) is specified prior to item 5 in
>> section 5.6.2. If this is indeed the case, then this is bad: The way the
>> mechanisms are combined needs to be made clear much sooner. I note in passing
>> that we've already had a case on this list where someone misunderstood this
>> detail.
> 
> Section 5, third paragraph, is the first formal statement of this kind.  Adding one somewhere up earlier in one of the overview sections would probably be a good idea.
>  
>> Section 6.2.2.1 states:
>> 
>>    In the case of a "mailto" URI, the Mail Receiver MUST communicate
>>    reports using the method described in [STARTTLS] whenever it is
>>    offered by a Report Receiver.
>> 
>> I seriously question the value or appropriateness of this paragraph. So your
>> DMARC agent, assuming it actually goes through a SUBMIT server and not through
>> an internal API, uses STARTTLS to secure that connection. Now what? At present
>> there's no standardized way to indicate in a message that it has to be
>> transported securely. So if you really want that, that leaves configuration - a
>> configuration that spans an essentially arbitrary set of transport agents, to
>> enforce this. At least part of which would have to be enforced by the target of
>> the mailto: to have any chance of being effective.
>> 
>> It's poor practice to have MUSTs in specifications that we know are going to be
>> ignored. It's also poor practice to have MUSTs that don't actually accomplish
>> much of anything as written. As such, I strongly recommend dumping this, or at
>> least making it a SHOULD.
> 
> I'd be fine with making it a SHOULD, exactly because of these reasons.
>  
>> Section 9.3 recommends using reply codes during the SMTP session rather than
>> doing anything that would require sending a DSN later, but doesn't come out and
>> say that the reason for doing this is to avoid blowback spam. I think it would
>> be clearer to be explicit about why these policies are a good idea.
> 
> Sounds good to me.
> 
> Thanks!
> 
> -MSK 
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc