Seenthis
•
 
Identifiants personnels
  • [mot de passe oublié ?]

 
  • #c
  • #co
  • #cour
  • #courrier
RSS: #courrier_électronique

#courrier_électronique

  • @stephane
    Stéphane Bortzmeyer @stephane CC BY-SA 1/03/2017

    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

    Stéphane Bortzmeyer @stephane CC BY-SA
    Écrire un commentaire
  • @stephane
    Stéphane Bortzmeyer @stephane CC BY-SA 12/01/2017

    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

    Stéphane Bortzmeyer @stephane CC BY-SA
    Écrire un commentaire
  • @stephane
    Stéphane Bortzmeyer @stephane CC BY-SA 9/09/2016
    3
    @kent1
    @severo
    @nhoizey
    3

    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

    Stéphane Bortzmeyer @stephane CC BY-SA
    • @perline
      Perline @perline CC BY-SA 9/09/2016

      Et oui, j’essaie depuis de très nombreuses années de faire accepter mon mail @xxx.name, mais c’est très compliqué pour les administrations, très très compliqué, malgré de nombreux courriers renvoyant leurs informaticien-nes à leurs codes, de manière plus ou moins gracieuse, toujours rien :(

      Perline @perline CC BY-SA
    Écrire un commentaire
  • @homlett
    Hoʍlett @homlett PUBLIC DOMAIN 28/08/2015
    4
    @fredlm
    @gastlag
    @la_taupe
    @02myseenthis01
    4

    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

    Hoʍlett @homlett PUBLIC DOMAIN
    • @stephane
      Stéphane Bortzmeyer @stephane CC BY-SA 28/08/2015

      Très mauvaise idée, le « hidden recipient » ►http://www.bortzmeyer.org/gpg-option-no-keyid.html

      Stéphane Bortzmeyer @stephane CC BY-SA
    • @homlett
      Hoʍlett @homlett PUBLIC DOMAIN 28/08/2015
      @stephane

      Merci @stephane, ça tombe sous le sens en fait ! Surtout que comme tu le dis, ça n’a quasiment aucun intérêt appliqué à l’e-mail...
      L’article ne parlant que de PGP/GPG appliqué à l’e-mail, pas de PGP en général comme peut le laisser supposer le titre.

      Hoʍlett @homlett PUBLIC DOMAIN
    Écrire un commentaire
  • @homlett
    Hoʍlett @homlett PUBLIC DOMAIN 28/07/2015
    2
    @gastlag
    2

    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

    • #Microsoft
    Hoʍlett @homlett PUBLIC DOMAIN
    • @goffi
      Goffi @goffi CC BY-SA 28/07/2015

      ça fait longtemps qu’on envisage d’intégrer les courriels dans XMPP, cf mon vieux message de blog : ►http://www.goffi.org/post/2011/01/18/Recevez-et-envoyez-vos-messages-XMPP/Jabber-avec-votre-lecteur-de-courriel-gr%C3%A2ce-%C3%A0-Salut-%C3%A0-Toi-%21

      Goffi @goffi CC BY-SA
    • @homlett
      Hoʍlett @homlett PUBLIC DOMAIN 28/07/2015
      @goffi

      @goffi Ah oui, c’est intéressant ça !

      Hoʍlett @homlett PUBLIC DOMAIN
    • @goffi
      Goffi @goffi CC BY-SA 28/07/2015

      On a déjà un serveur IMAP/SMTP (plus pour expérimenter qu’autre chose), mais après la prochaine sortie (à la rentrée), on prévoit de faire une passerelle SMTP (et aussi Diaspora et Seenthis, enfin faudra voir si ça demande un travail raisonnable).

      Si tu veux voir en action, y’a une vidéo de démo (vieille aussi, 2011 !) dispo ici : ftp://ftp.goffi.org/media/screencasts/pr%C3%A9sentation_S%C3%A0T_2.webm . La partie courriel est à partir de 3 min 32 .

      Goffi @goffi CC BY-SA
    • @erratic
      schrödinger @erratic 28/07/2015

      Pourquoi est-ce que je voudrais gérer mes mails comme une messagerie instantanée (IM) ?

      N’y a-t-il pas là un danger de dégrader encore plus la réflexion sur ce qu’on va écrire ?

      en présentant les emails et leurs réponses comme autant de petits textes qui pourraient ressembler à une simple conversation par SMS

      Pour moi ça sonne comme un pas de plus en arrière.

      Il y a-t-il encore des gens (comme moi) qui prennent le temps pour rédiger un long mail et structurer ce qu’on voudrait dire, de manière réfléchie ?

      Le principe de Send pourrait plaire à ceux qui communiquent souvent par email avec des collègues de travail.

      –-> De quel type de communication entre collègues parle-t-on ?
      1) Des échanges type « tchat » où l’on s’envoie des blagues ou quand on déconne toute la journée ? (le genre de trucs qu’on ne veut pas trop garder en fait parce que ça pollue la boîte mail)
      2) Ou bien de mails sérieux et professionnels, comptes rendus, organisation/coordination etc ? (le genre de trucs qu’on garde et qu’on classe dans des dossiers)

      Pour 2) le mail actuel fonctionne très bien en je ne vois pas comment cela se marie avec de l’IM.
      Pour 1) au boulot on utilise déjà un IM à cet effet, et ça me plaît que les deux soient séparés.

      Je m’interroge.

      schrödinger @erratic
    • @goffi
      Goffi @goffi CC BY-SA 28/07/2015
      @erratic

      @erratic : je sais que tu réponds au message de base, mais je précise au cas où que nous voulons intégrer SMTP dans XMPP mais pas en faire de la messagerie instantanée. Nous voulons juste permettre de regrouper les communications, et dans l’idéal remplacer SMTP par un protocole qui corrige pas mal de ses défauts (cf le billet lié plus haut).

      Mais sinon ta réflexion est intéressante, on touche en plein à la non neutralité de la technologie, et l’influence que la forme peut avoir sur notre réflexion (on aura moins tendance à réfléchir à quelque chose de posé et construit sur un truc présenté comme une messagerie instantanée).

      Goffi @goffi CC BY-SA
    • @homlett
      Hoʍlett @homlett PUBLIC DOMAIN 28/07/2015
      @goofy

      Effectivement, c’est moins gérer ses emails comme une conversation IM, que d’avoir des applications qui s’appuierait sur l’infrastructure de l’email pour proposer un service d’IM qui me semble intéressant.
      Tout le monde à une adresse email, il y a de multiple serveurs, de multiple fournisseurs... À partir de là, il suffirait sans doute d’ajouter une métadonnée pour dire qu’il ne s’agit pas d’un « email » mais d’un « chat ».

      Ce serait la solution du pauvre, j’entends bien. XMPP est un bien meilleur candidat (et la proposition de @goofy sans doute bien plus pertinente). Dans mon cas, j’utilise l’email de deux manières : en mode « rédaction aboutie » disons (auquel je suis attaché), mais aussi beaucoup en mode chat finalement. Or ça me plairait de pouvoir, juste par le design, distinguer les deux. Car mon client email n’est pas prévu pour ce dernier cas, et tenir une conversation devient vite fastidieux et brouillon.

      Hoʍlett @homlett PUBLIC DOMAIN
    • @goffi
      Goffi @goffi CC BY-SA 28/07/2015
      @homlett

      @homlett goffi et non goofy (mais l’erreur est fréquente, d’ailleurs c’est pas totalement dû au hasard)

      Goffi @goffi CC BY-SA
    • @erratic
      schrödinger @erratic 28/07/2015
      @goffi @homlett

      @goffi

      et dans l’idéal remplacer SMTP par un protocole qui corrige pas mal de ses défauts

      Oui j’avais lu le lien que tu avais ajouté et je peux comprendre les améliorations potentielles (-spam, -spoof, ..)

      @homlett

      avoir des applications qui s’appuierait sur l’infrastructure de l’email pour proposer un service d’IM qui me semble intéressant

      Oui, j’avais compris et je ne suis pas contre. Je pense que c’est intéressant. Je ne suis juste pas certain que c’est ce qui ait motivé Send, et réfléchissant plus loin je me suis un peu inquiété d’une opportunité additionnelle pour la prolifération du #kikoolol.

      Or ça me plairait de pouvoir, juste par le design, distinguer les deux.

      Je suis d’accord. Ca pourrait m’intéresser de pouvoir tagguer une « conversation » mail comme état du chat afin qu’il soit traité autrement. J’imagine par exemple un traitement DND - do not disturb - pour ce qui est du chat afin de ne pas afficher que j’ai un nouveau message avec l’aperçu de la première ligne quand il s’agit de conneries.

      schrödinger @erratic
    Écrire un commentaire
  • @stephane
    Stéphane Bortzmeyer @stephane CC BY-SA 1/07/2015
    2
    @la_taupe
    @fil
    2

    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

    Stéphane Bortzmeyer @stephane CC BY-SA
    Écrire un commentaire
  • @stephane
    Stéphane Bortzmeyer @stephane CC BY-SA 19/02/2015
    1
    @fil
    1

    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

    Stéphane Bortzmeyer @stephane CC BY-SA
    • @fil
      Fil @fil 19/02/2015

      pourrait être utile pour #caliopen ?

      Fil @fil
    Écrire un commentaire
  • @stephane
    Stéphane Bortzmeyer @stephane CC BY-SA 5/12/2014

    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

    Stéphane Bortzmeyer @stephane CC BY-SA
    Écrire un commentaire
  • @stephane
    Stéphane Bortzmeyer @stephane CC BY-SA 31/07/2014
    5
    @fil
    @02myseenthis01
    @bram1
    @homlett
    @gastlag
    5

    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

    Stéphane Bortzmeyer @stephane CC BY-SA
    Écrire un commentaire
  • @homlett
    Hoʍlett @homlett PUBLIC DOMAIN 12/05/2014
    6
    @fil
    @solidairnet
    @stephane
    @gastlag
    @7h36
    @goom
    6

    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

    Hoʍlett @homlett PUBLIC DOMAIN
    • @homlett
      Hoʍlett @homlett PUBLIC DOMAIN 12/05/2014

      Bon par contre je me heurte encore à la configuration de deux serveurs côte à côte (et pas juste un nom de domaine en alias). C’est pas simple tout ça.

      Hoʍlett @homlett PUBLIC DOMAIN
    • @stephane
      Stéphane Bortzmeyer @stephane CC BY-SA 12/05/2014

      #Raspbian (le Pi peut avoir plein de systèmes d’exploitation différents)

      Stéphane Bortzmeyer @stephane CC BY-SA
    Écrire un commentaire
  • @stephane
    Stéphane Bortzmeyer @stephane CC BY-SA 27/04/2014
    3
    @fil
    @james
    @erratic
    3

    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 :

    % dig +short TXT seenthis.net
    "v=spf1 a mx ip4:88.190.11.5 ~all"
    • #François Hollande
    Stéphane Bortzmeyer @stephane CC BY-SA
    • @erratic
      schrödinger @erratic 28/04/2014

      little tool written by kitterman himself to help you look up and validate SPF records.

      (and updated to RFC 7208)

      ►http://www.kitterman.com/spf/validate.html?

      schrödinger @erratic
    Écrire un commentaire
  • @stephane
    Stéphane Bortzmeyer @stephane CC BY-SA 16/01/2014

    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

    Stéphane Bortzmeyer @stephane CC BY-SA
    Écrire un commentaire
  • @stephane
    Stéphane Bortzmeyer @stephane CC BY-SA 21/09/2013

    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

    Stéphane Bortzmeyer @stephane CC BY-SA
    Écrire un commentaire
  • @stephane
    Stéphane Bortzmeyer @stephane CC BY-SA 13/03/2013
    1
    @kent1
    1

    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

    Stéphane Bortzmeyer @stephane CC BY-SA
    Écrire un commentaire
  • @stephane
    Stéphane Bortzmeyer @stephane CC BY-SA 17/02/2013
    3
    @loloster
    @fil
    @james
    3

    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. »

    Stéphane Bortzmeyer @stephane CC BY-SA
    Écrire un commentaire
  • @stephane
    Stéphane Bortzmeyer @stephane CC BY-SA 7/09/2012

    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

    Stéphane Bortzmeyer @stephane CC BY-SA
    Écrire un commentaire
  • @stephane
    Stéphane Bortzmeyer @stephane CC BY-SA 26/08/2012

    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

    Stéphane Bortzmeyer @stephane CC BY-SA
    Écrire un commentaire
  • @stephane
    Stéphane Bortzmeyer @stephane CC BY-SA 21/07/2012

    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

    Stéphane Bortzmeyer @stephane CC BY-SA
    Écrire un commentaire
  • @stephane
    Stéphane Bortzmeyer @stephane CC BY-SA 8/04/2012

    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

    Stéphane Bortzmeyer @stephane CC BY-SA
    Écrire un commentaire
  • @stephane
    Stéphane Bortzmeyer @stephane CC BY-SA 1/03/2012

    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

    Stéphane Bortzmeyer @stephane CC BY-SA
    Écrire un commentaire
  • @stephane
    Stéphane Bortzmeyer @stephane CC BY-SA 18/02/2012

    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

    Stéphane Bortzmeyer @stephane CC BY-SA
    Écrire un commentaire
  • @stephane
    Stéphane Bortzmeyer @stephane CC BY-SA 28/11/2011

    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

    Stéphane Bortzmeyer @stephane CC BY-SA
    • @baroug
      baroug @baroug 29/11/2011

      Un logiciel de mail classique type thunderbird ?

      baroug @baroug
    • @stephane
      Stéphane Bortzmeyer @stephane CC BY-SA 29/11/2011
      @baroug

      @Baroug : ça m’embêterait de devoir abandonner mutt.

      Stéphane Bortzmeyer @stephane CC BY-SA
    • @julien
      juba @julien CC BY 29/11/2011

      Y’a sans doute moyen de bricoler un truc semblable à ta capture d’écran avec #conky ?

      ►http://conky.sourceforge.net

      juba @julien CC BY
    Écrire un commentaire

Thèmes liés

  • #rfc
  • #rfc
  • #smtp
  • #ietf
  • #spam
  • #sécurité
  • #sécurité_informatique
  • #internationalisation
  • #courrier_électronique
  • company: microsoft
  • #spf
  • #imap
  • #smtp
  • company: twitter
  • #dns
  • #spf
  • #sender-id
  • #unicode
  • #unix
  • #microsoft
  • emailaddress: stephane@internet-en-cooperation.fr
  • url: internet-en-coopération.fr
  • emailaddress: joe@example.net
  • #e-mail
  • #authentification
  • #dkim
  • #arf