Re: Mails @free envoyés depuis un serveur non reçus
Cyrille BIOT a écrit : > Ces sites aident à les configurer correctement > https://www.mail-tester.com/ Je ne connais pas les deux autres, mais celui-ci me permet en effet de vérifier la configuration du serveur SMTP lorsque je monte une plateforme qui dispose de ses propres nom de domaine et MX. Il est fort utile. Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://sebastien.dinot.free.fr/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
Re: Pulseaudio qui ne démarre pas
Raphaël POITEVIN a écrit : > Bonsoir, > > BERTRAND Joël writes: >> Depuis, pulseaudio refuse de démarrer (quel que soit l'utilisateur). Si >> j'ouvre un xterm et que je tape pulseaudio --start, tout rentre dans >> l'ordre. >> >> L'ennui, dans le bazar kde, c'est que je ne vois pas qui doit lancer >> pulseaudio et j'aimerais assez éviter une rustine consistant à modifier >> les fichiers de conf de chaque utilisateur pour qu'en cas de connexion à >> kde sur cette machine, pulseaudio soit bien démarré. > > Avant de lancer pulse idiot à la main, voir si déjà une instance est en > mémoire : > ps aux | grep pulseaudio > > Est-ce que dans /etc/pulse/client.conf : > autospawn = yes Non, la ligne est commentée (j'ai la configuration par défaut, je n'ai jamais touché à ce fichier). > /etc/pulse/daemon.conf : > system-instance = no Pareil, ligne commentée. Je vais donc tester en modifiant ces deux fichiers. Merci pour l'indication. JKB
Re: Mails @free envoyés depuis un serveur non reçus
Daniel Huhardeaux a écrit : > Le 14/10/2019 à 18:08, BERTRAND Joël a écrit : > [...] >> >> Ce qui est important, c'est côté MX (plus que SMTP) parce que les >> rejets sont gérés côté MX. > > Je persiste: si le serveur SMTP d'envoi de l'OP log une erreur pas la > peine d'aller chercher celle-ci autre part. > Certes. Mais dans le cas de l'OP, j'avais surtout l'impression que c'était le MX qui passait le message par pertes et profits (sinon, le SMTP poli bounce localement). JKB
Re: Pulseaudio qui ne démarre pas
Bonsoir, BERTRAND Joël writes: > Depuis, pulseaudio refuse de démarrer (quel que soit l'utilisateur). Si > j'ouvre un xterm et que je tape pulseaudio --start, tout rentre dans > l'ordre. > > L'ennui, dans le bazar kde, c'est que je ne vois pas qui doit lancer > pulseaudio et j'aimerais assez éviter une rustine consistant à modifier > les fichiers de conf de chaque utilisateur pour qu'en cas de connexion à > kde sur cette machine, pulseaudio soit bien démarré. Avant de lancer pulse idiot à la main, voir si déjà une instance est en mémoire : ps aux | grep pulseaudio Est-ce que dans /etc/pulse/client.conf : autospawn = yes /etc/pulse/daemon.conf : system-instance = no -- Raphaël
Re: imprimer un message avec mutt
On 10/14/19 2:45 PM, Patrick wrote: avec la commande `set print_command= lp` dans ~/.mutt/muttrc et cela fonctionne parfaitement, Patrick Bonsoir Patrick et à la liste, Merci pour l'information. Très bonne soirée -- Frederic Robert
Re: Mails @free envoyés depuis un serveur non reçus
Le 14/10/2019 à 18:08, BERTRAND Joël a écrit : [...] Ce qui est important, c'est côté MX (plus que SMTP) parce que les rejets sont gérés côté MX. Je persiste: si le serveur SMTP d'envoi de l'OP log une erreur pas la peine d'aller chercher celle-ci autre part. -- Daniel
Re: Mails @free envoyés depuis un serveur non reçus
Bonjour, J'ai eu des soucis de SPF, DKIM... Ces sites aident à les configurer correctement https://www.mail-tester.com/ https://mxtoolbox.com/ https://dkimvalidator.com/ En espérant que ça t'aide ...
Re: Mails @free envoyés depuis un serveur non reçus
Daniel Huhardeaux a écrit : > Le 14/10/2019 à 15:18, BERTRAND Joël a écrit : >> Daniel Huhardeaux a écrit : >>> Il doit forcément y avoir des logs, que le message soit accepté ou >>> refusé. Quel logiciel serveur d'envois ? >> >> Pas forcément. Le message peut être traité par un mécanisme après >> l'acceptation (typiquement un milter) qui le supprime silencieusement. >> Seuls les logs du MX seraient pertinents. >> > > Le serveur réceptionnaire acquiterait la réception du message et > l'effacerai ensuite sans en informer l'émetteur ? Connais tu de > semblables cas et pourrais les exposer ? Je n'ai jamais rencontré cela ... En fait, il y a des milters qui travaillent sur l'enveloppe et d'autres sur les données. Si je prend mon sendmail des familles (je suis allergique à Postfix et encore plus à exim pour des serveurs sérieux, quant à qmail, j'aime mieux ne pas en parler...), il est configuré pour bouncer en cas de rejet sur l'enveloppe, mais pas en cas d'un traitement ayant lieu sur le contenu. Typiquement, sur l'enveloppe, je teste SPF, DKIM, rDNS, adresse IP de l'expéditeur. Si ça tourne mal, je bounce et le SMTP sait que le message est rejeté. Mais j'ai aussi des traitements sur les données. Ces traitements se font _après_ l'envoi un DSN OK au smtp et je ne bounce plus. Si le message est foireux (virus, pishing ou autres trucs du même acabit), je jette sans autre forme de procès et le SMTP n'a aucun moyen de savoir que le message n'est pas arrivé à bon port. C'est pour cela que la "notification" (et non l'accusé de réception) est important. Il garanti que le message est arrivé dans la boîte aux lettres du destinataire. Certains serveurs de FAI sont gérés par des pieds tendres (les domaines dépendants de SFR, entre autres) et il y a souvent des choses bizarres (mails qui n'arrivent jamais ou qui sont rejetés pour d'obscures raisons). Il fut un temps où il n'y avait qu'une seule adresse IPv4 de MX pour tous les domaines gérés par SFR. Je suppose qu'il y avait plusieurs machines physiques avec du round robin, mais ce n'était pas au point. Gmail est aussi merdico-foireux mais dans un autre style. Ils veulent (enfin voulaient parce qu'ils ont corrigé récemment) des champs SPFv1. Sauf qu'ils ont configuré IPv6 comme protocole prioritaire et qu'ils n'arrivaient pas à traiter les champs SPFv1 en IPv6 (!). Les en-têtes DKIM de gmail sont aussi foireuses (10% des mails en gros, au début, je pensais que le SMTP n'était pas le bon, même pas !...). Résultat, les mails passaient aléatoirement. Certains n'arrivaient jamais sans bounce (j'avais un temps désactivé IPv6 pour gmail pour éviter le problème). Hotmail est aussi par moment capricieux parce qu'il utilise une vieille version de SSL qui n'était plus capable de parler avec les versions Debian. Ça ne bounçait pas, on avait seulement au bout de cinq jours une notification du rejet. > Ceci dit, on ne sait pas si les messages envoyés par le serveur de l'OP > sont effectivement acquités/refusés par le destinataire, donc les logs > de l'échange doivent exister sur le serveur de l'émetteur. Ce qui est important, c'est côté MX (plus que SMTP) parce que les rejets sont gérés côté MX.
Re: imprimer un message avec mutt
Le 14 oct. 2019 a 12:29:33 +, Frederic Robert a écrit : > Bonjour, bonjour, > > Comment allez-vous? Qui utilise mutt comme client e-mail? Est-il possible > d'imprimer un e-mail reçu? Si oui, comment? avec la commande `set print_command= lp` dans ~/.mutt/muttrc et cela fonctionne parfaitement, Patrick
Re: Pulseaudio qui ne démarre pas
Bureau LxVx a écrit : > Bonjour à tous, > > Un de nos adhérents Linux Ventoux a eu le même problème : le passage au > nouveau noyau ... Je ne vois pas bien le rapport. Si c'était un problème de noyau, je ne pourrais pas le lancer dans un terminal. Pour moi, ça vient plutôt d'un problème quelque part dans la grouille KDE. Bien cordialement, JKB
Re: Mails @free envoyés depuis un serveur non reçus
Le 14/10/2019 à 15:18, BERTRAND Joël a écrit : Daniel Huhardeaux a écrit : Il doit forcément y avoir des logs, que le message soit accepté ou refusé. Quel logiciel serveur d'envois ? Pas forcément. Le message peut être traité par un mécanisme après l'acceptation (typiquement un milter) qui le supprime silencieusement. Seuls les logs du MX seraient pertinents. Le serveur réceptionnaire acquiterait la réception du message et l'effacerai ensuite sans en informer l'émetteur ? Connais tu de semblables cas et pourrais les exposer ? Je n'ai jamais rencontré cela ... Ceci dit, on ne sait pas si les messages envoyés par le serveur de l'OP sont effectivement acquités/refusés par le destinataire, donc les logs de l'échange doivent exister sur le serveur de l'émetteur. -- Daniel
Re: Pulseaudio qui ne démarre pas
Bonjour à tous, Un de nos adhérents Linux Ventoux a eu le même problème : le passage au nouveau noyau ... Bien librement, Sylvie Le 14/10/2019 à 14:32, BERTRAND Joël a écrit : > Bonjour à tous, > > J'utilise un player diskless qui tourne sous debian/stable. Pour je ne > sais plus quelle raison (sans doute un codec qui ne fonctionnait pas > correctement), j'ai fait un apt dist-upgrade. kde est passé de la > version 4 à la version 5 (j'utilise KDE sur cette machine car c'est le > seul qui est capable de gérer correctement la sortie son HDMI en étant > 'Michu compliant'). kdm n'étant plus supporté, j'ai installé et > configuré sddm à la place (franchement, quelle idée d'avoir les logins > disponibles sur la page de connexion...). > > Depuis, pulseaudio refuse de démarrer (quel que soit l'utilisateur). Si > j'ouvre un xterm et que je tape pulseaudio --start, tout rentre dans > l'ordre. > > L'ennui, dans le bazar kde, c'est que je ne vois pas qui doit lancer > pulseaudio et j'aimerais assez éviter une rustine consistant à modifier > les fichiers de conf de chaque utilisateur pour qu'en cas de connexion à > kde sur cette machine, pulseaudio soit bien démarré. > > Une idée ? > > Bien cordialement, > > JKB >
Re: imprimer un message avec mutt
On 10/14/19 1:29 PM, Frederic Zulian wrote: muttprint fera ton bonheur -- Frédéric ZULIAN Bonjour Frédéric et à la liste, Merci pour l'information. L'utilisez-vous? Très bonne journée, -- Frederic Robert
Re: imprimer un message avec mutt
muttprint fera ton bonheur -- Frédéric ZULIAN Le lun. 14 oct. 2019 à 14:37, Frederic Robert a écrit : > Bonjour, > > Comment allez-vous? Qui utilise mutt comme client e-mail? Est-il > possible d'imprimer un e-mail reçu? Si oui, comment? > > d'avance merci, très bonne journée, > > -- > Frederic Robert > >
Re: Mails @free envoyés depuis un serveur non reçus
Daniel Huhardeaux a écrit : > Il doit forcément y avoir des logs, que le message soit accepté ou > refusé. Quel logiciel serveur d'envois ? Pas forcément. Le message peut être traité par un mécanisme après l'acceptation (typiquement un milter) qui le supprime silencieusement. Seuls les logs du MX seraient pertinents.
Re: Mails @free envoyés depuis un serveur non reçus
ajh-valmer a écrit : > Bonjour à tous, > > J'ai un petit serveur de messagerie internet perso avec postfix et dovecot. > > On va dire que son nom de domaine est "machin.org", > donc "smtp.machin.org" est le facteur. > Tout est OK avec le DNS. > > Les mails @free envoyés depuis ce serveur > n'arrivent pas dans la boite Free, > et ni dans les répertoires pourriels et commerciaux. > > Aucune information dans /var/log/mail.info ou mail.err > > D'autres mails n'arrivent pas non plus, tel @sfr.fr... > Par contre les méls @gmail.com sont bien transférés. > > L'IP du serveur n'est pas blacklisté par Free. > > Avez vous une idée du blême, une piste ? > merci d'avance. Bonjour, SPF ? DKIM ? rDNS ? La plupart des MX refusent aujourd'hui les domaines sans SPF ni rDNS. DKIM, c'est beaucoup plus foireux parce que les en-têtes peuvent être modifiées bizarrement. Donc une absence de DKIM ne provoque pas un rejet implicite. Autre chose : si l'adresse IP est une adresse résidentielle ou variable, le serveur en face peut aussi rejeter. Bien cordialement, JKB
Re: Mails @free envoyés depuis un serveur non reçus
Le 14/10/2019 à 15:03, ajh-valmer a écrit : Bonjour à tous, Bonjour J'ai un petit serveur de messagerie internet perso avec postfix et dovecot. On va dire que son nom de domaine est "machin.org", donc "smtp.machin.org" est le facteur. Tout est OK avec le DNS. Ou est hébergé ce serveur ? Les mails @free envoyés depuis ce serveur n'arrivent pas dans la boite Free, et ni dans les répertoires pourriels et commerciaux. Aucune information dans /var/log/mail.info ou mail.err Il doit forcément y avoir des logs, que le message soit accepté ou refusé. Quel logiciel serveur d'envois ? D'autres mails n'arrivent pas non plus, tel @sfr.fr... Par contre les méls @gmail.com sont bien transférés. L'IP du serveur n'est pas blacklisté par Free. Elle peut l'être par d'autres. Perso j'utilise spamhaus avant d'accepter des messages. Et je fais du greylisting. Beaucoup d'opérateurs demandent aussi que le reverse DNS pointe sur le FQDN. Tu peux tester ton serveur à cette adresse par ex. https://mxtoolbox.com/diagnostic.aspx [...]
Mails @free envoyés depuis un serveur non reçus
Bonjour à tous, J'ai un petit serveur de messagerie internet perso avec postfix et dovecot. On va dire que son nom de domaine est "machin.org", donc "smtp.machin.org" est le facteur. Tout est OK avec le DNS. Les mails @free envoyés depuis ce serveur n'arrivent pas dans la boite Free, et ni dans les répertoires pourriels et commerciaux. Aucune information dans /var/log/mail.info ou mail.err D'autres mails n'arrivent pas non plus, tel @sfr.fr... Par contre les méls @gmail.com sont bien transférés. L'IP du serveur n'est pas blacklisté par Free. Avez vous une idée du blême, une piste ? merci d'avance. A. Valmer
Pulseaudio qui ne démarre pas
Bonjour à tous, J'utilise un player diskless qui tourne sous debian/stable. Pour je ne sais plus quelle raison (sans doute un codec qui ne fonctionnait pas correctement), j'ai fait un apt dist-upgrade. kde est passé de la version 4 à la version 5 (j'utilise KDE sur cette machine car c'est le seul qui est capable de gérer correctement la sortie son HDMI en étant 'Michu compliant'). kdm n'étant plus supporté, j'ai installé et configuré sddm à la place (franchement, quelle idée d'avoir les logins disponibles sur la page de connexion...). Depuis, pulseaudio refuse de démarrer (quel que soit l'utilisateur). Si j'ouvre un xterm et que je tape pulseaudio --start, tout rentre dans l'ordre. L'ennui, dans le bazar kde, c'est que je ne vois pas qui doit lancer pulseaudio et j'aimerais assez éviter une rustine consistant à modifier les fichiers de conf de chaque utilisateur pour qu'en cas de connexion à kde sur cette machine, pulseaudio soit bien démarré. Une idée ? Bien cordialement, JKB
imprimer un message avec mutt
Bonjour, Comment allez-vous? Qui utilise mutt comme client e-mail? Est-il possible d'imprimer un e-mail reçu? Si oui, comment? d'avance merci, très bonne journée, -- Frederic Robert
Re: Encodage de fichier détérioré - Debian MySQL Mediawiki ProFTPd DropBox
Le 14/10/19 à 11h33, G2PC a écrit : > La méthode avec mysqldump ou Automysqlbackup aboutit bien, et, comme > dit, si je charge par https, le fichier est fonctionnel, mais, pas si je > le récupère via une archive compressée sous DropBox ou FTP. Dans ce cas comment est faite la compression ? Par qui ? (si c'est une compression faite par un script php de mediawiki, y'a p'tet un paramètre de charset qq part qui déconne). Si tu récupères correctement ton dump.sql via https, c'est que ce source est bon, et si tu trouves pas de moyen correct de le compresser sur le serveur avant récupération, tu peux toujours lancer la compression dans ton cron via une connexion ssh qui compresse sur le serveur (avec gzip ou bzip2 ou zip), faudra "juste" autoriser sur le serveur la connexion ssh par clé et la commande qui compresse. -- Daniel On tue un homme, on est un assassin. On tue des millions d'hommes, on est un conquérant. On les tue tous, on est un dieu. Edmond Rostand
Re: Encodage de fichier détérioré - Debian MySQL Mediawiki ProFTPd DropBox
Bonjour Erwann, merci de ta réponse. Le hic, c'est que j'ai le même problème avec une archive compressée. C'est étonnant non ? L'archive que je récupère par DropBox ( et tâche cron ) est bien compressée. Idem, j'ai testé via FTP, avec une archive compressée. En décompressant, j'ai un fichier utf8 non valide. Pour le moment, seul la méthode de transfert en https semble avoir fonctionnée. C'est très embêtant. J'en ai profité pour réviser les alternatives de sauvegardes, pour Mediawiki : Sauvegarder Mediawiki : https://wiki.visionduweb.fr/index.php?title=Accueil_Utiliser_MediaWiki#Sauvegarder_la_base_de_donn.C3.A9es_de_MediaWiki Source : https://www.mediawiki.org/wiki/Manual:Backing_up_a_wiki/fr La méthode avec mysqldump ou Automysqlbackup aboutit bien, et, comme dit, si je charge par https, le fichier est fonctionnel, mais, pas si je le récupère via une archive compressée sous DropBox ou FTP. C'est ce qu'il me faut, pour pouvoir continuer d'utiliser ma tâche cron pour exporter automatiquement ma sauvegarde. Le 14/10/2019 à 09:24, Erwann Le Bras a écrit : > > bonjour > > Il doit s'agir d'un pb d'encodage lors du transfert du fichier. > Le fichier de "dump" mysql est un fichier texte contenant des > commandes SQL pour regénérer la base complète si besoin. > Lors du transfert, le caractère "ascii" (texte) du fichier n'est pas > respecté et il est transféré en "binaire". > il en résulte une conversion unix/dos du fichier, en trop ou > manquante, ce qui fait que le fichier n'a pas les retours chariots. > > Veillez à transférer le fichier en forçant le caractère "ascii" dans > les paramètres FTP pour l'extension ".sql" > ou compressez votre sauvegarde avant transfert pour écarter tout pb > d'encodage. > > Erwann > > Le 13/10/2019 à 17:02, G2PC a écrit : >> >> Drôle de problème que je rencontre : >> >> J'ai une sauvegarde automatique vers DropBox, qui syncronise mes >> fichiers, via cron. >> Je test de rapatrier un des fichiers SQL, vers ma VM locale, l'import >> plante, et, lorsque j'ouvre le fichier.sql, cela me dit qu'il y a un >> problème d'encodage. >> >> Idem, j'exporte le fichier directement en sql, depuis le serveur, et, >> je le met dans le dossier de mon FTP, je charge sans soucis, >> j'importe ça plante, et, si je l'ouvre, même constat : un problème >> d'encodage ! >> >> >> La ou je suis rassuré, c'est que si je déplace le même fichier sql >> vers le répertoire de mon site, je peux charger le même fichier >> depuis https, et, la, pas de soucis, l'import se fera sur la VM, et, >> le fichier peut être ouvert également !!! >> >> En gros, mon fichier se voit, semble t'il, être détérioré, quand il >> est récupéré depuis dropbox ? Idem, quand il est récupéré depuis >> proFTPd ? :/ >> Mais, le même fichier est fonctionnel quand je le charge depuis https:// >> >> Je n'y comprend rien :s >> >> >> Seule remarque que je peux ajouter, ( les deux prochaines >> configurations sont également appliquées à ma VM ) >> J'ai récemment modifié mariadb pour utiliser la collation >> utf8mb4_unicode_ci par défaut au lieu de utf8mb4_general_ci >> J'ai également ajouté les lignes suivantes à la configuration de >> MariaDB : >> >> [mariadb-10.3] >> innodb_file_format = Barracuda >> innodb_file_per_table = 1 >> innodb_default_row_format = dynamic >> innodb_large_prefix = 1 >> >> Cela pourrait expliquer le problème de corruption de fichier lors de >> l'export / récupération ? ( Sauf que par https, le fichier n'est PAS >> corrompu. ) >> >> >> Du coup, je suis embêté, comment puis je faire pour m'assurer que ma >> sauvegarde automatique qui se fait sur DropBox puisse être >> fonctionnelle !? >>
Re: Encodage de fichier détérioré - Debian MySQL Mediawiki ProFTPd DropBox
bonjour Il doit s'agir d'un pb d'encodage lors du transfert du fichier. Le fichier de "dump" mysql est un fichier texte contenant des commandes SQL pour regénérer la base complète si besoin. Lors du transfert, le caractère "ascii" (texte) du fichier n'est pas respecté et il est transféré en "binaire". il en résulte une conversion unix/dos du fichier, en trop ou manquante, ce qui fait que le fichier n'a pas les retours chariots. Veillez à transférer le fichier en forçant le caractère "ascii" dans les paramètres FTP pour l'extension ".sql" ou compressez votre sauvegarde avant transfert pour écarter tout pb d'encodage. Erwann Le 13/10/2019 à 17:02, G2PC a écrit : Drôle de problème que je rencontre : J'ai une sauvegarde automatique vers DropBox, qui syncronise mes fichiers, via cron. Je test de rapatrier un des fichiers SQL, vers ma VM locale, l'import plante, et, lorsque j'ouvre le fichier.sql, cela me dit qu'il y a un problème d'encodage. Idem, j'exporte le fichier directement en sql, depuis le serveur, et, je le met dans le dossier de mon FTP, je charge sans soucis, j'importe ça plante, et, si je l'ouvre, même constat : un problème d'encodage ! La ou je suis rassuré, c'est que si je déplace le même fichier sql vers le répertoire de mon site, je peux charger le même fichier depuis https, et, la, pas de soucis, l'import se fera sur la VM, et, le fichier peut être ouvert également !!! En gros, mon fichier se voit, semble t'il, être détérioré, quand il est récupéré depuis dropbox ? Idem, quand il est récupéré depuis proFTPd ? :/ Mais, le même fichier est fonctionnel quand je le charge depuis https:// Je n'y comprend rien :s Seule remarque que je peux ajouter, ( les deux prochaines configurations sont également appliquées à ma VM ) J'ai récemment modifié mariadb pour utiliser la collation utf8mb4_unicode_ci par défaut au lieu de utf8mb4_general_ci J'ai également ajouté les lignes suivantes à la configuration de MariaDB : [mariadb-10.3] innodb_file_format = Barracuda innodb_file_per_table = 1 innodb_default_row_format = dynamic innodb_large_prefix = 1 Cela pourrait expliquer le problème de corruption de fichier lors de l'export / récupération ? ( Sauf que par https, le fichier n'est PAS corrompu. ) Du coup, je suis embêté, comment puis je faire pour m'assurer que ma sauvegarde automatique qui se fait sur DropBox puisse être fonctionnelle !?
