depuis qques temps, nous avons remarqué que pas mal de mails envoyés
depuis notre dédié OVH n'etaient pas reçus par les destinataires.
Aucun message d'erreurs en retour, les mails se perdent dans la 4eme
dimmension... Impossible de savoir ce qu'il se passe. Curieusement,
quand nous envoyons certains message avec le smtp de wanadoo ils
passent, par contre avec celui de notre dédié, ils ne passent plus.
Comme d'hab chez OVH, ils repondent aux questions par.... des
questions !! c'est le sport national...
je m'en remet donc a vous :o)
si quelqu'un a un probleme similaire ou mieux, une solution ! il sera
le bienvenu !!
notre dédié est un cobalt, et conformément à la doc de SUN, nous évitons de déclarer les MX pour nos domaines. En effet, SUN fait remarquer que creer un MX pour les domaines sur la machine ne fait que rajouter une boucle de traitement supplémentaire. EN fait, pour chaque "A record" créé, l'OS SUN met a disposition le MX par défaut configuré pour le SMTP de la machine, la création d'un MX n'est donc nécessaire que lorsque l'on souhaite externaliser le service mail, pour le router sur une autre IP. Je ne pense pas que le pb de relaying de wanadoo provienne du MX ou non, dans la mesure ou c'est totalement aléatoire (une fois les mails passent une fois ils ne passent pas) Je pencherai plutot pour un filtrage, aleatoire, de la part de wanadoo sur certaines IP.. cette hypothese vous semble t elle crédible ? Dans ce cas, y a t il qques petitions en ligne que l'on pourrait signer contre ces abus ??
Merci
may the smtp be with you (c;
Certains serveurs de courrier n'acceptent pas les messages provenant de serveurs émetteurs non identifiés/identifiables/considérés comme appartenant à des plages d'IP réservées aux particuliers.
C'est très bête, mais de nombreux FAI/FSI ont adopté cette (mauvaise) solution pour se prémunir contre le spam.
si quelqu'un a un probleme similaire ou mieux, une solution ! il sera le bienvenu !!
Donner le nom de votre serveur SMTP aiderait probablement à comprendre... S'il n'en a pas/et ou n'a pas de MX, je pense que vous avez trouvé la réponse à votre question...
PS: c'est quand même bizarre que vous ne receviez pas de messages d'erreurs (avis de non distribution, etc.)
Bjr
notre dédié est un cobalt, et conformément à la doc de SUN, nous
évitons de déclarer les MX pour nos domaines. En effet, SUN fait
remarquer que creer un MX pour les domaines sur la machine ne fait que
rajouter une boucle de traitement supplémentaire. EN fait, pour chaque
"A record" créé, l'OS SUN met a disposition le MX par défaut configuré
pour le SMTP de la machine, la création d'un MX n'est donc nécessaire
que lorsque l'on souhaite externaliser le service mail, pour le router
sur une autre IP.
Je ne pense pas que le pb de relaying de wanadoo provienne du MX ou
non, dans la mesure ou c'est totalement aléatoire (une fois les mails
passent une fois ils ne passent pas)
Je pencherai plutot pour un filtrage, aleatoire, de la part de wanadoo
sur certaines IP.. cette hypothese vous semble t elle crédible ? Dans
ce cas, y a t il qques petitions en ligne que l'on pourrait signer
contre ces abus ??
Merci
may the smtp be with you (c;
Certains serveurs de courrier n'acceptent pas les messages provenant de
serveurs émetteurs non identifiés/identifiables/considérés comme
appartenant à des plages d'IP réservées aux particuliers.
C'est très bête, mais de nombreux FAI/FSI ont adopté cette (mauvaise)
solution pour se prémunir contre le spam.
si quelqu'un a un probleme similaire ou mieux, une solution ! il sera
le bienvenu !!
Donner le nom de votre serveur SMTP aiderait probablement à
comprendre... S'il n'en a pas/et ou n'a pas de MX, je pense que vous
avez trouvé la réponse à votre question...
PS: c'est quand même bizarre que vous ne receviez pas de messages
d'erreurs (avis de non distribution, etc.)
notre dédié est un cobalt, et conformément à la doc de SUN, nous évitons de déclarer les MX pour nos domaines. En effet, SUN fait remarquer que creer un MX pour les domaines sur la machine ne fait que rajouter une boucle de traitement supplémentaire. EN fait, pour chaque "A record" créé, l'OS SUN met a disposition le MX par défaut configuré pour le SMTP de la machine, la création d'un MX n'est donc nécessaire que lorsque l'on souhaite externaliser le service mail, pour le router sur une autre IP. Je ne pense pas que le pb de relaying de wanadoo provienne du MX ou non, dans la mesure ou c'est totalement aléatoire (une fois les mails passent une fois ils ne passent pas) Je pencherai plutot pour un filtrage, aleatoire, de la part de wanadoo sur certaines IP.. cette hypothese vous semble t elle crédible ? Dans ce cas, y a t il qques petitions en ligne que l'on pourrait signer contre ces abus ??
Merci
may the smtp be with you (c;
Certains serveurs de courrier n'acceptent pas les messages provenant de serveurs émetteurs non identifiés/identifiables/considérés comme appartenant à des plages d'IP réservées aux particuliers.
C'est très bête, mais de nombreux FAI/FSI ont adopté cette (mauvaise) solution pour se prémunir contre le spam.
si quelqu'un a un probleme similaire ou mieux, une solution ! il sera le bienvenu !!
Donner le nom de votre serveur SMTP aiderait probablement à comprendre... S'il n'en a pas/et ou n'a pas de MX, je pense que vous avez trouvé la réponse à votre question...
PS: c'est quand même bizarre que vous ne receviez pas de messages d'erreurs (avis de non distribution, etc.)
Un prestataire d'accès, de services et/ou d'hébergement Internet n'est pas sensé filtrer de façon autoritaire quelque courrier que ce soit adressé à ses clients s'il y a le moindre risque de faux positif.
Alors, autant ne rien filtrer et laisser pourrir.
J'ai bien écrit « s'il y a le moindre risque de faux positif », hein.
Imaginons d'autres solutions alors : lorsque le client signe un contrat avec son prestataire, le contrat stipule que par défaut les courriers jugés dangereux (spam, virus, si possible en faisant la distinction) ne seront pas distribués, sauf si le client en fait expressément la demande.
En cas de péril imminnent, le plus urgent est de faire des cahiers des charges, des réunions et des comptes rendus ?
Il est clair qu'en cas de péril (et là on parle de virus virulent et plus de spam à mon sens), il me paraît légitime, dans la mesure ou on sait que l'antivirus repérera sans risque d'erreur Swen ou MyDoom pour citer deux exemples à la mode, de les virer directement.
Je dirais même plus, et ça a été un facteur de dispute avec mes collègues techniciens lors de l'apparition de Swen, je suis favorable [*] à ce que, quand des centaines de milliers de messages pourris d'une taille avoisinant les 150 ko déferlent sur les serveurs, saturent les boîtes aux lettres et saturent la bande passante, les serveurs les poubellisent plutôt que de les bouncer, et tant pis pour les 0,01% de faux positifs, car il en va de la survie du réseau.
[*] En fait j'y suis devenu tout à coup favorable quand j'ai vu, quelques heures après le début du bombardement de Swenn, le smtp de Wanadoo me répondre, juste avant de disparaître du réseau « can't deliver message, queue overflow ».
Un prestataire d'accès, de services et/ou d'hébergement Internet n'est
pas sensé filtrer de façon autoritaire quelque courrier que ce soit
adressé à ses clients s'il y a le moindre risque de faux positif.
Alors, autant ne rien filtrer et laisser pourrir.
J'ai bien écrit « s'il y a le moindre risque de faux positif », hein.
Imaginons d'autres solutions alors : lorsque le client signe un contrat
avec son prestataire, le contrat stipule que par défaut les courriers
jugés dangereux (spam, virus, si possible en faisant la distinction) ne
seront pas distribués, sauf si le client en fait expressément la
demande.
En cas de péril imminnent, le plus urgent est de faire des cahiers des
charges, des réunions et des comptes rendus ?
Il est clair qu'en cas de péril (et là on parle de virus virulent et
plus de spam à mon sens), il me paraît légitime, dans la mesure ou on
sait que l'antivirus repérera sans risque d'erreur Swen ou MyDoom pour
citer deux exemples à la mode, de les virer directement.
Je dirais même plus, et ça a été un facteur de dispute avec mes
collègues techniciens lors de l'apparition de Swen, je suis favorable
[*] à ce que, quand des centaines de milliers de messages pourris d'une
taille avoisinant les 150 ko déferlent sur les serveurs, saturent les
boîtes aux lettres et saturent la bande passante, les serveurs les
poubellisent plutôt que de les bouncer, et tant pis pour les 0,01% de
faux positifs, car il en va de la survie du réseau.
[*] En fait j'y suis devenu tout à coup favorable quand j'ai vu,
quelques heures après le début du bombardement de Swenn, le
smtp de Wanadoo me répondre, juste avant de disparaître du
réseau « can't deliver message, queue overflow ».
Un prestataire d'accès, de services et/ou d'hébergement Internet n'est pas sensé filtrer de façon autoritaire quelque courrier que ce soit adressé à ses clients s'il y a le moindre risque de faux positif.
Alors, autant ne rien filtrer et laisser pourrir.
J'ai bien écrit « s'il y a le moindre risque de faux positif », hein.
Imaginons d'autres solutions alors : lorsque le client signe un contrat avec son prestataire, le contrat stipule que par défaut les courriers jugés dangereux (spam, virus, si possible en faisant la distinction) ne seront pas distribués, sauf si le client en fait expressément la demande.
En cas de péril imminnent, le plus urgent est de faire des cahiers des charges, des réunions et des comptes rendus ?
Il est clair qu'en cas de péril (et là on parle de virus virulent et plus de spam à mon sens), il me paraît légitime, dans la mesure ou on sait que l'antivirus repérera sans risque d'erreur Swen ou MyDoom pour citer deux exemples à la mode, de les virer directement.
Je dirais même plus, et ça a été un facteur de dispute avec mes collègues techniciens lors de l'apparition de Swen, je suis favorable [*] à ce que, quand des centaines de milliers de messages pourris d'une taille avoisinant les 150 ko déferlent sur les serveurs, saturent les boîtes aux lettres et saturent la bande passante, les serveurs les poubellisent plutôt que de les bouncer, et tant pis pour les 0,01% de faux positifs, car il en va de la survie du réseau.
[*] En fait j'y suis devenu tout à coup favorable quand j'ai vu, quelques heures après le début du bombardement de Swenn, le smtp de Wanadoo me répondre, juste avant de disparaître du réseau « can't deliver message, queue overflow ».
-- Eric Demeester - http://www.galacsys.net
Eric Demeester
dans (in) fr.reseaux.internet.hebergement, Vincent <Vincent+ ecrivait (wrote) :
Bonsoir Vincent,
C'est d'autant plus vrai que certains hébergeurs ne fournissent pas de SMTP sortant
On ne parle pas exactement de la même chose :)
ex AMEN pack web pro : ("serveur de courrier sortant (smtp) : celui de votre fournisseur d'accès. (ex : smtp.wanadoo.fr)
Comment on fait dans ce cas pour écrire avec son adresse ?
From: smtp: smtp.wanadoo.fr
On peut normalement indiquer ce qu'on veut dans le From: , puisqu'il s'agit d'un champ d'en-tête purement informatif (i.e. n'ayant aucune influence dans les transactions entre serveurs et la propagation des messages).
Je ne comprends d'ailleurs pas comment OVH arrive à proposer un SMTP sortant sur une offre à 1,2 euros/an
Proposer un SMTP sortant accessible depuis n'importe où via identifiant/mot de passe est à la portée de tous les prestataires connaissant les RFC.
Un plus est de proposer ce service sur un autre port que le port 25, pour contourner les paramétrages mal pensés de certains (exemple, Noos).
-- Eric Demeester - http://www.galacsys.net
dans (in) fr.reseaux.internet.hebergement, Vincent
<Vincent+news@domain.invalid> ecrivait (wrote) :
Bonsoir Vincent,
C'est d'autant plus vrai que certains hébergeurs ne fournissent
pas de SMTP sortant
On ne parle pas exactement de la même chose :)
ex AMEN pack web pro : ("serveur de courrier sortant (smtp) :
celui de votre fournisseur d'accès. (ex : smtp.wanadoo.fr)
Comment on fait dans ce cas pour écrire avec son adresse nom@domaine ?
From: nom@domaine
smtp: smtp.wanadoo.fr
On peut normalement indiquer ce qu'on veut dans le From: , puisqu'il
s'agit d'un champ d'en-tête purement informatif (i.e. n'ayant aucune
influence dans les transactions entre serveurs et la propagation des
messages).
Je ne comprends d'ailleurs pas comment OVH arrive à proposer
un SMTP sortant sur une offre à 1,2 euros/an
Proposer un SMTP sortant accessible depuis n'importe où via
identifiant/mot de passe est à la portée de tous les prestataires
connaissant les RFC.
Un plus est de proposer ce service sur un autre port que le port 25,
pour contourner les paramétrages mal pensés de certains (exemple, Noos).
dans (in) fr.reseaux.internet.hebergement, Vincent <Vincent+ ecrivait (wrote) :
Bonsoir Vincent,
C'est d'autant plus vrai que certains hébergeurs ne fournissent pas de SMTP sortant
On ne parle pas exactement de la même chose :)
ex AMEN pack web pro : ("serveur de courrier sortant (smtp) : celui de votre fournisseur d'accès. (ex : smtp.wanadoo.fr)
Comment on fait dans ce cas pour écrire avec son adresse ?
From: smtp: smtp.wanadoo.fr
On peut normalement indiquer ce qu'on veut dans le From: , puisqu'il s'agit d'un champ d'en-tête purement informatif (i.e. n'ayant aucune influence dans les transactions entre serveurs et la propagation des messages).
Je ne comprends d'ailleurs pas comment OVH arrive à proposer un SMTP sortant sur une offre à 1,2 euros/an
Proposer un SMTP sortant accessible depuis n'importe où via identifiant/mot de passe est à la portée de tous les prestataires connaissant les RFC.
Un plus est de proposer ce service sur un autre port que le port 25, pour contourner les paramétrages mal pensés de certains (exemple, Noos).
-- Eric Demeester - http://www.galacsys.net
Téraï Pso
dans (in) fr.reseaux.internet.hebergement, Téraï Pso ecrivait (wrote) :
Bonjour,
C'est très bête, mais de nombreux FAI/FSI ont adopté cette (mauvaise) solution pour se prémunir contre le spam.
cette mauvaise solution comme tu dit a le mérite de bloquer les virus en même temps que les merdes et si les gens respectaient les standarts ils n'y aurai pas de problemes.
Elle bloque aussi énormément de trafic légitime, et est trop souvent mal paramétrée. Elle interdit par exemple à certaines personnes d'avoir leur propre SMTP, même s'il est sur une IP fixe, même s'il ne sert pas de relais ouvert, même si les MX correpondant sont bien renseignés.
chez moi ca bloque 0% de traffic légitime. et pour parer au probleme ip fixe j'ai ma propre liste que je construit au fur et a mesure des spam que je reçois.
C'est une solution de gribouille, à peu près aussi intelligente que de bloquer les courriers dont le sujet est « HI » ou « test » pour se protéger du virus MyDoom.
il n'y a que ceux qui ne font rien qui ne se trompent jamais.
-- The Téraï Sushiiiii.
dans (in) fr.reseaux.internet.hebergement, Téraï Pso
<teraii@nospam.olympus-zone.net.invalid> ecrivait (wrote) :
Bonjour,
C'est très bête, mais de nombreux FAI/FSI ont adopté cette (mauvaise)
solution pour se prémunir contre le spam.
cette mauvaise solution comme tu dit a le mérite de bloquer les virus en
même temps que les merdes et si les gens respectaient les standarts ils
n'y aurai pas de problemes.
Elle bloque aussi énormément de trafic légitime, et est trop souvent mal
paramétrée. Elle interdit par exemple à certaines personnes d'avoir leur
propre SMTP, même s'il est sur une IP fixe, même s'il ne sert pas de
relais ouvert, même si les MX correpondant sont bien renseignés.
chez moi ca bloque 0% de traffic légitime.
et pour parer au probleme ip fixe j'ai ma propre liste que je construit
au fur et a mesure des spam que je reçois.
C'est une solution de gribouille, à peu près aussi intelligente que de
bloquer les courriers dont le sujet est « HI » ou « test » pour se
protéger du virus MyDoom.
il n'y a que ceux qui ne font rien qui ne se trompent jamais.
dans (in) fr.reseaux.internet.hebergement, Téraï Pso ecrivait (wrote) :
Bonjour,
C'est très bête, mais de nombreux FAI/FSI ont adopté cette (mauvaise) solution pour se prémunir contre le spam.
cette mauvaise solution comme tu dit a le mérite de bloquer les virus en même temps que les merdes et si les gens respectaient les standarts ils n'y aurai pas de problemes.
Elle bloque aussi énormément de trafic légitime, et est trop souvent mal paramétrée. Elle interdit par exemple à certaines personnes d'avoir leur propre SMTP, même s'il est sur une IP fixe, même s'il ne sert pas de relais ouvert, même si les MX correpondant sont bien renseignés.
chez moi ca bloque 0% de traffic légitime. et pour parer au probleme ip fixe j'ai ma propre liste que je construit au fur et a mesure des spam que je reçois.
C'est une solution de gribouille, à peu près aussi intelligente que de bloquer les courriers dont le sujet est « HI » ou « test » pour se protéger du virus MyDoom.
il n'y a que ceux qui ne font rien qui ne se trompent jamais.
