Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy

[Дилян Палаузов <[e-mail]>]

Hello,

sending a notification, when DMARC does not match is comparable to sending a notification/feedback loop, when a user
clicks a message as spam.  In practice, when a company owns two labels, that were distinct companies in the past, for
the one label the new company sends in the feedback loop the user, who clicked the the mail as unwanted, and the other
label does not include the recipient’s mailbox.

Both labels include the Message-Id in the report.  So when the messege was sent to one user, with the Message-Id it is
possible to determine which user clicked the mail as unwanted (provided no transparent MLMs were involved).  When the
message was sent over a mailing list, from the Message-Id it is not possible to determine which user marked the mail as
unwanted.

It is technically possible to provide to every single recipient-copy spread over a mailing list a distinct Message-Id,
in order to be able to conclude from the feedback-loop message, which user marked the mail as unwanted, and be able to
unsubscribe the user from the mailing list.  Is this the way to go, or is the rationalle that the one who implemented
the feedback loop including Message-Id intentionally skipping the recipient mailbox do not understand the big picture?

Will be there any rational concerns, if for a failed DKIM validation a report is sent to the signing server, containing
just the Message-Id, when From: alignes and DMARC p!=none?

Regards
  Дилян

On Mon, 2019-01-28 at 10:15 +0100, Alessandro Vesely wrote:
> On Sat 26/Jan/2019 18:21:28 +0100 Дилян Палаузов wrote:
> 
> > Imagine there is a failure report stating that after a direct communication
> > between your server and another server, the receiving server sends you an
> > aggregate report, stating that 1% of the messages you sent yesterday do not
> > validate DKIM. How do you suggest to proceed to reduce this to 0%?
> 
> No way.  There are lots of little traps, for one example plain text messages
> where a line start with "From ", like so:
> 
> > From here on, this message likely fails DKIM.
> 
> As small as this cases appear, if you program your MTA to fix them before DKIM
> signing, you are going to break any OpenPGP/SMIME signatures that users had
> affixed before.
> 
> You can educate users to use format=flowed, good luck.
> 
> You can push for global maildir usage, even harder.
> 
> The bottom line is that, in practice, understanding where that 1% failures come
> from won't help eliminate them.
> 
> 
> Best
> Ale