Subject: [dmarc-ietf] Charter text to add

From: Franck Martin <[email-masked]>
Date: Fri, 19 Jul 2013 20:42:29 +0000

http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC

It seems to me the BCP should provide advice on how you can strengthen your receiving MTA to avoid "cousin" domain abuse. I see it at the moment mainly based on domain reputation and invalid syntax, but there are may be other. For instance, I have noticed that spamassassin has no rule to check domains present in From: Helo, MailFrom against blacklists such as the DBL.

So I propose the following bullet point to add:

- mechanisms for receivers to mitigate potential methods to circumvent DMARC. For instance, but not limited to handling of malformed emails, domain based blacklists and domain based reputation

---

From: Dave Crocker <[email-masked]>
Date: Mon, 22 Jul 2013 18:40:31 +0100

On 7/19/2013 9:42 PM, Franck Martin wrote:
> It seems to me the BCP should provide advice on how you can
> strengthen your receiving MTA to avoid "cousin" domain abuse. I see

Please, no.

Unless I've missed the extensive discussion on the topic, there's no 
basis for believing -- nevermind 'knowing' -- what will avoid that.

There's no basis for tieing it to DMARC.

> - mechanisms for receivers to mitigate potential methods to
> circumvent DMARC. For instance, but not limited to handling of
> malformed emails, domain based blacklists and domain based
> reputation

Maybe it's jet lag, but I don't understand this text.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 22 Jul 2013 17:53:16 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dave Crocker
> Sent: Monday, July 22, 2013 1:41 PM
> To: Franck Martin
> Cc: [email-masked]
> Subject: Re: [dmarc-ietf] Charter text to add
> 
> > It seems to me the BCP should provide advice on how you can strengthen
> > your receiving MTA to avoid "cousin" domain abuse. I see
> 
> Please, no.
> 
> Unless I've missed the extensive discussion on the topic, there's no basis for
> believing -- nevermind 'knowing' -- what will avoid that.
> 

+1 - While I believe that this is worthy of discussion and ultimately efforts to mitigate such abuse, it is clearly well beyond the scope of DMARC. This should be a separate effort/document.

> > - mechanisms for receivers to mitigate potential methods to circumvent
> > DMARC. For instance, but not limited to handling of malformed emails,
> > domain based blacklists and domain based reputation
> 

Yes.

---

From: Franck Martin <[email-masked]>
Date: Mon, 22 Jul 2013 13:20:29 -0500 (CDT)

The charter is about building a BCP for implementation of DMARC, but we will not provide advice or point in the right directions for closing the other doors that make DMARC irrelevant?

This should not be an exhaustive anti-spamming implementation document, but if we talk about display name, then we can talk about cousin domains therefore all  methods to reduce this type of exploits that are peripheral of DMARC.

The BCP deserves such chapter.

----- Original Message -----
From: "MH Michael Hammer (5304)" <[email-masked]>
To: "Dave Crocker" <[email-masked]>, "Franck Martin" <[email-masked]>
Cc: [email-masked]
Sent: Monday, July 22, 2013 10:53:16 AM
Subject: Re: [dmarc-ietf] Charter text to add

Yes.

---

From: John Sweet <[email-masked]>
Date: Mon, 22 Jul 2013 11:35:44 -0700

On Mon, Jul 22, 2013 at 10:53 AM, MH Michael Hammer (5304)
<[email-masked]>wrote:

>>>   your receiving MTA to avoid "cousin" domain abuse.
>>>
>>
>>   Please, no.
>>
>> basis for
> +1 - While I believe that this is worthy of discussion and ultimately
> efforts to mitigate such abuse, it is clearly well beyond the scope of
> DMARC. This should be a separate effort/document.
>

IMHO, complaining that DMARC is vulnerable to cousin domain abuse is like
pointing out that auto license plates can't prevent someone else from
buying the same model/color car as yours, and wearing a disguise.

I do appreciate that someone looking for the benefits of DMARC would also
want guidance on how to address domain spoofing in general, but it feels
like it could escalate to a bottomless time-suck very quickly.

J