bonjour,
le sujet est clair je crois.
Je suis actuellement lié à mon fai pour le reste de l'année et celui-ci
peut offrir un ip statique à condition de passer l'abonnement à la
version pro = + 15/mois ( + prix de l'ip ?) ( orange)
Le but est de me faire un serveur de mail correcte comme n'importe quel fai.
Comme j'ai déjà dit dans mes mails précédents ( sujet: hebergement
serveur de mail. D'après les réponses j'en conclu qu'il est impossible
de le faire avec un ip dynamique. De par là un ip statique.
Tout ceci afin de me créer un MX avec son adresse ip + un A.
Chez zoneedit cela semble impossible, le MX y est mais pas l'adresse ip
ni le A.
ca n'est toujours pas le 100% biensur, mais avez-vous (ceux qui ont un ip fixe), controlé si l'ip était blacklisté ?
Quand Nerim m'a alloué un bloc d'adresses IP (fixes évidemment) j'ai vu que celles-ci étaient listées comme dynamiques par dynablock.njabl.org, liste aujourd'hui abandonnée. Ayant défini des reverses personnalisés (qui marchent, pas comme chez certain FAI ;-) ) pour chacune de mes adresses, j'ai demandé leur retrait aux gestionnaires de la liste. Quelques temps plus tard, j'ai constaté que mes adresses étaient sorties de la liste.
Salut,
ca n'est toujours pas le 100% biensur, mais avez-vous (ceux qui ont un
ip fixe), controlé si l'ip était blacklisté ?
Quand Nerim m'a alloué un bloc d'adresses IP (fixes évidemment) j'ai vu
que celles-ci étaient listées comme dynamiques par dynablock.njabl.org,
liste aujourd'hui abandonnée. Ayant défini des reverses personnalisés
(qui marchent, pas comme chez certain FAI ;-) ) pour chacune de mes
adresses, j'ai demandé leur retrait aux gestionnaires de la liste.
Quelques temps plus tard, j'ai constaté que mes adresses étaient sorties
de la liste.
ca n'est toujours pas le 100% biensur, mais avez-vous (ceux qui ont un ip fixe), controlé si l'ip était blacklisté ?
Quand Nerim m'a alloué un bloc d'adresses IP (fixes évidemment) j'ai vu que celles-ci étaient listées comme dynamiques par dynablock.njabl.org, liste aujourd'hui abandonnée. Ayant défini des reverses personnalisés (qui marchent, pas comme chez certain FAI ;-) ) pour chacune de mes adresses, j'ai demandé leur retrait aux gestionnaires de la liste. Quelques temps plus tard, j'ai constaté que mes adresses étaient sorties de la liste.
Pascal Hambourg
GPLHost (thomas) wrote:
Je tenais a signaler qu'un ami s'est fait changer d'ip "fixe" par free sans préavis, car ils ont changé leur infrastructure. Ca lui est arrivé 2 fois l'an passé...
Sur une ligne dégroupée, non dégroupée, lors d'un passage de non dégroupé à dégroupé ou vice versa ?
Ca fait réfléchir pour Nerim dont les avantages sont: -connectivité stable
La plupart du temps, oui. Certains ont émis des craintes sur la stabilité de l'offre dégroupée par LDCOM/9T, mais pour ma part je ne regrette pas.
-abonnement sans contraintes -ip fixe
A noter que si on change de formule Start vers Fast ou vice versa, l'adresse IP change obligatoirement ainsi que les éventuels blocs d'adresses IP supplémentaires car il y a des pools d'adresses distincts pour chaque formule.
GPLHost (thomas) wrote:
Je tenais a signaler qu'un ami s'est fait changer d'ip "fixe" par free
sans préavis, car ils ont changé leur infrastructure. Ca lui est arrivé
2 fois l'an passé...
Sur une ligne dégroupée, non dégroupée, lors d'un passage de non
dégroupé à dégroupé ou vice versa ?
Ca fait réfléchir pour Nerim dont les avantages sont:
-connectivité stable
La plupart du temps, oui. Certains ont émis des craintes sur la
stabilité de l'offre dégroupée par LDCOM/9T, mais pour ma part je ne
regrette pas.
-abonnement sans contraintes
-ip fixe
A noter que si on change de formule Start vers Fast ou vice versa,
l'adresse IP change obligatoirement ainsi que les éventuels blocs
d'adresses IP supplémentaires car il y a des pools d'adresses distincts
pour chaque formule.
Je tenais a signaler qu'un ami s'est fait changer d'ip "fixe" par free sans préavis, car ils ont changé leur infrastructure. Ca lui est arrivé 2 fois l'an passé...
Sur une ligne dégroupée, non dégroupée, lors d'un passage de non dégroupé à dégroupé ou vice versa ?
Ca fait réfléchir pour Nerim dont les avantages sont: -connectivité stable
La plupart du temps, oui. Certains ont émis des craintes sur la stabilité de l'offre dégroupée par LDCOM/9T, mais pour ma part je ne regrette pas.
-abonnement sans contraintes -ip fixe
A noter que si on change de formule Start vers Fast ou vice versa, l'adresse IP change obligatoirement ainsi que les éventuels blocs d'adresses IP supplémentaires car il y a des pools d'adresses distincts pour chaque formule.
Pascal Hambourg
Vous pouvez tres 'bien' gerer la reception avec une ip dynamique [...]
On peut, mais pas "très bien".
Cela dit c'est moyen, IMHO, si un mail arrive juste apres un changement d'ip et que la nouvelle ip est attribuée à une machine qui recoit du mail, le mail sera rejeté.
Voilà. C'est très moyen, pas très bien. Et le cas où le mail est rejeté est le cas favorable car le MTA émetteur réessaiera un peu plus tard et tombera sur la bonne adresse IP. Le cas moins favorable est quand le MTA qui a récupéré l'ancienne adresse accepte le mail sans rien dire et ne le transmet pas. Le MTA émetteur considère que le mail a été délivré et ne cherchera pas à le réémettre.
Pour l'emission, zero probleme excepté les serveurs en face qui peuvent rejeter le mail pour 3 raisons: absence eventuelle de reverse dns,
Ou bien reverse DNS présent mais d'aspect "généré automatiquement".
refus de reception de mails emanant de plages d'ip 'domestiques', non concordance entre le helo présenté et votre reverse dns.
Ce qui est une connerie. La vérification que le HELO pointe vers l'adresse IP suffirait. Aucune RFC n'impose que le HELO contienne le nom canonique de la machine.
Vous pouvez tres 'bien' gerer la reception avec une ip dynamique [...]
On peut, mais pas "très bien".
Cela dit c'est moyen, IMHO, si un mail arrive juste apres un changement
d'ip et que la nouvelle ip est attribuée à une machine qui recoit du
mail, le mail sera rejeté.
Voilà. C'est très moyen, pas très bien. Et le cas où le mail est rejeté
est le cas favorable car le MTA émetteur réessaiera un peu plus tard et
tombera sur la bonne adresse IP. Le cas moins favorable est quand le MTA
qui a récupéré l'ancienne adresse accepte le mail sans rien dire et ne
le transmet pas. Le MTA émetteur considère que le mail a été délivré et
ne cherchera pas à le réémettre.
Pour l'emission, zero probleme excepté les serveurs en face qui peuvent
rejeter le mail pour 3 raisons: absence eventuelle de reverse dns,
Ou bien reverse DNS présent mais d'aspect "généré automatiquement".
refus
de reception de mails emanant de plages d'ip 'domestiques', non
concordance entre le helo présenté et votre reverse dns.
Ce qui est une connerie. La vérification que le HELO pointe vers
l'adresse IP suffirait. Aucune RFC n'impose que le HELO contienne le nom
canonique de la machine.
Vous pouvez tres 'bien' gerer la reception avec une ip dynamique [...]
On peut, mais pas "très bien".
Cela dit c'est moyen, IMHO, si un mail arrive juste apres un changement d'ip et que la nouvelle ip est attribuée à une machine qui recoit du mail, le mail sera rejeté.
Voilà. C'est très moyen, pas très bien. Et le cas où le mail est rejeté est le cas favorable car le MTA émetteur réessaiera un peu plus tard et tombera sur la bonne adresse IP. Le cas moins favorable est quand le MTA qui a récupéré l'ancienne adresse accepte le mail sans rien dire et ne le transmet pas. Le MTA émetteur considère que le mail a été délivré et ne cherchera pas à le réémettre.
Pour l'emission, zero probleme excepté les serveurs en face qui peuvent rejeter le mail pour 3 raisons: absence eventuelle de reverse dns,
Ou bien reverse DNS présent mais d'aspect "généré automatiquement".
refus de reception de mails emanant de plages d'ip 'domestiques', non concordance entre le helo présenté et votre reverse dns.
Ce qui est une connerie. La vérification que le HELO pointe vers l'adresse IP suffirait. Aucune RFC n'impose que le HELO contienne le nom canonique de la machine.
mess-mate
Pascal Hambourg wrote:
Vous pouvez tres 'bien' gerer la reception avec une ip dynamique [...]
On peut, mais pas "très bien".
Cela dit c'est moyen, IMHO, si un mail arrive juste apres un changement d'ip et que la nouvelle ip est attribuée à une machine qui recoit du mail, le mail sera rejeté.
Voilà. C'est très moyen, pas très bien. Et le cas où le mail est rejeté est le cas favorable car le MTA émetteur réessaiera un peu plus tard et tombera sur la bonne adresse IP. Le cas moins favorable est quand le MTA qui a récupéré l'ancienne adresse accepte le mail sans rien dire et ne le transmet pas. Le MTA émetteur considère que le mail a été délivré et ne cherchera pas à le réémettre.
Pour l'emission, zero probleme excepté les serveurs en face qui peuvent rejeter le mail pour 3 raisons: absence eventuelle de reverse dns,
Ou bien reverse DNS présent mais d'aspect "généré automatiquement".
refus de reception de mails emanant de plages d'ip 'domestiques', non concordance entre le helo présenté et votre reverse dns.
Ce qui est une connerie. La vérification que le HELO pointe vers l'adresse IP suffirait. Aucune RFC n'impose que le HELO contienne le nom canonique de la machine. Pas encore ue à faire à cloud9 ?? (serveur dont ce sert entre-autres la
liste postfix) Un petit point trop peu et hop, du vite fait.
Pascal Hambourg wrote:
Vous pouvez tres 'bien' gerer la reception avec une ip dynamique [...]
On peut, mais pas "très bien".
Cela dit c'est moyen, IMHO, si un mail arrive juste apres un changement
d'ip et que la nouvelle ip est attribuée à une machine qui recoit du
mail, le mail sera rejeté.
Voilà. C'est très moyen, pas très bien. Et le cas où le mail est rejeté
est le cas favorable car le MTA émetteur réessaiera un peu plus tard et
tombera sur la bonne adresse IP. Le cas moins favorable est quand le MTA
qui a récupéré l'ancienne adresse accepte le mail sans rien dire et ne
le transmet pas. Le MTA émetteur considère que le mail a été délivré et
ne cherchera pas à le réémettre.
Pour l'emission, zero probleme excepté les serveurs en face qui peuvent
rejeter le mail pour 3 raisons: absence eventuelle de reverse dns,
Ou bien reverse DNS présent mais d'aspect "généré automatiquement".
refus
de reception de mails emanant de plages d'ip 'domestiques', non
concordance entre le helo présenté et votre reverse dns.
Ce qui est une connerie. La vérification que le HELO pointe vers
l'adresse IP suffirait. Aucune RFC n'impose que le HELO contienne le nom
canonique de la machine.
Pas encore ue à faire à cloud9 ?? (serveur dont ce sert entre-autres la
liste postfix)
Un petit point trop peu et hop, du vite fait.
Vous pouvez tres 'bien' gerer la reception avec une ip dynamique [...]
On peut, mais pas "très bien".
Cela dit c'est moyen, IMHO, si un mail arrive juste apres un changement d'ip et que la nouvelle ip est attribuée à une machine qui recoit du mail, le mail sera rejeté.
Voilà. C'est très moyen, pas très bien. Et le cas où le mail est rejeté est le cas favorable car le MTA émetteur réessaiera un peu plus tard et tombera sur la bonne adresse IP. Le cas moins favorable est quand le MTA qui a récupéré l'ancienne adresse accepte le mail sans rien dire et ne le transmet pas. Le MTA émetteur considère que le mail a été délivré et ne cherchera pas à le réémettre.
Pour l'emission, zero probleme excepté les serveurs en face qui peuvent rejeter le mail pour 3 raisons: absence eventuelle de reverse dns,
Ou bien reverse DNS présent mais d'aspect "généré automatiquement".
refus de reception de mails emanant de plages d'ip 'domestiques', non concordance entre le helo présenté et votre reverse dns.
Ce qui est une connerie. La vérification que le HELO pointe vers l'adresse IP suffirait. Aucune RFC n'impose que le HELO contienne le nom canonique de la machine. Pas encore ue à faire à cloud9 ?? (serveur dont ce sert entre-autres la
liste postfix) Un petit point trop peu et hop, du vite fait.
Manuel Guesdon
On Mon, 05 Feb 2007 13:47:57 +0100, Pascal Hambourg wrote:
Vous pouvez tres 'bien' gerer la reception avec une ip dynamique [...]
On peut, mais pas "très bien".
Cela dit c'est moyen, IMHO, si un mail arrive juste apres un changement d'ip et que la nouvelle ip est attribuée à une machine qui recoit du mail, le mail sera rejeté.
Voilà. C'est très moyen, pas très bien. Et le cas où le mail est rejeté est le cas favorable car le MTA émetteur réessaiera un peu plus tard et tombera sur la bonne adresse IP. Le cas moins favorable est quand le MTA qui a récupéré l'ancienne adresse accepte le mail sans rien dire et ne le transmet pas. Le MTA émetteur considère que le mail a été délivré et ne cherchera pas à le réémettre.
Et entre les 2: mail rejeté 'definitivement', en 5xx (genre relaying denied).
refus de reception de mails emanant de plages d'ip 'domestiques', non concordance entre le helo présenté et votre reverse dns.
Ce qui est une connerie. La vérification que le HELO pointe vers l'adresse IP suffirait. Aucune RFC n'impose que le HELO contienne le nom canonique de la machine.
Concernant le FQDN: http://rfc.net/rfc2821.html#s4.1.1.1 Et la RFC1912 indique: <<Every Internet-reachable host should have a name. The consequences of this are becoming more and more obvious. Many services available on the Internet will not talk to you if you aren't correctly registered in the DNS. Make sure your PTR and A records match.
Et il est parfaitement possible d'avoir plusieurs PTR pou une meme IP.
Manuel
On Mon, 05 Feb 2007 13:47:57 +0100, Pascal Hambourg wrote:
Vous pouvez tres 'bien' gerer la reception avec une ip dynamique [...]
On peut, mais pas "très bien".
Cela dit c'est moyen, IMHO, si un mail arrive juste apres un changement
d'ip et que la nouvelle ip est attribuée à une machine qui recoit du
mail, le mail sera rejeté.
Voilà. C'est très moyen, pas très bien. Et le cas où le mail est rejeté
est le cas favorable car le MTA émetteur réessaiera un peu plus tard et
tombera sur la bonne adresse IP. Le cas moins favorable est quand le MTA
qui a récupéré l'ancienne adresse accepte le mail sans rien dire et ne
le transmet pas. Le MTA émetteur considère que le mail a été délivré et
ne cherchera pas à le réémettre.
Et entre les 2: mail rejeté 'definitivement', en 5xx (genre relaying
denied).
refus
de reception de mails emanant de plages d'ip 'domestiques', non
concordance entre le helo présenté et votre reverse dns.
Ce qui est une connerie. La vérification que le HELO pointe vers
l'adresse IP suffirait. Aucune RFC n'impose que le HELO contienne le nom
canonique de la machine.
Concernant le FQDN: http://rfc.net/rfc2821.html#s4.1.1.1
Et la RFC1912 indique:
<<Every Internet-reachable host should have a name. The consequences
of this are becoming more and more obvious. Many services available on the
Internet will not talk to you if you aren't correctly registered in the
DNS. Make sure your PTR and A records match.
Et il est parfaitement possible d'avoir plusieurs PTR pou une meme IP.
On Mon, 05 Feb 2007 13:47:57 +0100, Pascal Hambourg wrote:
Vous pouvez tres 'bien' gerer la reception avec une ip dynamique [...]
On peut, mais pas "très bien".
Cela dit c'est moyen, IMHO, si un mail arrive juste apres un changement d'ip et que la nouvelle ip est attribuée à une machine qui recoit du mail, le mail sera rejeté.
Voilà. C'est très moyen, pas très bien. Et le cas où le mail est rejeté est le cas favorable car le MTA émetteur réessaiera un peu plus tard et tombera sur la bonne adresse IP. Le cas moins favorable est quand le MTA qui a récupéré l'ancienne adresse accepte le mail sans rien dire et ne le transmet pas. Le MTA émetteur considère que le mail a été délivré et ne cherchera pas à le réémettre.
Et entre les 2: mail rejeté 'definitivement', en 5xx (genre relaying denied).
refus de reception de mails emanant de plages d'ip 'domestiques', non concordance entre le helo présenté et votre reverse dns.
Ce qui est une connerie. La vérification que le HELO pointe vers l'adresse IP suffirait. Aucune RFC n'impose que le HELO contienne le nom canonique de la machine.
Concernant le FQDN: http://rfc.net/rfc2821.html#s4.1.1.1 Et la RFC1912 indique: <<Every Internet-reachable host should have a name. The consequences of this are becoming more and more obvious. Many services available on the Internet will not talk to you if you aren't correctly registered in the DNS. Make sure your PTR and A records match.
Et il est parfaitement possible d'avoir plusieurs PTR pou une meme IP.
