[dmarc-ietf] Re: Aggregate Reports sent by a third party
On Mon, 9 Dec 2024, Daniel K. wrote: On 12/9/24 18:37, John R Levine wrote: Once again, we are not the Network Police. If we make the fields mandatory, that means that reports that are missing them but are otherwise OK are ill formed and should presumably be discarded. Why would that be a good idea? Implementing DMARCbis and new aggregate reporting should go hand in hand. The new stuff in DMARCbis should be reflected in the new reports. E.g. the "np" and "discovery_method" tags should be the reports, Sure. and mandatory. Once again, why? What benefit is there to discarding reports that don't have them? Presumably, no one will just implement new aggregate reporting on top of existing RFC 7489 DMARC. And, presumably, no one will update to DMARCbis, but keep the old aggregate reporting mechanism in place. People will update in all sorts of haphazard ways. (I should know.) Some may get around to some parts before they get to others. Why should we try as much as possible to be backward compatible in the aggregate reporting XML format? Um, so that people can continue to accept the reports they actually get? R's, John PS. we need to add the "np" element to PolicyPublishedType. Sure, send in a pull request. ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Aggregate Reports sent by a third party
On 12/9/24 18:37, John R Levine wrote: > Once again, we are not the Network Police. If we make the fields > mandatory, that means that reports that are missing them but are otherwise > OK are ill formed and should presumably be discarded. Why would that be a > good idea? Implementing DMARCbis and new aggregate reporting should go hand in hand. The new stuff in DMARCbis should be reflected in the new reports. E.g. the "np" and "discovery_method" tags should be the reports, and mandatory. I don't think anyone, in response to the new RFCs, will update the namespace declaration, and call it a day. Presumably, no one will just implement new aggregate reporting on top of existing RFC 7489 DMARC. And, presumably, no one will update to DMARCbis, but keep the old aggregate reporting mechanism in place. DMARCbis require new things; tree-walk, "np", "testing" etc. We should expect that to be in the report, just as we expect the removed "pct" not to be there. Changes are mandatory, old reports are not compatible. Why should we try as much as possible to be backward compatible in the aggregate reporting XML format? Daniel K. PS. we need to add the "np" element to PolicyPublishedType. ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Aggregate Reports sent by a third party
On 12/9/24 17:06, John R Levine wrote: Sorry, I was wrong there. Of course we need updated XML if only to add the flag for whether you did a tree walk. Coincidentally, this new element, "discovery_method" is optional in the new schema. The same applies to the new "testing", it's optional in the schema. I thought it strange, but chalked it up to limited backwards compatibility, or some such when I read it the first time. Reading it through again, I think those should not be optional, those details are an important part of this iteration of the specification, and needs to be in the reports. Once again, we are not the Network Police. If we make the fields mandatory, that means that reports that are missing them but are otherwise OK are ill formed and should presumably be discarded. Why would that be a good idea? R"s, John ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Aggregate Reports sent by a third party
On 12/9/24 17:06, John R Levine wrote: > Sorry, I was wrong there. Of course we need updated XML if only to add > the flag for whether you did a tree walk. Coincidentally, this new element, "discovery_method" is optional in the new schema. The same applies to the new "testing", it's optional in the schema. I thought it strange, but chalked it up to limited backwards compatibility, or some such when I read it the first time. Reading it through again, I think those should not be optional, those details are an important part of this iteration of the specification, and needs to be in the reports. Daniel K. ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Aggregate Reports sent by a third party
On Mon, 9 Dec 2024, Tero Kivinen wrote: And if someone invents a way to use this attack vector to do something bad (even if we have not invented how to use things for attacks does not mean that someone does not do that in the future), how much you want to do pay for us to come back in few years and fix the standard and also all the implementations in short timeframe to stop that attack? Since we're talking about an attack that has been hypothetically possible for a decade but has never occured, the obvious answer is zero. Furthermore, as I have pointed out several times, if someone wanted to send fake aggregate reports, there's no way to stop them. Bad guys can sign as easily as good guys. Separate reports for each domain would not change that. Email streams carrying DMARC feedback data MUST conform to the DMARC mechanism, thereby resulting in an aligned "pass" (see Section 3.1). That is fine, if they're DKIM signed you can use the usual reputation analysis to decide whose mail to accept. This practice minimizes the risk of report consumers processing fraudulent reports. That is not really true but it's not worth taking out. That's fine, but now that everyone needs to update the XML they produce anyway, ... Uh, what? Sorry, I was wrong there. Of course we need updated XML if only to add the flag for whether you did a tree walk. In my defense, tweaking the XML scripts and adding a few fields to the analysis datahases is a lot easier than completely redoing the way you send the reports. I've written analysis scripts, so I speak from some experience here. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Aggregate Reports sent by a third party
John Levine writes: > It appears that Daniel K. said: > >I'd rather eliminate any possibility of this type of bad actor to send > >bogus third party reports in the first place, but it seems like that is > >not going to happen. > > How much are you willing to pay every mail system in the world to > make major changes to their reporting system to address this entirely > hypothetical non-problem? That's not how standards work. And if someone invents a way to use this attack vector to do something bad (even if we have not invented how to use things for attacks does not mean that someone does not do that in the future), how much you want to do pay for us to come back in few years and fix the standard and also all the implementations in short timeframe to stop that attack? I know that security is not high up in the list of things email people do, but I usually work on the security area, and there we must always think about all possible ways of attacking the system, even when nobody has used those attack vectors before. We have to list all ways someone could attack the system and make sure we know what will happen when someone uses that attack vector. If what happens is bad, then we need to provide solution against that attack vector. If those aggregate reports are only "for your information only", and there is no actual actions ever happening based on those reports, then fake reports most likely will not cause any issues. If there is someone somewhere who are using automated tools and perhaps doing some actions based on those reports then they can be used to attack system, and we need to know what those attacks can be. On the other hand the text in draft-ietf-dmarc-aggregate-reporting: Email streams carrying DMARC feedback data MUST conform to the DMARC mechanism, thereby resulting in an aligned "pass" (see Section 3.1). This practice minimizes the risk of report consumers processing fraudulent reports. seems otherwise fine (i.e., saying the DMARC reports MUST be alinged), but the reference "(see Section 3.1)" seems to be invalid. There is no section 3.1 in that draft, and if it is trying to reference to base DMARCbis document, then I think section number is wrong, as 3.1 is "Conventions Used in This Document". I assume it used to refer to "3.1. Identifier Alignment" of "Domain-based Message Authentication, Reporting, and Conformance (DMARC)" RFC7489. If the reports are aligned with DMARC then we can at least filter fake reports out based on the sender if we start receiving such reports from bad actors. > >That's fine, but now that everyone needs to update the XML they produce > >anyway, ... > > Uh, what? If that's what the draft says, we need to fix it since for > obvious reasons, approximately nobody is going to change their report > software. After all, Google is still sending ZIP files. If your expectations is that nobody is going to change their implementations based on new standard track documents, then why are we producing these documents? I actually do at least hope that people will implement the standard track documents, and phase out old implementations which do not implement current non standard track versions... -- kivi...@iki.fi ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Aggregate Reports sent by a third party
On Sun 08/Dec/2024 01:30:27 +0100 Daniel K. wrote: [...] I see we receive similar third party reports from, among others: fastmaildmarc.com for fastmail.com dmarc.mailmike.net for inboxsys.net Inboxsys is wise not to set a rua= tag in the DMARC record of the domain it uses to send reports. For fastmail and others who don't have the same consideration, it may happen that small operators exchange messages with one of these domains only sporadically. In that case, an aggregate report can be the only message received by them during the entire next day. However, it still deserves to be reported, with 1. Then, in turn, that domain will report that they received that report, and so on, and so forth... Best Ale -- ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Aggregate Reports sent by a third party
On 12/8/24 22:04, John Levine wrote: > It appears that Daniel K. said: >> That's fine, but now that everyone needs to update the XML they produce >> anyway, ... > > Uh, what? If that's what the draft says, we need to fix it since for > obvious reasons, approximately nobody is going to change their report > software. After all, Google is still sending ZIP files. Need, and need. I guess everyone can keep on sending RFC 7489 compatible aggregate reports if they want to. The current draft, for example: * changes the XML namespace declaration * removed "pct" from PolicyPublishedType * removed helo as a valid value for spf/scope * removed forwarded/sampled_out, added policy_test_mode as valid values for PolicyOverrideType If you want to send Aggregate reports according to this draft, you must make some changes. Likewise, Report Consumers must adapt to the new world order. Daniel K. ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Aggregate Reports sent by a third party
It appears that Daniel K. said: >I'd rather eliminate any possibility of this type of bad actor to send >bogus third party reports in the first place, but it seems like that is >not going to happen. How much are you willing to pay every mail system in the world to make major changes to their reporting system to address this entirely hypothetical non-problem? That's not how standards work. >That's fine, but now that everyone needs to update the XML they produce >anyway, ... Uh, what? If that's what the draft says, we need to fix it since for obvious reasons, approximately nobody is going to change their report software. After all, Google is still sending ZIP files. R's, John ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Aggregate Reports sent by a third party
On 12/8/24 19:46, Richard Clayton wrote: > a) do you get so many duplicate reports every day that you don't wonder > about them anyway ? There's a lot of duplicate reports around, and the worst offender is Google, occasionally sending up to 5 identical reports. This has me kind of desensitised to error messages mentioning duplicate reports. On occasion I look into the duplicates, especially if there's a new sender involved. > b) DMARC reports are really useful in tracking down why genuine email > has been sent from your organisation that has not properly authenticated > (though it continues to amaze me in $DAYJOB$ how many people don't do > that at all and are surprised to learn it is happening). I agree totally. The reports are really useful in understanding the flow of our email. Most of the time the failures come from forwarders forwarding to BigMailProvider. > Beyond that, > knowing that there are bad actors out there is seldom actionable. I'd rather eliminate any possibility of this type of bad actor to send bogus third party reports in the first place, but it seems like that is not going to happen. That's fine, but now that everyone needs to update the XML they produce anyway, it seems like this would also be the perfect time to update the alignment requirement to make the described third-party fraud impossible. The fact that it's not a problem now, does not mean that it will continue to not be a problem. It's now or never. Daniel K. ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Aggregate Reports sent by a third party
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <3446f0a8-5a90-0d50-b315-f25140fd6...@vendo.no>, Daniel K. writes >Imagine OK, boring afternoon so far ... >This way we do not know about what bad actor is doing, unless we >manually look into every duplicate report. a) do you get so many duplicate reports every day that you don't wonder about them anyway ? b) DMARC reports are really useful in tracking down why genuine email has been sent from your organisation that has not properly authenticated (though it continues to amaze me in $DAYJOB$ how many people don't do that at all and are surprised to learn it is happening). Beyond that, knowing that there are bad actors out there is seldom actionable. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZ1X3j92nQQHFxEViEQJd5ACfe+H17cs6r3Glmg3XgvfCBZDzsd0An1BM Rf165buQ8WPtwjsF2AwYFcKc =c9uA -END PGP SIGNATURE- ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Aggregate Reports sent by a third party
On Sun, Dec 8, 2024 at 12:53 PM John R Levine wrote: > > On Sun, 8 Dec 2024, Daniel K. wrote: > > * Bad actor sends email to example.com spoofing the > > From address. > > > > * Bad actor then sends a fake third-party report to us > > purporting to be from example.com for the reporting period. > > Does that really happen? > > We have several people here who run services that process a lot of > reports, so I'd be interested to hear what they have to say. I've never heard of this happening. I hear the concern. I think if it took us years to even think about it, it's probably not something we have to rush to address. How we might link or verify reporting MBPs to domains in the future might be an interesting thing to discuss ... in the future. My hope is that we backburner it for today. It ranks number eleven, at best, on everybody's top ten list of issues. Cheers, Al Iverson ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Aggregate Reports sent by a third party
On Sun, 8 Dec 2024, Daniel K. wrote: * Bad actor sends email to example.com spoofing the From address. * Bad actor then sends a fake third-party report to us purporting to be from example.com for the reporting period. Does that really happen? We have several people here who run services that process a lot of reports, so I'd be interested to hear what they have to say. R's, John ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Aggregate Reports sent by a third party
On 12/8/24 17:32, John R Levine wrote: >> Suddenly someone clever may come up with a use case, and start sending >> bogus third-party reports. > > I really, really, do not want to waste time on "this has never happened in > the past decade and nobody can think of a plausible reason to do it but it > MIGHT happen" stuff. We'll be here until the end of time if we do. Thanks, but I wish you could state so more plainly, I feel like I'm really insisting to get my points across, and that I'm on the brink of overstaying my welcome, being a PITA to all of you, doing so. In addition to what Mark said, which I did not know about since I do not use those services, I can think of the following: Imagine example.com using a deterministic report_id based on our domain name and epoch start and end time of the report. A pattern I see from many reporters. * Bad actor sends email to example.com spoofing the From address. * Bad actor then sends a fake third-party report to us purporting to be from example.com for the reporting period. * The report is processed * example.com sends the real report, but this report is discarded as duplicate. This way we do not know about what bad actor is doing, unless we manually look into every duplicate report. Granted, the unauthorized third-party report is only one piece of the puzzle here. The report_id could be chosen better, etc. Daniel K. ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Aggregate Reports sent by a third party
I agree with you (as it's not a DMARC problem itself, like I said); just thought I'd mention it for consideration. - Mark Alley On 12/8/2024 12:16 PM, John Levine wrote: It appears that Mark Alley said: If an actor with mal-intent wanted to grief an organization identified using one of these services that bill their services this way, they could spoof unfathomable amounts of emails to receivers known to generate Aggregate and/or Failure reports, and blow said customer's paid-for DMARC reporting analytics licensing out of the water, and could increase their costs for using the tool extremely high. Please see the message I just sent. But in the meantime ... DMARC analysis services have existed for a decade. If this were a real problem, it would already have happened and they'd have figured out how to deal with it. Furthermore, even if it were a real problem, bad guys can sign their mail as easily as anyone else, so there's nothing we could put in the spec would help. Can we please stop inventing problems and finish up this document? It's way, way, past its sell date. R's, John___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Aggregate Reports sent by a third party
It appears that Mark Alley said: >If an actor with mal-intent wanted to grief an organization identified >using one of these services that bill their services this way, they >could spoof unfathomable amounts of emails to receivers known to >generate Aggregate and/or Failure reports, and blow said customer's >paid-for DMARC reporting analytics licensing out of the water, and could >increase their costs for using the tool extremely high. Please see the message I just sent. But in the meantime ... DMARC analysis services have existed for a decade. If this were a real problem, it would already have happened and they'd have figured out how to deal with it. Furthermore, even if it were a real problem, bad guys can sign their mail as easily as anyone else, so there's nothing we could put in the spec would help. Can we please stop inventing problems and finish up this document? It's way, way, past its sell date. R's, John ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Aggregate Reports sent by a third party
One thing I will add to supplement the scenarios mentioned - many commercial DMARC products charge customers by total Aggregrate/Failure report volume, regardless of legitimacy. (but this isn't an RFC7489/DMARCbis problem IMO) If an actor with mal-intent wanted to grief an organization identified using one of these services that bill their services this way, they could spoof unfathomable amounts of emails to receivers known to generate Aggregate and/or Failure reports, and blow said customer's paid-for DMARC reporting analytics licensing out of the water, and could increase their costs for using the tool extremely high. - Mark Alley On 12/8/2024 11:27 AM, Daniel K. wrote: On 12/8/24 01:58, John R Levine wrote: Well, you know, I have a domain dmarc.fail, and if I wanted I could send you dmarc reports from dmarc.fail that are 100% DKIM signed and SPF pass and DMARC aligned and 100% valid XML but that are also 100% fictional. And if I suddenly start to get bogus DMARC reports from you, I can filter out everything reported by dmarc.fail I do not understand what problem you think exists here. As stated elsewhere, I'm reading through the drafts looking for inconsistencies, and pointing them out in case changes are warranted. Even if no change is made, the extra scrutiny at least means that we have more than "it was carried over from RFC 7489" as the reason the text is there. Here, I think the problem was stated in the part of my initial message that you cut out. As written now, carried over from 7489: Email streams carrying DMARC feedback data MUST conform to the DMARC mechanism, thereby resulting in an aligned "pass" (see Section 3.1). This practice minimizes the risk of report consumers processing fraudulent reports. By our discussion here, DMARC alignment reduces no such risk. The fact that no one seems to send fraudulent reports, is a happy coincidence. There are two types of fraudulent reports: * the one you described above; bogus reports from dmarc.fail. This is hard to protect against. But they can be filtered out if discovered. * the one I described; someone claiming to report on behalf of third parties. Like Yahoo, and others, currently does on behalf of its subsidiaries, or due to misconfiguration. This is easy to discover. Right now all of them seem to be legitimate, but there is no way to know for sure. Anyone can send fake DMARC reports but as I said, I've never seen one and it's hard to imagine a plausible reason to do so other than just being perverse. Suddenly someone clever may come up with a use case, and start sending bogus third-party reports. If we want to take action, right now seems to be the time to add further requirements of alignment that will eliminate this third-party kind of fraud. At least then, a sender can only send fraudulent reports on its own behalf, not on the behalf of others. Daniel K. ___ dmarc mailing list --dmarc@ietf.org To unsubscribe send an email todmarc-le...@ietf.org___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Aggregate Reports sent by a third party
Suddenly someone clever may come up with a use case, and start sending bogus third-party reports. I really, really, do not want to waste time on "this has never happened in the past decade and nobody can think of a plausible reason to do it but it MIGHT happen" stuff. We'll be here until the end of time if we do. R's, John PS: As written now, carried over from 7489: Email streams carrying DMARC feedback data MUST conform to the DMARC mechanism, thereby resulting in an aligned "pass" (see Section 3.1). This practice minimizes the risk of report consumers processing fraudulent reports. It's true that what it says is wrong, since in fact it doesn't have any material effect, but I don't think it's worth changing. ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Aggregate Reports sent by a third party
On 12/8/24 01:58, John R Levine wrote: > Well, you know, I have a domain dmarc.fail, and if I wanted I could send > you dmarc reports from dmarc.fail that are 100% DKIM signed and SPF pass > and DMARC aligned and 100% valid XML but that are also 100% fictional. And if I suddenly start to get bogus DMARC reports from you, I can filter out everything reported by dmarc.fail > I do not understand what problem you think exists here. As stated elsewhere, I'm reading through the drafts looking for inconsistencies, and pointing them out in case changes are warranted. Even if no change is made, the extra scrutiny at least means that we have more than "it was carried over from RFC 7489" as the reason the text is there. Here, I think the problem was stated in the part of my initial message that you cut out. As written now, carried over from 7489: Email streams carrying DMARC feedback data MUST conform to the DMARC mechanism, thereby resulting in an aligned "pass" (see Section 3.1). This practice minimizes the risk of report consumers processing fraudulent reports. By our discussion here, DMARC alignment reduces no such risk. The fact that no one seems to send fraudulent reports, is a happy coincidence. There are two types of fraudulent reports: * the one you described above; bogus reports from dmarc.fail. This is hard to protect against. But they can be filtered out if discovered. * the one I described; someone claiming to report on behalf of third parties. Like Yahoo, and others, currently does on behalf of its subsidiaries, or due to misconfiguration. This is easy to discover. Right now all of them seem to be legitimate, but there is no way to know for sure. > Anyone can send > fake DMARC reports but as I said, I've never seen one and it's hard to > imagine a plausible reason to do so other than just being perverse. Suddenly someone clever may come up with a use case, and start sending bogus third-party reports. If we want to take action, right now seems to be the time to add further requirements of alignment that will eliminate this third-party kind of fraud. At least then, a sender can only send fraudulent reports on its own behalf, not on the behalf of others. Daniel K. ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Aggregate Reports sent by a third party
On Sun, 8 Dec 2024, Daniel K. wrote: Personally, I don't think I've ever seen a fake aggregate report, and it's hard to imagine e plausible reason for sending one, so I don't worry about it. Or you can use DKIM the way we originally intended and observe that yahoo.com has a generally good reputation so you'll accept the reports they send. Many of these domains only send us DMARC reports and have no independent reputation for 'normal' mail. Well, you know, I have a domain dmarc.fail, and if I wanted I could send you dmarc reports from dmarc.fail that are 100% DKIM signed and SPF pass and DMARC aligned and 100% valid XML but that are also 100% fictional. I do not understand what problem you think exists here. Anyone can send fake DMARC reports but as I said, I've never seen one and it's hard to imagine a plausible reason to do so other than just being perverse. R's, John ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Aggregate Reports sent by a third party
On 12/7/24 20:35, John Levine wrote: > It appears that Daniel K. said: >> But how can I know that nore...@dmarc.yahoo.com speaks on behalf of >> yahoo.no, aol.com, rocketmail.com, etc.? > > Yahoo is an outlier here sending separate reports for different hosted > domains. They're not the only ones doing it like that, and looking a bit harder I see we receive similar third party reports from, among others: fastmaildmarc.com for fastmail.com dmarc.mailmike.net for inboxsys.net Banks *long*.sbcore.net for swedbank.se seb.se for sebkort.no Government statens-it.dk for sitnet.dk Some of them does not even pass DMARC. *many.labels*.iphmx.com for avinor.no and lots more perim-prod-007.politiet.master.net for dmarc_noreply.politiet.no Looks like it's from the Norwegian police, but hard to tell since they're using a totally made up domain. Not DKIM signed, but SPF for politiet.no lists the sending IP. > Personally, I don't think I've ever seen a fake aggregate report, and it's > hard > to imagine e plausible reason for sending one, so I don't worry about it. Or > you can use DKIM the way we originally intended and observe that yahoo.com has > a generally good reputation so you'll accept the reports they send. Many of these domains only send us DMARC reports and have no independent reputation for 'normal' mail. > You probably also get reports from google.com that include mail sent > not just to google.com or gmail.com but the gazillion private domains > they host. You can't even tell what recipient domains they purport to be > reporting. Indeed. Daniel K. ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Aggregate Reports sent by a third party
It appears that Daniel K. said: >I regularly get reports from nore...@dmarc.yahoo.com, that are DKIM >signed by yahoo.com, on behalf of all the other yahoo ccTLDs and their >other domains. > >The "Submitter" field in the subject identifies the domain the report is >from, and the attachment filename starts with this same domain as well. >(e.g. yahoo.no) > >But how can I know that nore...@dmarc.yahoo.com speaks on behalf of >yahoo.no, aol.com, rocketmail.com, etc.? Yahoo is an outlier here sending separate reports for different hosted domains. Personally, I don't think I've ever seen a fake aggregate report, and it's hard to imagine e plausible reason for sending one, so I don't worry about it. Or you can use DKIM the way we originally intended and observe that yahoo.com has a generally good reputation so you'll accept the reports they send. You probably also get reports from google.com that include mail sent not just to google.com or gmail.com but the gazillion private domains they host. You can't even tell what recipient domains they purport to be reporting. R's, John ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
