Benjamin Piouffle · Blog

My burner email blocklist blocked me

Wed, 08 Jul 2026 00:00:00 GMT

A few days ago I tried to sign up for a public open-data service (the ECMWF, if you care) using a Proton Mail alias, and the form rejected my address as “potential spam”. My frustration was mixed with a bit of guilt: in 2018 I published Burnex, an Elixir package that compared emails against a large list of known burner domains, temporary inboxes like yopmail.fr that exist to receive a confirmation link and disappear. The library itself was relying on the fairly popular wesbos/burner-email-providers list.

At the time, I was working on a collaborative fact-checking platform where account authenticity mattered, and we needed some confidence that users were not fake or batch-generated. A domain blocklist felt like a cheap heuristic for a broader trust problem.

I may be late to the party, but let me put it clearly: I no longer recommend systematically blocking burner domains at signup.

TLDR;

If you are deciding signup policy today, do not automatically reject users for using privacy email services. Distinguish between public shared inboxes and personal aliases, and only block the former. The person behind an alias is more likely protecting themselves than trying to scam you, and the spammers have already moved on. If you maintain or consume a blocklist, consider splitting the categories and encourage good practices in your documentation.

Burners and aliases are not the same thing

A distinction that we often forget when it comes to email blocklists: a classic burner email is a public, short-lived inbox anyone can access, useful for clicking a verification link once and walking away. An email alias is the opposite: a permanent forwarding address tied to your account, that you control, can disable, and can trace back to a specific signup when your password appears in a breach.

Nowadays, tools like Firefox Relay and Apple Hide My Email are mainstream products, not edge-case hacker tools. Mozilla markets Relay as a way to keep your identity private when signing up for new accounts, and Apple sells Hide My Email as a way to share an address without sharing your real one (though they may be overselling that promise).

Blocklists that treat alias providers like throwaway inboxes end up blocking people who are trying to protect themselves. That matters beyond signup friction: aliases limit cross-site tracking, reduce spam after breaches, and let you know exactly which service leaked your address when junk mail starts arriving at a forwarding address you gave only to them. We should want more people using aliases, not fewer.

Blocklists don’t stop determined abusers

Determined abusers have never been limited to blocklisted domains. Gmail’s + aliasing creates unlimited variations of the same inbox (you+shop@gmail.com, you+news@gmail.com), services like Emailnator can help you generate infinite variations of these throwaway Gmail addresses on demand. Custom domains cost a few dollars a year while looking indistinguishable from legitimate business email. Unlike your users, spammers have the means and the time to work around a domain blocklist. For them it is a small obstacle, not a wall.

Yes, blocklists still catch some low-effort automated signups. But the cost is asymmetric: a naive bot gets slowed down slightly, while a real user with a legit alias gets hard-rejected with no recourse. You are optimizing for the attacker who gives up easily and punishing the user who takes privacy seriously. The people blocklists were meant to stop were never really stopped; they just learned to use domains you trust.

Beyond blocklists, email verification in general (including confirmation links) should not be treated as proof that an account is real, unique, or trustworthy. It only proves that someone could receive an email at that address once.

There are still valid uses

Checking whether an email domain appears on a known-disposable list is still a reasonable signal to feed into a broader trust or risk score, to surface suspicious patterns across a batch of signups, or to ignore them in your marketing campaigns.

If I were to rebuild Burnex today, I would narrow its scope to genuinely public and shared inboxes (addresses like mailinator.com where anyone can receive your verification email) rather than conflating those with personal forwarding services that happen to use a non-mainstream domain:

# Public burner inbox, probably ok to block
Burnex.is_burner?("random@yopmail.fr")

# Personal alias, usually not ok to block
Burnex.is_alias?("random@passmail.net")

But the problem is not just how one library categorizes domains: the upstream list Burnex relied on (wesbos/burner-email-providers) is consumed as-is by signup validators, third-party packages, and APIs worldwide. Many integrators block every domain in emails.txt without curating it, so the list’s categorization choices have real downstream effects.

For those who come after

I have opened an issue to propose exactly that split in wesbos’ list: keep one file for public shared inboxes (yopmail.fr, mailinator.com, and similar) and add a second for personal alias and forwarding providers (passmail.net, anonaddy.me, mozmail.com, and the rest). Then update the README with recommendations for good practices.

Due to a lack of time and because I don’t use Burnex anymore in the products I maintain, I deprecated the project in early 2026. Since then, Klemen Sever offered to take over the project, and I have transferred ownership.

Display channel users count with Elixir/Phoenix + React/Redux

Tue, 21 Aug 2018 00:00:00 GMT

A few months ago, we decided to implement a users count feature on CaptainFact’s videos pages. It had to be reliable, light and simple. We also wanted to differentiate between logged-in and anonymous users.

The most interesting read I had at the time on this subject was a medium article which has one major flaw: the full users list is returned from the backend and the count occurs on the frontend (which actually respects the default behaviour of Phoenix.Presence).

Depending on your business, it can represent a privacy issue (you don’t especially want anyone to be able to know who’s connected to your channel) as well as a performance issue.

In the following article, I’ll show you how I implemented Phoenix.Presence in such a way that it only returns the total of connected / anonymous users. We’ll then see how to bind it to Redux.

Backend

Implementing `Phoenix.Presence`

The first thing you want is to implement your own tracker:

lib/my_app_web/presence.ex

defmodule MyAppWeb.Presence do
  @moduledoc """
  Provides presence tracking to channels and processes.

  See the [`Phoenix.Presence`](http://hexdocs.pm/phoenix/Phoenix.Presence.html)
  docs for more details.
  """

  # Replace the values below with your app's values
  use Phoenix.Presence, otp_app: :my_app, pubsub_server: MyApp.PubSub
end

This implementation is enough if you want to return the classic users list (for example in a chat). In our case we want to override the default fetch to return only the users count, and not the full users list:

@doc """
Overrides the default fetch. Instead of returning the full users list,
we only return the count of open sockets.
This map is what will be returned to the frontend.
"""
def fetch(_topic, entries) do
  %{
    "viewers" => %{"count" => count_presences(entries, "viewers")},
    "users" => %{"count" => count_presences(entries, "users")}
  }
end

defp count_presences(entries, key) do
  case get_in(entries, [key, :metas]) do
    nil -> 0
    metas -> length(metas)
  end
end

Binding the presence module

Add your new module to your app’s supervisor

lib/my_app/application.ex

defmodule MyApp.Application do
  use Application

  def start(_type, _args) do
    import Supervisor.Spec

    # Define workers and child supervisors to be supervised
    children = [
      # Presence to track number of connected users to a channel
      supervisor(CaptainFactWeb.Presence, []),
      ...
    ]
  end
end

Plugging Presence on the channel

Last thing you need to do is to plug your new Presence module to your channel. This part depends of how you’ve implemented channels authentication, in our case we detect an authenticated channel by setting a user_id in the channel attributes.

Add the two following functions to the channel you want to track:

lib/my_app_web/channels/my_channel.ex

@doc """
Register a public connection in presence tracker
"""
def handle_info(:after_join, socket = %{assigns: %{user_id: nil}}) do
  {:ok, _} = Presence.track(socket, :viewers, %{})
  push_presence_state(socket)
  {:noreply, socket}
end

@doc """
Register a user connection in presence tracker
"""
def handle_info(:after_join, socket = %{assigns: %{user_id: user_id}}) do
  {:ok, _} = Presence.track(socket, :users, %{user_id: user_id})
  push_presence_state(socket)
  {:noreply, socket}
end

defp push_presence_state(socket) do
  push(socket, "presence_state", Presence.list(socket))
end

Then call these in you join/3 function when it succeeds:

def join("my_channel", _payload, socket) do
  send(self(), :after_join)
  {:ok, %{}, socket}
end

And that’s it for the backend !

Frontend

We now need to plug the channel presence messages to update our frontend. This example uses Redux, but you can easily transpose it for another store system.

app/state/presence/reducer.js

import { handleActions, createAction } from 'redux-actions'
import { Record } from 'immutable'


export const setPresence = createAction('PRESENCE/SET')
export const presenceDiff = createAction('PRESENCE/DIFF')


const INITIAL_STATE = new Record({
  viewers: new Record({count: 0})(),
  users: new Record({count: 0})(),
})

const PresenceReducer = handleActions({
  [setPresence]: (state, {payload}) => state.merge(payload),
  [presenceDiff]: (state, {payload: {leaves, joins}}) => {
    return state.withMutations(record => record
      .updateIn(['viewers', 'count'], x => {
        return (x + joins.viewers.count) - leaves.viewers.count
      })
      .updateIn(['users', 'count'], x => {
        return (x + joins.users.count) - leaves.users.count
      })
    )
  }
}, INITIAL_STATE())

export default PresenceReducer

And the final binding on channel:

app/state/my_channel/effects.js

import { Socket } from 'phoenix'
import { setPresence, presenceDiff } from '../my_channel/reducer'

/**
 * Effect to dispatch. Joins a channel 
 */
export const joinChannel = () => (dispatch) => {
  const socket = new Socket(SOCKET_URL)
  const channel = socket.channel("my_channel")
  channel.on('presence_state', presenceState => dispatch(setPresence(presenceState)))
  channel.on('presence_diff', diff => dispatch(presenceDiff(diff)))
  channel.join()
  return channel
}

And voilà! Add a component to render this stuff:

import React from 'react'
import PropTypes from 'prop-types'
import { connect } from 'react-redux'

const mapStateToProps = {presence: {nbUsers, nbViewers}} => ({nbUsers, nbViewers})

const Presence = ({nbUsers, nbViewers}) => (
  <div className="presence">
    <div type="primary">
      <span>{nbUsers} users</span>
    </div>
    <div className="viewers">
      <span>{nbViewers} viewers</span>
    </div>
  </div>
)

Presence.propTypes = {
  nbUsers: PropTypes.number.isRequired,
  nbViewers: PropTypes.number.isRequired,
}

export default connect(mapStateToProps)(Presence)

And you’ll end up with a nice anonimized and well-optimized counter:

All CaptainFact’s code is open-source (AGPL3). You can find the API code on https://github.com/CaptainFact/captain-fact-api and the frontend code on https://github.com/CaptainFact/captain-fact-frontend

Fact-checking et score de crédibilité : entre subjectivité et fausses interprétations, le cas de PolitiFact

Tue, 13 Mar 2018 00:00:00 GMT

This article was first posted on Medium.

C’est une demande qui revient régulièrement sur CaptainFact : pourrait-on calculer, à posteriori du fact-checking, une note qui jugerait de la factualité des intervenant·e·s ?

Loin d’être de l’ordre de la science-fiction, cette idée est en fait déjà appliquée outre-atlantique par le site politifact.com qui met en avant ses statistiques de vérification par personnalité. On y découvre que Donald Trump ne dit la vérité que sur 31% des affirmations vérifiées par le service là où son prédécesseur Barack Obama est à 76%.

Bien qu’elle puisse sembler attirante pour trier l’information plus vite, l’idée d’un score de crédibilité est aussi dangereuse qu’elle est probablement inefficace et ce même (surtout ?) si le travail de vérification est fait de manière collaborative, en encourageant la confrontation des sources comme nous cherchons à le faire sur CaptainFact.

Toutes les fausses informations ne se valent pas

Faire une erreur en annonçant des chiffres surréalistes sur les importations de produits laitiers n’a pas le même impact que de nier l’existence des chambres à gaz. Chez PolitiFact on ne s’encombre pas de cet aspect : une affirmation est vraie, plutôt vraie, à moitié vraie, plutôt fausse, fausse, ou un gros bobard. La nature de ce bobard importe peu : inventer une fraude électorale, multiplier par trois le nombre d’immigrés ou prétendre à tort que les pubs de McCain lors des élections étaient plutôt négatives vous vaudront tous les trois un “Pants on fire” - le bonnet d’âne de la fake news chez PolitiFact.

Sélectionner les informations qu’on vérifie, c’est attribuer un score subjectif

Pour être sélectionnée, une affirmation doit d’abord attirer l’attention d’un·e journaliste, d’un lecteur ou d’une lectrice (un tiers de leurs publications sont issues de suggestions). Elle doit ensuite répondre à un ou plusieurs des critères suivants :

Être vérifiable
Être trompeuse ou sonner fausse
Être significative (les erreurs mineures ou une langue qui fourche de manière évidente sont ignorées)
Être sujette à partage ou à répétition par le public
Une personne typique peut être amenée à se questionner sur sa véracité

Même en admettant une totale impartialité des journalistes, la mise de côté de leurs biais idéologiques et la parité de leurs propres lectures, on peut raisonnablement penser que ces règles poussent à privilégier la vérification des affirmations qu’on pense être fausses.

Aucun effort ne semble en tous cas être fait pour apporter une vérification systématique et quand bien même la volonté serait là, vérifier toutes les affirmations d’un·e intervenant·e n’est ni faisable ni souhaitable.

Mais que peut bien vouloir dire ce score s’il ne prend pas en compte 100% des affirmations vérifiables ?

L’interprétation

Malgré le fait que la représentativité de ces vérifications ne soit nulle part garantie, PolitiFact ne se gêne pas pour présenter ses scores comme un “Truth-O-Meter”. Autrement dit, un appareil de mesure de vérité. Une mesure si scientifique et objective qu’elle leur permet même de comparer les candidats entre eux !

Et tant pis si quand PolitiFact annonçait en 2016 30.5% d’affirmations fausses chez les démocrates (à l’exception d’Obama) là où son équivalent du Washington Post Fact Checker arrivait lui à un chiffre de 57.1% - soit presque deux fois plus (source: American Press Institute).

C’est pourtant ici que réside la question la plus importante : Comment le public va-t-il interpréter cette note ? Quelle information va-t-il en retirer ?

Une petite recherche sur Twitter permet de constater que beaucoup d’utilisateurs perçoivent effectivement ce score comme une mesure absolue qui leur permet de comparer de manière crédible qui ment le plus entre Trump et Obama, entre démocrates et républicains :

Un exemple typique : trois affirmations classées comme fausses sur PolitiFact suffisent pour être fiché comme un menteur compulsif, et le simple fait de citer l’individu invalide l’ensemble du propos.

Le travail de fact-checking n’est ici plus utilisé pour construire une argumentation factuelle mais pour servir un message idéologique dont le score constitue l’argument d’autorité. Score dont la légitimité reste à prouver.

Dear PolitiFact, please focus on your job 💛

Le travail de fact-checking de PolitiFact est précieux. Sa valeur ajoutée réside dans la vérification de points précis et potentiellement délicats par des équipes dont l’efficacité a plusieurs fois été saluée.

Offrir aux lecteurs un résumé grossier, une caricature, par un pourcentage dont la fiabilité statistique ne saurait être démontrée semble aller à l’encontre de cette mission.

Coller des étiquettes sur des médias et des individus en se basant sur des données discutables ne semble définitivement pas être une bonne chose à faire si l’on espère agir avec la confiance du public.

The urge for a collaborative, citizen fact-checking platform

Thu, 19 Oct 2017 00:00:00 GMT

This article was first posted on Medium. Text has been left untouched but graphical resources have been updated.

The Internet has drawn us into strange places lately. It has helped us to share information faster and at a larger scale, but it has also shown many weaknesses when it comes to verifying that information.

The biggest concern that has emerged from this is probably the disregard for facts: on the Internet, no matter what your beliefs are, you’ll find sources to confirm them. Our confirmation bias, with the help of Google’s and Facebook’s algorithms, has locked us into filter bubbles - we follow people and medias that don’t contradict too much with our view of the world and we’re often shocked when we finally debate with someone who thinks differently.

Centralized fact-checkers

Serious medias are probably the most concerned about this misinformation issue. They see a historic wave of distrust and often have trouble attracting readers: it’s easier to get people to click on your article when you’re selling them the “ten reasons that prove aliens are among us” than a deep and complicated analysis of a political subject.

One of the few responses we’ve seen so far from traditional medias is for them to try to act as a single source of truth. In France, the newspaper Le Monde has created a tool called Le Décodex to which you give a website and that tells you if you should trust it or not. But can we rely on a single, centralized media to tell us what we should read and what we should not ?

Décodex - “Enter a web page URL or a site name to know if the source is reliable or not”

And what will happen when less professional medias bring their own Décodex, when a conservative news media creates an extension warning its users that they should not read this liberally-biased media, and when liberal entities come with something to block every conservative posts from their news feed ?

Truth, especially in politics, cannot rely only on a central authority.

Another big issue with this approach is granularity. A reference media can make mistakes, and the worst fake news website can sometimes tell the truth. By telling people who they should trust or not, we’re only reinforcing the cleavage and comforting an increasing number of skeptics in their belief that traditional medias “do not want them to know the truth”.

If we want to give them some perspective, we definitely need to add some precision to this picture: verification must be per statement - not per media!

We’ve also seen some interesting responses: along with the Décodex, LeMonde also created an ambitious fact-checking platform: Les Décodeurs, where journalists verify specific points from articles, debates and speeches. This initiative has many brothers and sisters: LibéDésintox for Libération (FR), Politifact (US), FactCheck.org…

The work done by all these services is extremely valuable: they focus on specific arguments and give sources and explanations that are usually hard to argue with. But here is the big problem : Centralized fact-checkers will never be able to deal with the enormous amount of data produced on the Internet today. From PolitiFact’s own words :

Let’s do an exercise: For most of 2017, there were five fact-checking organizations participating in this project in the United States. (It’s also running in France and Germany.) Let’s say they all fact-checked as many URLs as we did - 1,722, that’s 8,610 articles fact-checked a year. Now let’s say the universe of false news stories of 1,000 a week - that’s 52,000 articles a year. In that scenario, the best we’re doing is covering 16.5 percent of the field. In all likelihood, the percentage is lower.

And we’re just talking about fake news here, not misinformation in general !

If we owe to address the issue of online misinformation, we have to let the citizen enter the arena of fact-checking.

Is Wikipedia’s model applicable to fact checking?

Wikipedia - The Free Encyclopedia

Wikipedia’s biggest strength is having been able to build a collaborative platform on which the multiplicity and the diversity of the contributions create a certain form of neutrality. And most studies on the question agree on the fact that for the most important subjects, Wikipedia has at least the same level of reliability than others encyclopedias; especially because it systematically asks for sources.

Could we apply the same model for our day-to-day information ?

Well, Wikipedia is great for non-cleaving subjects. But astroturfing proves that when it comes to sensitive and political subjects, a system that allows anyone to edit anything with very few consequences has some drawbacks; having a sane debate requires rules. And rules can actually be fun; could we play games without cheating otherwise?

A brilliant model to support this idea is Stack Overflow. By using reputation, votes, achievements and (reputation) bounties they have created a platform which makes people willing to contribute to what may seems like a tedious task (fixing other people’s code problems) and that naturally filters pollutive content.

Collaborative, real-time fact checking - using games to fight misinformation

For the last year we’ve been thinking and experimenting with this idea through a project named CaptainFact.io, a set of tools that could help us to collectively verify information anywhere on the Internet.

The goal: approaching Wikipedia’s reliability by using sources, warnings and collective moderation, with the gamification approach that made Stack Overflow a fun and safe place to be -applied to our daily news.

This is currently pursued by the development of 3 linked tools:

A video overlay (thanks to a web browser extension) that add sources and context to the videos you’re watching on the Internet. Each statement can be verified and we show with a small icon if it is believed to be true or false, based on users votes.

**A debate platform **that aggregates this information in a place where you can have rich and focused discussions by working point by point, argument by argument - instead of taking the content as a whole like almost all today’s comment systems do.

Ethics, 21st century’s organizations and big brother

If you’re concerned about privacy, you’re probably thinking right now that an extension that checks every website and video you’re watching is extremely dangerous, and you’re right. Though we respect your privacy and won’t log or sell any of this data, you shouldn’t trust us or anyone on this point.

Ability to disable CaptainFact in one click

What can you trust ? Open-source code and open organizations. As it is for Mozilla Firefox, we should be able to demonstrate with proof that we don’t (and won’t) track your online activity.

CaptainFact is a non-profit project that you can back on OpenCollective - transparent funds, transparent code, and collective decisions on how to build it.

What now, and how can I participate ?

The first iteration is ready: we have a debate platform and an extension that will bring these debated information down to the videos we’re watching online. I believe they are now ready to be tested on the battleground with a small number of actors to adjust the variables and see what can be improved.

Various roles and skills will be required to put this project on track:

Content creators

If you are a Youtube creator, CaptainFact can help you to better engage your community, to bring trust on your content and to make it even richer. By using CaptainFact, your content is peer-reviewed by your entire community.

Beside exceptions like WikiTribune very few medias can say the same.

Beta testers

For now, CaptainFact is in private beta (invitation only). Though it is ready to scale up fast, bringing it to a very large number of people right now would be risky. We need to test and improve the existing rules, like how many negative votes a new user can make each day. Finding good values for these can only be done through experience.

We’re particularly interested in having journalists joining us, your experience with news and information verification would be very helpful to see how such tools could compare to the job that you do by yourself.

Developers

There are many ways to improve and optimize the existing code, and many other ways for the data to be re-used. Strongly motivated developers are welcome to contribute and take a central part in this new and fast-growing project! For those interested, current stack uses Elixir + Phoenix (server) and React (frontend + browser extension).

Graphic designers

If you’re a graphic designer, there is cool stuff to work on for CaptainFact. We especially need fun graphics for achievements.

Lawyers

We’re in favor of a strong free-speech policy. Law geek’s passionate about these questions could help us achieving our goals without conflicting with international laws.

Translators

At the moment the website is available in English and French. We’d love to have it available in Spanish, German and any other language that could help to bring these tools to a wider community.

Enthusiasts

This is a collaborative project and we need people to spread the word. Community managers, students interested in media literacy… contact us if you’re motivated about working together!

You can follow the project on Twitter and on Facebook