Skiff Mail (Email Provider)

You seem to misunderstand the difference between RUA and RUF. RUF is for failures and forensic reports which you would need for violations, they are not shared it seems (luckily).

RUA is for aggregate reports, so not just failures. RUA reports include the following information: timestamps, domainnames, and the ipaddress of sender. I hope that you are aware that Active Campaign is a marketing company, and you just feed them data. They can get more info on what services your users use, not what I expect from a private mail firm. Do you have agreements with Active Campaign on what they can do with this data?

Let me ask this, since I do not have means to test, do you also configure these RUA for custom domains people order at you? I wonder this because that would even further narrow down the information and could directly tell Active Campaign what services someone is using or who they know, etc. Or do they not get to use this monitoring?

Obviously many people got their domains through different providers so can configure it themselves. Appearantly not as greatly as one would hope, most of the other domainsnames I can find on your MX are not having any DMARC. Not saying you should but might be nice to advice them. As for Proton Mail I know this is part off the onboarding of domains.

On the scary story of “DKIM reply attacks” I assume that you mean DKIM replay attacks?
Here is a cool blogpost on what measures actually work:

e class="onebox allowlistedgeneric" data-onebox-src="https://proton.me/blog/dkim-replay-attack-breakdown">
Proton – 13 Jan 22

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.

2 Likes

We won’t be responding to any further messages back and forth due to the bad faith nature of the arguments (and they appear to be circular). If you have any other questions please write to security@skiff.org.

We’d love to hear any other questions from the PG team in the meantime.

I do not have a custom domain at you that’s why I cannot test this, Hence I ask, I will take your word for this. I am not saying this is not verfiable. I said I cannot test it.

I am glad, that’s positive!

I definitely do! As I also said I am happy to have seen the changes made before. I am just critical and hope to push to actually change more.

A domain can be PII sorry not sorry, who are you to judge what is PII? I asked explicitedly about the custom domains here cuz it could directy tie togther that e@bob.example knows e@alice.example.

Edit:
Just to add to this aswell, even now that you confirmed this is not the case you still give a marketing company access to data of usage of your customers. I cannot see this in another way. By doing so you might be helping them in profiling. Hence I asked about your argeements with them, who could legally restrain them from utilizing it, besides that I think it would be preferable to keep this internal.

I am just being critical and if you don’t like that I am sorry. I am open to a good discussion on what is privacy and the values, we do not seem to see it in the same way. It saddens me you are not willing to discuss it.

1 Like

Actually, you could test this! You don’t even need a domain to see what records you would need to add. We enjoy having conversations about privacy (this entire thread is for that purpose), but not ones with disinformation or bad assumptions. Also, there’s plenty of documentation available if you prefer “not to test” some of the things being discussed.

BTW, there are legal definitions of PII! Domain names are not on that list. We do agree they are sensitive, though, so I would advise reading the response above again.

Again, I will try to limit responses because it’s quite time consuming to step through this issue by issue.

Okay sure lets not use the PII from the US law but a more sane term used in the EU:

“Personal data is any information that relates to an identified or identifiable living individual. Different pieces of information, which collected together can lead to the identification of a particular person, also constitute personal data.”
-Data protection explained - European Commission

Edit:
I think it seems time for a little sum up of the issues I had/have:

  • DNS settings (mostly resolved)
  • Amazon SES (resolved)
  • Giving data to third parties, especially marketing firms
  • False GDPR claims
  • Being called out for not knowing GDPR? While it seems to be the other way around
  • Using emails for recovery for product updates, or as I call it spam (resolved only for new users)

And we seem to have different values when it comes to privacy. I care more about the intensions and the privacy by design aspect of your business, while you are focussed on being complaint for listing.

Did you even read Nishil’s response?

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.

Of course, we are happy to have discussions about this, but not waste time.

Yes I have read it and also in previous reply acknowledged it.

Honestly, we’ve spent an incredible amount of time walking through the false pretenses and claims in your posts. And, everything we’ve noted about GDPR is correct - I can’t find a logical argument in any of your comments (especially the one I posted on cookies).

Values-wise, our entire business is architected around privacy. We collect as little PII as possible - even avoiding user IP address collection on login - and that’s why we were banned in Russia in only 8 months of Skiff Mail being launched (Russia is blocking encrypted email startup Skiff | TechCrunch or https://www.wsj.com/articles/encryption-bans-what-is-this-russia-hacking-online-privacy-security-data-signal-whatsapp-emails-protection-11675436242).

We also take a ton of time to engage with our community on Discord, Reddit, YouTube, Play Store reviews, etc. What is tough is when we get into circular debates or discussions that aren’t grounded in technical fact. We love the PG community - I’ve been participating in threads for over a year! - and spent a huge amount of time making Skiff suitable to your criteria.

We’re launching Webauth/hardware keys soon, are working on options for encrypted email to non-Skiff users, removed MX records that we had intended as a last-resort backup because we do align in values and are open to having our opinions changed. There is nothing more exhausting than practicing these values but spending time on incorrect assumptions.

I am not disagreeing on you efforts, they are appreciated. Yet we disagree on how the GDPR is read, even dates seem to cause a disagreement while all is public info.

The architecture I fully believe is done right. I am not talking about that. I am talking about values. You might be listed by PG team even without having the same view as I have. I just never would go for a provider that does the things mentioned when there are others who do not. I am not sure if being blocked in russia is somthing to celebrate, but okay.

I am not seeing why this is circular I brought up things that are not solved yet and new discoveries. I even made a list now in my previous reply with the list of things I take issue with.

I know you have been around, just like myself (i lost count of years) for a while, and I am happy to have your view on things even if we do not agree.

This sounds really cool and that is just awesome. :clap:

I still hope you will take a look at what I have said and reconsider those. I will continue to report if I find other things, but I think I have well argued for my views and explained what I like to see changed.

1 Like

I completely understand. We are here both to improve our product and hopefully to be listed. Nishil and I are merely disagreeing with some of the technical points because we do not mass-share user domains with any third parties (also, to be clear, knowing whether a single domain is connected to Skiff is public record via a DNS lookup - no matter what we want to do about it).

We are open to any further feedback and will continue to improve our product regardless. Not that long ago, Skiff was a 2-3 person team, so we would not have existed this far without absorbing a lot of important feedback.

1 Like

I’m confused about what your concern here is. As far as I can see, the only information even remotely related to “usage” that DMARCDigests receives is:

  • How many emails each reporting mailserver received from @skiff.com.

I don’t see how this could be used to individually profile any users.


I also don’t fully understand your argument relating to GDPR here, I think I’ll have to read through this thread again and unpack this tomorrow lol. Although @amilich’s blog post that says GDPR went into effect in 2020 is obviously incorrect, that seems a bit nitpicky to me :slight_smile:

Clearly I will have to re-test the whole “marketing emails going to recovery addresses” thing though, since we last tested that ~7 weeks ago and it was supposedly fixed “about 6 weeks ago.”

For what it’s worth, GDPR does require affirmative opt-in consent for marketing communications. I suppose if this is indeed fixed then you are compliant in this area now, but you would not have been compliant prior to ~6 weeks ago to my knowledge, which is probably why this issue was brought up.

I would imagine that any of your existing customers in the EU could still file a complaint about this.

1 Like

My point above was that the emails aren’t marketing mail, particularly before Skiff Mail existed. So, there was a ~6 month period of time where this situation existed and I understand it wasn’t ideal. But, we did fix it, so sign up for a new account, add a backup email, and you will not get any sort of product updates. Anyway, I don’t think it’s necessarily rehashing the nitpick about transactional mail vs legitimate interest vs marketing mail.

1 Like

Hey all! We just launched Yubikey/hardware key support.

Anything we can do to unblock the thread or the PR to include Skiff Mail?

3 Likes

What makes you guys want to be recommended on Privacy Guides? While I do appreciate that you guys are improving your services and stuff, I don’t know if this is being done because you actually want to be as good as possible for privacy and security and help people with their privacy journeys or because you guys want some free “advertising” by being recommended on Privacy Guides.

1 Like

We’ve spent a year improving our product to the point where we’re quite confident it stands alone to be on this list by being as good or better than every other existing option. The same is true of every Skiff product: Drive, Pages, Calendar, and Mail.

We have absolutely no desire for free advertising. Our product stands alone in going above and beyond on security, usability, and privacy.

Have you read the other 137 topics in the thread above?

A 128x128 SVG logo for Skiff Mail (two if there needs to be a separate one for dark mode) would be quite handy.