cricx

sans vouloir troller sur windows, le serveur dont je parlais plus haut d'uptime 682 jours a eu toutes les mises à jour d'applications faites, et sans redémarrage (il n'y a que la mise à jour du noyau qui le nécessite). Sur un windows, le redémarrage est souvent obligatoire... même pour installer un windows, je ne compte plus le nombre de redémarrages nécessaires (un linux ne redémarre qu'une fois à la fin de l'installation et est immédiatement opérationnel).

oui, mais pour tester tu peux forcer la résolution sur les dns d'ovh (qui sont à jour tout de suite). ceci dit, tes enregistrements dns ne sont pas bons : mx.b-p.be n'existe pas il n'y a pas d'enregistrement MX pour b-p.be donc en l'état, impossible de recevoir de mails pour ton domaine. ce que tu dois avoir pour recevoir tes mails du domaine b-p.be mx.b-p.be A 95.182.129.240 .b-p.be MX 10 mx.b-p.be

non, tu supprimes simplement mail dans la ligne mail.b-p.be MX 1 mx.b-p.be tu devrais avoir .b-p.be MX 1 mx.b-p.be

l'un de mes serveurs : uptime 16:30:35 up 682 days, 18:09, 6 users, load average: 0.16, 0.03, 0.01 sans onduleur... mais ce n'est pas un syno ! et on trouve couramment des uptimes encore plus élevés sur les serveurs linux. Ceci dit, la stabilité légendaire des serveurs linux est applicable aux syno (mais adieu les mises à jour !)

Oui, je l'ai remarqué... ça signifie en tous cas que le mx secondaire fonctionne et qu'il filtre ! OK, je n'avais pas bien compris (idem sur ehlo et dkim, je suppose... encore que la vérification du ehlo devrait ajouter des points si incorrect, car un vrai serveur mail s'annonce comme il faut) oui, j'ai vu, je vais faire en sorte de traiter ce header (mais bon, je n'ai pas beaucoup de spams non plus) je pense qu'il suffirait d'abaisser la note... car si un message est, par exemple, sur les 3 rbl/sbl on peut raisonnablement en déduire que c'est un spam (sur mon postfix je considère que la présence sur zen.spamhaus.org est suffisante et les mails sont donc éliminés) merci ! sus aux spams !

Return-Path: <amyrabinovitz@avsc.eu.com> X-Original-To: moi@mondomaine.net Delivered-To: moi@mondomaine.net Received: from backup.nas-forum.be (ns3.deathrock.be [176.31.247.102]) by mondomaine.net (Postfix) with SMTP id 920757C401B for <moi@mondomaine.net>; Sun, 29 Apr 2012 04:59:46 +0200 (CEST) Received: from cpe-76-169-29-124.socal.res.rr.com ([76.169.29.124]) by backup.nas-forum.be ; Sun, 29 Apr 2012 04:59:45 +0200 Received: from unknown (HELO sk3xvw) ([91.199.108.98]) by cpe-76-169-29-124.socal.res.rr.com with ESMTP; Sat, 28 Apr 2012 20:02:40 -0800 Message-ID: <002501cd25b4$213e3b80$5bc76c62@ReVaHPCsk3xvw> From: "Owen Cole" <amyrabinovitz@avsc.eu.com> To: <moi@mondomaine.net> Subject: It's time to start a new intimate life Date: Sat, 28 Apr 2012 19:59:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 [color=#ff0000]X-hMailServer-Spam: YES X-hMailServer-Reason-1: Rejected by SpamCop. - (Score: 3) X-hMailServer-Reason-2: Rejected by Spamhaus. - (Score: 3) X-hMailServer-Reason-3: Rejected by SURBL. - (Score: 3) X-hMailServer-Reason-Score: 9[/color] Solution to your marriage problems http://kemaliyesenibekliyor.com/fly.html On voit bien que le message a été envoyé directement au backup, puis retransmis à mon syno 1 seconde plus tard. Selon rodolphe : "Notre serveur effectue plusieurs contrôle et attribue des points à chaque erreur rencontrées. Si le message arrive à 12 points, il sera automatiquement supprimé afin d'éviter une surcharge sur notre serveur. Vérification SPF - 3 points Vérification de la commande HELO - 2 points Vérification DNS - 2 points Vérification de la signature DKIM - 5 points Refus par SpamHaus - 3 points Refus par SpamCop - 3 points Vérification des liens par SURBL - 3 points " On voit bien d'après les en-têtes ajoutés par le backup mx que le message a été classifié comme spam (9 points), mais transmis quand même (rejet à 12 points), et la vérification spf ne semble pas avoir fonctionné (pas de spf pour le domaine), ni la vérification du HELO, ni la signature dkim. Sur mon syno, je suis moins tolérant, ce qui explique le nombre extrèmement faible de spams.

Je ne re

mais picasa c'est mal !!

pas la peine d'être root si tu mets la ligne de montage dans fstab avec l'option user.

c'est effectivement la clé du problème. as-tu essayé avec d'autres serveurs smtp ? quels types de messages ? texte seul, html, avec pièce jointe ? les messages envoyés par le webmail de la poste ne contiennent pas de texte, uniquement des parties incluses, en encodage utf-8 et transfert en 7 bits. tu peux essayer d'envoyer les mails avec d'autres clients (je ne pense pas que ce soit le serveur smtp d'envoi qui soit en cause, mais plutôt le format du mail). Avec quel client mail fais-tu tes tests ?

pour les commandes smtp : http://the-welters.com/professional/smtp.html pour esmtp : http://smtpfilter.sourceforge.net/esmtp.html http://technet.microsoft.com/fr-fr/library/aa996114%28v=exchg.65%29.aspx mais les informations que tu obtiendras ne seront probablement pas utiles (les erreurs que tu as sont liées à une erreur dans la commande DATA, pendant laquelle se produit un timeout. Il est possible que ce timeout soit causé par un mauvais format de la commande DATA envoyé par le relais (caractère de fin de flux non reconnu).

convmv ne convenait pas à cet usage ?

ça n'empêche pas de tester le dns... il ne tourne pas sur ton syno ! mais tu as raison, il vaut mieux attendre le rétablissement de ta connexion, pour tester aussi la réponse du syno.

pour faire ce que tu veux faire, une redirection ne fonctionne pas, il faut un cname.

oui, tu as raison sur les moyens de google. mais depuis 6 ans que mon syno gère les mails de mon domaine, pas plus de problème que ça (coupure de courant courtes, gérées par l'onduleur, pas d'attaques en règle du serveur -mais par contre des dizaines et des dizaines de rigolos qui essaient de se connecter-, et une stabilité de ma connexion internet (chez free) remarquable. ceci dit, j'ai aussi des comptes mail ailleurs, et l'un d'entre eux a subi une perte de messages très importante (tu peux regarder sur les forums, je ne suis pas le seul à être dans ce cas) et c'est à la suite de cette défaillance majeure d'une société qui a plus les moyens que moi que j'ai basculé définitivement sur mon syno.

le killall est plus rapide et a le même effet dans le cas présent.

bof, pas trop de désagréments en ce qui me concerne, mais je reconnais avoir modifié un peu la conf postfix (ainsi que la conf dns/mx). j'ai extrêmement peu de spams (de l'ordre d'un ou deux par mois), pour une cinquantaine d'adresses mail associées à ma boite (et donc diffusées dans la nature). Idem pour les autres comptes. Pour les cas d'indisponibilité de ton serveur, tu as le service mailbag offert par rodo sur ce forum. Pour les mails sans destinataire réel sur ton nas, tu as deux solutions : avoir une adresse catchall, ou laisser postfix faire son boulot (rejet du message destinataire inconnu). J'ai opté pour la seconde solution. Pour la blacklist, j'utilise celle de zen.spamhaus.org

tu peux quand même préciser que l'utilisation de download station sur le syno est rigoureusement identique à l'utilisation d'un soft du même genre sur pc ou mac sur le plan de l'anonymat. En bref tu n'es pas anonyme... Cela ne pose aucun problème pour les téléchargements légaux. Dans tous les cas, on n'est jamais vraiment anonyme sur internet...

il n'y a pas de danger d'ouvrir un port ssh, mais : - il vaut mieux changer le port par défaut - il faut se connecter avec un compte de simple utilisateur - il est préférable de n'autoriser que des connexions avec clé après, tu lances tes téléchargements avec wget, de préférence dans un screen. ça fait des années que mon syno est accessible en ssh, sans problème d'attaque ou autre. quant à celui qui veut installer un client ftp (filezilla) sur le serveur distant, il doit oublier trois choses : - que le fait de pouvoir télécharger sur un serveur ne donne pas pour autant le droit d'y installer quelque chose - qu'il faut pouvoir se connecter sur le serveur en mode graphique pour y lancer le client - que les bons serveurs n'ont pas de mode graphique

un lien sftp est normalement de la forme user@server:/chemin (du moins le "vrai" sftp) @bud77 : le sftp n'est en général pas du ftp passant par le port ssh ! c'est du ssh (en fait un protocole de transfert de fichiers spécifique utilisant ssh) , pas du ftp (il existe cependant un sftp correspondant à un tunnelling de ftp dans ssh, mais ce n'est pas très utilisé) donc vérifier si c'est bien vraiment du sftp (et vérifier l'ouverture du port 22)

top peut-être, mais pas terrible d'utiliser encore un service google alors qu'on a notre petit syno qui peut le faire

oui (mais a priori aucun rapport avec ton problème, puisque ton serveur répond lors de la retransmission du message) oui. j'en ai des centaines comme ça tous les jours idem. c'est une vérification du reverse dns (nom associé à l'IP non résolu), en général ce sont mails expédiés de machines de particuliers (et notamment les spams issus de machines compromises). Pas de rapport non plus avec ton problème. par contre je suis un peu étonné de voir ces messages sur une machine non déclarée en mx ! car mailhop est censé faire le filtrage, non, et là ce sont des connexions directes sur ton serveur (probablement issues d'un scan systématique de l'ouverture du port 25 pour utiliser ton serveur mail en relais). Tu devrais n'autoriser les connexions sur le port 25 que depuis les serveurs de mailhop. Et pourquoi utiliser mailhop ? tu as donc tant de spams que ça ?

entre autres. la sécurité d'une application dépend de beaucoup d'autres paramètres aussi. on voit tous les jours des failles qui affectent des applications "professionnelles" et qui sont pourtant auditées, il y a toujours un risque avec des applications "maison". Bien entendu, si l'application n'est pas accessible de l'extérieur, le risque est moindre.

commence par regarder les logs de postfix sur ton syno. mais le message d'erreur est : "relay=jodecorle.net[109.212.137.97]:25, delay=438006, delays=437706/0/0.56/300, dsn=4.4.2, status=deferred (host jodecorle.net[109.212.137.97] said: 421 4.4.2 jodecorle.net Error: timeout exceeded (in reply to end of DATA command))" ce message indique en général un problème réseau (mauvaise communication entre les deux serveurs). Vérifie ton routeur (redirection du port 25), le firewall du syno, le bloquage d'IP, et bien sûr la qualité de ton lien adsl et ton câblage réseau.

tu n'es absolument pas obligé de mettre le smtp de ton fai. mais c'est plus simple. qu'entends-tu par "voir mon serveur mail de l'extérieur" ? lui permettre de recevoir le courrier de ton domaine ?