Reprise du message précédent :

 
voui
 
De toute manière honnêtement on peut pas dire que le protocole mail soit une réussite, c'est une vraie merde concrétement

Ce serait intéressant d'écrire un nouveau protocole mail, un truc mieux pensé

 
commençons par le commencement :
propositions d'amélioration par rapport à l'existant ?  

 
smtp2 ?
 

mais de toutes manières pour le moment vu le nombre de personnes qui ne respectent pas les RFC, je sais pas si un nouveau protocole changerait grand chose.
 
Surtout que c'est une solution à long terme (le temps de migrer), alors que le spam est un problème de plus en plus grave maintenant.
 
Ou alors faire un truc compatible avec l'existant ?
 

 
Déjà un meilleur contrôle à l'envoi, une meilleure définition du header, un refus de réception si le header ne correspond pas à une norme fixée, un meilleur suivi du mail avec des systèmes de CRC pour checker que l'intégrité est préservée le long du chemin...  
 
Là j'ai un peu la tête dans le paté, mais y'a très peu de crontrôles dans le protocole smtp et il est facile de faker bcp de choses.
 
Déjà avec le protocole actuel en configurant bien y'a moyen que ça se passe mieux mais il faudrait que tous les serveurs mails revoient à empêcher la possibilité d'autoriser le relaying a tout le monde. Ensuite je pense que c'est pratiquement qu'une amélioration de l'information pour rapidement isoler la source. Empêcher l'envoi massif d'un même mail à plein de gens par un smtp en relay, c'est à dire que pour une mailing par ex, il faudrait avoir son propre serveur mail sans passer par un smtp extérieur.
 
Ca met des contraintes pour certaines de ces choses, mais c'est configurable après, seulement le mec doit assumer son choix volontaire et avoir toutes les infos sur ce qui se passe avant son smtp dans ce cas.
 
Avoir une identification qui serait checkée par le smtp d'envoi sur le serveur principal MX du domaine et qui ne serait ensuite plus transmise au smtp destinataire...
 
Le système de roaming users en smtp sur le serveur MX du domaine par exemple est une bonne chose, meilleure que de passer par un smtp tierce pour envoyer les mails. Je pense que passer par le(s) smtp du MX du domaine d'envoi serait plus logique et plus secure. A ce niveau là tu peux après bien plus facilement checker des choses.
 
Bon là c'est un peu des tas de choses dans le vent pas trop conrètes, mais ce qui est certain, c'est qu'il y a une grande liberté dans le protocole mail et qu'il est tout sauf sûr à mes yeux
 
Voilà en gros, meilleure traçabilité ( ça le fait c'est à la mode =) ), abstraction des smtp tierces de relai pour passer par le SMTP du domaine d'envoi avec identification comme pour le POP, contrôle de l'intégrité des infos header du mail.

 
Tu peux pas faire compatible puisque tu ajoutes des contraintes pour justement empêcher des mails de passer, par contre tu peux très bien imaginer un protocole sur chaque port, si le port smtp2 ne répond pas positivement, tu passes le mail en smtp, ainsi tout le monde peut doucement migrer jusqu'à ce que le smtp soit obsolete. Tu peux marquer les messages smtp1 à la réception comme étant protocole 1, moins sûr que le protocole 2. Après c'est de la communication et du temps oui...

ou oui en fait que le smtp2 accepte le smtp mais le marque comme smtp 1 et que ce soit possible ou non de passer en smtp1, comme ssh 1 et ssh 2 quoi.

huh ? pour la vérification des headers avant envoie de la totalité du message y-a imap mais je sais pas si c'est de ça que tu parles (pas bien compris)
pour l'intégrité y-a la signature gpg
 

bah évidemment l'email d'envoi est facile à spoofer mais apres il reste l'ip de toutes les machines par où ça passe, je trouve ça déjà pas si mal (enfin je connais pas bien le protocole mais ça me parait difficile à contourner)
 

bah là le pb c'est clairement la configuration et on aura beau créé tous les protocoles qu'on veut, si y-a des boulets qui se conf en relai, le pb sera toujours présent
 

bah avec les ip il peut black listé à tout va mais ça peut vite grimper vu l'ampleur que le spam à prix
 

c'est déjà le cas chez wanadoo et tele2 par exemple il me semble
donc c'est faisable mais là encore, faudrait que tout le monde s'en prenne la peine
 

alors là j'ai rien compris
skoi roaming ?  ("ho .... hu" ... nan mais il s'éclate le commentateur là )
 

toi tu vois un truc trop libre, moi je vois un truc modulaire où on peut faire plein de chose, du moisi, mais aussi du très bon donc au pire on peut le faire évoluer mais il est pas à jeter je trouve (enfin toujours en partant de mes connaissances )
 

ouai, rien de bien transcandant quoi  

dernz

udok : bah rien de transcendant on est d'accord, mais le fait est que sous sa forme actuelle y'a un pbm quand même
 
Disons qu'il faut configurer spécifiquement bcp de choses actuellement qu'il serait utile d'avoir à la base...
 
Le roaming ( ou je sais pas quel autre nom ), c'est juste que tu peux t'autentifier sur un serveur mail où tu as un compte pour pouvoir utiliser son smtp pour l'envoi alors que ton IP n'est pas forcément autorisée elle sur ce smtp.

 
Disons que roaming n'est pas spécifique au smtp, c'est un terme générique pour désigner quelque chose
 
to roam = ~ se déplacer d'un endroit à un autre  
 
Déjà si l'authentication smtp était obligatoire avant de se connecter, ca ferait déjà pas mal de problèmes en moins.

ouais ...
 
 
Bonjour

bonsoir !

 
Décalé  

Tu peux télécharger le même fichier en zip et tu te retrouves avec un .mov.

l'imap n'a pas grand intéret dans la vérification des headers

tu peux spoofer toute une série dans tes headers pour faire croire que ton mail a fait le tour du monde
et comme certains boulets d'admin blackliste le dernier smtp qui a reçu le mail ...
Si on commencait a appliquer SPF , cela commencerait a donner quelque chose , cela limiterait un peu le spam ( bon cela peut casser quelques petits trucs a coté mais on n'a pas d'omelette sans casser des oeufs )

hein ?
quel identification là ?
 

tu sous estimes fortement outlook express là et autre virii capable déja de piocher dans son carnet d'addresses , ils ne risquent pas de se géner a  aller vérifier le pass qu'on a mis en mémoire

je parle pas de ca

sauf que vivendi c est un editeur, blizard, sierra/valve sont en plus developpeurs

 
oui, mais d'un autre côté, si tu établis une chaine de confiance des serveurs SMTP, tu es en mesure de déterminer quel est le serveur SMTP boulaÿ qui a envoyé le spam.
 
Les headers de mon serveur de mail en .esiee.fr, ils sont vrais. Et si je m'assure que esiee.fr est bien configurer, je peux encore remonter.

le point important ici étant le si
enfin pour mémoire je critiquais les admins a deux balles des rbls hein ...
enfin boulaÿ pour te reprendre ....
edit: ah bas tu as édité
mais cela change rien quand aux admins de rbls boulay qui jugent que le smtp qui relaye est en faute .

bah fallait pas relayer

forcément tu ne relayes pas ton réseau  

effectivement

ah tiens, anectode marrante.
 
Je me suis inscrit pour aller à l'Apple Expo. Donc normalement, je devais recevoir un mail avec un numéro. Mail que je ne recevait jamais sur mon courrier en .esiee.fr
 
Pourquoi ? Parce que le serveur mail ( de l'application pro d'inscription en ligne ) était configuré comme une  merde et envoyait depuis un domaine inconnu  ( DNS )  

c'est la faute du serveur smtp de l'esiee qui est trop strict

http://www.esiee.fr/infos/mail.html
 
Problème de non délivrance de courrier électronique.
 
Ceci est du à une mauvaise configuration du DNS de l'ENVOYEUR ou de son ISP ( FAI en Français ).
 
En effet pour mériter le nom de host FQDN une machine connectée à l'Internet DOIT être configurée de la façon suivante dans la base de donnée de son serveur de noms (DNS).
 
Un DNS correctement configuré s'appuie sur deux bases "croisées" :
 
      une base contient la correspondance Nom de machine <--> adresse IP
      la deuxieme contient la correspondance adresse IP <--> Nom de machine
 
Par exemple pour mail.esiee.fr :
 
      dans la base 1 mail.esiee.fr = 147.215.1.3
      dans la base 2 147.215.1.3 = mail.esiee.fr
 
Le serveur de email de l'ESIEE refuse les connexions en provenance de machines mal configurées, afin de filtrer au maximum les emails indésirables (SPAM).
 
Enfin, certaines machines de SPAM sont INTENTIONNELLEMENT mal configurées pour brouiller les pistes.

bcp de societes, meme des tres grosses n ont pas de reverse

c'est pas fini

 
rien a voir
 
il s'agit de reverse n'ayant pas d'enregistrement DNS correspondant
 
par exemple, mon ip freebox, j'ai un reverse dns et un dns, meme si c'est un nom en segur-2.xx.xx.xx.xx.fbx.proxad.net

tu le fais exprès la hein ?  

gné ?
 
on peut très bien envoyer un mail sans reverse dns...
 
 
edit : enfin le terme exemple était maladroit, mais ca veut dire que je peux quand même envoyer un mail si j'ai  
 
farib.com -> ip
dslam-ip.fbx.proxad.net -> ip
ip -> dslam-ip.fbx.proxad.net

 
Le retour

tu as lu ce qu'a écris tomate ?

 
nope, c'est pas ça qui empeche d'envoyer le mail.
 
La société chez qui je fais mon stage n'a pas de reverse personalisé pour son domaine, et le mail n'est pas refusé par le serveur mail de l'esiee...

je n'ai jamais dis cela et tomate non plus ...
il a juste précisé que bcp d'entreprises n'avait pas de reverse sur l'ip de leur smtp afin d'apporter une précision a ton post initial .
apres c'est toi qui est parti en bourrasque

bah c vrai

je crois oui

vous aites méchan je retourn sou Window XP

Pour information, un confrère de tomate77 semble-t-il prépare quelque chose de fort intéressant :
http://www.kde-apps.org/content/show.php?content=15339