#courrier_électronique

RFC 8098 : Message Disposition Notification

Une demande fréquente des utilisateurs du #courrier_électronique est d’avoir un mécanisme permettant de savoir si et quand le message a été lu par le destinataire. Comme toutes les demandes des utilisateurs, il ne faut pas forcément la satisfaire sans réfléchir (elle pose des gros problèmes de vie privée et, en outre, elle ne garantit pas que le message a été traité, juste que le logiciel l’a affiché). Ce n’est pas par hasard que cette fonction « accusé de réception » était souvent présente (et mise en avant par les vendeurs) pour les systèmes de messagerie conçus pour des environnements très bureaucratiques. Mais, bon, si les gens y tiennent, cette possibilité existe dans la norme : ce nouveau #RFC spécifie un mécanisme permettant de signaler qu’on souhaite un tel accusé de réception, ainsi qu’un format structuré (lisible par un programme comme le MUA) pour les accusés de réception qui seront (peut-être) envoyés. Ces accusés de réception sont appelés #MDN pour Message Disposition Notification. Ce RFC remplace son prédecesseur, le RFC 3798.

▻http://www.bortzmeyer.org/8098.html

Un paranoïaque bien grave prétend avoir inventé le #courrier_électronique et fait un procès aux journaux qui rectifient.

▻https://www.techdirt.com/articles/20170111/11440836465/techdirts-first-amendment-fight-life.shtml

#libelMadness #droit_états-unien #liberté_de_la_presse

Excellent article sur ces stupides programmes de validation d’adresses de courrier électronique, qui trainent sur pas mal de formulaires Web, qui refusent des adresses parfaitement légales (leurs stupides auteurs ne lisent jamais les normes techniques) et qui, comme le montre l’auteur avec un amusant calcul, n’ont quasiment aucune chance d’attraper les vraies erreurs. « A user is far more likely to enter a wrong and valid email address than they are to enter an invalid one. »

▻https://hackernoon.com/the-100-correct-way-to-validate-email-addresses-7c4818f24643

#programmation #courrier_électronique

https://cdn-images-1.medium.com/max/1200/1*qkkv0iT-g7cMAN3XjpOEow.png

Les problèmes de PGP
▻http://blog.notmyidea.org/les-problemes-de-pgp.html

Une fois passé l’euphorie du « il faut utiliser PGP pour l’ensemble de nos communications », j’ai réalisé lors de discussions que PGP avait plusieurs problèmes

#Chiffrement #Courrier_électronique #Cryptographie #E-mail #PGP #Pretty_Good_Privacy #Vie_privée

Microsoft Send : gérez vos emails à la manière d’une messagerie instantanée
▻http://www.nextinpact.com/news/95906-microsoft-send-gerez-vos-emails-a-maniere-dune-messagerie-instanta

Microsoft propose depuis hier soir l’application Send sur iOS. Anciennement baptisée Flow en interne, elle cherche à réinventer l’utilisation des emails pour les présenter sous une forme identique aux applications de messagerie.

C’est pertinent. L’émail reste malgré tout l’une des applications d’Internet parmi les plus résilientes, décentralisées, efficaces, interopérables, utilisées... De nombreuses améliorations peuvent y être apportées (à commencer par son design ainsi que sur les métadonnées), c’est certain, mais après tout pourquoi pas partir de là.

Après bien sûr il y a XMPP ou demain Tox.im.

#Courrier_électronique #Design #E-mail #Interface_utilisateur #Messagerie_instantanée #Microsoft #Microsoft_Send

RFC 7505 : A "Null MX" No Service Resource Record for Domains that Accept No Mail

Comment indiquer qu’un domaine ne reçoit jamais de courrier ? Jusqu’à présent, il n’existait pas de mécanisme standard, permettant d’indiquer aux clients de ne pas perdre de temps à essayer d’écrire. Ce nouveau #RFC indique une méthode, le « MX nul » qui consiste à mettre un point en partie droite de l’enregistrement MX.

▻https://www.bortzmeyer.org/7505.html

#courrier_électronique #DNS

RFC 7444 : Security Labels in Internet Email

On a souvent besoin, lorsqu’on transmet un document, d’indiquer le niveau de sensibilité ou de #confidentialité du document. Quelque chose du genre SECRET ou CONFIDENTIEL. Cela peut être fait de manière non structurée, par du texte (par exemple dans l’objet du message) mais cela ne permet pas aux logiciels d’agir automatiquement sur la base de ce texte. D’où l’idée d’un nouveau champ dans l’en-tête du message, SIO-Label :, pour indiquer de manière structurée la sécurité souhaitée pour ce message.

▻http://www.bortzmeyer.org/7444.html

#RFC #email #courrier_électronique #sécurité_informatique #TopSecret

RFC 7410 : A Property Types Registry for the Authentication-Results Header Field

Le RFC 7001 avait créé l’en-tête de courrier Authentication-Results : qui permettait de signaler à un logiciel de courrier les résultats de tests d’authenticité faits par un serveur. Cet en-tête pouvait inclure un type de propriété (property type ou ptype) qui indiquait d’où venait la propriété testée : la session #SMTP, l’en-tête du message, son corps, ou bien une politique locale. Le jeu de valeurs pour les types possibles était fixe et, depuis, certains ont trouvé ce jeu trop restreint. Ce nouveau et très court #RFC remplace donc la liste fixe du RFC 7001 par un registre en ligne à l’IANA.

▻http://www.bortzmeyer.org/7410.html

#courrier_électronique #sécurité_informatique

Depuis #Snowden, le nombre de projets de sécurisation du courrier électronique a explosé. Mais il règne dans ce secteur une grande confusion et on lit souvent n’importe quoi. Félicitons donc les auteurs de cette synthèse, qui permet de comparer sérieusement les différents projets.

▻https://github.com/OpenTechFund/secure-email

#NSA #courrier_électronique #sécurité_informatique

Raspberry Pi Email Server
▻http://www.samhobbs.co.uk/raspberry-pi-email-server

The RasPi’s small size and low power consumption make it an ideal choice for use as a home email server. After trying a couple of different pieces of software, I finally found an excellent combination: Postfix with Dovecot and Squirrelmail, plus Spamasssassin and Sieve for spam filtering.

Voilà un bon tutoriel, c’est à dire complet, didactique et clair, pour l’installation d’un serveur email personnel avec Postfix et Dovecot.

#Auto-hébergement_(informatique) #Courrier_électronique #Dovecot #IMAP #Postfix #Raspberry_Pi #SMTP

RFC 7208 : Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1

On le sait, le #courrier_électronique, tel qu’il est spécifié dans les RFC 5321 et RFC 5322, ne fournit aucune authentification, même faible, de l’émetteur. Un expéditeur de courrier peut toujours prétendre être François Hollande <president@elysee.fr> et il n’y a aucun moyen de l’en empêcher. C’est parfois pratique mais c’est aussi un gros obstacle lorsqu’on tente de gérer le problème des courriers non désirés comme le spam. #SPF vise à diminuer cette facilité de frauder en permettant à un titulaire de nom de domaine de déclarer quelle(s) adresse(s) IP sont autorisées à envoyer du courrier pour ce domaine. Ce nouveau #RFC représente la première norme SPF (le premier RFC, le RFC 4408, était officiellement une expérimentation, sans le statut de norme.)

▻http://www.bortzmeyer.org/7208.html

Notez que SeenThis a un enregistrement SPF :

RFC 7103 : Advice for Safe Handling of Malformed Messages

Dans un monde idéal, les messages transmis par le système de #courrier_électronique de l’Internet seraient tous parfaitement conformes aux normes. Dans la réalité, l’ancienneté du courrier, et son succès, qui a mené à une explosion du nombre de logiciels, font que beaucoup de messages sont incorrects, « malformed », dit ce nouveau #RFC. Que doivent faire les logiciels confrontés à ces messages incorrects ? Voici une série d’avis pour les programmeurs qui veulent essayer de faire le moins mal possible.

▻http://www.bortzmeyer.org/7103.html

#principe_de_robustesse

RFC 7001 : Message Header Field for Indicating Message Authentication Status

Il existe désormais plusieurs techniques pour authentifier les courriers électroniques. Certaines peuvent nécessiter des calculs un peu compliqués et on voudrait souvent les centraliser sur une machine de puissance raisonnable, dotée de tous les logiciels nécessaires. Dans cette hypothèse, le MUA (le logiciel de l’utilisateur) ne recevra qu’une synthèse (« Ce message vient bien de example.com ») et pourra alors prendre une décision, basée sur cette synthèse. C’est le but de l’en-tête Authentication-Results :, normalisé originellement dans le RFC 5451 quatre ans plus tôt, RFC que ce nouveau #RFC met légèrement à jour (il y a peu de changements).

▻http://www.bortzmeyer.org/7001.html

#sécurité #courrier_électronique #DKIM #SPF

Cinq nouveaux #RFC viennent de paraitre, autour du courrier électronique entièrement internationalisé (donc, y compris les en-têtes, les adresses, etc) :

– RFC 6854 (pas directement lié à l’internationalisation) qui change légèrement la syntaxe du champ From : pour avoir plusieurs expéditeurs

– RFC 6855 qui normalise l’usage d’#IMAP avec le courrier complètement internationalisé (accès à des boîtes aux lettres qui contiennent des messages internationalisés) Voir ▻http://www.bortzmeyer.org/6855.html

– RFC 6856 qui fait la même chose pour #POP

– RFC 6857 et 6858, deux algorithmes (un simple et un compliqué) pour le cas où le serveur IMAP stocke des messages internationalisés et où un vieux client IMAP demande à accéder à la boite. Ces deux RFC spécifient des algorithmes de « repli », où le message va être massacré pour s’adapter au client. Voir ▻http://www.bortzmeyer.org/6857.html et ▻http://www.bortzmeyer.org/6858.html

#internationalisation #courrier_électronique

Une excellente défense du #courrier_électronique contre la mode managériale actuelle qui voudrait que ce soit une perte de temps.

▻http://techcrunch.com/2013/02/16/in-defense-of-email

« I’m bemused by the CEOs who declare their companies are giving up email. [...] We tried that. It was called the ’80s. »

RFC 6729 : Indicating Email Handling States in Trace Fields

Lorsqu’on débogue un problème de #courrier_électronique en examinant un message reçu, le technicien regarde souvent en premier les champs Received : de l’en-tête. Ceux-ci indiquent les différents MTA qui ont pris en charge le message et sont notamment très utiles en cas de retard inattendu : ils permettent de voir quel MTA a traîné dans la remise du message au MTA suivant. Mais cela ne suffit pas toujours. Aujourd’hui, il est de plus en plus fréquent que les messages soient retardés en raison d’un traitement local à une machine, par exemple le passage par un programme de sécurité qui met très longtemps à vérifier quelque chose. Il n’y avait pas de moyen pratique avec les champs Received : pour indiquer ces traitements. C’est désormais fait avec un nouvel indicateur dans Received : : state qui permet de signaler le passage d’un traitement lent à un autre.

►http://www.bortzmeyer.org/6729.html

#RFC #SMTP

RFC 6710 : Simple Mail Transfer Protocol Extension for Message Transfer Priorities

Des tas d’utilisateurs du #courrier_électronique souhaiteraient un mécanisme de priorité, permettant de dire que tel message est plus important que tel autre et devrait être traité en premier. Après tout, les ressources (par exemple la capacité disponible dans le réseau) sont souvent insuffisantes et il serait souhaitable que les messages vraiment urgents en profitent avant les informations envoyées par Twitter (« vous avez un nouvel abonné »). Il n’existait pas jusqu’à présent, pour un serveur de messagerie, de moyen standard en #SMTP de dire à un de ses pairs quelle était la priorité d’un message. C’est désormais fait grâce à la nouvelle extension SMTP MT-PRIORITY.

►http://www.bortzmeyer.org/6710.html

#RFC

RFC 6686 : Resolution of The SPF and Sender ID Experiments

L’#IETF avait créé en 2004 un groupe de travail nommé MARID, qui avait pour tâche de normaliser un mécanisme d’authentification faible du courrier électronique par le biais de la publication dans le #DNS des serveurs autorisés à envoyer du courrier pour un domaine. Deux propositions étaient sur la table, #SPF et #Sender-ID. #Microsoft avait pratiqué une intense obstruction contre SPF, pour promouvoir sa propre solution, Sender-ID. En 2006, l’IETF avait cédé devant cette obstruction, en renonçant à normaliser SPF, déjà très répandu, et en publiant les deux protocoles avec le statut Expérimental : RFC 4408 pour SPF et RFC 4406 pour Sender"ID. Cette solution peu courageuse avait été contestée, notamment pour le risque que la coexistence de deux protocoles incompatibles faisait peser sur la bonne délivrance du courrier. Officiellement, la retraite de l’IETF devait être provisoire : une période de deux ans d’observation était prévue, suite à laquelle des conclusions pourraient être tirées sur l’expérience. En fait, c’est seulement six ans après qu’est publié notre #RFC 6686 qui conclut enfin officiellement que Sender-ID est un échec total et que seul SPF est déployé et utilisé.

►http://www.bortzmeyer.org/6686.html

#sécurité #courrier_électronique #spam

RFC 6590 : Redaction of Potentially Sensitive Data from Mail Abuse Reports

Il est fréquent qu’un message électronique contienne de l’information sensible ou personnelle, ne serait-ce que le nom des parties qui communiquent. Si ce message doit être transmis, comme faisant partie d’un rapport de problème (typiquement au format standard #ARF), cette information doit être protégée. Ce #RFC décrit un cadre général pour la retouche des messages. Le terme de « retouche » désigne l’opération d’occultation des parties confidentielles (notez que le redaction de l’original en anglais est un faux-ami, il ne signifie pas « rédaction »).

►http://www.bortzmeyer.org/6590.html

#spam #courrier_électronique

RFC 6541 : DKIM Authorized Third-Party Signers

Depuis la sortie de la norme #DKIM d’#authentification du #courrier_électronique, il y a des incompréhensions sur ce que DKIM garantit réellement. Beaucoup d’utilisateurs croient que, lorsqu’un message prétend venir de joe@example.net et qu’il est signé par DKIM, on peut être sûr que le message vient de joe@example.net. Rien n’est plus faux. DKIM garantit tout autre chose. Il dit juste que l’identité du domaine signeur, dans le champ DKIM-Signature :, est correcte. Résultat, il y a un fossé entre ce qu’espère l’utilisateur et ce que DKIM livre effectivement. Ce #RFC expérimental propose une solution pour combler ce fossé.

►http://www.bortzmeyer.org/6541.html

Les normes du courrier électronique enfin entièrement internationalisées

Parmi les protocoles utilisés sur Internet, presque tous sont internationalisés depuis longtemps. Le dernier gros manque concernait les adresses de courrier électronique, obligées de s’en tenir à stephane@internet-en-cooperation.fr alors qu’on voudrait pouvoir écrire à stéphane@internet-en-coopération.fr. Désormais, nous avons une solution normalisée, Internationalized Email, dont les spécifications viennent d’accéder au statut de norme #IETF.

►http://www.bortzmeyer.org/courrier-entierement-internationalise.html

#Unicode #internationalisation #courrier_électronique

Je suis sûr que les lecteurs de SeenThis peuvent m’aider pour ce choix difficile d’un logiciel pour afficher l’état de mes nombreuses boîtes aux lettres :

►http://www.bortzmeyer.org/afficher-boites.html

#courrier_électronique #Unix