Le Tue, Jul 20, 2010 at 12:14:25PM +0200, Vincent Carpentier [vincent.carpentier(a)cegedim.fr] a écrit:
> [...]
Dites, là, sur une liste neuve, ça serait bien de prendre directement de
bonnes habitudes, et d'éviter les dérives de sujet sans changer de fil, le
goret-quoting et le top-posting.
Merci.
--
Dominique Rousseau
Neuronnexion, Prestataire Internet & Intranet
50, rue Riolan 80000 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
depuis quelques jours, un des domaines de mes clients ne recevai plus
les emails en provenance de hotmail
retour en erreur immediat dans hotmail :
This is an automatically generated Delivery Status Notification.
Delivery to the following recipients failed.
avec en piece jointe :
Reporting-MTA: dns;blu0-omc3-s12.blu0.hotmail.com
Received-From-MTA: dns;BLU139-W6
Arrival-Date: Mon, 19 Jul 2010 23:38:53 -0700
Final-Recipient: rfc822;admin(a)p*****rs.com
Action: failed
Status: 5.7.1
Diagnostic-Code: smtp;554 5.7.1 <admin(a)p*****rs.com>: Relay access denied
Final-Recipient: rfc822;info(a)p*****rs.com
Action: failed
Status: 5.7.1
Diagnostic-Code: smtp;554 5.7.1 <info(a)p*****rs.com>: Relay access denied
je sais que mes DNS et MX sont 100 % cleans ( zonecheck entre autres )
apres une longue enquete je finis enfin par trouver :
http://windowslivehelp.com/thread.aspx?threadid=b27e8335-2d5b-4d2b-8510-83e…
voir le commentaire de "I run servers that work" qui m a donne la
solution ainsi que le mien que j ai rajoute au thread
This is caused by microsoft's failure to follow mail standards.
The only fix (short of getting MS to do something) is to convince the
person who runs the domain you are trying to email to (hilariously)
block hotmail's IP's from sending mail to there web server.
I did this for my linux mail server with the following;
iptables -A INPUT -s 65.52.0.0/14 -p tcp -j REJECT --reject-with
icmp-port-unreachable
Note: you may have to add more IP's to this range, I am unsure if msn,
live, etc use other IP's
--Technical explanation--
First MS for some reason pull's your domain's A record and attempts to
deliver to it.
EG....
dig hotmail.com A +short
64.4.20.186
64.4.20.169
64.4.20.174
64.4.20.184
If those IP's do not host a mail server it will pull the MX record and
deliver mail appropriately.
dig hotmail.com MX +short
5 mx1.hotmail.com.
5 mx2.hotmail.com.
5 mx3.hotmail.com.
5 mx4.hotmail.com.
This will cause issues ANY time you have an email server on your web
server if it is not also your email server.
Such as;
An outgoing server (as mine was)
A filtering service
A shared host
An authentication required mail server
effectivement en regardant les logs du serveur concernen , qui nest
PAS un des MX de ce domaine , j ai effectivement vu que hotmail
essayai de se connecter a ce serveur , et evidemment le postfix du
serveur refusai les mails, vu qu il ne gere pas les mails de ce
domaine, et n est pas un MX de ce domaine
apres un drop de 65.52.0.0/16 65.55.0.0/16 sur le serveur en question
hop ca marche
hotmail n ayant pas trouve de port 25 sur le IN A de parcours.com est
finalement alle chercher le DNS et les IN MX du domaine , et envoie
dorenavant les emails aux vrais MX du domaine
voila, je tenais a partager ca :
1 pour que quand ca vous arrivera vous ayez la solution, j ai perdu
quelques heures a chercher
2 pourfoutre la honte a microsoft hotmail, hesitez pas a faire tourner
l info :
http://windowslivehelp.com/thread.aspx?threadid=b27e8335-2d5b-4d2b-8510-83e…
je suis pas le premier a qui ca arrive . . .
--
Cordialement
-----------------------------------
William Waisse
http://waisse.org | http://neoskills.comhttp://cahierspip.ww7.be | http://feeder.ww7.be
Computers are like air conditionners. They work better when you close windows.
Bonjour à tous.
J'ai un réseau interne d'une 12aine de machines de machines qui tourne sous
windows (xp, vista et seven), linux (ubuntu) et plusieurs mac avec des
version différentes selon leurs ages ...
Assez hétéroclite :)
Je voudrez mettre en place une sauvegarde journalière de l'ensemble des
machines, mais pas du disque entier, juste un répertoire par ordinateur.
Type de sauvegarde : incrémentale sur 1 mois.
J'ai un petit serveur de stockage (un NAS en faite) qui a largement de quoi
comme espace disque pour couvrir les besoins de sauvegarde.
Vu les différents système, je pensez partager un répertoire sur chaque
ordinateur et que la sauvegarde soit effectué par une petite tour sous
linux.
Comment faire ?
Je m'essaye à rsync, sans trop de succès jusqu'a présent.
Si vous avez une idée d'une autre organisation...
Merci d'avance pour votre temps et expertise.
Sky_G
Bonsoir,
Je viens de lire un post sur le blog de l'ISC (Internet Systems
Consortium) à propos d'une annonce faite au Black Hat avant hier et à
la DefCon hier : l'introduction d'un système de notation de la
réputation des noms de domaines : DNS RPZ.
Voici le post: https://www.isc.org/community/blog/201007/taking-back-dns-0
Je me permets de contacter la liste pour relayer l'information d'une
part, et que nous puissions discuter de cette technologie et de son
intérêt (ou plutôt l'absence d'intérêt, à mes yeux) d'autre part.
J'ai beau me torturer, je ne vois pas le moindre intérêt à cette idée
: les DNSBL n'ont jamais réussi à juguler le Spam (causant plus de
problèmes qu'autre chose (cf.
http://www.mail-archive.com/frnog@frnog.org/ conversation sur les
antispams), sans parler de la déléguation de sa politique d'email à
des inconnus), et pourtant, ils veulent reprendre cette idée afin de
permettre la notation des noms de domaines et ainsi limiter les
méfaits des "bad guys".
Dans la série des problèmes adressés par cette techno, je vois, de
prime abord le contenu reconnu universellement illicite (13yo.xxx et
autres sites contenant des images que nous ne souhaitons pas voir (?))
et également le phising.
Concernant les sites à caractères innopportuns (oui, je tourne autour
du pot, mais je ne compte pas prononcer ce mot, affiché trop souvent
comme porte-étendard, voire seul mal sur Internet (avec le piratage,
évidemment) (http://www.cleanternet.org/ )), nous le savons tous,
bloquer le nom de domaine ou la récursion n'est pas une solution pour
stopper la diffusion (pour peu que des noms de domaine soient
utilisés, ce dont rien n'est moins sur) ; déjà que bloquer les IP ne
sert à rien puisque les sysadm s'occupant de ce genre de réseaux sont
tout aussi capables que nous de mettre en place des solutions
d'hébergement multi-site robustes, avec l'avantage d'utiliser des
botnets, donc autant dire des milliers de sites (Tiens d'ailleurs,
personne a envisagé de tenter l'hébergement de son site sur un botnet
? ^^ ca coute certainement moins cher qu'un
rps/kimsufi/dedibox/digicube).
Concernant le phishing – même si je ne suis pas spécialement d'accord
avec son approche, puisqu'il arrivera bien un jour où, acculés, ils y
viendront – Stéphane Bortzmeyer a publié un billet sur son blog à
propos du typosquatting (en l'occurence avec des IDN) et de son manque
totale de nécessité vis à vis du phishing (
http://www.bortzmeyer.org/idn-et-phishing.html ) .
En effet, M. Michu, en bon luser, ne vérifie pas le nom de domaine
employé avant de saisir ses informations personnelles.
La solution globale au phishing n'a pas encore été trouvée (HTTPS ne
résout rien ; M Michu ne regarde pas plus son certificat que son URL ;
du moment que la barre est verte (!) avec le petit cadenas, c'est bon,
il met son numéro de CB), mais plusieurs technologies s'occupent déjà
de cela, comme elles peuvent ; rajouter une autre technologie ne sert
réellement qu'à justifier le temps passé en réunion improductive.
On voit donc bien que ce genre de technologie n'apportera rien : le
problème est ailleurs ; à mon sens, il se situe au niveau des
registrars ; mais ça, ce n'est peut être pas politiquement correct de
l'annoncer ouvertement de leur part.
"Oh, mon dieu ! Mon nom de domaine à 5 euros a une mauvaise réputation
! Foutu DNS RPZ ! Je vais encore devoir en acheter un autre ! Ils
viennent de me faire perdre 1/10000 de mon chiffre d'affaire ! Trop
dur !" se diront les hameçonneurs, exactement comme les spammeurs le
disent depuis que le domain-tasting a été supprimé.
Une solution qui me parait viable serait tout simplement de renforcer
le contrôle identitaire à la délégation d'un nom de domaine (notez
l'emploi du terme délégation et non achat), par injonction de l'IANA
et consort auprès des TLD. Si une personne physique ne peut plus
enregistrer de nom de domaine pendant une période de X années après un
abus constaté et que l'ensemble de ses noms de domaines sont repris
par les registres en cas de faute, mathématiquement le nombre de
domaines malicieux va être appelé à descendre. Afin d'empêcher la
réservation massive (pour une campagne de spam, au hasard), la limite
serait également imposée sur la quantité de noms de domaines
réservables sur une période donnée.
On résoudrait par ailleurs en parti le problème du Spam, si l'on
forcait l'emploi des solutions anti-spoofing comme SPF (avec
limitation du nombre de cibles maximum) ou DKIM reposant toutes les
deux sur l'emploi de DNS.
Si je spam, on me reprend mes domaines et je ne peux plus en demander
d'autre => je ne peux plus spammer puisque je n'ai pas la possibilité
de configurer des records DNS et qu'ils sont indispensables à la
livraison de mes courriers.
Si les grands webmail (plouf plouf live, gmail, yahoo) se mettent à
appliquer ce genre de politique, on peut être sur de voir une adoption
assez rapide et radicale.
Bref, après cette digression sur le spam, et pour en revenir au sujet
initial, ai-je manqué une étape ? Quel est votre avis sur DNS RPZ ?
Cordialement,
Florian MAURY
Bonjour,
la plupart des membres de la liste qui utilise une adresse @{free,online}.fr, ont été automatiquement désactivé par rejet :
host mx1.free.fr[212.27.48.6] said: 550 spam detected
(in reply to end of DATA command)
Donc si vous voulez continuer à être membre, soit free m'explique ce que je fais de mal, soit ils trouvent une solution, soit les membres concernés changent leur adresse d'abonnement à la liste.
--
Greg
Hello la liste,
Je reprends un sujet d'une autre liste où celui-ci n'avait pas grand
chose à faire et que certain d'entre vous a déjà suivi avec plus ou
moins de passion.
Il est vrai que le suspens est au rendez-vous : Kimberley
apprendra-t-elle que Rodrigo a tué son père avant la fin de la saison ?
Le début de la discussion portait sur l'intérêt (ou pas) des soft et
appliances de filtrage de spams. Je cite:
>
> A titre d'information, utilisez-vous des appliances du type
> antispam/antivirus et si oui quel retour avez-vous au niveau :
>
> - efficacité,
>
> - fiabilité au niveau soft/hardware des boîtiers,
>
> - facilité d'usage pour l'utilisateur final,
>
> - flexibilité d'administration,
>
> - etc.
Après une malheureuse réponse sur le sujet, comportant le fatal nota
bene "l'open source peut le faire", le malheureux poseur de questions
n'aura pas droit à d'autres réponses à sa question.
Si _VOUS_ avez des réponses qui collent à la question, il serait
intéressant d'avoir vos retours d'expérience.
Sinon pour partir dans la philosophie, nombre de posts plus tard,
quelqu'un a donc dit :
> "C'est quoi le SPAM ?"
>
> Parce qu'on est arrive au point ou le spam c'est un e-mail qu'on a recu
> et qu'on aime pas => un spammeur = quelqu'un qui envoie beaucoup
> d'emails que beaucoup de gens aiment pas(*). Le bon-sens, l'opt-in (meme
> "confirme"), le concept de "relation contractuelle" ou les diverses
> "definitions" (UBE, UCE, ....) ne veulent quasiment plus rien dire.
Et quelqu'un d'autre a répondu :
> - si l'émetteur a acheté son fichier chez biduleProspect => spam
> - les mails medoc/montres/logiciels à prix cassé et autres => spam
> - les mails qui viennent d'une boite avec qui tu n'as pas de relation, que
> ce n'est pas quelqu'un que tu connais qui l'envoi et qui veut en plus te
> vendre des volets roulants => spam
> - les mails envoyés à des messages-id => spam
> - et j'en oublie...
> Dans 97% (à la louche) des cas, pas besoin de réfléchir plus d'1 seconde.
>
> Et par inférence les boites spécialisées (dont c'est le business) dans le
> routage de ces saloperies ou autres groupements du même acabit ben on les
> appelle des spammeurs.
Une définition largement répandue, et acceptée par la plupart des gros
receveurs, est que "le spam est ce que le destinataire considère étant
un spam".
Ca inclut tout un tas de trucs, notamment des messages pour lequel le
destinataire s'est bien abonné mais qu'il ne souhaite soudain plus
recevoir. Pour cette raison, les receveurs tolères un faible pourcentage
de plaintes pour spam par IP, domaine et/ou envoi (en fonction de leur
système) et ne requièrent pas le zéro absolu en matière de taux de plaintes.
Ca signifie aussi que, même si le message a été envoyé par un
utilisateur de escrocProspect, si le destinataire va chercher le message
en spambox pour le remettre en inbox, ça ne sera pas un spam.
Autrement dit, un même message peut être et ne pas être un spam, la
différence étant la personne qui le reçoit.
Le problème avec cette définition, c'est que l'on risque de considérer
que les "messages" pour le viagra ne sont pas toujours du spam,
puisqu'il y a des acheteurs.
Je pense donc que cette définition n'est utilisable que pour construire
des systèmes de filtrage par réputation (ou scoring des IP, ou scoring
des domaines, appelez-ça comme vous voulez), et que des exceptions
doivent forcément être faites : "ok, le type est venu chercher le
message en spambox, mais il vient quand même d'une IP dynamique, listée
dans 4 blacklists et contient des termes qui feraient rougir spamassassin".
Une autre définition elle celle de l'UBE: Unsolicited Bulk Email.
Là on ajoute une notion de quantité, et donc de "campagne".
Je n'ai pas trouvé d'exemple pour contredire cette définition, donc si
_vous_ avez de quoi l'écorner, n'hésitez pas.
Toutefois, celle-ci ne permet pas de répondre pas aux problèmes du
sysadmin qui doit épurer le trafic mail de son réseau : comment savoir
si 1) c'est un email (bon ça ça devrait aller) 2) si c'est envoyé en
masse* et 3) si il est attendu ou non**.
Si on avait la réponse à "comment savoir quand un mail est un spam", la
vie serait déjà beaucoup plus belle.
* Pour un gros receveur, ce n'est pas très compliqué, mais nous pensons
à tous les sysadmins, même ceux qui ne gèrent qu'un seul petit domaine.
Certains réseaux rendent publiques leurs statistiques (nombre de
messages reçu de tel bloc / telle IP / tel domaine), mais souvent a
posteriori, après que la campagne soit terminée
** des solutions comme celles d'Habeas permettent de certifier que le
destinataire s'est abonné au message (et de fait faciliter l'arrivée en
inbox). Ca n'est toutefois pas à la portée de toutes les bourses.
Merci à ceux qui ont lu jusqu'au bout, vous êtes mes plus grands fans.
--
Benjamin
Hello la liste,
suite à quelques déboires avec depmod qui a évolué entre Lenny et
Squeeze, je me demande si ma méthode de propagation des kernels sur les
VM est judicieuse. Il arrivera fatalement un moment où le Dom0 et le
DomU ne seront pas "compatibles".
De plus, si au passage je peux automatiser un peu plus ou améliorer le
process, c'est pas plus mal.
Le contexte : le kernel utilisé dans la VM est fourni par l'host, mais
il faut aussi propager les modules du kernel dans la VM.
Actuellement j'utilise un script sur le Dom0 qui coupe la VM, monte son
système en local, balance les dossiers de /lib/modules/, mets à jour la
version du kernel indiquée dans le fichier ".cfg" et enfin redémarre la
VM. Rudimentaire, mais fonctionnel.
Problèmes :
- le Dom0 doit donc avoir une version de /lib/modules/ compatible avec
ce qu'attend le DomU (d'où mon soucis Lenny/Squeeze)
- la mise à jour du kernel est donc déclenchée à l'initiative du Dom0...
donc pas d'autonomie de ce coté pour le client
Solution 1 : déplacer le kernel dans la VM. Cela implique l'utilisation
de pygrub (sécurité ?), et d'avoir un outil de propagation simple du
kernel sur chaque VM, si possible sans avoir à trop intervenir. On gagne
en souplesse, mais pour l'industrialisation c'est un peu rapé.
Solution 2 : compiler les modules en statique, et toujours utiliser le
même nom de kernel (ou faire pointer un lien symbolique). Ainsi à chaque
reboot la VM prend automatiquement la dernière version du kernel qu'on
lui propose. J'utilise déjà cette technique dans le cadre d'un projet
spécifique, mais manque de bol ici j'ai besoin de l'aspect modulaire de
mes kernels.
Solution 3 : déployer le kernel et ses modules dans 2 packets Debian
adéquat, à fournir pour toutes les distribs utilisées (y compris dérivés
Debian), ajouter le repository en question sur chaque VM, et
synchroniser comme il faut les mises à jour de paquet Dom0 & DomU...
C'est la solution utilisée par défaut avec ce que propose Debian, mais
ça ne me semble pas vraiment jouable ici.
Solution 4 : utiliser un lien symbolique pour pointer sur le dernier
kernel dans le fichier de conf Xen (cf solution 2), et utiliser un
système de fichier spécifique pour propager automatiquement mon dossier
/lib/modules/ dans la VM. NFS, ou une partition spécifique en read-only
commune à toutes les VM et à ajouter dans le fstab de chacune d'elles.
Ca me semble tordu comme montage, mais ormis l'aspect bricolage ça
semble répondre à tous mes problèmes.
Solution 5 : faire comme certains hébergeurs et ne mettre à jour le
kernel que tous les 5 ans. Un petit coucou en passant à mon hébergeur
préféré qui me fourni un joli 2.6.16 sur ses Xen ;)
Et vous, vous faites comment pour déployer vos kernels sur les VM ?
Ai-je loupé une solution plus simple / rapide / propre ?
Olivier B.
Bonjour,
Je fais du dev et m'occupe d'une petite infra (5 serveurs) web pour
des applis de ma boîte (environ 5000 visiteurs uniques/jour) hébergées
par notre hébergeur.
J'aimerais avoir votre retour d'expérience sur l'analyse des logs PHP.
Je cherche une solution qui :
- me permette d'être alertée des erreurs des scripts PHP
- des fréquences des différentes erreurs
- si possible avec la pile d'exécution (backtrace)
- si possible avec l'URL de la page incriminée
- si possible avec les variables de session, post, get, ...
L'objectif est d'être prévenu des problèmes survenant sur la prod et
de les transmettre aux dev (voire alimentation automatique du bug
tracker).
Nous utilisons pour le moment Zend_Platform qui propose ces
fonctionnalités. Nous sommes pleinement satisfaits de la partie
monitoring des erreurs PHP (possibilité d'être alertée par mail,
interface d'administration qui permet de visualiser la fréquence des
erreurs, ...) mais pas du packaging du produit.
Le produit est assez fermé. Les extensions sont celles de Zend. Les
hébergeurs connaissent mal le produit, nous avons parfois des
problèmes de stabilité du produit.
On est en train de migrer sur Zend_Server mais on rencontre les mêmes problèmes.
Vu le coût des solutions Zend, j'aimerais bien trouver une solution un
peu moins chère et un peu moins exotique (remplacement des extensions
de Zend par les extensions reconnues, type APC, xdebug,...).
J'ai regardé un peu du côté de Logwatch avec un agent PHP. Cela répond
à une partie du problème mais l'analyse des erreurs est moins fine
(pas l'url posant problème, pas la pile d'exécution - backtrace -,
...).
Il existe bien des alternatives Open Source comme Pinba
(www.pinba.org) ou APM (http://code.google.com/p/peclapm/) mais le
développement semble arrêté.
Et vous ? Quelle solution avez-vous mis en place pour monitorer PHP ?
Je suis curieux de savoir comment est traité cette question sur de
grosses plate-formes genre site de médias, facebook, ... ?
Je vous remercie pour vos retours.
Bonne journée,
frantishrek
