Subject: [dmarc-ietf] Concerns for not Sending a Failure Report?

From: Дилян Палаузов <[email-masked]>
Date: Fri, 02 Aug 2019 21:41:04 +0000

Hello,

I just thougth once again on this.

Some of the senders of aggregate reports offer free mailboxes.

Aggregate reports show that emails from a host to a provider of free mailboxes sometimes do not validate DMARC.

The one provider sending emails opens a free mailbox on the receiver and then sends a secret copy of each, otherwise
ordinary delivered email, to that special mailbox.

Then the mails from that mailbox are downloaded, and the A-R header is checked.  By this way the sender finds out, which
messages exactly have failed DMARC validation.

At the end the same information is obtained, that can be obtained by exchanging a failure report: which messages have
failed.

Has somebody done this?

Why does it have to be that complicated?

Regards
  Дилян

---

From: Steve Atkins <[email-masked]>
Date: Sun, 4 Aug 2019 09:07:47 +0100

> On Aug 2, 2019, at 10:41 PM, Дилян Палаузов <[email-masked]> wrote:
> 
> Hello,
> 

Information found in mail mail headers in accounts that you have created includes email that's been sent to you.

Information found in failure reports includes email that generally was not sent to you.

Cheers,
  Steve

---

From: Дилян Палаузов <[email-masked]>
Date: Sun, 04 Aug 2019 08:18:15 +0000

Hello Steve,

in both cases it is about information that was sent over from the same mailhost.  To whom the information was sent
decides the operator of the mailhost, not the one who suppresses failure reports.

In any case, for a failure report containing only the Message-Id it does not matter what information the email carried
and to whom the information was sent.

Regards
  Дилян

On Sun, 2019-08-04 at 09:07 +0100, Steve Atkins wrote:
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: Steve Atkins <[email-masked]>
Date: Sun, 4 Aug 2019 10:35:21 +0100

> On Aug 4, 2019, at 9:18 AM, Дилян Палаузов <[email-masked]> wrote:
> 
> Hello Steve,
> 
> in both cases it is about information that was sent over from the same mailhost.  

The mailbox provider has no way of knowing that you sent the mail. If it was authenticated as coming from you this wouldn't be an issue.

One mail was sent to *you*. It's OK for you to have access to it.

The other mail was sent to someone *not you*. There's no a priori reason you should have access to the content of the message.

Cheers,
  Steve

> To whom the information was sent

---

From: Дилян Палаузов <[email-masked]>
Date: Sun, 04 Aug 2019 10:10:51 +0000

Hello Steve,

do you mean, that a mailhost sending emails for a particular domain, protected by restrictive DMARC policy, has no
authority to decide, that persons appointed by the mailhost provider can read any email and any report?

I mean, a domain @A.int publishes “p=reject; ruf=[email-masked]” and sends all emails over host mail.a.int .  The provider
gives access to all (sent) emails to person Z.  Does publishing ruf=[email-masked], by the domain owner mean, that the domain
owner is capable to ensure that the persons who receive the failure reports and the persons who can read all sent mails
from @a.int are the same persons?  Or it means, that the domain owner is not capable to make such decision?

Z is capable to sent a copy of all outgoing mails indended for a particular provider to a dedicated mailbox at that
provider, fetch then the emails from the dedicated mailbox and filter the ones with Authentication-Result: dmarc=fail .

> The mailbox provider has no way of knowing that you sent the mail. If it was authenticated as coming from you this
wouldn't be an issue.

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.

I think now, that not sending failure reports has nothing to do with (privacy) concerns.  It is either laziness of the
receiving site to make the appropriate setup, or unwillingness to reveal information about mismatching DKIM
implementation of sender and receiver.

With willingness to align the implementations, a receiving site having (privacy) concerns, can offer a mailbox to the
sending site, where the sending mailhost duplicates each email from the sending to the receiving host.  Then the sending
host can fetch the mails and look for A-R: dmarc=fail.

That said I would like to see some text in the revisited DMARC specification about obtaining information about messages
failing DMARC, sent from a particular mailhost to another mailhost, when the receiving site does not send failure
reporst (for any reason), but is otherwise willing to exchange information about messages, failing DMARC validation.

Regards
  Дилян

---

From: Дилян Палаузов <[email-masked]>
Date: Sun, 04 Aug 2019 10:55:09 +0000

> is also the one, who has anyway access to the message.

Nope.  This does not work for redirected messages.

The assumption is that no host (sending spam) is going to forge headers in order to entitle another host to receive
failure reports.

A mail receiving host can obtain the IP addresses that receive emails for a domain (@a.int).

If a message, failing DMARC validation, is either sent from an IP address that receives emails for a domain (MX a.int),
or has such an address in its Received: headers, then the receiving site shall not have concerns that the one who would
receive the failure report would have anyway access to the message in question.

If the above validation of the IP address fails, but the DKIM-Signature contains "ruf=y", this means, that the receiving
site can assume, that the writer of the message is willing that a failure report is sent for the message and the
receiving site shall not have concern about sending reports.

As with the b= tag, when calculating or verifying the signature, the value of the "ruf=" tag (signature value) of that
DKIM-Signature header field MUST be treated as though it were an empty string.  Or NOT?

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 4 Aug 2019 12:56:06 +0200

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
--

---

From: Дилян Палаузов <[email-masked]>
Date: Sun, 04 Aug 2019 11:47:01 +0000

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
  Дилян