On 1/26/21 12:01 PM, Todd Herr wrote:
On Tue, Jan 26, 2021 at 2:24 PM Michael Thomas <[email protected] <mailto:[email protected]>> wrote:


    On 1/26/21 10:56 AM, Todd Herr wrote:

        > In addition, if I recover that message from the log, I might
        find no
        > relationship with the reporting domain or the reported
        source IP.
        > That is to say, I won't be able to deduce if the report is
        fake or real.


        My main point here is to point out the attack.


    The attack scenario you have described relies on several possible
    but perhaps implausible conditions all being true:

    1. There exists a domain run by people who are savvy enough to
    want to implement DMARC and can consume reports, but don't have a
    good grasp on which IPs are likely to be theirs and which aren't,
    and don't have an understanding of how to use common tools to
    figure out whether an IP address might belong to their provider's
    ASN or one halfway around the world, and

    Here's a very basic question: if I do not know all of the IP
    addresses that send on my behalf, are DMARC reports of any value?
    Enterprises farm out email all of the time and it could be
    difficult to know when they change their server addresses, etc. If
    the reporting is predicated on your having in effect and up to
    date SPF record (ie, do all of the work to be able to produce
    one), then that negates anybody who just uses DKIM alone which
    should be a completely acceptable use case. And no, the
    domain/selector tells you nothing when it doesn't verify.

    If it is the case that you MUST know all of your sending IP
    addresses, that should be in blinking bold right up front in
    section 7.


Yes, DMARC reports are of value if you don't know all of the IP addresses that send on your behalf. Some have even written blog posts on the topic of using DMARC aggregate reports as a tool to audit one's authentication practices, by publishing a policy of p=none, collecting the reports, analyzing the data, fixing problems, iterate, iterate, iterate until one is ready to move on to the ultimate goal of p=reject.

How do I know when I'm done though if I don't know the IP addresses who send on my behalf? Is it an actual forgery or is it Marsha in marketing using a outsourced email blaster?

The larger point is that I should not have had to come to a working group mailing list to find out what should be in the document in the first place. Along with some ascii art in 7.2, there needs to be some explanation of the reporting's applicability and limitations. It doesn't need to be tome but some informative text goes a long way to helping people out who we're involved with the document from the beginning.

Mike

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

Reply via email to