Re: [FRsAG] Cherche une offre de VM
Bonjour, En plus, des précités : Y a Milkywan que j'ai découvert récemment grâce à la liste (non testé) : https://milkywan.fr/prices#popupVM Onet Solutions qui a vraiment des prix très attractifs mais un service à la hauteur du tarif : https://onetsolutions.net/vps-cloud-basic Guy. Le 2020-03-02 18:19, Artur a écrit : Le 02/03/2020 à 17:18, Artur a écrit : Si vous connaissez des hébergeurs qui proposent des VMs et qui bossent bien en dehors d'OVH, je suis preneur. Merci par avance. Si possible hébergement français et/ou en France, svp. ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Postfix et TLS. Comment bien paramétrer ses ciphers ?
Bonjour, En effet, ça ne te sert à rien à toi. Par contre, ça serait utile à tes clients, ça éviterait qu'ils aient des mails en clair qui se baladent sur Internet. C'est utile directement si quelqu'un écoute le réseau et indirectement parce que ça augmente le flux chiffré général de ce qui sort de son tuyau. Je n'y connais rien en fax, mais il m'étonnerait que ce soit les mêmes techniques ou entités qui puissent écouter ces deux réseaux, donc chiffrer l'amont est toujours intéressant. Et dans tous les cas, TLS est tellement facile à mettre en place de nos jours sur la plupart des serveurs de messagerie que j'ai du mal à voir le gain de ne pas le faire. C'est ce qu'on appelle par chez moi une économie de bout de chandelle. En tout cas, j'appelle de mes vœux une prise en compte du TLS et de sa version dans la notation des mails, ça ferait en effet bouger les lignes. Guy. Le 2020-04-06 16:54, Alexis a écrit : Bonjour tout le monde, Répondre me démangeait depuis le début de ce thread, je saute le pas (et le ton sera volontairement provocateur, en plus !) Ce sera a double tranchants, soit j'apporterai ma pierre à l'édifice soit je serai trainé devant la justice pour l'infamie mise en place sur certains de mes serveurs. Contexte : j'ai développé des services de mail2fax. Des clients envoient des e-mails vers @mon-tld, je converti ça en fax et hop, j'envoie ça au destinataire. Sur le serveur SMTP mis en place pour ça, y'a QUE du SMTP non authentifié. Pas de TLS, même pas de SSL. Rien, juste du SMTP en clair. "Olala il a mal fait son travail, mort au roi !" Sauf que dans mon cas, je m'en fiche un peu ! Pourquoi je m'emmerderais à mettre du TLS sur mon postfix ? Le risque est ou ? La chose la plus sensible de l'e-mail, c'est la pièce jointe qui sera transmise ensuite par fax. Mais du coup, comme la partie la moins sécurisée est l'envoi du fax lui-même, implémenter TLS c'est fermer une fenêtre mais laisser la porte grande ouverte. L'implémenter ne serait pas pire, mais ça n'améliorerait pas non plus la situation, honnêtement. Du coup, DMARC/DKIM/SPF sont déclarés pour mon fax2mail/mail2fax parce que ça améliore ma note de SPAM, mais tant que les providers de comptes e-mails ne me pénaliseront pas sur le fait que je ne fais que du non-chiffré sur ce service précis, bah je ne passerai pas plus de temps de mon côté. Le jour ou Google et Microsoft (parce que ce sont eux qui font tourner le monde des e-mails, grosso modo) décideront de me coller un malus, j'y jetterai un oeil. (si vous avez des arguments contre, je suis preneur quand même :p) Alexis Le 03/04/2020 à 12:53, Jonathan Leroy - Inikup via FRsAG a écrit : Salut, Le ven. 3 avr. 2020 à 12:06, P. MARCHAND a écrit : Sauf que j'avoue être confronté à l'interopérabilité avec les serveurs SMTP tiers. J'ai pris la décision de "respecter" certains standard et actes conseillé, cependant je crois que cela est un poil barbare. Il y a 2-3 ans, j'ai tenté la même chose sur une partie de mon infra : j'ai très rapidement dû faire un rollback devant l'état catastrophique des configurations TLS de la plupart des serveurs SMTP. C'est triste à dire, mais ça va sûrement se terminer comme pour HTTPS : un beau jour Google, Yahoo! et Microsoft vont décréter que leurs serveurs ne parleront plus avec ceux n'ayant pas une configuration TLS valide et moderne. Et alors en 6 mois 90 % des serveurs SMTP de la planète seront mis à jour. En l'état actuel des choses, activer une configuration TLS "moderne" en SMTP c'est forcer une bonne partie des mails à transiter en clair, malheureusement. ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
[FRsAG] Solution de système d'échange local.
Bonjour, Dans un cadre associatif, je cherche une solution web de gestion d'un sel. L'idée est de permettre l'inscription, la présentation, la modification et le suivi des échanges entre membres : X exprime un besoin. Y répond au besoin, gagne Z unités d'échanges. Les utilisateurs doivent pouvoir consulter leur compte, ajouter une annonce, proposer leurs services, etc. J'imagine que ça doit exister. Je préfère étudier les solutions en place avant de passer à un éventuel développement. Idéalement, il faudrait que ça s'appuie ou s'intègre sur un Nextcloud. Guy. ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Dégradation perfs Linux sur le long-terme
Bonjour, Personnellement, sous Debian, je reboot à chaque "révision" (10.4 -> 10.5, 11.0 -> 11.1, etc). Ca correspond la plupart du temps à une maj noyau et ça rythme pas mal les redémarrages, trouve-je. Guy. Le 08-11-2021 09:55, Luc Didry a écrit : jeudi 4 novembre 2021, 13:30:17 CET Vincent Tondellier via FRsAG wrote: needrestart est plus complet, et propose également de redémarrer les services (si en mode tty non scripté) avec un choix par défaut excluant ce qui pourrait poser problème. Il prévient aussi quand il faut redémarrer la machine pour mettre a jour le noyau et/ou le microcode. Je vais faire ma petite pub : j’ai fait un motd dynamique qui utilise needrestart ou checkrestart (selon ce qui est installé) pour prévenir s’il faut redémarrer des services ou s’il y a une mise à jour noyau en attente et donc qu’il faudrait redémarrer : https://framagit.org/luc/dynamic-motd Ça affiche aussi d’autres infos (genre occupation disque, inode…). Je trouve que c’est très pratique, ça fait des rappels dès qu’on se connecte en SSH. ___ Liste de diffusion du FRsAG http://www.frsag.org/
[FRsAG] Re: Alternative G.Suite/Workspare
Bonjour, Dans mon souvenir, certes lointain, la version communautaire de Sogo était une véritable purge à installer/maintenir sur Debian. Je ne sais pas si ça a évolué depuis, mais ça m'intéresse, j'vais y jeter un oeil. Guy. Le 03-02-2022 11:17, Mickael MONSIEUR a écrit : Le jeu. 3 févr. 2022 à 11:10, Wallace a écrit : Postfix / rspamd / NextCloud / Sogo et tu as un groupware super efficace à titre perso et pro. D'ailleurs SOGO tu pourrais faire un petit retour dessus ? Je dois pas être le seul intéressé. Le 03/02/2022 à 10:48, David Ponzone a écrit : Maintenant que Google a décidé d'éjecter tous les utilisateurs gratuits qui ont un domaine custom, va falloir chercher une alternative. Est-ce que quelqu’un a trouvé qqchose de sympa, pour un usage perso/familial ? Merci David ___ Liste de diffusion du %(real_name)s http://www.frsag.org/ ___ Liste de diffusion du %(real_name)s http://www.frsag.org/ ___ Liste de diffusion du %(real_name)s http://www.frsag.org/ ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: Renforcement politique DMARC/SPF chez Gmail ?
Bonsoir, De ce que j'ai pu constater vendredi, ça concerne bien tous les domaines sans SPF (ou SPF incorrect). Guy. Le 06-03-2022 20:56, Kevin Labécot a écrit : Ca va faire un carnage si c’est une volonté de Gmail de rejeter tous les domaines sans SPF… A voir si cela concerne tous les domaines par contre ? Le 6 mars 2022 à 20:24, David Ponzone a écrit : Donc même orange.fr [1] n’a pas de SPF ou j’ai mal cherché ? Le 6 mars 2022 à 20:20, Kevin Labécot a écrit : C’est juste pour prouver la propriété du domaine quand on ouvre un compte pro sur ces sites :) Links: -- [1] http://orange.fr/ ___ Liste de diffusion du %(real_name)s http://www.frsag.org/ ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: Renforcement politique DMARC/SPF chez Gmail ?
Le 07-03-2022 22:35, Jean-Yves LENHOF via FRsAG a écrit : Le 07/03/2022 à 09:42, David Ponzone a écrit : Y a quand même une bizarrerie chez GMail (genre nouvelle conf pas propagée sur tous leurs frontaux) car je viens d’envoyer 2 mails en telnet sur le port 25 de gmail-smtp-in.l.google.com [1], un venant de wanadoo.fr [2] et un de orange.fr [3], et les 2 sont passés. Yep, ils doivent faire du canary sur certains de leur service... j'avais un moment donné des mails qui ne passaient pas direct mais qui finissait par passer sur un autre serveur de chez eux Après pour moi c'est pas bon signe, ils sont en train de doser les choses, mais en général c'est bien pour durcir les règles. A noter que les serveurs de Google ont commencé à interpréter aussi différement les mails provenants de messagerie émettant que depuis un port 25 et celle émettant depuis TLS, il y a un petit cadenas qui apparait à côté de tes mails... A+ Links: -- [1] http://gmail-smtp-in.l.google.com [2] http://wanadoo.fr [3] http://orange.fr ___ Liste de diffusion du %(real_name)s http://www.frsag.org/ Bonjour, C'est un point de détail mais si je ne m'abuse, tout le trafic entre MTA se fait sur le port 25, qu'il utilise TLS ou pas. Guy. ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
[FRsAG] Re: Fuck, l'outil improbable
Bonjour, Le 22-04-2022 09:29, Stéphane Rivière a écrit : Pour un user, je discute pas le principe, mais pour un sysadmin qui, direct, va se monter un terminal sous root pour s'éviter de tapoter 5 caractères (avec l'espace)... Dans l'idée, la connexion initiale, qu'elle soit locale ou ssh, devrait toujours se faire avec un compte non privilégié, puis faire une élévation de droits une fois connecté. Que cette élévation de droits se fasse en "su -" ou en "sudo -s", ça ne change pas grand chose. Ca permet une meilleure identification de l'intervenant (compte nominal), une meilleure sécurité globale (clé + mdp) au prix d'une commande et un mdp à taper en plus. Ca vaut surement le coup. Guy. ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
