Hello Alessandro, what is the purpose of the failure reports?
If the purpose is align DKIM, SPF and DNS implementations of senders and receivers, then I am proposing ways to exchange information for debugging. I do not propose how to obtain information about scammers’ actions. DMARC is invented to make the workflow of scammers impossible, it is not about exchanging information of performed scammers’ action. If a site promises to its users, that all emails will be encrypted, then publishing a ruf= address likely violates that promise. This is not necessary true, if the failure report is delivered (encrypted) only to the person who sent the original message. This creates a big fuzz, whether forwarding always the failure reports to the sender of the original message is a good idea and goes out of scope. I changed my mind: The DKIM—Signature has a tag r=y. It is a matter of adding a new value r=a, that means both: • The writer of the message, or a site which has received the message at some moment, is willing that a failure report for failed DKIM validation is sent, for every present DKIM-Signature that aligns to DMARC. The one who adds r=a can have a copy of the message. • Receiving sites can assume, that whoever adds r=a has a already a copy of the message and sending failure report with the content of the email does not reveal information to the recepient of the report about the content of the email. Now, if nearly all mails from a domailn, that pass DMARC have r=a and emails that fail DMARC from the domain, have no r=a, then the lack of r=a on its own, makes the mail suspicious. Will scammers start inserting r=a? Will be there a doubt, when both r=a and ruf= are present, that both the writer of the message and the domain owner are willing to receive failure reports and neither of them has concerns, when the reports are sent? Regards Дилян On Sun, 2019-08-04 at 12:56 +0200, Alessandro Vesely wrote: > Hi Dilyan, > > On Sun 04/Aug/2019 12:10:51 +0200 Дилян Палаузов wrote: > > > The receiving server knows, which IP address sent the mail and it knows, to > > which IP addresses set the failure report will go. If there is a match in > > the IP addresses, then the receiving server knows that the one who will get > > the report is also the one, who has anyway access to the message. > > That's not always true. For example, I know of mailbox providers who, on > delivery, automatically encrypt cleartext messages to the public key of the > recipients, including the Sent folder. Operators at that provider's aren't > able to sniff message contents unless they're sent back on failure by > receiving > sites. In general, users trust their mailbox providers also because of the > policies they enact. Matching those policies with unwarranted disclosure of > messages is not straightforward. > > In addition, the most interesting reports are messages not coming from my IP. > Scammers abusing may domain name use their own IPs. I see those failures in > the aggregate reports, but don't know if the IPs mentioned there correspond to > mailing lists or other legitimate forwarders, or even some ill-informed users > of mine who send their mail through their ISPs. That's why I need failure > reports. It would be enough if the aggregate reports contained an indication > of the spamminess of those messages, or the reputation of those IPs. > > Failure reports for messages originating from my IP are only useful for > debugging. An activity which I can more easily do by using free mailboxes, as > you said, or sites specifically dedicated to testing email. > > > Best > Ale _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
