j'aimerais que l'expéditeur d'un mail à ma bal ne sache pas si le mail en
question est bien parvenue à destination.
Le but est d'éviter de renseigner les pirates sur l'exactitude des adresses e-
mail.
Je ne craint pas particulièrement les spam puisque je peu éliminer les
expéditeurs non autorisés , mais je crains d'être submerger et avoir mon serveur
bloqué.
Il s'agit d'un projet pour un serveur à vocation commerciale.
Cordialement,
Pierre
--
Ce message a été posté via la plateforme Web club-Internet.fr
This message has been posted by the Web platform club-Internet.fr
Le routage BGP, les serveurs secondaires ou relais, les DSN ; qui gère et qui paye cela?
Pierre -- Ce message a été posté via la plateforme Web club-Internet.fr This message has been posted by the Web platform club-Internet.fr
http://forums.club-internet.fr/
yves
Voici quelques infos qui peuvent peut-être t'aider un peu:
Le design de SMTP est basé sur le modèle suivant de communication : suite à une requête de l'utilisateur du courrier user, L'émetteur SMTP établit une communication bidirectionnelle vers un récepteur-SMTP. Celui-ci peut être soit la destination finale, soit seulement un intermédiaire. Les commandes SMTP sont générées par l'émetteur SMTP et sont émises vers le récepteur SMTP. Les réponses SMTP sont envoyées par le récepteur-SMTP à l'émetteur-SMTP en réponse aux commandes. Une fois le canal de transmission établi, l'émetteur SMTP envoie une commande MAIL mentionnant l'émetteur d'un courrier. Si le récepteur SMTP peut accepter le courrier, il répondra par un message OK. L'émetteur-SMTP envoie alors une commande RCPT identifiant un récipiendaire pour ce courrier. Si le récepteur- SMTP peut accepter un courrier pour ce récipiendaire, alors il répondra par un message OK ; sinon, il répond par un message refusant le courrier pour ce récipiendaire (mais n'annulant totalement pas la transaction de courrier). L'émetteur SMTP et le récepteur SMTP pourront négocier plusieurs récipiendaires. Une fois cette négociation effectuée, l'émetteur SMTP envoie le contenu du courrier, en le terminant par une séquence spéciale. Si le récepteur SMTP traite avec succès la réception du contenu du courrier, il répondra par un message OK. Le dialogue est volontairement un dialogue pas à pas, à étapes verrouillées.
-- Ce message a été posté via la plateforme Web club-Internet.fr This message has been posted by the Web platform club-Internet.fr
http://forums.club-internet.fr/
Voici quelques infos qui peuvent peut-être t'aider un peu:
Le design de SMTP est basé sur le modèle suivant de communication : suite à une
requête de l'utilisateur du courrier user, L'émetteur SMTP établit une
communication bidirectionnelle vers un récepteur-SMTP. Celui-ci peut être soit
la destination finale, soit seulement un intermédiaire. Les commandes SMTP sont
générées par l'émetteur SMTP et sont émises vers le récepteur SMTP. Les réponses
SMTP sont envoyées par le récepteur-SMTP à l'émetteur-SMTP en réponse aux
commandes.
Une fois le canal de transmission établi, l'émetteur SMTP envoie une commande
MAIL mentionnant l'émetteur d'un courrier. Si le récepteur SMTP peut accepter le
courrier, il répondra par un message OK. L'émetteur-SMTP envoie alors une
commande RCPT identifiant un récipiendaire pour ce courrier. Si le récepteur-
SMTP peut accepter un courrier pour ce récipiendaire, alors il répondra par un
message OK ; sinon, il répond par un message refusant le courrier pour ce
récipiendaire (mais n'annulant totalement pas la transaction de courrier).
L'émetteur SMTP et le récepteur SMTP pourront négocier plusieurs récipiendaires.
Une fois cette négociation effectuée, l'émetteur SMTP envoie le contenu du
courrier, en le terminant par une séquence spéciale. Si le récepteur SMTP traite
avec succès la réception du contenu du courrier, il répondra par un message OK.
Le dialogue est volontairement un dialogue pas à pas, à étapes verrouillées.
--
Ce message a été posté via la plateforme Web club-Internet.fr
This message has been posted by the Web platform club-Internet.fr
Voici quelques infos qui peuvent peut-être t'aider un peu:
Le design de SMTP est basé sur le modèle suivant de communication : suite à une requête de l'utilisateur du courrier user, L'émetteur SMTP établit une communication bidirectionnelle vers un récepteur-SMTP. Celui-ci peut être soit la destination finale, soit seulement un intermédiaire. Les commandes SMTP sont générées par l'émetteur SMTP et sont émises vers le récepteur SMTP. Les réponses SMTP sont envoyées par le récepteur-SMTP à l'émetteur-SMTP en réponse aux commandes. Une fois le canal de transmission établi, l'émetteur SMTP envoie une commande MAIL mentionnant l'émetteur d'un courrier. Si le récepteur SMTP peut accepter le courrier, il répondra par un message OK. L'émetteur-SMTP envoie alors une commande RCPT identifiant un récipiendaire pour ce courrier. Si le récepteur- SMTP peut accepter un courrier pour ce récipiendaire, alors il répondra par un message OK ; sinon, il répond par un message refusant le courrier pour ce récipiendaire (mais n'annulant totalement pas la transaction de courrier). L'émetteur SMTP et le récepteur SMTP pourront négocier plusieurs récipiendaires. Une fois cette négociation effectuée, l'émetteur SMTP envoie le contenu du courrier, en le terminant par une séquence spéciale. Si le récepteur SMTP traite avec succès la réception du contenu du courrier, il répondra par un message OK. Le dialogue est volontairement un dialogue pas à pas, à étapes verrouillées.
-- Ce message a été posté via la plateforme Web club-Internet.fr This message has been posted by the Web platform club-Internet.fr
http://forums.club-internet.fr/
db
Pierre wrote:
Merci pour vos intéressantes réponses.
Cependant, mon poste initial est très ciblé : Je part du postulat que mon ordinateur est correctement protéger et bien évidemment cela peu prêter à discutions, mais ce n'est pas le sujet que je souhaite aborder ici.
Il s'agit en fait de me protéger contre le blocage éventuel de mon serveur en raison de l'obligation de devoir virer les courriers entrants non sollicités, cela oblige à trier et peu prendre du temps.
Si le pirate n'est pas informé que les mail qu'il envoie arrivent à destination, quel intérêt a-t-il à émettre dans le vide ? Il s'agit bien d'un pirate qui essai d'infecter ou d'entrer dans mon ordinateur, et non d'un simple spammeur
Un contributeur à écrit "si le mail n'est pas retourné c'est qu'il est BIEN arrivé" j'aimerais donc savoir si cela est dû à internet ou à un protocole ou à une autre chose ? Cela fait ou plutôt l'inverse (l'accusé de non-remise) fait partie du
protocole SMTP et DOIT ETRE (*) respecté pour un bon fonctionnement du courrier électronique sur l'Internet. Bien entendu, lorsque les auteurs du RFC 822 ont écrit cela ils n'imaginaient pas que 15 ans plus tard le monde souffrirait du SPAM. De toute manière le SPAM n'est pas une raison suffisante pour neutraliser cet élément protocolaire.
1. L'adresse de l'expéditeur à 99% de chance de ne pas exister donc accusé ou pas peu importe.
2. Les spammeurs ne sont pas forcément idiots (étant donné qu'il s'agit d'un business à part entière et donc qu'il y a pas mal de fric derrière) et une absence d'accusé de non-remise ne signifie pas pour autant que le courrier est parvenu à destination. Ils connaissent l'existence des << trous noirs
et continueront à << émettre dans le vide >> jusqu'à preuve du contraire ! 2 ou 3 millions d'adresses en plus ne leur posent pas de
problèmes particuliers : c'est gratuit ! Il n'est pas rare de voir des adresses générées automatiquement : aaa, aab, aac, etc C'est idiot mais au final l'une finira par passer et une réponse (humaine) sera fournie ce qui permettra de mettre à jour leur base.
Pour ce qui est des spammeurs idiots, ceux-là sont incurables et l'accusé de non-remise ne suffira jamais à supprimer la fausse adresse de leur base étant donné qu'ils ne recoivent JAMAIS cet accusé de non-remise (postulat 1).
Le problème n'est pas à traiter au niveau des adresses de destination mais d'abord au niveau des adresses d'expéditeur : I. tout domaine inexistant doit conduire le mail à la poubelle ; II. toute adresse ne figurant pas dans une liste blanche entraîne un traitement spécial du mail : mise en attente (liste grise), demande de renseigneemnt ; III. ensuite, vient l'analyse de contenu afin d'aider à la prise de décision dans la phase II voire dans un passage ultérieur dans la phase I là où l'ensemble du mail n'a pas encore été transféré.
db
Cordialement, Pierre
-- email : usenet blas net
Pierre wrote:
Merci pour vos intéressantes réponses.
Cependant, mon poste initial est très ciblé :
Je part du postulat que mon ordinateur est correctement protéger et bien
évidemment cela peu prêter à discutions, mais ce n'est pas le sujet que je
souhaite aborder ici.
Il s'agit en fait de me protéger contre le blocage éventuel de mon serveur
en raison de l'obligation de devoir virer les courriers entrants non
sollicités,
cela oblige à trier et peu prendre du temps.
Si le pirate n'est pas informé que les mail qu'il envoie arrivent à
destination, quel intérêt a-t-il à émettre dans le vide ?
Il s'agit bien d'un pirate qui essai d'infecter ou d'entrer dans mon
ordinateur, et non d'un simple spammeur
Un contributeur à écrit "si le mail n'est pas retourné c'est qu'il est
BIEN
arrivé" j'aimerais donc savoir si cela est dû à internet ou à un
protocole ou à une autre chose ?
Cela fait ou plutôt l'inverse (l'accusé de non-remise) fait partie du
protocole SMTP et DOIT ETRE (*) respecté pour un bon fonctionnement du
courrier électronique sur l'Internet.
Bien entendu, lorsque les auteurs du RFC 822 ont écrit cela ils
n'imaginaient pas que 15 ans plus tard le monde souffrirait du SPAM.
De toute manière le SPAM n'est pas une raison suffisante pour neutraliser
cet élément protocolaire.
1. L'adresse de l'expéditeur à 99% de chance de ne pas exister donc
accusé ou pas peu importe.
2. Les spammeurs ne sont pas forcément idiots (étant donné qu'il s'agit d'un
business à part entière et donc qu'il y a pas mal de fric derrière) et une
absence d'accusé de non-remise ne signifie pas pour autant que le courrier
est parvenu à destination. Ils connaissent l'existence des << trous noirs
et continueront à << émettre dans le vide >> jusqu'à preuve du
contraire ! 2 ou 3 millions d'adresses en plus ne leur posent pas de
problèmes particuliers : c'est gratuit !
Il n'est pas rare de voir des adresses générées automatiquement :
aaa, aab, aac, etc
C'est idiot mais au final l'une finira par passer et une réponse (humaine)
sera fournie ce qui permettra de mettre à jour leur base.
Pour ce qui est des spammeurs idiots, ceux-là sont incurables et l'accusé de
non-remise ne suffira jamais à supprimer la fausse adresse de leur base
étant donné qu'ils ne recoivent JAMAIS cet accusé de non-remise (postulat
1).
Le problème n'est pas à traiter au niveau des adresses de destination mais
d'abord au niveau des adresses d'expéditeur :
I. tout domaine inexistant doit conduire le mail à la poubelle ;
II. toute adresse ne figurant pas dans une liste blanche entraîne un
traitement spécial du mail : mise en attente (liste grise), demande de
renseigneemnt ;
III. ensuite, vient l'analyse de contenu afin d'aider à la prise de décision
dans la phase II voire dans un passage ultérieur dans la phase I là où
l'ensemble du mail n'a pas encore été transféré.
Cependant, mon poste initial est très ciblé : Je part du postulat que mon ordinateur est correctement protéger et bien évidemment cela peu prêter à discutions, mais ce n'est pas le sujet que je souhaite aborder ici.
Il s'agit en fait de me protéger contre le blocage éventuel de mon serveur en raison de l'obligation de devoir virer les courriers entrants non sollicités, cela oblige à trier et peu prendre du temps.
Si le pirate n'est pas informé que les mail qu'il envoie arrivent à destination, quel intérêt a-t-il à émettre dans le vide ? Il s'agit bien d'un pirate qui essai d'infecter ou d'entrer dans mon ordinateur, et non d'un simple spammeur
Un contributeur à écrit "si le mail n'est pas retourné c'est qu'il est BIEN arrivé" j'aimerais donc savoir si cela est dû à internet ou à un protocole ou à une autre chose ? Cela fait ou plutôt l'inverse (l'accusé de non-remise) fait partie du
protocole SMTP et DOIT ETRE (*) respecté pour un bon fonctionnement du courrier électronique sur l'Internet. Bien entendu, lorsque les auteurs du RFC 822 ont écrit cela ils n'imaginaient pas que 15 ans plus tard le monde souffrirait du SPAM. De toute manière le SPAM n'est pas une raison suffisante pour neutraliser cet élément protocolaire.
1. L'adresse de l'expéditeur à 99% de chance de ne pas exister donc accusé ou pas peu importe.
2. Les spammeurs ne sont pas forcément idiots (étant donné qu'il s'agit d'un business à part entière et donc qu'il y a pas mal de fric derrière) et une absence d'accusé de non-remise ne signifie pas pour autant que le courrier est parvenu à destination. Ils connaissent l'existence des << trous noirs
et continueront à << émettre dans le vide >> jusqu'à preuve du contraire ! 2 ou 3 millions d'adresses en plus ne leur posent pas de
problèmes particuliers : c'est gratuit ! Il n'est pas rare de voir des adresses générées automatiquement : aaa, aab, aac, etc C'est idiot mais au final l'une finira par passer et une réponse (humaine) sera fournie ce qui permettra de mettre à jour leur base.
Pour ce qui est des spammeurs idiots, ceux-là sont incurables et l'accusé de non-remise ne suffira jamais à supprimer la fausse adresse de leur base étant donné qu'ils ne recoivent JAMAIS cet accusé de non-remise (postulat 1).
Le problème n'est pas à traiter au niveau des adresses de destination mais d'abord au niveau des adresses d'expéditeur : I. tout domaine inexistant doit conduire le mail à la poubelle ; II. toute adresse ne figurant pas dans une liste blanche entraîne un traitement spécial du mail : mise en attente (liste grise), demande de renseigneemnt ; III. ensuite, vient l'analyse de contenu afin d'aider à la prise de décision dans la phase II voire dans un passage ultérieur dans la phase I là où l'ensemble du mail n'a pas encore été transféré.
