You should check all settings against skiff.com as that is what is relevant to this discussion. Letâs focus on the facts here rather than spreading innuendos and misinformation. Itâs really disappointing to see bad faith arguments to continue to be made. We will answer it seriously once in case that the previous questions were actually made in good faith.
Here is our DMARC record for skiff.com. Source: DNS Propagation Checker - Global DNS Testing Tool
I have also included it below if you donât want to click the link.
v=DMARC1;p=reject;pct=100;adkim=s;aspf=r;rua=mailto:rua-com@skiff.org,mailto:re+b36bf17d2996@inbound.dmarcdigests.com;ruf=mailto:ruf-com@skiff.org;fo=1;
Here we have 100% rejection for DMARC failures. Yes, we accept RUA and RUF reports that recipient email providers can choose to send us.
RUA vs RUF reports (Source: The Difference in DMARC Reports: RUA and RUF - dmarcian)
RUA reports - no PII. These are aggregate reports on DMARC failures.
RUF reports - email is only sent back to us in case of DMARC failure which means the mail did not originate from Skiff. We have a legitimate interest in finding spammers impersonating our domain and working with the broader community to take them down.
RUF reports are not sent at all to DMARCDigests. RUA reports again contain no PII of our users. It indicates the IP address of the sending email server. This means the IP we get back for legitimate users is the IP address of Skiffâs email servers which is known through our SPF records. Other IP addresses are not authorized to send on behalf of skiff.com. These IP addresses that we receive again from recipient email service providers is the IP addresses of email servers and not users.
Our agreements with DMARC Digests and their parent company are irrelevant because they do not ever receive personal information about our users because they only receive RUA reports do not contain identifying information about our users.
Let me ask this, since I do not have means to test,
This is categorically false. DNS records are available publicly for custom domains bought through us or when a user brings their own domain. Again, this is where we believe these arguments are made in extremely bad faith by arguing that these items are not verifiable when in fact they are through websites that let you query DNS records or by even using the dig CLI tool.
To answer your question since you claim you cannot test this, we do not add RUA and RUF tags for custom domains. To onboard a custom domain, SPF, DKIM, and DMARC are all required before verification. Here is a screenshot of a test domain and the records we require clearly documenting these requirements.
On the scary story of âDKIM reply attacksâ I assume that you mean DKIM replay attacks?
Yes, we meant DKIM replay attacks. Weâve dealt with them successfully and have just as strong mitigations as Proton and in some cases stronger. For example, the expiry tag we use on our DKIM signatures last just a few minutes. For Proton, this is a few days. Proton does not over sign headers. We do. Here is the evidence for that.
Proton DKIM Signature Header
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1680725421; x=1680984621; bh=vkaEgdv9blx7I/kJwDMn9s2jZkAkWlF0qXcEEPbw3JA=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=CxYNgddWxKevJYlJlx8LFHwJUfaPqjOFmjIkBHWV2+UqEIfc1iWqWRSJt6FH5COnb
NUWNRguW+6RkXVZ56Ab17KkFpsgqNNafivGHLMQMS8ujpUe98v4FfNsX6RSDHaQxFr
Qg/CCOONC7K9g4pcigek5+XGHi7E8iUnOQ7NkNcYRQvMVAyGKEvCNK6Tep77tPdLC8
lbRiGrgGfF/skJJW/kYXZnu+x7JRAWXFWr8Td3/VG58mky7LXcq9G1zMGpY3Sf5JK2
1oRDm2a4d3iuD6oiufOWvBAisKrJW1o9r6G6wo+q/SLoKt0BiryvxA3KjPPer6hoXk
frAf+OBUBtugQ==
Skiff DKIM Signature Header
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=skiff.com; s=skiff1; h=subject:subject:from:from:to:to:date:date:message-id:message-id:reply-to:resent-date:resent-from:resent-to:resent-cc:in-reply-to:references:list-id:list-help:list-unsubscribe:list-subscribe:list-post:list-owner:list-archive:feedback-id:feedback-id:content-type:content-type:content-transfer-encoding:content-disposition:mime-version:mime-version:sender:resent-message-id:resent-sender:content-description:content-id; bh=fo/cTVEj7VfLbVN/naM8bq4BjudDvGFxFpC11rjyKao=; t=1680725670; x=1680729270; b=Ez+DIa4CkP+DwXHFTomNCsamgQ0dAIsuWsufwanWZZ9s97O//q4I05kJk934K+tec9dvRKPifY MZsGr76I47TCtluQpFZRSdWSYyvuF5bpwD3C1iOXYi1Lthtz/h6XZym8ZQLzUF7IRPBRKMtmkCDK kYfarFAka3c/QYiu9hfo/romY5+DHASn5kK3/iEGm8W20ywD+46xXAfv8kLb/p7VFoFutlnUsAhR OBbix0S+IGCKxgqO3RhZuk7XDY7PjQYcGXkve71CmmbOTTQPhU59JvbCajl/UeVx7QmWUq23OS1/ cpnBEp2SekfwhPDjc5+khoFo5H1cKuPRpmnRVY3Q==
Again, this is all verifiable by sending an email from Proton and an email from Skiff to any of your favorite email providers and viewing the raw headers.
If you want to engage in good faith arguments, please do so! We welcome that! We removed SES as a backup and prioritized that work due to legitimate concerns. However, spreading misinformation through innuendo should not be welcome when we actually are looking to build privacy services for the Internet.