Après l'article sur comment retrouver l'origine d'une attaque, nous allons voir aujourd'hui comment accueillir comme il se doit sur votre serveur un envoi de spam. Pour changer, on partira du principe que l'on est sur une Debian avec un postfix. Notre serveur s'appelle exemple.octopuce.fr, et notre site de référence installé sur ce serveur s'appelle exemple.com.
On partira aussi du principe que l'on n'aime pas beaucoup le spam… voire même qu'on lui mettrait bien un bon coup de clavier en pleine poire.
Sommaire
Au commencement était…
Une liste d'envoi de mails (mailq) qui se remplit beaucoup trop rapidement, on parle de plusieurs centaines, voire plusieurs milliers de mails en quelques minutes/heures (selon la technique que l'attaquant utilise). Vous pouvez voir en bas de cet article comment être alerté automatiquement.
On commence par regarder la liste d'attente des mails (mail queue) avec la commande mailq. La commande less est là pour éviter d'afficher plusieurs centaines de mails, on aura ainsi seulement les premiers de la liste :
mailq | less
Vous devriez voir une suite de blocs qui ressemble à ceci :
E35BA5318CA83 1389 Fri Jul 31 10:25:10 MAILER-DAEMON
(delivery temporarily suspended: connect to yahoo.com[63.250.192.45]:25: Connection refused)
darcy.bolden75@yahoo.com
F21DC4093C551 1400 Fri Jul 31 09:36:40 MAILER-DAEMON
(delivery temporarily suspended: connect to yahoo.com[63.250.192.45]:25: Connection refused)
nicki.forth76@yahoo.com
F125553301B52 1409 Fri Jul 31 18:15:21 MAILER-DAEMON
(delivery temporarily suspended: connect to yahoo.com[63.250.192.45]:25: Connection refused)
renato_kalman62@yahoo.com
Détaillons le premier bloc :
-
E35BA5318CA83correspond à l'ID du mail - et
1389correspond à la taille du mail en octet -
Fri Jul 31 10:25:10correspond à la date de l'envoi (idéal pour le retrouver dans les logs ;-)) -
MAILER-DAEMONest l'expéditeur (peut être www-data, une adresse mail…) -
delivery temporarily suspendedexplique pourquoi le mail est toujours là (dans notre cas, les serveurs de yahoo ne veulent pas de lui) -
darcy.bolden75@yahoo.comreprésente le destinataire
Si ça ressemble à du spam, que ça a le goût du spam (et que ça tente de vous vendre du viagra…)…
Je choisis dans mon tas de mail celui avec l'ID B58B18A1C2140 et je "l'ouvre" avec la commande postcat (à noter que cette commande affiche par défaut la totalité du mail (header, body, envelope content) :
postcat -q B58B18A1C2140|less
Et voici le résultat :
*** ENVELOPE RECORDS deferred/B/B58B18A1C2140 ***
message_size: 826 195 1 0 826
message_arrival_time: Fri Jul 24 06:08:12 2015
create_time: Fri Jul 24 06:08:12 2015
named_attribute: rewrite_context=local
sender: mechant@exemple.octopuce.fr
*** MESSAGE CONTENTS deferred/B/B58B18A1C2140 ***
Received: by exemple.octopuce.fr (Postfix, from userid 2001)
id B58B18A1C2140; Fri, 24 Jul 2015 06:08:12 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=exemple.com;
s=alternc; t=1437710892;
bh=jovdSJ/Kn2/7639VFyVqNVkUC4F7d1BbnAP59auo7XI=;
h=To:Subject:From:Reply-To:Date;
b=EkH7RR1L6vi0gkvl/AXhJChbwtOvMTB6KFS/tuoxoo6+O3UINMgxpLqp45vY9E+ED
Dl0rOINTF8YDAGFmv6VCU4SDt1FTmWyjcJyefj1Mc9wl3TGRQVPfUDkUhVrrDB3yau
Boz8MjYyfBIz28gXWB680XdkC1E5LQwnsmmay//8=
To: anhselagiolong_2710@yahoo.com
Subject: RE: Your Top Affordable Vagra solutions
X-PHP-Originating-Script: 2001:dir.php
From: "Melba Bauer" <melba_bauer@exemple.com>
Reply-To:"Melba Bauer" <melba_bauer@exemple.com>
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-RealFrom:
Message-Id: <20150724040812.B58B18A1C2140@exemple.octopuce.fr>
Date: Fri, 24 Jul 2015 06:08:12 +0200 (CEST)
<div>
Your Top Affordable Vagra solutions – <a href="http://strobeton.ru/assets/plugins/tinymce/jscripts/tiny_mce/plugins/contextmenu/defines.html">check it out</a>
</div>
*** HEADER EXTRACTED deferred/B/B58B18A1C2140 ***
named_attribute: encoding=8bit
original_recipient:
recipient: anhselagiolong_2710@yahoo.com
*** MESSAGE FILE END deferred/B/B58B18A1C2140 ***
Les points importants :
- create_time: Fri Jul 24 06:08:12 2015 (date de création)
- Received: by exemple.octopuce.fr (Postfix, from userid 2001) (reçu par)
- sender: exemple@exemple.octopuce.fr (si c'est une de vos adresses mails qui existe réellement, c'est simple : changement de mot de passe immédiat).
- X-PHP-Originating-Script: 2001:dir.php (origine de l'envoi (fichier vérolé, formulaire sans captcha…))
Et puis bon, celui là il est facile, il tente de nous vendre du viagra… je pouvais pas avoir plus stéréotypé comme exemple…
Viens, on joue à cache-cache \o/
À partir de là, la marche à suivre est la même que dans l'article "remonter une attaque avec les logs d'apache2". Nous allons commencer notre chasse dans le fichier /var/log/mail.log.
On commence par aller voir au moment de l'attaque :
astuce :
/permet de faire une recherche dansless, comme par exemple2015:06:0si vous n'avez qu'une seule journée par fichier
less /var/log/mail.log
176.9.139.10 - - [24/Jul/2015:06:07:18 +0200] "POST /wp-content/plugins/wsanalytics-google-analytics-and-dashboards/images/dir.php HTTP/1.1" 200 382 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.7.6)" 5
129.195.0.205 - - [24/Jul/2015:06:07:27 +0200] "GET /wp-includes/js/comment-reply.min.js?ver=4.1.4 HTTP/1.1" 304 - "-" "Mozilla/4.0 (compatible;)" 0
89.184.77.50 - - [24/Jul/2015:06:07:26 +0200] "POST /wp-content/plugins/wsanalytics-google-analytics-and-dashboards/images/dir.php HTTP/1.1" 200 466 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.7.6)" 2
89.184.77.50 - - [24/Jul/2015:06:07:34 +0200] "POST /wp-content/plugins/wsanalytics-google-analytics-and-dashboards/images/dir.php HTTP/1.1" 200 219 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.7.6)" 1
176.9.139.10 - - [24/Jul/2015:06:07:28 +0200] "POST /wp-content/plugins/wsanalytics-google-analytics-and-dashboards/images/dir.php HTTP/1.1" 200 64 "-" "Mozilla
/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.7.6)" 10
89.184.77.50 - - [24/Jul/2015:06:07:41 +0200] "POST /wp-content/plugins/wsanalytics-google-analytics-and-dashboards/images/dir.php HTTP/1.1" 200 541 "-" "Mozill
a/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.7.6)" 2
89.184.77.50 - - [24/Jul/2015:06:07:48 +0200] "POST /wp-content/plugins/wsanalytics-google-analytics-and-dashboards/images/dir.php HTTP/1.1" 200 370 "-" "Mozill
a/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.7.6)" 1
176.9.139.10 - - [24/Jul/2015:06:08:12 +0200] "POST /wp-content/plugins/wsanalytics-google-analytics-and-dashboards/images/dir.php HTTP/1.1" 200 374 "-" "Mozill
a/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.7.6)" 9
oh bah si c'est [google analytics] ça doit pas être ça…
OU PAS ! Comme nous l'avions vu, nous recherchons des requêtes POST dans les logs, et là nous en avons une jolie fournée ! Les "pirates" étant des animaux fourbes et rusés, ils n'hésitent pas à mettre des faux noms, comme des fichiers wordpress dans l'arborescence d'un drupal…
Allons voir de plus près ce fichier !
less /var/www/alternc/m/monjolisite/wp-content/plugins/wsanalytics-google-analytics-and-dashboards/images/dir.php
On y trouve quelque chose comme ceci :
Et là, on appelle ça un fichier vérolé :]
Note : si vous n'avez que ça dans votre fichier, vous pouvez l'effacer directement après avoir remonté entièrement l'attaque. Si vous avez du code "valide" dans le fichier, vous pouvez enlever seulement la partie incompréhensible.
Juste pour savoir, j'ai eu combien de requêtes sur ce fichier depuis 4 jours ?
cat access-20150721.log access-20150722.log access-20150723.log access-20150724.log|grep -c "/wp-content/plugins/wsanalytics-google-analytics-and-dashboards/images/dir.php"
3204
Ah oui quand même… Et avec combien d'IPs différentes ?
cat access-20150721.log access-20150722.log access-20150723.log access-20150724.log|grep "/wp-content/plugins/wsanalytics-google-analytics-and-dashboards/images/dir.php"|awk '{print $1}'|sort -gu|wc -l
123
Comme vous vous en doutez, la "traque" ne s'arrête pas là. Je vous renvoie à l'article remonter une attaque avec les logs d'Apache2, vu que c'est là que ça va se passer. Je vous conseille de finir de trouver la faille avant de passer à la suite.
KILL EVERYTHING WITH FIRE
Mais avant, on va quand même faire une sauvegarde, parce que l'on est jamais à l'abri d'une connerie… (la commande suivante vous permet de copier votre mailq dans le dossier /var/tmp/svg-mail) :
mkdir /var/tmp/svg-mail
rsync -avP /var/spool/mail/ /var/tmp/svg-mail
Reprenons notre lance-flammes. Comme vous l'avez vu au début de cet article, la commande mailq est assez verbeuse, et nous avons juste besoin de l'ID des mails pour les effacer. La commande qu'il nous faut est la suivante (en changeant MOTIF, bien entendu…):
mailq|grep MOTIF|awk '{print $1}'|postsuper -d -
-
mailq-> affiche la liste des mails en attente -
grepMOTIF --> recherche les lignes avec le motif que nous voulons (ici ce seraitMAILER-DAEMON) -
awk '{print $1}'-> affiche la première partie de la ligne, ça correspond ici à l'ID des mails -
postsuper -d ---> indique à la commandepostsuperd'effacer (-dpour delete) les mails qu'on lui donne.
Et ça nous donnera quelque chose ressemblant à ceci :
mailq|grep MOTIF|awk '{print $1}'|postsuper -d -
[...]
postsuper: F21198830C2B1: removed
postsuper: F108B894D4171: removed
postsuper: F22718A48D820: removed
postsuper: F11EB8FB2A9E7: removed
postsuper: F02B78A14E94D: removed
postsuper: F0B5B8D42374F: removed
postsuper: F02BB8D422BEC: removed
postsuper: Deleted: 17047 messages
Spamhaus
Si votre serveur a envoyé (beaucoup) de spam, il est sans doute dans les listes de différents organismes (comme les RBL, pour Realtime blacklist), qui fournissent eux-mêmes des systèmes antispams. Les plus célèbres d'entre eux sont sans doute anti-abuse.org et spamhaus qui a le mérite (en plus de faire du très bon travail) d'avoir un site plutôt bien foutu, sur lequel on peut vérifier et débloquer son serveur s'il est considéré comme spammeur : spamhaus.org/lookup/.
Améliorons encore
Supervision
Il existe des outils pour vous aider à superviser et à vous alerter en cas de problèmes. Ils peuvent se présenter sous la forme de script "à la main" (merci stackoverflow). Des checks pour Nagios (que ce soit sur les RBLs) ou la taille de la mailq. On peut aussi parler de mailgraph et de pflogsumm.
À noter que anti-abuse.org fournit un service en ligne, rblmon.com qui peut vous alerter automatiquement quand une de vos IPs arrivent dans une RBL.
PHP / mail.log
Pour retrouver plus facilement les fichiers ayant servi à envoyer du spam, n'hésitez pas à les logger via l'option mail.log de votre php.ini :
vim /etc/php5/apache2/php.ini
## trouver la ligne "mail.log" et la compléter comme ceci :
mail.log = /var/log/mail.php.log
Puis on crée le fichier (n'hésitez pas à modifier les permissions si le coeur vous en dit):
touch /var/log/mail.php.log && chmod 777 /var/log/mail.php.log
SPF, DKIM et DMARC
Au fur et à mesure du temps, des techniques ont été inventées pour lutter contre le spam et authentifier les expéditeurs "légaux". On parle ici de 3 choses :
- SPF, pour Sender Policy Framework,
- DKIM pour DomainKeys Identified Mail,
- DMARC pour Domain-based Message Authentication, Reporting and Conformance.
Je vous conseille vivement de les configurer sur vos serveurs de mails. Vous pouvez lire à ce sujet les articles de Steve Kemp.
Des outils le font par défaut, comme AlternC.
antivirus
Si vous avez un antivirus, par exemple ClamAV (idéalement en y ajoutant les signatures de maldet) sur votre serveur, il peut vous aider à (re)trouver des fichiers vérolés :
clamscan -ri /var/www/
/var/www/search.php: Php.Trojan.StopPost FOUND
/var/www/help.php: Php.Trojan.StopPost FOUND
----------- SCAN SUMMARY -----------
Known viruses: 3912137
Engine version: 0.98.5
Scanned directories: 550
Scanned files: 78469
Infected files: 2
Data scanned: 1382.68 MB
Data read: 1509.90 MB (ratio 0.92:1)
Time: 132.390 sec (2 m 12 s)
Aller plus loin
- lien vers l'article original (707 clics)
# hum
Posté par jacot . Évalué à -9.
Quand je lis cela:
Cela décribilise l'ensemble de l'article. On peut envoyer un mail avec n'importe quelle adresse émail. Jusqu'à preuve du contraire, je n'ai pas besoin de m'identifier pour envoyer un mail.
[^] # Re: hum
Posté par Samk (Mastodon) . Évalué à 0.
Euh… Non.
Tu as des serveurs mail en open relay pour lesquelles tu ne dois pas t'identifier (typiquement ce que propose les fournisseurs internet quand tu es dans leur réseau).
Si tu configures un serveur de cette manière, tu n'as pas à te tracasser du spam car tu en envois plein.
Sinon tu ajoutes une identification avant l'envoi.
[^] # Re: hum
Posté par abraxas . Évalué à 8.
Si le serveur SMTP est correctement configuré, il est nécessaire de s'authentifier avant d'envoyer un mail.
[^] # Re: hum
Posté par kna . Évalué à 8.
Oui, sauf que l'exemple est mauvais. Ici il utilise une faille d'un site web, et envoie du spam. Typiquement, il se connecte au SMTP via localhost ou appelle directement la commande sendmail. Et généralement, il n'y a pas besoin d'authentification.
De plus, tu peux aussi t'authentifier avec un compte et envoyer avec un From différent.
Il est intéressant, pour trouver l'origine des spams d'avoir auparavant :
- configuré ses sites pour que les scripts soient utilisés par un compte différent, par exemple php-fpm avec des pools ayant chacun un user différent
- configuré son mailer pour qu'il ajoute dans les headers l'uid ayant invoqué sendmail
- si mails entrants, configuré son mailer pour qu'il ajoute dans les headers le compte qui s'est authentifié.
Le cas le plus délicat, est quand le site est hacké, mais envoie du spam directement sans passer par le mailer du système.
[^] # Re: hum
Posté par Dring . Évalué à 6.
Attention, l'auteur du journal parle bien de la zone "sender", pas du "From" de l'entête de mail qui est effectivement libre.
[^] # Re: hum
Posté par rpnpif . Évalué à 1.
Même la zone sender me semble fragile. En vérifiant dans des spams reçus, je dirais que c'est plutôt la zone Return-Path qui est la plus pertinente pour repérer le destinataire. C'est la première ligne des en-têtes qui sert à Bounce address ou plus complet : en anglais
Elle correspond à envelope-from que l'on trouve dans les paramètres de Mutt par exemple ou « envelope from » du SMTP. Bien sûr ils peuvent tous être forcés mais un peu moins facilement à mon avis.
[^] # Re: hum
Posté par haleth . Évalué à 1.
Ça s'appelle un serveur SMTP configuré avec les pieds.
Sur mes serveurs, une authentification est nécessaire (ie: t'es qui pour vouloir m'utiliser pour envoyer des mails ?).
Mais également, ce n'est pas parcque toi, grouillot, tu as un compte mail, que tu peux envoyer des mails from le boss.
Pourquoi autoriserais-je cela ?
Chaque utilisateur possède un compte, et les from autorisé sont déduis de ce compte et des alias en cours.
Au final, il n'y a plus qu'une sorte de spammeur qui utilisent mes serveurs : c'est bob, from bob@machin, qui envoye de la merde. Et je sais qui est le coupable. C'est bob.
Le problème du spam, c'est avant tout des serveurs SMTP débiles.
[^] # Re: hum
Posté par MTux . Évalué à 4.
Tu fais exprès de pas comprendre ?
Ou alors tes applis en php doivent s'authentifier aussi en localhost ?
[^] # Re: hum
Posté par haleth . Évalué à -2.
Ben ouais, pourquoi ne le feraient-elles pas ?
[^] # Re: hum
Posté par Romeo . Évalué à 4.
Donc tu vas mettre dans le config.inc.php (ou équivalent) de ton CMS les identifiants SMTP.
Ok, mais sachant que les pirates passent par ton CMS pour déposer leurs .php, ils pourraient très bien jeter un œil à ce fichier pour te voler les identifiants.
[^] # Re: hum
Posté par haleth . Évalué à 3.
Aucune importance.
Je sais quel compte est utilisé (et je suis sûr que c'est lui).
Je peux donc, de source sûr, et que ce soit via php, d'autres site, ou des clients SMTP plus classique, trouver le coupable (ou a minima, le responsable), et le châtier.
De plus, il est impossible de faire du source spoofing : la page PHP de machin.fr peut envoyer des mails pour vendre du viagra .. from info@machin.fr uniquement.
[^] # Re: hum
Posté par Anonyme . Évalué à 3.
J'ai pas trouvé d'exemple de configuration implémentant ça, je suis curieux d'en voir un.
Sinon, comment tu fais pour autoriser l'utilisateur example@example.net à envoyer des mails avec l'adresse support@example.net ou noc@example.net ?
[^] # Re: hum
Posté par haleth . Évalué à 4.
La conf postfix qui fait ça: smtpd_sender_login_maps
Dans ton smtpd_sender_restrictions, utilise reject_sender_login_mismatch
# Le probléme d'origine
Posté par wysman . Évalué à 10.
Visiblement, le problème d'origine viens du fonctionnement des CMS utilisés qui nécessite des droits en écriture sur eux-même pour l'installation de divers thèmes et extentions. Ce qui permet a l'attaquant d'exploiter une faille du site web pour écrire la backdoor.
[^] # Re: Le probléme d'origine
Posté par Blount (site web personnel) . Évalué à 0.
Oui mais d'un autre coté, il est souvent nécessaire d'avoir un répertoire de cache, donc avec l'accès en écriture.
Au final, il sera toujours possible d'exploiter la faille en mettant le fichier dans ce répertoire.
Sinon, rien n'empêche d'enlever l'écriture et de le remettre au moment des mises à jour/installations.
[^] # Re: Le probléme d'origine
Posté par wysman . Évalué à 6.
Et la on se demande pourquoi le cache a besoin de stocker des fichiers exécutables…
[^] # Re: Le probléme d'origine
Posté par Spack . Évalué à 4. Dernière modification le 05 août 2015 à 12:34.
Parce que dans le doute
chmod -R 777 *…[^] # Re: Le probléme d'origine
Posté par KiKouN . Évalué à 4.
Un script n'a pas besoin d'avoir les droits d'exécution. Un binaire non plus, remarquez.
[^] # Re: Le probléme d'origine
Posté par Kerro . Évalué à -1.
Comment fais-tu pour le lancer s'il n'a pas les droits d'exécution ?
Lancement direct = ça ne fonctionne pas
Lancement via un autre programme = il faut une faille bien spécifique
[^] # Re: Le probléme d'origine
Posté par KiKouN . Évalué à 9.
[^] # Re: Le probléme d'origine
Posté par Benoît Sibaud (site web personnel) . Évalué à 10. Dernière modification le 07 août 2015 à 08:52.
Et pour un shell :
[^] # Re: Le probléme d'origine
Posté par jyes . Évalué à 2.
Bah, non. Ta technique ne devrait pas marcher. As-tu au moins vérifié que ta point de montage /tmp était monté avec l’option « noexec » ?
Dans le doute j’ai quand-même vérifié sur ma machine, en m’assurant que /tmp est en « noexec » :
$ cp /bin/echo /tmp/echo
$ chmod -x /tmp/echo
$ /lib64/ld-linux-x86-64.so.2 /tmp/echo -e "bla\tbla"
/tmp/echo: error while loading shared libraries: /tmp/echo: failed to map segment from shared object: Operation not permitted
[^] # Re: Le probléme d'origine
Posté par KiKouN . Évalué à 5.
J'ai testé mon exemple sur un VPS qui n'a donc que le root en point de montage. Ça ne doit pas passé SElinux et autres sécurités ( à tester ).
Le but était surtout de démontrer que le droit d'exécution peut être outre-passé. Que le droit lecture suffit. De toute manière, dans le même genre, si on à le droit lecture, on peut recopier le fichier te lui donner le droit d'exécution.
[^] # Re: Le probléme d'origine
Posté par Sufflope (site web personnel) . Évalué à 3.
Le montage en noexec était pas dans le cahier des charges.
[^] # Re: Le probléme d'origine
Posté par jyes . Évalué à 1.
Bien vu, j’ai réagi trop vite à cause du /tmp, mais il n’est pas rare de trouver des répertoires d’installation de CMS qui ne sont pas montés en « noexec », donc le contournement via ld-linux-… fonctionne.
Raison de plus pour être paranoïaque sur une machine qui expose des services sur le grand Internet, ce ne sont pas les mécanismes de mitigation qui manquent avec Linux !
[^] # Re: Le probléme d'origine
Posté par Kerro . Évalué à 1.
Si tu es capable de lancer une commande abitraire (/lib64/ld-linux-x86-64.so.2) c'est que tu as accès au shell (même de manière indirecte). Donc c'est bien une faille spécifique.
Et de toutes manières, une fois que tu as l'accès au shell, il est facile de modifier ce que tu veux.
Donc la question est toujours : comment tu exécutes ton fichier sans le bit x depuis une page PHP moisies ?
[^] # Re: Le probléme d'origine
Posté par octane . Évalué à 8.
Ou pas.
http://0x90909090.blogspot.fr/2015/07/no-one-expect-command-execution.html
En fait, plein de commandes permettent d'en exécuter d'autres, sans avoir besoin de faille.
[^] # Re: Le probléme d'origine
Posté par Elfir3 . Évalué à 3.
Sans oublier qu'il y a sans doute une faille dans la version installée du CMS, ou un mot de passe qui s'est envolé dans la nature. Il serait bon de remonter jusqu'à la mise en place de la backdoor pour savoir par quel moyen elle est arrivée là. Et bien entendu, s'arranger pour que ça n'arrive plus.
[^] # Re: Le probléme d'origine
Posté par wysman . Évalué à 3.
Les failles sont listées dans les changelog des projets open-source, couplé à l'utilisation de CMS pas a jour fait forcement des ravages :p
Des CMS comme DotClear sont utilisé par de nombreux non-informaticiens, qui vont décompresser via leur client FTP favoris puis ne jamais mettre a jour. Bonjour les problèmes…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le probléme d'origine
Posté par xcomcmdr . Évalué à 1.
Tout aussi pratique que sous Windows…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le probléme d'origine
Posté par xcomcmdr . Évalué à 6. Dernière modification le 10 août 2015 à 09:31.
Ça fait au moins 15 ans que je fais ça en cliquant sur un icône et en tapant mon mot de passe une seule fois…
Et en fait c'est pas que moi, mais tous les utilisateurs de distributions grand public.
Franchement je me demande dans quel univers parallèle tu vis.
Et depuis quand c'est centralisé sous windows ?!
C'est bien pour y remédier que windows 10 introduit un gestionnaire de paquets !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le probléme d'origine
Posté par Marotte ⛧ . Évalué à 3.
Il parlait des installations hors gestionnaire de packages. S’il n’y a pas de package (.deb ou .rpm) fourni et c’est pas super simple pour le grand public.
Mais il est effectivement un peu hors sujet parce que le grand public il a pas besoin de faire des installations hors gestionnaire de packages :)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 16 août 2015 à 18:03.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le probléme d'origine
Posté par xcomcmdr . Évalué à 2. Dernière modification le 16 août 2015 à 18:50.
xfce4-weather-plugin dit bonjour.
(ceux de KDE sont biens aussi)
(et avant y'avait celui de KDE 4 sur les dépôts Ubuntu)
dispose d'un PPA officiel : https://launchpad.net/~mudlet-makers/+archive/ubuntu/ppa
Les drivers nvidia et intel sont très efficaces.
Bref, tu ne sais pas de quoi tu parles.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 17 août 2015 à 00:54.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le probléme d'origine
Posté par Marotte ⛧ . Évalué à 5.
Ajouter un PPA Officiel c’est pas forcément M. Michu compliant mais l’installation de certains trucs sous Windows ou Mac ne le sont pas pas plus. C’est pour ça qu’on a des professionnels, des cours d’informatique et « le neveu qui s’y connaît »…
[mylife]
J’ai un pote qui a récupéré le « vieux » Mac de son grand frère. Ses parents un jour on voulu lui offrir un disque dur externe. Ils lui offrent le disque… Flûte il marche pas ! Ah bin oui, sur la boîte ya écrit « Compatible Windows », vous êtes cons Papa, Maman, j’ai un Mac moi :( C’est pas grave fiston, on va aller au magasin pour l’échanger et en prendre un où il y a écrit « Compatible Windows et Mac ». Ce qu’ils ont fait. Et c’est là que mon pote m’appelle : « ouai le disque il marche pas :( » Il me raconte ce que je viens de vous raconter… Bah oui ce disque il était formaté en NTFS… (tout comme le premier vous vous en doutez…). N’y connaissant pas grand chose au Mac et au format de partoche utilisé et ayant conscience que son DD il voudrait l’utiliser sur son Mac mais aussi sur l’ordi des potes j’ai cherché comment faire lire du NTFS à un Mac… Pour un informaticien comme moi je dois dire que ce fût assez facile, il suffit d’installer le logiciel qui va bien (qui est d’ailleurs le même que celui utilisé sous GNU/Linux pour lire le NTFS), vraiment rien de bien compliqué… Pourtant il est bien clair que si tu n’as pas la notion de « système de fichiers » et qu’a fortiori tu ne sais pas qu’il en existe plusieurs…
[/mylife]
Pour reprendre ton exemple d’applet météo, tu penses vraiment que l’utilisateur de base fait un comparatif des applet météo et cherche à installer celle qui roxe du poney ? Bah non, il utilise celle fournie… S’il est sous Ubuntu il utilise celle du gestionnaire de package, s’il est sous Windows il utilise celle déjà installée sous Windows…
Bon, pour Skype là je m’incline, effectivement ça pue côté Linux :( J’espère que le Hello de Firefox va prendre, si Google fout un truc compatible dans Chrome (et ils ont tout intérêt à le faire pour contre Microsoft sur ce terrain…) les choses pourraient bien changer rapidement…
[^] # Re: Le probléme d'origine
Posté par Marotte ⛧ . Évalué à 3.
Je ne connaissais pas mudlet…
Un « MUD client » : grand public, vraiment ?
Je ne connais pas l’univers des gamers (mais pour moi un gamer fait effectivement partie de ce grand public), m’enfin ce truc là c’est vraiment super répandu parmi les joueurs ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 17 août 2015 à 08:50.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par xcomcmdr . Évalué à 2. Dernière modification le 17 août 2015 à 08:51.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le probléme d'origine
Posté par Zenitram (site web personnel) . Évalué à -1. Dernière modification le 10 août 2015 à 09:57.
Windows a une part de marché correcte, tout comme Mac OS, Android, iOS, ça OK.
Linux, c'est déjà pas beaucoup, mais ensuite un truc pour Debian ne marche pas pour Fedora, et compagne…
Faudra un jour arrêter de (se) mentir sur la praticité hors gestionnaire paquet Linux, la réalité frappe en permanence les développeurs.
[^] # Re: Le probléme d'origine
Posté par xcomcmdr . Évalué à 2.
Que ce soit Windows 10 avec son gestionnaire de paquets, ou n'importe quel distribution Linux, si c'est pas sur les dépôts/stores, la mise à jour devient plus problématique.
Pendant longtemps sous Windows, il fallait mettre à jour chaque application une à une, et je doute que ça change de sitôt avec Windows 10 (le pois de l'existant).
Bref, dire que Windows est plus pratique à ce niveau là (regarde le post auquel je réponds, ça t'évitera de répondre à côté la prochaine fois), c'est juste un mensonge.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Le probléme d'origine
Posté par Zenitram (site web personnel) . Évalué à -2. Dernière modification le 10 août 2015 à 15:59.
tu n'as pas compris : part de marché.
Les développeurs diffusent pour Windows (avec un peu de chance, Mac aussi). Ils font le taf.
Linux, c'est tellement la merde (un .deb ne va pas passer sur Fedora, vice-versa, une version pour Debian 6 va crasher sous Debian 8 car une lib aura été enlevée…) et c'est tellement explosé comme part de marché que les développeurs ne font pas.
D'un côté, l’utilisateur a un installeur, pas de l'autre.
D'où le "arrête de te mentir sur Linux aussi pratique que Windows" : non, ça ne l'est pas, tout simplement car sorti du repo, c'est "démerde-toi, c'est trop chiant à faire le packaging pour ta distro qui a si peu de monde".
Et c'est ça qu'il faudra se mettre dans la tête : quand on est petit, on évite d'encore plus diviser, à défaut pas l'utilisateur n'a rien (il doit prier pour avoir le logiciel dans le repo, et pas avec une version d'il y a 3 ans), et c'est aussi pour ça que des OS pour particuliers marchent (Win, Mac, iOS, Android) et pas d'autres (Linux desktop par exemple)
[^] # Re: Le probléme d'origine
Posté par xcomcmdr . Évalué à 2. Dernière modification le 10 août 2015 à 16:39.
Le truc, c'est que tu es hors sujet.
Je répondais à un post qui prétendait que Linux n'avait aucun moyen de tout mettre à jour en une seule fois. Or, ça fait 20 ans que ça existe, ça s'appelle un couple gestionnaire de paquets + dépôts.
Quant au reste de ton poste, Windows gagne d'abord parce qu'il est préinstallé depuis 20 ans. Le reste, c'est des détails d'implémentation dont l'impportance est ridiculement petite face à un avantage aussi massif et utilisé constamment depuis 20 ans (et tout ce qui en découle : support matériel meilleur, plus d'applications, etc. …).
Le nerf de la guerre, ce n'est pas la stabilité de l'ABI, la diversité des distros, ou je ne sais quoi. Une ABI stable, c'est très bien,, mais ça changera pas grand chose aux parts de marché.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Le probléme d'origine
Posté par Zenitram (site web personnel) . Évalué à -2.
Tu répondais à "Faut dire c'est super pratique les mises a jour hors gestionnaire de paquet sous linux….", j'ai répondu dans le sujet.
Non.
Ca fait que les développeurs apprécient, ça fait boule de neige.
Ho que si c'est important, et c'est bien pour ça que MS, Appl, Google… Gardent leur API longtemps.
tu crois sérieusement que Windows resterait aussi implanté si MS cassait les API toutes les versions?
[^] # Re: Le probléme d'origine
Posté par xcomcmdr . Évalué à 2.
Non, mais je sais que Windows s'est imposé via la vente liée d'abord, et une ABI stable ENSUITE, pas l'inverse !
Bah si.
T'auras peut-être plus de développeurs, mais pas beaucoup plus de parts de marché.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Le probléme d'origine
Posté par oinkoink_daotter . Évalué à 3.
Ben c'est un peu un cercle vicieux/vertueux. Si t'as pas de développeurs, t'as pas d'appli sympa. Si t'as pas d'appli sympas, t'as pas de clients. Pas de clients pas de parts de marché. Pas de parts de marché, pas de développeurs… Bref.
Ce n'est pour rien qu'Apple, MS et Google ont fait la danse du ventre aux développeurs pour les encourager à développer sur leurs plateformes mobiles où l'on partait de rien.
Faut bien commencer quelque part.
[^] # Re: Le probléme d'origine
Posté par xcomcmdr . Évalué à 3.
Android s'est imposé via la vente liée sur des milliers de devices.
Windows, pareil.
La danse du ventre pour qu'on vienne développer chez toi, c'est quand tu as pas de vente liée, et pas de part de marché.
C'est long, et à la fin, Android domine toujours. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Le probléme d'origine
Posté par oinkoink_daotter . Évalué à 5.
La réalité est beaucoup moins rose que ça en fait.
En gros, Android c'est bien en nombre d'utilisateurs, mais si tu veux gagner de l'argent, faut faire de l'iOS. Si je me rappelle bien et groumly< me fouettera si c'est faux mais l'ordre de grandeur, iOS c'est 20% de PDM en nombre de smartphones pour 80% des bénéfices.
[^] # Re: Le probléme d'origine
Posté par Kerro . Évalué à 4.
J'ai vu que des « jeux gratuits pour votre smartphone » passent en publicité à la télévision.
Vu le coût de ces publicité, je suppose qu'Android génère tout de même un bon paquet de fric.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le probléme d'origine
Posté par xcomcmdr . Évalué à 3.
Oui et ?
Il n'empêche qu'il s'est vraiment imposé à partir du moment où il était en vente liée.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Le probléme d'origine
Posté par Kerro . Évalué à 2.
J'ai le souvenir que MS-DOS et Windows était déjà les standards de facto en 1990, pourtant il fallait les acheter à part.
La vente liée à vraiment débuté vers 1995 je pense (quelqu'un a de meilleurs souvenirs ou sources ?). En 1995 les gens achetait pas mal de machines assemblées, donc pas de vente liée. De toutes manières il n'y avait que Windows d'utilisable, donc vente liée ou pas c'était kif-kif : OS/2 Warp qui était très très très prometteur a été coulé par les mauvaises manœuvres d'IBM (en gros c'est mieux que Windows, donc on le vend plus cher. Résultat = 0% de parts de marché), et il n'y avait pas d'autres concurrents crédibles.
[^] # Re: Le probléme d'origine
Posté par Marotte ⛧ . Évalué à 3.
Source ? Parce que cela me semble suggestif. Je pourrais aussi affirmer « pas mal de gens achetaient des machines de constructeurs ». À l’époque pré 95 l’OS n’était peut-être pas souvent pré-installé mais les disquettes (de MS-DOS) étaient dans le carton avec la machine, vu que la machine ne sert strictement à rien sans un OS.
Certainement. Tout comme Digital Research avec CP/M un peu plus d’une dizaine d’années auparavant…
[^] # Re: Le probléme d'origine
Posté par Kerro . Évalué à 3.
Je bossais chez un « semi-grossiste » informatique, qui avait aussi une boutique.
Les demandes était quasi-uniquement pour de l'assemblé.
Et chez les gens et les artisants, on ne voyait presque que de l'assemblé. Les collèges, lycées, IUT et facs que j'ai connu étaient également en assemblés (de mémoire).
En entreprise plus grosse c'était Dell, IBM, et compagnie. Remarque c'était peut-être déjà plus que 50% des parts de marché.
Mais dans tous les cas il n'y avait rien d'autre que Windows qui soit convaincant, donc vente liée ou pas ça ne changeait rien.
Je ne connais pas l'histoire de CP/M. Je l'ai utilisé mais c'est tout.
Par contre Digital Research a sorti l'excellent DR-DOS, mais qui n'a pas fait le poids commercialement devant MS-DOS.
Lorsqu'on est challenger, on ne peut clairement pas appliquer les mêmes tarifs, méthodes de communication, etc, que le premier. Donc disparition aussi.
[^] # Re: Le probléme d'origine
Posté par vincent LECOQ (site web personnel) . Évalué à 2.
Tu peux arrêter de réinventer l'histoire un moment ?
La chute de DR-DOS n'est pas due à son poids commercial mais au fait que windows 3.xx faisait exprès d’afficher un faux message d'erreur si le DOS présent n´était pas estampillé M$. Du coup les gens rejetaient la faute sur DR-DOS.
La chute d'OS/2 (projet commun IBM et M$) est surtout due au fait que M$ à fait semblant de bosser en n'y affectant un seul ingé sur les 40 financés, les 39 autres repompant/imitant tout ce qui était possible pour le projet Chicago.
Il me semble même qu'il y a eu des actions de justice pour ces histoires.
[^] # Re: Le probléme d'origine
Posté par Kerro . Évalué à 2.
Le poids commercial de qui/quoi ?
J'ai écrit que DR-DOS n'a pas fait le poids commercialement devant MS-DOS = DR-DOS s'est beaucoup moins bien vendu.
Je précise « commercialement » car il faisait très largement le poids techniquement. Microsoft était très à la traîne.
J'avais DR-DOS + Windows 3.xx et je n'ai jamais eu cela.
Une rapide recherche avec ton ami Google m'indique qu'aucun Windows commercialisé n'a eu ce faux message d'erreur. Uniquement une béta.
https://en.wikipedia.org/wiki/AARD_code
La tricheLe comportement habituel de Microsoft n'est pas la cause de l'échec d'OS/2. IBM était déjà très à la traine avant cet accord (c'est d'ailleurs pour cela qu'il y a eu l'accord).IBM a réussi à sortir un excellent système (OS/2 Warp) plusieurs mois avant que Microsoft ne sorte Windows 95. Ils ont décidé qu'il était possible de l'utiliser gratuitement pendant quelques mois, pour ensuite le vendre bien plus cher que Windows. Qui va acheter plus cher pour un truc qui fait la même chose ? Même si techniquement c'est mieux, encore que ce point soit discutable car il était critiqué pour être moche, et je me souviens que c'était le cas :-)
Les magasines de l'époque parlaient pas mal d'OS/2 Warp, donc la communication d'IBM a bien fonctionné aussi, bingo. Tout le monde pensait qu'il allait continuer à être gratuit afin de gagner de grosses parts de marché.
Lorsqu'IBM a finalement fait payer OS/2 Warp, je suppose que ça a été terminé en 2 mois (c'était pile au moment où Windows 95 sortait).
[^] # Re: Le probléme d'origine
Posté par Marotte ⛧ . Évalué à 3. Dernière modification le 13 août 2015 à 01:17.
Il me semble que la vente liée date de MS-DOS… Ce n’est pas très clair toute cette histoire mais la manœuvre de Bill Gates pour imposer l’OS de sa compagnie montre qu’il devait avoir bien saisi l’importance de la vente liée pour parvenir à être en position de monopole.
https://fr.wikipedia.org/wiki/Gary_Kildall#Le_.22contrat_du_si.C3.A8cle.22_avec_IBM
Gary Kildall a peut-être à ce moment là fait un mauvais choix en alignant pas le prix de CP/M sur celui de MS-DOS mais quoi qu’il en soit, de par le fait c’est MS-DOS qui allait très vite se retrouver pré-installé sur tous les Compatible PC…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le probléme d'origine
Posté par Marotte ⛧ . Évalué à 4.
https://www.youtube.com/watch?v=0wwB-qCEtXI
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le probléme d'origine
Posté par oinkoink_daotter . Évalué à 6.
Il me semble que ce thread discute de la pénibilité pour un utilisateur comme un développeur de mettre à jour une application dans une distrib en dehors d'un gestionnaire de package. Qu'on puisse mettre à jour sa distrib via un apt-get update+upgrade en utilisant son gestionnaire est un fait mais n'est pas le sujet.
Le problème, quand on écrit "Or, ça fait 20 ans que ça existe, ça s'appelle un couple gestionnaire de paquets + dépôts.", c'est que c'est peut-être vrai, mais ça nécessite :
1 - d'avoir un packageur pour chaque distrib (si on compte les distribs majeures, ça en fait au moins 5, sans compter les parfums)
2 - d'être accepté par la distrib (problématiques possibles d'ego, de compatibilité de licence, de brevets machin toussa), d'un dépôt parallèle connu ou de faire son équivalent PPA perso avec le site d'explications qui va bien autour.
C'est très très lourd. Du coup ça peut être fait (genre pour virtualbox) ou pas. Du coup, quand on doit installer ou mettre un jour un soft hors distrib, ça donne au choix :
1-targz autoporteur genre firefox
2-targz de sources
3-un script shell qui embarque une archive qui est elle-même décompressée sur acceptation d'une licence.
4-d'autres solutions créatives toutes pourrites à base de copier collage qui finissent par un wget | sh
Sous Windows, ben les développeurs se démerdent parfois/souvent (mais c'est vrai pas dans tous les cas, et ce n'est pas centralisé) pour faire des trucs qui se mettent à jour tout seul, mais de toute façon, ils mettent à disposition un installateur qui marche sur à peu près tout depuis Windows XP à Windows 10.
Le fait de passer par des stores à la MS, Apple ou Google permet de régler les problèmes propres à Windows.
Chaque solution a ses avantages et ses inconvénients. Mais force est de constater que sous Linux quand tu es en dehors du gestionnaire de packages, c'est rapidement chiant.
Ce qui est étonnant c'est que ce débat revienne environ tous les 3 mois.
[^] # Re: Le probléme d'origine
Posté par dj_ (site web personnel) . Évalué à 3.
Beaucoup de CMS ont maintenant des mises à jour en un clic ;) c'est le cas pour dotclear par exemple
[^] # Re: Le probléme d'origine
Posté par Zenitram (site web personnel) . Évalué à 0.
Beaucoup de CMS ont maintenant des mises à jour auto ;) c'est le cas pour wordpress par exemple.
nan, parce que les mises à jour en un clic, on sait tous que les gens ne le font pas et que c'est le meilleur moyen d'avoir la moité des installs trouées.
Le monde évolue, les mises à jour en un clic (ou plus compliqué) devraient appartenir au passé.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 08 août 2015 à 16:16.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le probléme d'origine
Posté par Kerro . Évalué à 8.
Soit tu es un génie incompris. Soit tu es un crétin total.
Je ne vois aucune possibilité entre les deux.
Peux-tu donner des arguments pour faire comprendre que les gestionnaires de paquet sont une erreur ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 09 août 2015 à 01:02.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le probléme d'origine
Posté par Kerro . Évalué à 8.
Ce que je comprends de tes arguments, c'est que tu estimes qu'il est problématique de faire confiance à quelques personnes pour gérer les mises à jour. C'est à peu près cela ?
Personnellement, je trouve cela très bien. Pas parfait, mais globalement bien mieux que si je devais tout me farcir moi-même.
Que proposes-tu de mieux ?
Tout faire à la mimine ?
Que les logiciels se mettent à jour tous seuls (comme Firefox sous Windows) ?
L'idée des stores est bien antérieur à l'internet de masse. Au début c'était des entreprises de commande par correspondance. Même principe, mais avec les moyens de l'époque.
L'internet, sa consommation de masse, et le poids des géants ont rendu possibles les stores actuels. Dont le but est effectivement de gagner de l'argent. Tu penses que ça devrait avoir un but humanitaire ?
[^] # Re: Le probléme d'origine
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 09 août 2015 à 08:15.
Au moins tu n'oses pas affirmer être un génie incompris…
Et comme tu n'es pas un génie incompris, tu n'as rien comme idée pour proposer mieux.
En attendant, un modèle économique est utile si on veut que les utilisateurs utilisent, sinon on se retrouve avec Debian qui est pas mal mais n'est que peu utilisé dans le monde réel (à part quelques admins de serveur et quelques geeks, pas foule, et après on a Ubuntu et Linux Mint mais qui ont aussi une tentative de modèle économique pour pouvoir proposer encore plus ensuite).
L'histoire de Windows qui n'avait pas de gestionnaire de paquet, ça va appartenir de plus en plus au passé, pour une raison toute simple : non, pas "faire banker", mais surtout que ce modèle ne marche plus avec les utilisateurs qui ne sont plus de passionnés, mais des gens qui veulent trouver facilement et que ça marche, tout simplement.
Maintenant, le jour où un génie incompris arrive à proposer quelque chose de mieux, ce sera utilisé, je n'en doute pas.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 10 août 2015 à 09:21.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le probléme d'origine
Posté par Zenitram (site web personnel) . Évalué à -1.
Il marche tellement bien que personne y reste.
Le monde change, avec des utilisateurs ayant grandi (et leur nombre augmenté, pour passer des quelques geeks aimant la souffrance technique à des utilisateurs) et n'ayant plus du tout envie de s'emmerder à faire les choses à la main.
Le problème est sans doute que le monde change. tu peux rester dans le "modèle actuel", il n'est pas enlevé, donc pourquoi te plaindre? Toi tu es content, les autres le sont aussi avec le nouveau modèle, tout va pour tout le monde!
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
# euh et mettre un filtre antispam ?
Posté par dufour olivier . Évalué à 1.
un outil qui aurait aussi son utilité pour améliorer c'est simplement un filtre antispam comme spamassassin par exemple.
http://spamassassin.apache.org/
il se base sur des règles publiques et privées qu'il applique sur le mail. C'est de l'analyse de contenue.
Cela ralentie les mails queues mais bon si tu ne route pas des millions d'email, il n'y aura pas de problème.
Par contre, pas d'analyse comportementale comme nos amis de gmail.
Aussi, paramétrer postfix pour interroger les blacklists.
Euh sinon, yahoo peut aussi bloquer les email pour des raisons de throtling (limitation de nombre de mail par heure) De mémoire, je crois que c'est 50 000/h.
[^] # Re: euh et mettre un filtre antispam ?
Posté par Kerro . Évalué à -1.
Oui et ?
Tu as un beau filtre anti-spam.
Plus un anti-virus.
Plus une super politique de sécurité.
Plus des utilisateurs au dessus de la moyenne.
Et donc ça te garanti de ne jamais avoir de spam envoyé à partir de ton serveur ?
--> montes vite une entreprise, car tu vas être riche dans les 6 mois. Mais je suppose tu vas également être la cible de plusieurs contrat sur ta tête, c'est un inconvénient certain.
[^] # Re: euh et mettre un filtre antispam ?
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 5.
Je ne comprends pas ton commentaire, il propose juste d'utiliser un antispam en complément des outils cités dans la dépêche. Je ne vois pas où il dit avoir une solution parfaite.
[^] # Re: euh et mettre un filtre antispam ?
Posté par dufour olivier . Évalué à -2.
Ouah un beau troll comme on en fait plus.
MA - GNI - FIQUE !!!
Ohhh ca réchauffe le coeur d'avoir des gens accueillants, chaleureux,…
PS: J'ai déjà monté mon entreprise et je suis consultant emailing & délivrabilité ;-)
Mais vu que tu as l'air de mieux t'y connaitre…
[^] # Re: euh et mettre un filtre antispam ?
Posté par Kerro . Évalué à 3.
Le titre de ton commentaire est « euh et mettre un filtre antispam ? »
Je l'ai interpreté comme « à la place de tes manipulations compliquées, utilises plutôt un filtre anti-spam ». Ce qui est peut-être/probablement une erreur de ma part.
Ce genre d'argument, ça vaut exactement zéro.
Tout comme n'importe quel spécialiste de tel ou tel domaine, il y a zéro garantie qu'il soit compétent. J'ai trop vu de mauvais médecins, de mauvais garagistes. Pour les informaticiens/développeurs/administrateurs, nous ne sommes pas mieux.
# Commentaire supprimé
Posté par Depinne . Évalué à -1. Dernière modification le 14 août 2015 à 08:51.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Depinne . Évalué à 0. Dernière modification le 14 août 2015 à 08:51.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.