"jbongran" a écrit dans le message de news:JG wrote:"JG" a écrit dans le message de news:
etqr6t$4n7$
[...]Hello
J'ai réussi à tout refaire fonctionner, la config paraît ok. (en
fait le domaine sans les www avait "disparu" de la config des DNS,
donc mon serveur de mail était introuvable...)
Mais les mails pour AOL n'arrivent toujours pas !
J'ai donc configuré un smart host. Le problème c'est que désormais,
je ne reçois plus aucun mail de retour! Donc je ne sais même pas si
les mails arrivent à destination !
Pourtant dans mon PHP, je configure bien le reply-to et le
return-path correctement...
Ah d'accord, c'est depuis un code php que les envois de mails vers
AOL ne fonctionnent pas!
Je me souvient qu'une des possibilités était liée au format du body,
de retours lignes manquants ou en trop, je ne sais plus.
En tout état de cause, il FAUT faire le test en telnet depuis ton
serveur IIS vers celui d'AOL afin de voir la réponse exacte du
serveur AOL. Puis le test en telnet depuis ton IIS vers ton SMTP
IIS, puis consulter les logs smtp afin de voir la transaction vers
AOL. Enfin, il peut être interessant de configurer ton outlook pour
utiliser le smtp de ton IIS et voir ce qui se passe, toujours dans
les logs de ton smtp IIS. Si l'anglais ne te rebute pas, ce site AOL de
résolution d'incident
lié aux mails est intéressant.
http://postmaster.info.aol.com/
Puisque tu as ta zone DNS sur Gandi, il serait judicieux d'ajouter un
enregistrement (Text) SPF. Tu trouvera toute l'info nécessaire,
ainsi qu'un assistant pour te creer cet enregistrement ici
www.openspf.org
Enfin, il faut être sûr à 100% (et avec AOL des fois c'est pas assez
!) que ton mx pointe sur un aname, que ce aname retourne bien une
IP, et que cette ip retourne bien le aname. Il faut aussi être sûr
que ton IP publique ne soit pas déclarée par ton FAI comme étant
dynamique. Un des sites permettant de voir le status de ton IP publique:
http://www.mail-abuse.com/cgi-bin/lookup
Hello
Oui, j'envoies avec PHP. Effectivement, je ne mets
"traditionnellement" pas de retour de ligne après la balise </HTML>
(j'envoies au format HTML, car sinon ça ne passe pas... chez FREE !
prise de tête...) J'essairai avec un retour de ligne...
Pour la connexion sur le serveur d'AOL, je ne comprends pas.
S'agit-il d'une connexion en telnet sur smtp.aol.com sur le port 25 ?
Si c'est le cas, c'est comme si je voulais envoyer un courrier à
partir du serveur d'AOL, mais ce n'est pas ce que je veux faire. (En
plus, j'ai essayé, mais il me demande une authenfication, donc
impossible)
Concernant l'envoi d'un mail en me connectant à mon serveur smtp
depuis mon serveur IIS, ca a l'air d'avoir fonctionné, mais j'attends
d'avoir éventuellement une confirmation de la personne à qui j'ai
envoyé un mail. J'ai tout de même regardé dans les logs SMTP, et je
me suis aperçu qu'il y a des connexions bizarres à mon serveur, de la
part d'IP inconnues, dont celle ci:
205.188.157.217. En faisant une recherche sur cette IP, j'ai lu ici:
http://discussion.dreamhost.com/showflat.pl?Board=forum_troubleshooting&NumberB403
qu'il faut avoir une adresse qui doit être
configurée, ce qui n'est pas mon cas. Donc je rajoute ceci à la liste
des choses à faire!
Merci pour le lien http://postmaster.info.aol.com . Malheuseuement je
n'ai pas trouvé d'information sur mon problème.
L'enregistrement SPF, c'est fait depuis avant-hier. J'ai vu que
j'avais un warning sur mon domaine à ce sujet sur dnsstuff, donc j'ai
corrigé, en suivant le lien openspf.
Concernant le mx qui pointe sur un aname etc... Je suis pas bien sûr
d'avoir tout saisi. Sur dnsstuff, je rentre mon nom de domaine dans
DNS Lookup, en choisissant MX. Cela me renvoit le nom de mon serveur
***.ikexpress.com Mais ce nom n'étant pas enregistré dans ma zone
DNS, un DNS Report de ***.ikexpress.com ne renvoit aucun résultat.
Cela est-il le problème ? Dans ce cas, ai-je interet à configurer le
reverse DNS de mon serveur
en mettant mon nom de domaine, ou plutôt à ajouter ***.ikexpress.com
dans ma zone DNS ?
Dernier point, le test sur mail-abuse est ok, puisqu'il ne trouve pas
l'IP publique de mon serveur dans sa base.
Merci encore une fois pour tous ces renseignements !
"jbongran" <jbongran@free.fr> a écrit dans le message de news:
eI507ZebHHA.2448@TK2MSFTNGP02.phx.gbl...
JG wrote:
"JG" <jgg@libertysurf.fr> a écrit dans le message de news:
etqr6t$4n7$1@news.tiscali.fr...
[...]
Hello
J'ai réussi à tout refaire fonctionner, la config paraît ok. (en
fait le domaine sans les www avait "disparu" de la config des DNS,
donc mon serveur de mail était introuvable...)
Mais les mails pour AOL n'arrivent toujours pas !
J'ai donc configuré un smart host. Le problème c'est que désormais,
je ne reçois plus aucun mail de retour! Donc je ne sais même pas si
les mails arrivent à destination !
Pourtant dans mon PHP, je configure bien le reply-to et le
return-path correctement...
Ah d'accord, c'est depuis un code php que les envois de mails vers
AOL ne fonctionnent pas!
Je me souvient qu'une des possibilités était liée au format du body,
de retours lignes manquants ou en trop, je ne sais plus.
En tout état de cause, il FAUT faire le test en telnet depuis ton
serveur IIS vers celui d'AOL afin de voir la réponse exacte du
serveur AOL. Puis le test en telnet depuis ton IIS vers ton SMTP
IIS, puis consulter les logs smtp afin de voir la transaction vers
AOL. Enfin, il peut être interessant de configurer ton outlook pour
utiliser le smtp de ton IIS et voir ce qui se passe, toujours dans
les logs de ton smtp IIS. Si l'anglais ne te rebute pas, ce site AOL de
résolution d'incident
lié aux mails est intéressant.
http://postmaster.info.aol.com/
Puisque tu as ta zone DNS sur Gandi, il serait judicieux d'ajouter un
enregistrement (Text) SPF. Tu trouvera toute l'info nécessaire,
ainsi qu'un assistant pour te creer cet enregistrement ici
www.openspf.org
Enfin, il faut être sûr à 100% (et avec AOL des fois c'est pas assez
!) que ton mx pointe sur un aname, que ce aname retourne bien une
IP, et que cette ip retourne bien le aname. Il faut aussi être sûr
que ton IP publique ne soit pas déclarée par ton FAI comme étant
dynamique. Un des sites permettant de voir le status de ton IP publique:
http://www.mail-abuse.com/cgi-bin/lookup
Hello
Oui, j'envoies avec PHP. Effectivement, je ne mets
"traditionnellement" pas de retour de ligne après la balise </HTML>
(j'envoies au format HTML, car sinon ça ne passe pas... chez FREE !
prise de tête...) J'essairai avec un retour de ligne...
Pour la connexion sur le serveur d'AOL, je ne comprends pas.
S'agit-il d'une connexion en telnet sur smtp.aol.com sur le port 25 ?
Si c'est le cas, c'est comme si je voulais envoyer un courrier à
partir du serveur d'AOL, mais ce n'est pas ce que je veux faire. (En
plus, j'ai essayé, mais il me demande une authenfication, donc
impossible)
Concernant l'envoi d'un mail en me connectant à mon serveur smtp
depuis mon serveur IIS, ca a l'air d'avoir fonctionné, mais j'attends
d'avoir éventuellement une confirmation de la personne à qui j'ai
envoyé un mail. J'ai tout de même regardé dans les logs SMTP, et je
me suis aperçu qu'il y a des connexions bizarres à mon serveur, de la
part d'IP inconnues, dont celle ci:
205.188.157.217. En faisant une recherche sur cette IP, j'ai lu ici:
http://discussion.dreamhost.com/showflat.pl?Board=forum_troubleshooting&NumberB403
qu'il faut avoir une adresse postmaster@domaine qui doit être
configurée, ce qui n'est pas mon cas. Donc je rajoute ceci à la liste
des choses à faire!
Merci pour le lien http://postmaster.info.aol.com . Malheuseuement je
n'ai pas trouvé d'information sur mon problème.
L'enregistrement SPF, c'est fait depuis avant-hier. J'ai vu que
j'avais un warning sur mon domaine à ce sujet sur dnsstuff, donc j'ai
corrigé, en suivant le lien openspf.
Concernant le mx qui pointe sur un aname etc... Je suis pas bien sûr
d'avoir tout saisi. Sur dnsstuff, je rentre mon nom de domaine dans
DNS Lookup, en choisissant MX. Cela me renvoit le nom de mon serveur
***.ikexpress.com Mais ce nom n'étant pas enregistré dans ma zone
DNS, un DNS Report de ***.ikexpress.com ne renvoit aucun résultat.
Cela est-il le problème ? Dans ce cas, ai-je interet à configurer le
reverse DNS de mon serveur
en mettant mon nom de domaine, ou plutôt à ajouter ***.ikexpress.com
dans ma zone DNS ?
Dernier point, le test sur mail-abuse est ok, puisqu'il ne trouve pas
l'IP publique de mon serveur dans sa base.
Merci encore une fois pour tous ces renseignements !
"jbongran" a écrit dans le message de news:JG wrote:"JG" a écrit dans le message de news:
etqr6t$4n7$
[...]Hello
J'ai réussi à tout refaire fonctionner, la config paraît ok. (en
fait le domaine sans les www avait "disparu" de la config des DNS,
donc mon serveur de mail était introuvable...)
Mais les mails pour AOL n'arrivent toujours pas !
J'ai donc configuré un smart host. Le problème c'est que désormais,
je ne reçois plus aucun mail de retour! Donc je ne sais même pas si
les mails arrivent à destination !
Pourtant dans mon PHP, je configure bien le reply-to et le
return-path correctement...
Ah d'accord, c'est depuis un code php que les envois de mails vers
AOL ne fonctionnent pas!
Je me souvient qu'une des possibilités était liée au format du body,
de retours lignes manquants ou en trop, je ne sais plus.
En tout état de cause, il FAUT faire le test en telnet depuis ton
serveur IIS vers celui d'AOL afin de voir la réponse exacte du
serveur AOL. Puis le test en telnet depuis ton IIS vers ton SMTP
IIS, puis consulter les logs smtp afin de voir la transaction vers
AOL. Enfin, il peut être interessant de configurer ton outlook pour
utiliser le smtp de ton IIS et voir ce qui se passe, toujours dans
les logs de ton smtp IIS. Si l'anglais ne te rebute pas, ce site AOL de
résolution d'incident
lié aux mails est intéressant.
http://postmaster.info.aol.com/
Puisque tu as ta zone DNS sur Gandi, il serait judicieux d'ajouter un
enregistrement (Text) SPF. Tu trouvera toute l'info nécessaire,
ainsi qu'un assistant pour te creer cet enregistrement ici
www.openspf.org
Enfin, il faut être sûr à 100% (et avec AOL des fois c'est pas assez
!) que ton mx pointe sur un aname, que ce aname retourne bien une
IP, et que cette ip retourne bien le aname. Il faut aussi être sûr
que ton IP publique ne soit pas déclarée par ton FAI comme étant
dynamique. Un des sites permettant de voir le status de ton IP publique:
http://www.mail-abuse.com/cgi-bin/lookup
Hello
Oui, j'envoies avec PHP. Effectivement, je ne mets
"traditionnellement" pas de retour de ligne après la balise </HTML>
(j'envoies au format HTML, car sinon ça ne passe pas... chez FREE !
prise de tête...) J'essairai avec un retour de ligne...
Pour la connexion sur le serveur d'AOL, je ne comprends pas.
S'agit-il d'une connexion en telnet sur smtp.aol.com sur le port 25 ?
Si c'est le cas, c'est comme si je voulais envoyer un courrier à
partir du serveur d'AOL, mais ce n'est pas ce que je veux faire. (En
plus, j'ai essayé, mais il me demande une authenfication, donc
impossible)
Concernant l'envoi d'un mail en me connectant à mon serveur smtp
depuis mon serveur IIS, ca a l'air d'avoir fonctionné, mais j'attends
d'avoir éventuellement une confirmation de la personne à qui j'ai
envoyé un mail. J'ai tout de même regardé dans les logs SMTP, et je
me suis aperçu qu'il y a des connexions bizarres à mon serveur, de la
part d'IP inconnues, dont celle ci:
205.188.157.217. En faisant une recherche sur cette IP, j'ai lu ici:
http://discussion.dreamhost.com/showflat.pl?Board=forum_troubleshooting&NumberB403
qu'il faut avoir une adresse qui doit être
configurée, ce qui n'est pas mon cas. Donc je rajoute ceci à la liste
des choses à faire!
Merci pour le lien http://postmaster.info.aol.com . Malheuseuement je
n'ai pas trouvé d'information sur mon problème.
L'enregistrement SPF, c'est fait depuis avant-hier. J'ai vu que
j'avais un warning sur mon domaine à ce sujet sur dnsstuff, donc j'ai
corrigé, en suivant le lien openspf.
Concernant le mx qui pointe sur un aname etc... Je suis pas bien sûr
d'avoir tout saisi. Sur dnsstuff, je rentre mon nom de domaine dans
DNS Lookup, en choisissant MX. Cela me renvoit le nom de mon serveur
***.ikexpress.com Mais ce nom n'étant pas enregistré dans ma zone
DNS, un DNS Report de ***.ikexpress.com ne renvoit aucun résultat.
Cela est-il le problème ? Dans ce cas, ai-je interet à configurer le
reverse DNS de mon serveur
en mettant mon nom de domaine, ou plutôt à ajouter ***.ikexpress.com
dans ma zone DNS ?
Dernier point, le test sur mail-abuse est ok, puisqu'il ne trouve pas
l'IP publique de mon serveur dans sa base.
Merci encore une fois pour tous ces renseignements !
> Ps de souci, nous sommes en train de faire le thread le plus long du
groupe ;-)
Pour l'envoi par telnet sur le port 25, tu n'a pas bien lu la manip donné:
avec nslookup il te faut demander les mx d'aol.com (set type=mx)
Cela te retournera des nom d'hôtes de la forme mailin-xx.mx.aol.com (ou xx
va de 01 a 04)
Donc c'est logique que smtp.aol.com te demande une authentification, ce
doit être les serveurs sortants pour les abonnés aol.
Pour la conformité avec les RFC (les "règles") smtp, oui, l'adresse
postmaster, l'adresse abuse sont obligatoires.
Pour info, normalement on devrait aussi accepter les mails pour
, mais je n'ai jamais réussi à faire faire ça au smtp de
IIS ;-(
Pour le mx, il faut faire le test du DOMAINE, pas seulement celui du mx du
domaine.
dans nslookup (les commandes à taper sont en majuscules, mais je ne te
crie pas dessus, et tu les tapera en minuscules):
SET TYPE=MX
TONDOMAINE.TLD
=> retourne le mx de la forme tondomaine.tld MX preference = 5, mail
exchanger = nom_d_hote.tondomaine.tld
=> retourne en dessous l'adresse IP correspondant a nom_d_hote sous la
forme nom_d_hote.tondomaine.tld internet address = 123.123.123.123
SET TYPE=PTR
123.234.345.456
=> doit retourner une ligne de la forme 456.345.234.123.in-addr.arpa name
= nom_d_hote.tondomaine.tld
=> il s'agit du reverse adresse
En fait, pour dire les chose autrement:
Dans ta zone, tu a un enregistrement de type MX pointant sur un nom
d'hote. Ce nom d'hote n'a pas besoin d'etre dans ta zone. En revanche ce
nom d'hote doit pointer vers ton adresse IP publique. Et ton adresse ip
publique doit retourner le nom d'hote indiqué dans le mx.
Bien sûr si tu bouge ton MX, la plupart du temps il te faut aussi modifier
le spf.
Concernant les logs smtp, il faut surtout regarder que tu ne soit pas un
open relay, c'est à dire un serveur de mail accessible depuis internet et
autorisant 'tout le monde' à se connecter et a envoyer des mails pour un
domaine qui n'est pas un de ceux pour lesquels ton serveur reçoit des
mails.
Ps: dans la mesure où cela ne te pose pas de souci, peut être qu'en
indiquant ton nom de domaine, ce serait plus simple ?
> Ps de souci, nous sommes en train de faire le thread le plus long du
groupe ;-)
Pour l'envoi par telnet sur le port 25, tu n'a pas bien lu la manip donné:
avec nslookup il te faut demander les mx d'aol.com (set type=mx)
Cela te retournera des nom d'hôtes de la forme mailin-xx.mx.aol.com (ou xx
va de 01 a 04)
Donc c'est logique que smtp.aol.com te demande une authentification, ce
doit être les serveurs sortants pour les abonnés aol.
Pour la conformité avec les RFC (les "règles") smtp, oui, l'adresse
postmaster, l'adresse abuse sont obligatoires.
Pour info, normalement on devrait aussi accepter les mails pour
user@adresse_ip , mais je n'ai jamais réussi à faire faire ça au smtp de
IIS ;-(
Pour le mx, il faut faire le test du DOMAINE, pas seulement celui du mx du
domaine.
dans nslookup (les commandes à taper sont en majuscules, mais je ne te
crie pas dessus, et tu les tapera en minuscules):
SET TYPE=MX
TONDOMAINE.TLD
=> retourne le mx de la forme tondomaine.tld MX preference = 5, mail
exchanger = nom_d_hote.tondomaine.tld
=> retourne en dessous l'adresse IP correspondant a nom_d_hote sous la
forme nom_d_hote.tondomaine.tld internet address = 123.123.123.123
SET TYPE=PTR
123.234.345.456
=> doit retourner une ligne de la forme 456.345.234.123.in-addr.arpa name
= nom_d_hote.tondomaine.tld
=> il s'agit du reverse adresse
En fait, pour dire les chose autrement:
Dans ta zone, tu a un enregistrement de type MX pointant sur un nom
d'hote. Ce nom d'hote n'a pas besoin d'etre dans ta zone. En revanche ce
nom d'hote doit pointer vers ton adresse IP publique. Et ton adresse ip
publique doit retourner le nom d'hote indiqué dans le mx.
Bien sûr si tu bouge ton MX, la plupart du temps il te faut aussi modifier
le spf.
Concernant les logs smtp, il faut surtout regarder que tu ne soit pas un
open relay, c'est à dire un serveur de mail accessible depuis internet et
autorisant 'tout le monde' à se connecter et a envoyer des mails pour un
domaine qui n'est pas un de ceux pour lesquels ton serveur reçoit des
mails.
Ps: dans la mesure où cela ne te pose pas de souci, peut être qu'en
indiquant ton nom de domaine, ce serait plus simple ?
> Ps de souci, nous sommes en train de faire le thread le plus long du
groupe ;-)
Pour l'envoi par telnet sur le port 25, tu n'a pas bien lu la manip donné:
avec nslookup il te faut demander les mx d'aol.com (set type=mx)
Cela te retournera des nom d'hôtes de la forme mailin-xx.mx.aol.com (ou xx
va de 01 a 04)
Donc c'est logique que smtp.aol.com te demande une authentification, ce
doit être les serveurs sortants pour les abonnés aol.
Pour la conformité avec les RFC (les "règles") smtp, oui, l'adresse
postmaster, l'adresse abuse sont obligatoires.
Pour info, normalement on devrait aussi accepter les mails pour
, mais je n'ai jamais réussi à faire faire ça au smtp de
IIS ;-(
Pour le mx, il faut faire le test du DOMAINE, pas seulement celui du mx du
domaine.
dans nslookup (les commandes à taper sont en majuscules, mais je ne te
crie pas dessus, et tu les tapera en minuscules):
SET TYPE=MX
TONDOMAINE.TLD
=> retourne le mx de la forme tondomaine.tld MX preference = 5, mail
exchanger = nom_d_hote.tondomaine.tld
=> retourne en dessous l'adresse IP correspondant a nom_d_hote sous la
forme nom_d_hote.tondomaine.tld internet address = 123.123.123.123
SET TYPE=PTR
123.234.345.456
=> doit retourner une ligne de la forme 456.345.234.123.in-addr.arpa name
= nom_d_hote.tondomaine.tld
=> il s'agit du reverse adresse
En fait, pour dire les chose autrement:
Dans ta zone, tu a un enregistrement de type MX pointant sur un nom
d'hote. Ce nom d'hote n'a pas besoin d'etre dans ta zone. En revanche ce
nom d'hote doit pointer vers ton adresse IP publique. Et ton adresse ip
publique doit retourner le nom d'hote indiqué dans le mx.
Bien sûr si tu bouge ton MX, la plupart du temps il te faut aussi modifier
le spf.
Concernant les logs smtp, il faut surtout regarder que tu ne soit pas un
open relay, c'est à dire un serveur de mail accessible depuis internet et
autorisant 'tout le monde' à se connecter et a envoyer des mails pour un
domaine qui n'est pas un de ceux pour lesquels ton serveur reçoit des
mails.
Ps: dans la mesure où cela ne te pose pas de souci, peut être qu'en
indiquant ton nom de domaine, ce serait plus simple ?
Ps de souci, nous sommes en train de faire le thread le plus long du
groupe ;-)
Pour l'envoi par telnet sur le port 25, tu n'a pas bien lu la manip
donné:
avec nslookup il te faut demander les mx d'aol.com (set type=mx)
Cela te retournera des nom d'hôtes de la forme mailin-xx.mx.aol.com (ou
xx va de 01 a 04)
Donc c'est logique que smtp.aol.com te demande une authentification, ce
doit être les serveurs sortants pour les abonnés aol.
Pour la conformité avec les RFC (les "règles") smtp, oui, l'adresse
postmaster, l'adresse abuse sont obligatoires.
Pour info, normalement on devrait aussi accepter les mails pour
, mais je n'ai jamais réussi à faire faire ça au smtp de
IIS ;-(
Pour le mx, il faut faire le test du DOMAINE, pas seulement celui du mx
du domaine.
dans nslookup (les commandes à taper sont en majuscules, mais je ne te
crie pas dessus, et tu les tapera en minuscules):
SET TYPE=MX
TONDOMAINE.TLD
=> retourne le mx de la forme tondomaine.tld MX preference = 5, mail
exchanger = nom_d_hote.tondomaine.tld
=> retourne en dessous l'adresse IP correspondant a nom_d_hote sous la
forme nom_d_hote.tondomaine.tld internet address = 123.123.123.123
SET TYPE=PTR
123.234.345.456
=> doit retourner une ligne de la forme 456.345.234.123.in-addr.arpa
name = nom_d_hote.tondomaine.tld
=> il s'agit du reverse adresse
En fait, pour dire les chose autrement:
Dans ta zone, tu a un enregistrement de type MX pointant sur un nom
d'hote. Ce nom d'hote n'a pas besoin d'etre dans ta zone. En revanche ce
nom d'hote doit pointer vers ton adresse IP publique. Et ton adresse ip
publique doit retourner le nom d'hote indiqué dans le mx.
Bien sûr si tu bouge ton MX, la plupart du temps il te faut aussi
modifier le spf.
Concernant les logs smtp, il faut surtout regarder que tu ne soit pas un
open relay, c'est à dire un serveur de mail accessible depuis internet et
autorisant 'tout le monde' à se connecter et a envoyer des mails pour un
domaine qui n'est pas un de ceux pour lesquels ton serveur reçoit des
mails.
Ps: dans la mesure où cela ne te pose pas de souci, peut être qu'en
indiquant ton nom de domaine, ce serait plus simple ?
Beaucoup plus simple en effet, tant pis pour la confidentialité:
madeinaudio.com
Donc j'ai fait les tests, et en effet, il semble qu'il y ait un problème
avec le reserve DNS, puisque
SET TYPE=PTR
213.246.39.108
=> retourne le nom de domaine et pas le nom d'hote.
J'ai donc demandé une modification dans mon interface client...
Concernant les MX d'aol, c'est ok, j'ai bien tous les noms d'hote
mailin-xx ...
Concernant l'open relay, après pas mal de "batailles", j'ai réussi à ce
qu'il soit "à peu près" sécurisé...
"A peu près", car il semblerait que certains mails passent quand même. Je
teste avec ce site:
http://www.abuse.net/relay.html
Bon début de semaine ;-)
Ps de souci, nous sommes en train de faire le thread le plus long du
groupe ;-)
Pour l'envoi par telnet sur le port 25, tu n'a pas bien lu la manip
donné:
avec nslookup il te faut demander les mx d'aol.com (set type=mx)
Cela te retournera des nom d'hôtes de la forme mailin-xx.mx.aol.com (ou
xx va de 01 a 04)
Donc c'est logique que smtp.aol.com te demande une authentification, ce
doit être les serveurs sortants pour les abonnés aol.
Pour la conformité avec les RFC (les "règles") smtp, oui, l'adresse
postmaster, l'adresse abuse sont obligatoires.
Pour info, normalement on devrait aussi accepter les mails pour
user@adresse_ip , mais je n'ai jamais réussi à faire faire ça au smtp de
IIS ;-(
Pour le mx, il faut faire le test du DOMAINE, pas seulement celui du mx
du domaine.
dans nslookup (les commandes à taper sont en majuscules, mais je ne te
crie pas dessus, et tu les tapera en minuscules):
SET TYPE=MX
TONDOMAINE.TLD
=> retourne le mx de la forme tondomaine.tld MX preference = 5, mail
exchanger = nom_d_hote.tondomaine.tld
=> retourne en dessous l'adresse IP correspondant a nom_d_hote sous la
forme nom_d_hote.tondomaine.tld internet address = 123.123.123.123
SET TYPE=PTR
123.234.345.456
=> doit retourner une ligne de la forme 456.345.234.123.in-addr.arpa
name = nom_d_hote.tondomaine.tld
=> il s'agit du reverse adresse
En fait, pour dire les chose autrement:
Dans ta zone, tu a un enregistrement de type MX pointant sur un nom
d'hote. Ce nom d'hote n'a pas besoin d'etre dans ta zone. En revanche ce
nom d'hote doit pointer vers ton adresse IP publique. Et ton adresse ip
publique doit retourner le nom d'hote indiqué dans le mx.
Bien sûr si tu bouge ton MX, la plupart du temps il te faut aussi
modifier le spf.
Concernant les logs smtp, il faut surtout regarder que tu ne soit pas un
open relay, c'est à dire un serveur de mail accessible depuis internet et
autorisant 'tout le monde' à se connecter et a envoyer des mails pour un
domaine qui n'est pas un de ceux pour lesquels ton serveur reçoit des
mails.
Ps: dans la mesure où cela ne te pose pas de souci, peut être qu'en
indiquant ton nom de domaine, ce serait plus simple ?
Beaucoup plus simple en effet, tant pis pour la confidentialité:
madeinaudio.com
Donc j'ai fait les tests, et en effet, il semble qu'il y ait un problème
avec le reserve DNS, puisque
SET TYPE=PTR
213.246.39.108
=> retourne le nom de domaine et pas le nom d'hote.
J'ai donc demandé une modification dans mon interface client...
Concernant les MX d'aol, c'est ok, j'ai bien tous les noms d'hote
mailin-xx ...
Concernant l'open relay, après pas mal de "batailles", j'ai réussi à ce
qu'il soit "à peu près" sécurisé...
"A peu près", car il semblerait que certains mails passent quand même. Je
teste avec ce site:
http://www.abuse.net/relay.html
Bon début de semaine ;-)
Ps de souci, nous sommes en train de faire le thread le plus long du
groupe ;-)
Pour l'envoi par telnet sur le port 25, tu n'a pas bien lu la manip
donné:
avec nslookup il te faut demander les mx d'aol.com (set type=mx)
Cela te retournera des nom d'hôtes de la forme mailin-xx.mx.aol.com (ou
xx va de 01 a 04)
Donc c'est logique que smtp.aol.com te demande une authentification, ce
doit être les serveurs sortants pour les abonnés aol.
Pour la conformité avec les RFC (les "règles") smtp, oui, l'adresse
postmaster, l'adresse abuse sont obligatoires.
Pour info, normalement on devrait aussi accepter les mails pour
, mais je n'ai jamais réussi à faire faire ça au smtp de
IIS ;-(
Pour le mx, il faut faire le test du DOMAINE, pas seulement celui du mx
du domaine.
dans nslookup (les commandes à taper sont en majuscules, mais je ne te
crie pas dessus, et tu les tapera en minuscules):
SET TYPE=MX
TONDOMAINE.TLD
=> retourne le mx de la forme tondomaine.tld MX preference = 5, mail
exchanger = nom_d_hote.tondomaine.tld
=> retourne en dessous l'adresse IP correspondant a nom_d_hote sous la
forme nom_d_hote.tondomaine.tld internet address = 123.123.123.123
SET TYPE=PTR
123.234.345.456
=> doit retourner une ligne de la forme 456.345.234.123.in-addr.arpa
name = nom_d_hote.tondomaine.tld
=> il s'agit du reverse adresse
En fait, pour dire les chose autrement:
Dans ta zone, tu a un enregistrement de type MX pointant sur un nom
d'hote. Ce nom d'hote n'a pas besoin d'etre dans ta zone. En revanche ce
nom d'hote doit pointer vers ton adresse IP publique. Et ton adresse ip
publique doit retourner le nom d'hote indiqué dans le mx.
Bien sûr si tu bouge ton MX, la plupart du temps il te faut aussi
modifier le spf.
Concernant les logs smtp, il faut surtout regarder que tu ne soit pas un
open relay, c'est à dire un serveur de mail accessible depuis internet et
autorisant 'tout le monde' à se connecter et a envoyer des mails pour un
domaine qui n'est pas un de ceux pour lesquels ton serveur reçoit des
mails.
Ps: dans la mesure où cela ne te pose pas de souci, peut être qu'en
indiquant ton nom de domaine, ce serait plus simple ?
Beaucoup plus simple en effet, tant pis pour la confidentialité:
madeinaudio.com
Donc j'ai fait les tests, et en effet, il semble qu'il y ait un problème
avec le reserve DNS, puisque
SET TYPE=PTR
213.246.39.108
=> retourne le nom de domaine et pas le nom d'hote.
J'ai donc demandé une modification dans mon interface client...
Concernant les MX d'aol, c'est ok, j'ai bien tous les noms d'hote
mailin-xx ...
Concernant l'open relay, après pas mal de "batailles", j'ai réussi à ce
qu'il soit "à peu près" sécurisé...
"A peu près", car il semblerait que certains mails passent quand même. Je
teste avec ce site:
http://www.abuse.net/relay.html
Bon début de semaine ;-)
Le dernier truc à voir, peut-être, est cette erreur que me signale
dnsstuff:
WARNING: One or more of your mailservers is claiming to be a host
other than what it really is (the SMTP greeting should be a 3-digit
code, followed by a space or a dash, then the host name). If your
mailserver sends out E-mail using this domain in its EHLO or HELO,
your E-mail might get blocked by anti-spam software. This is also a
technical violation of RFC821 4.3 (and RFC2821 4.3.1). Note that the
hostname given in the SMTP greeting should have an A record pointing
back to the same server. Note that this one test may use a cached DNS
record.
ik108.ikexpress.com claims to be invalid hostname 'IK108':
220 IK108 Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830
ready at Mon, 26 Mar 2007 21:39:14 +0200
Mais j'ai bien compris (encore une fois !) quel est le problème, et
comment le résoudre...
Le dernier truc à voir, peut-être, est cette erreur que me signale
dnsstuff:
WARNING: One or more of your mailservers is claiming to be a host
other than what it really is (the SMTP greeting should be a 3-digit
code, followed by a space or a dash, then the host name). If your
mailserver sends out E-mail using this domain in its EHLO or HELO,
your E-mail might get blocked by anti-spam software. This is also a
technical violation of RFC821 4.3 (and RFC2821 4.3.1). Note that the
hostname given in the SMTP greeting should have an A record pointing
back to the same server. Note that this one test may use a cached DNS
record.
ik108.ikexpress.com claims to be invalid hostname 'IK108':
220 IK108 Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830
ready at Mon, 26 Mar 2007 21:39:14 +0200
Mais j'ai bien compris (encore une fois !) quel est le problème, et
comment le résoudre...
Le dernier truc à voir, peut-être, est cette erreur que me signale
dnsstuff:
WARNING: One or more of your mailservers is claiming to be a host
other than what it really is (the SMTP greeting should be a 3-digit
code, followed by a space or a dash, then the host name). If your
mailserver sends out E-mail using this domain in its EHLO or HELO,
your E-mail might get blocked by anti-spam software. This is also a
technical violation of RFC821 4.3 (and RFC2821 4.3.1). Note that the
hostname given in the SMTP greeting should have an A record pointing
back to the same server. Note that this one test may use a cached DNS
record.
ik108.ikexpress.com claims to be invalid hostname 'IK108':
220 IK108 Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830
ready at Mon, 26 Mar 2007 21:39:14 +0200
Mais j'ai bien compris (encore une fois !) quel est le problème, et
comment le résoudre...
Concernant l'open relay, après pas mal de "batailles", j'ai réussi à
ce qu'il soit "à peu près" sécurisé...
"A peu près", car il semblerait que certains mails passent quand
même. Je teste avec ce site:
http://www.abuse.net/relay.html
Concernant l'open relay, après pas mal de "batailles", j'ai réussi à
ce qu'il soit "à peu près" sécurisé...
"A peu près", car il semblerait que certains mails passent quand
même. Je teste avec ce site:
http://www.abuse.net/relay.html
Concernant l'open relay, après pas mal de "batailles", j'ai réussi à
ce qu'il soit "à peu près" sécurisé...
"A peu près", car il semblerait que certains mails passent quand
même. Je teste avec ce site:
http://www.abuse.net/relay.html
> Oui, ça c'est un classique. Sur mes serveurs de mail, tu serait
immédiatement jeté à la connexion (pourquoi attendre) avec un message du
style "need fully qualified domain (FQDN)".
Dans la console IIS, propriété du serveur smtp, onglet remise, options
avancées, ajouter le nom fqdn (en minuscules de preference) dans domaine
complet.
Il est aussi possible de modifier le nom du serveur dans les propriétés
système, mais c'est souvent plus simple de le faire dans les propriétés du
serveur smtp.
Il est aussi judicieux, a ce même endroit dans le champ domaine fictif de
mettre tondomaine.tld (sans le nom d'hôte donc), ainsi les mails sortants
verront apparaitre tondomaine.tld plutot que hote.tondomaine.tld, c'est
plus cosmétique qu'autre chose .
Vérifier avec un telnet 127.0.0.1 25 que la baniière retourne bien le
fqdn.
Concernant le souci de relais, il FAUT vérifier que ce ne soit pas le cas.
En effet, si tu acceptes user%, cela
signifie que ton serveur accepte le "mail routing", c'est à dire qu'il
accepte le mail en pensant que c'est pour tondomaine.tld (normal), puis va
se rendre compte qu'il y a du sous routage vers autredomaine.tld. Il FAUT
(j'insiste) s'assurer que ce n'est pas le cas.
Tous les tests de mail relais doivent se solder par un "unable to relay",
point barre.
Si toute personne mettant un serveur de mail visible sur internet se
donnait la peine comme toi d'essayer de bien faire les choses, les
éditeurs d'anti-spam n'auraient plus qu'à se reconvertir ;-)
> Oui, ça c'est un classique. Sur mes serveurs de mail, tu serait
immédiatement jeté à la connexion (pourquoi attendre) avec un message du
style "need fully qualified domain (FQDN)".
Dans la console IIS, propriété du serveur smtp, onglet remise, options
avancées, ajouter le nom fqdn (en minuscules de preference) dans domaine
complet.
Il est aussi possible de modifier le nom du serveur dans les propriétés
système, mais c'est souvent plus simple de le faire dans les propriétés du
serveur smtp.
Il est aussi judicieux, a ce même endroit dans le champ domaine fictif de
mettre tondomaine.tld (sans le nom d'hôte donc), ainsi les mails sortants
verront apparaitre tondomaine.tld plutot que hote.tondomaine.tld, c'est
plus cosmétique qu'autre chose .
Vérifier avec un telnet 127.0.0.1 25 que la baniière retourne bien le
fqdn.
Concernant le souci de relais, il FAUT vérifier que ce ne soit pas le cas.
En effet, si tu acceptes user%autredomaine.tld@tondomaine.tld, cela
signifie que ton serveur accepte le "mail routing", c'est à dire qu'il
accepte le mail en pensant que c'est pour tondomaine.tld (normal), puis va
se rendre compte qu'il y a du sous routage vers autredomaine.tld. Il FAUT
(j'insiste) s'assurer que ce n'est pas le cas.
Tous les tests de mail relais doivent se solder par un "unable to relay",
point barre.
Si toute personne mettant un serveur de mail visible sur internet se
donnait la peine comme toi d'essayer de bien faire les choses, les
éditeurs d'anti-spam n'auraient plus qu'à se reconvertir ;-)
> Oui, ça c'est un classique. Sur mes serveurs de mail, tu serait
immédiatement jeté à la connexion (pourquoi attendre) avec un message du
style "need fully qualified domain (FQDN)".
Dans la console IIS, propriété du serveur smtp, onglet remise, options
avancées, ajouter le nom fqdn (en minuscules de preference) dans domaine
complet.
Il est aussi possible de modifier le nom du serveur dans les propriétés
système, mais c'est souvent plus simple de le faire dans les propriétés du
serveur smtp.
Il est aussi judicieux, a ce même endroit dans le champ domaine fictif de
mettre tondomaine.tld (sans le nom d'hôte donc), ainsi les mails sortants
verront apparaitre tondomaine.tld plutot que hote.tondomaine.tld, c'est
plus cosmétique qu'autre chose .
Vérifier avec un telnet 127.0.0.1 25 que la baniière retourne bien le
fqdn.
Concernant le souci de relais, il FAUT vérifier que ce ne soit pas le cas.
En effet, si tu acceptes user%, cela
signifie que ton serveur accepte le "mail routing", c'est à dire qu'il
accepte le mail en pensant que c'est pour tondomaine.tld (normal), puis va
se rendre compte qu'il y a du sous routage vers autredomaine.tld. Il FAUT
(j'insiste) s'assurer que ce n'est pas le cas.
Tous les tests de mail relais doivent se solder par un "unable to relay",
point barre.
Si toute personne mettant un serveur de mail visible sur internet se
donnait la peine comme toi d'essayer de bien faire les choses, les
éditeurs d'anti-spam n'auraient plus qu'à se reconvertir ;-)
J'ai également changé le champ domaine fictif et... tiens, plus de
retour?! Y'aurait-il un côté autre que cosmétique ?
J'attends quelques minutes avant de crier victoire... (chat échaudé
etc..)
Concernant le relai... c'est vrai que j'essaye de me donner la peine
de bien faire les choses, mais c'est pas facile quand on a une
formation de... musique !
Bref, je comprends que ce soit rebutant.
Comment faire pour fermer complètement le relai ?
J'ai décoché la case "Autoriser tout ordinateur correctement
authentifié à relayer..." dans la config du relais du serveur smtp.
J'ai également changé le champ domaine fictif et... tiens, plus de
retour?! Y'aurait-il un côté autre que cosmétique ?
J'attends quelques minutes avant de crier victoire... (chat échaudé
etc..)
Concernant le relai... c'est vrai que j'essaye de me donner la peine
de bien faire les choses, mais c'est pas facile quand on a une
formation de... musique !
Bref, je comprends que ce soit rebutant.
Comment faire pour fermer complètement le relai ?
J'ai décoché la case "Autoriser tout ordinateur correctement
authentifié à relayer..." dans la config du relais du serveur smtp.
J'ai également changé le champ domaine fictif et... tiens, plus de
retour?! Y'aurait-il un côté autre que cosmétique ?
J'attends quelques minutes avant de crier victoire... (chat échaudé
etc..)
Concernant le relai... c'est vrai que j'essaye de me donner la peine
de bien faire les choses, mais c'est pas facile quand on a une
formation de... musique !
Bref, je comprends que ce soit rebutant.
Comment faire pour fermer complètement le relai ?
J'ai décoché la case "Autoriser tout ordinateur correctement
authentifié à relayer..." dans la config du relais du serveur smtp.
> Ce qui peut être logique, hote.tondomaine.tld n'est pas un sous-domaine
mais un nom d'hôte dans ton domaine. Donc doit
être recherché par aol avec un mx pour le domaine hote.tondomaine.tld, qui
n'existe pas. Enfin, là c'est un peu tiré par les cheveux, aol n'ayant
jamais expliqué les controles effectués de leur côté.
Pour le relai, tu peux recocher la case sans inquiètude.
Dans les propriétés, onglet accès, cliquer sur le bonton restriction de
relais.
S'assurer que la case uniquement a liste ci-dessous soit cochée. dans la
liste, mettre au moins l'IP du serveur et la boucle locale (127.0.0.1),
éventuellement ajouter les sous-réseaux ou domaines (pouvant être résolus
par le serveur IIS) devant pouvoir relayer un mail.
Si tu a créé des domaines distants, il faut maintenant t'assurer que la
case autoriser le courrier entrant a être relayé
1 - Soit cochée pour un domaine distant étant sous ta responsabilité (un
autre domaine sur un autre serveur de mail, non directement accessible par
l'IP public, par exemple)
2 - Ne soit pas cochée pour un domaine distant configuré en tant que mil
routing. C'est à dire un domaine distant, en général créé pour ne pas
passer par le MX officiel, ou pour ne pas faire la résolution MX pour
chaque mail envoyé)
> Ce qui peut être logique, hote.tondomaine.tld n'est pas un sous-domaine
mais un nom d'hôte dans ton domaine. Donc user@hote.tondomaine.tld doit
être recherché par aol avec un mx pour le domaine hote.tondomaine.tld, qui
n'existe pas. Enfin, là c'est un peu tiré par les cheveux, aol n'ayant
jamais expliqué les controles effectués de leur côté.
Pour le relai, tu peux recocher la case sans inquiètude.
Dans les propriétés, onglet accès, cliquer sur le bonton restriction de
relais.
S'assurer que la case uniquement a liste ci-dessous soit cochée. dans la
liste, mettre au moins l'IP du serveur et la boucle locale (127.0.0.1),
éventuellement ajouter les sous-réseaux ou domaines (pouvant être résolus
par le serveur IIS) devant pouvoir relayer un mail.
Si tu a créé des domaines distants, il faut maintenant t'assurer que la
case autoriser le courrier entrant a être relayé
1 - Soit cochée pour un domaine distant étant sous ta responsabilité (un
autre domaine sur un autre serveur de mail, non directement accessible par
l'IP public, par exemple)
2 - Ne soit pas cochée pour un domaine distant configuré en tant que mil
routing. C'est à dire un domaine distant, en général créé pour ne pas
passer par le MX officiel, ou pour ne pas faire la résolution MX pour
chaque mail envoyé)
> Ce qui peut être logique, hote.tondomaine.tld n'est pas un sous-domaine
mais un nom d'hôte dans ton domaine. Donc doit
être recherché par aol avec un mx pour le domaine hote.tondomaine.tld, qui
n'existe pas. Enfin, là c'est un peu tiré par les cheveux, aol n'ayant
jamais expliqué les controles effectués de leur côté.
Pour le relai, tu peux recocher la case sans inquiètude.
Dans les propriétés, onglet accès, cliquer sur le bonton restriction de
relais.
S'assurer que la case uniquement a liste ci-dessous soit cochée. dans la
liste, mettre au moins l'IP du serveur et la boucle locale (127.0.0.1),
éventuellement ajouter les sous-réseaux ou domaines (pouvant être résolus
par le serveur IIS) devant pouvoir relayer un mail.
Si tu a créé des domaines distants, il faut maintenant t'assurer que la
case autoriser le courrier entrant a être relayé
1 - Soit cochée pour un domaine distant étant sous ta responsabilité (un
autre domaine sur un autre serveur de mail, non directement accessible par
l'IP public, par exemple)
2 - Ne soit pas cochée pour un domaine distant configuré en tant que mil
routing. C'est à dire un domaine distant, en général créé pour ne pas
passer par le MX officiel, ou pour ne pas faire la résolution MX pour
chaque mail envoyé)
Aujourd'hui les mails d'AOL me sont revenus :( (les serveurs d'AOL
auraient-ils des humeurs?)
Mais il y a encore plus étrange. J'ai reçu un rapport d'erreur pour
un mail sur un autre domaine, et pourtant j'ai eu confirmation que ce
mail était bien arrivé !!
"Échec de la remise aux destinataires suivants"
et pourtant, aucun doute, mon client a eu le mail.
Je deviens dingue.
Concernant le relai, je n'autorise que l'IP du serveur (même pas la
boucle locale, ni autre chose)
J'ai une config très simple. Un site sur un serveur IIS avec son
serveur SMTP.
Donc pas de demaine distant ou autre.
Je vois pas comment je pourrais bloquer plus que ça...
Aujourd'hui les mails d'AOL me sont revenus :( (les serveurs d'AOL
auraient-ils des humeurs?)
Mais il y a encore plus étrange. J'ai reçu un rapport d'erreur pour
un mail sur un autre domaine, et pourtant j'ai eu confirmation que ce
mail était bien arrivé !!
"Échec de la remise aux destinataires suivants"
et pourtant, aucun doute, mon client a eu le mail.
Je deviens dingue.
Concernant le relai, je n'autorise que l'IP du serveur (même pas la
boucle locale, ni autre chose)
J'ai une config très simple. Un site sur un serveur IIS avec son
serveur SMTP.
Donc pas de demaine distant ou autre.
Je vois pas comment je pourrais bloquer plus que ça...
Aujourd'hui les mails d'AOL me sont revenus :( (les serveurs d'AOL
auraient-ils des humeurs?)
Mais il y a encore plus étrange. J'ai reçu un rapport d'erreur pour
un mail sur un autre domaine, et pourtant j'ai eu confirmation que ce
mail était bien arrivé !!
"Échec de la remise aux destinataires suivants"
et pourtant, aucun doute, mon client a eu le mail.
Je deviens dingue.
Concernant le relai, je n'autorise que l'IP du serveur (même pas la
boucle locale, ni autre chose)
J'ai une config très simple. Un site sur un serveur IIS avec son
serveur SMTP.
Donc pas de demaine distant ou autre.
Je vois pas comment je pourrais bloquer plus que ça...
> Pour le relais, ce doit être Ok (je te conseille quand même d'ajouter la
boule locale 127.0.0.1).
Pour les mails en retour d'AOL, il faudrait regarder dans le log de ton
serveur smtp si AOL accepte le mail (code 250), puis le renvoi plus tard.
Si c'est le cas, plus grand chose à faire de ton côté, a part essayer de
les contacter, avec l'ID (le numéro) d'un mail revenu en echec.
> Pour le relais, ce doit être Ok (je te conseille quand même d'ajouter la
boule locale 127.0.0.1).
Pour les mails en retour d'AOL, il faudrait regarder dans le log de ton
serveur smtp si AOL accepte le mail (code 250), puis le renvoi plus tard.
Si c'est le cas, plus grand chose à faire de ton côté, a part essayer de
les contacter, avec l'ID (le numéro) d'un mail revenu en echec.
> Pour le relais, ce doit être Ok (je te conseille quand même d'ajouter la
boule locale 127.0.0.1).
Pour les mails en retour d'AOL, il faudrait regarder dans le log de ton
serveur smtp si AOL accepte le mail (code 250), puis le renvoi plus tard.
Si c'est le cas, plus grand chose à faire de ton côté, a part essayer de
les contacter, avec l'ID (le numéro) d'un mail revenu en echec.
