Je reçois parfois des mails de personnes qui disent avoir reçu un virus
de ma part. Ca m'énerve et je ne réponds même plus.
Mais là, sur un domaine (qui a un catch-all), j'ai un spammeur qui
envoie en masse en utilisant ce domaine, précédé de prénom aléatoire.
Y'a-t-il un risque quelconque d'être blacklisté à cause d'un simple
champ From "usurpé" (ce serait trop facile, mais avec la folie du spam,
on sait jamais) ?
:-) Fallait pas. En répondant tu as confirmé que quelqu'un (toi) lis cette adresse.
Merci, je suis pas tout à fait naïf. Je répondais à ceux qui m'écrivaient vraiment, pas aux robots. Je ne réponds plus à ceux qui m'envoient des hoax non plus.
:-)
Fallait pas.
En répondant tu as confirmé que quelqu'un (toi) lis cette adresse.
Merci, je suis pas tout à fait naïf. Je répondais à ceux qui
m'écrivaient vraiment, pas aux robots.
Je ne réponds plus à ceux qui m'envoient des hoax non plus.
:-) Fallait pas. En répondant tu as confirmé que quelqu'un (toi) lis cette adresse.
Merci, je suis pas tout à fait naïf. Je répondais à ceux qui m'écrivaient vraiment, pas aux robots. Je ne réponds plus à ceux qui m'envoient des hoax non plus.
bonjour,
"Xavier Roche" a écrit dans le message de news: f35uv1$amb$
Moi j'ai abandonné le catch-all, et installé SPF (quand le domaine le permet -- ce n'est pas toujours très pratique), qui protège non seulement les autres, mais également soi même (les mails venant de son propre domaine, depuis l'exterieur, sont alors très efficacement filtrés)
peut tu m'en dire plus sur le spf, en quoi cela permet d'eviter ce genre de problemes d'usurpation et comment doit t'il etre parametré sur la zone dns ?
bonjour,
"Xavier Roche" <xroche@free.fr.NOSPAM.invalid> a écrit dans le message de
news: f35uv1$amb$1@news.httrack.net...
Moi j'ai abandonné le catch-all, et installé SPF (quand le domaine le
permet -- ce n'est pas toujours très pratique), qui protège non
seulement les autres, mais également soi même (les mails venant de son
propre domaine, depuis l'exterieur, sont alors très efficacement filtrés)
peut tu m'en dire plus sur le spf, en quoi cela permet d'eviter ce genre de
problemes d'usurpation et comment doit t'il etre parametré sur la zone dns ?
"Xavier Roche" a écrit dans le message de news: f35uv1$amb$
Moi j'ai abandonné le catch-all, et installé SPF (quand le domaine le permet -- ce n'est pas toujours très pratique), qui protège non seulement les autres, mais également soi même (les mails venant de son propre domaine, depuis l'exterieur, sont alors très efficacement filtrés)
peut tu m'en dire plus sur le spf, en quoi cela permet d'eviter ce genre de problemes d'usurpation et comment doit t'il etre parametré sur la zone dns ?
LJVD
Olivier Masson wrote:
Mais là, sur un domaine (qui a un catch-all)
Oulah, un catch-all :p
Moi j'ai abandonné le catch-all, et installé SPF (quand le domaine le permet -- ce n'est pas toujours très pratique), qui protège non seulement les autres, mais également soi même (les mails venant de son propre domaine, depuis l'exterieur, sont alors très efficacement filt rés)
Cela n'a rien d'incompatible, les deux sont très complémentaires ... -- Laurent J.V. Dubois http://www.ljvd.com
Olivier Masson wrote:
Mais là, sur un domaine (qui a un catch-all)
Oulah, un catch-all :p
Moi j'ai abandonné le catch-all, et installé SPF (quand le domaine le
permet -- ce n'est pas toujours très pratique), qui protège non
seulement les autres, mais également soi même (les mails venant de son
propre domaine, depuis l'exterieur, sont alors très efficacement filt rés)
Cela n'a rien d'incompatible,
les deux sont très complémentaires ...
--
Laurent J.V. Dubois
http://www.ljvd.com
Moi j'ai abandonné le catch-all, et installé SPF (quand le domaine le permet -- ce n'est pas toujours très pratique), qui protège non seulement les autres, mais également soi même (les mails venant de son propre domaine, depuis l'exterieur, sont alors très efficacement filt rés)
Cela n'a rien d'incompatible, les deux sont très complémentaires ... -- Laurent J.V. Dubois http://www.ljvd.com
Xavier Roche
smaphi wrote:
peut tu m'en dire plus sur le spf
SPF déclare, pour un (sous) domaine donné, une liste de serveurs ayant l'autorisation d'envoyer du courrier avec ce nom.
Je peux par exemple déclarer que "les courriers en @example.com ne peuvent venir _que_ de 127.42.42.42 ; merci de refuser comme illégitime tout courrier qui ne proviendrait pas de ce serveur"
Evidemment, cela a quelques inconvénients: vous devez ensuite interdire les .forward, et interdire aux nomades d'envoyer du courrier en passant par autre chose que le serveur qui va bien (SMTP+auth).
smaphi wrote:
peut tu m'en dire plus sur le spf
SPF déclare, pour un (sous) domaine donné, une liste de serveurs ayant
l'autorisation d'envoyer du courrier avec ce nom.
Je peux par exemple déclarer que "les courriers en @example.com ne
peuvent venir _que_ de 127.42.42.42 ; merci de refuser comme illégitime
tout courrier qui ne proviendrait pas de ce serveur"
Evidemment, cela a quelques inconvénients: vous devez ensuite interdire
les .forward, et interdire aux nomades d'envoyer du courrier en passant
par autre chose que le serveur qui va bien (SMTP+auth).
SPF déclare, pour un (sous) domaine donné, une liste de serveurs ayant l'autorisation d'envoyer du courrier avec ce nom.
Je peux par exemple déclarer que "les courriers en @example.com ne peuvent venir _que_ de 127.42.42.42 ; merci de refuser comme illégitime tout courrier qui ne proviendrait pas de ce serveur"
Evidemment, cela a quelques inconvénients: vous devez ensuite interdire les .forward, et interdire aux nomades d'envoyer du courrier en passant par autre chose que le serveur qui va bien (SMTP+auth).
LJVD
LJVD wrote in news:4656266e$0$29412 $:
Cela permet de rassurer l'utilisateur sur la fiabilité du service.
Tout en le faisant persister dans son erreur d'adresse...
La réponse est simple : - voici le mail que vous n'avez pas reçu en effet, - Communiquez correctement votre adresse mail,
L'important est qu'il soit rassuré sur la qualité de l'infrastructure technique, qu'il ai des éléments à communiquer à l'expéditeur d e mail , et qu'il apprenne à bien donner son adresse.
Le plus simple est de donner accès a la boite catch-all.
Pour une recherche, cela pourrait faire l'objet d'un service à la demande, un peu comme chez nos amis banquiers pour la recherche de documents.
Le classique est une erreur d'imprimerie ou de mailing, nécessitant de mettre en place un alias ou une réponse automatique. Il est intéressant de pouvoir s'en apercevoir.
Pour ces raisons, et dans le cadre d'usage professionnel, le catch-all me semble incontournable.
CQFD Qualité de service -- Laurent J.V. Dubois - 06 65 45 82 86 http://www.ljvd.com
LJVD <ljvd@freeeeeeeeeeee.fr.invalid> wrote in news:4656266e$0$29412
$426a74cc@news.free.fr:
Cela permet de rassurer l'utilisateur sur la fiabilité du service.
Tout en le faisant persister dans son erreur d'adresse...
La réponse est simple :
- voici le mail que vous n'avez pas reçu en effet,
- Communiquez correctement votre adresse mail,
L'important est qu'il soit rassuré sur la qualité de l'infrastructure
technique, qu'il ai des éléments à communiquer à l'expéditeur d e mail ,
et qu'il apprenne à bien donner son adresse.
Le plus simple est de donner accès a la boite catch-all.
Pour une recherche, cela pourrait faire l'objet d'un service à la
demande, un peu comme chez nos amis banquiers pour la recherche de
documents.
Le classique est une erreur d'imprimerie ou de mailing,
nécessitant de mettre en place un alias ou une réponse automatique.
Il est intéressant de pouvoir s'en apercevoir.
Pour ces raisons, et dans le cadre d'usage professionnel, le catch-all
me semble incontournable.
CQFD Qualité de service
--
Laurent J.V. Dubois - 06 65 45 82 86
http://www.ljvd.com
Cela permet de rassurer l'utilisateur sur la fiabilité du service.
Tout en le faisant persister dans son erreur d'adresse...
La réponse est simple : - voici le mail que vous n'avez pas reçu en effet, - Communiquez correctement votre adresse mail,
L'important est qu'il soit rassuré sur la qualité de l'infrastructure technique, qu'il ai des éléments à communiquer à l'expéditeur d e mail , et qu'il apprenne à bien donner son adresse.
Le plus simple est de donner accès a la boite catch-all.
Pour une recherche, cela pourrait faire l'objet d'un service à la demande, un peu comme chez nos amis banquiers pour la recherche de documents.
Le classique est une erreur d'imprimerie ou de mailing, nécessitant de mettre en place un alias ou une réponse automatique. Il est intéressant de pouvoir s'en apercevoir.
Pour ces raisons, et dans le cadre d'usage professionnel, le catch-all me semble incontournable.
CQFD Qualité de service -- Laurent J.V. Dubois - 06 65 45 82 86 http://www.ljvd.com
Romain Tournier
LJVD wrote in <4656b30f$0$31046$:
LJVD wrote in news:4656266e$0$29412 $:
Cela permet de rassurer l'utilisateur sur la fiabilité du service. Tout en le faisant persister dans son erreur d'adresse...
L'important est qu'il soit rassuré sur la qualité de l'infrastructure
technique, qu'il ai des éléments à communiquer à l'expéditeur de mail , et qu'il apprenne à bien donner son adresse. [...]
Pour ces raisons, et dans le cadre d'usage professionnel, le catch-all me semble incontournable.
heu.... les logs des serveurs de mails ne suffisent pas pour avoir une trace que le mail est bien passé par l'infrastructure de mail et de recuperer les informations pertinentes (message d'erreur) sur la raison pour laquelle la personne n'a pas recu le mail ?
-- Romain
LJVD <ljvd@freeeeeeeeeeee.fr.invalid> wrote
in <4656b30f$0$31046$426a74cc@news.free.fr>:
LJVD <ljvd@freeeeeeeeeeee.fr.invalid> wrote in news:4656266e$0$29412
$426a74cc@news.free.fr:
Cela permet de rassurer l'utilisateur sur la fiabilité du service.
Tout en le faisant persister dans son erreur d'adresse...
L'important est qu'il soit rassuré sur la qualité de l'infrastructure
technique, qu'il ai des éléments à communiquer à l'expéditeur de mail ,
et qu'il apprenne à bien donner son adresse.
[...]
Pour ces raisons, et dans le cadre d'usage professionnel, le catch-all
me semble incontournable.
heu.... les logs des serveurs de mails ne suffisent pas pour avoir une
trace que le mail est bien passé par l'infrastructure de mail et de
recuperer les informations pertinentes (message d'erreur) sur la raison
pour laquelle la personne n'a pas recu le mail ?
Cela permet de rassurer l'utilisateur sur la fiabilité du service. Tout en le faisant persister dans son erreur d'adresse...
L'important est qu'il soit rassuré sur la qualité de l'infrastructure
technique, qu'il ai des éléments à communiquer à l'expéditeur de mail , et qu'il apprenne à bien donner son adresse. [...]
Pour ces raisons, et dans le cadre d'usage professionnel, le catch-all me semble incontournable.
heu.... les logs des serveurs de mails ne suffisent pas pour avoir une trace que le mail est bien passé par l'infrastructure de mail et de recuperer les informations pertinentes (message d'erreur) sur la raison pour laquelle la personne n'a pas recu le mail ?
-- Romain
LJVD
Pour ces raisons, et dans le cadre d'usage professionnel, le catch-all me semble incontournable.
heu.... les logs des serveurs de mails ne suffisent pas pour avoir une trace que le mail est bien passé par l'infrastructure de mail et de recuperer les informations pertinentes (message d'erreur) sur la raison pour laquelle la personne n'a pas recu le mail ?
Tu as raison, après il s'agit de niveau de service. Retrouver la trace ou retrouver le mail.
Ce n'est pas une règle d'or, juste un feed back ... Chaque hébergeur fournit le service qu'il veut. En tout cas, ce sont souvent sur des petits détails qui se font les choix. Le type d'arguments qui facilite la vie du commercial.
C'est comme le mode d'emploi pour le service RH du client, pour créer u n répondeur automatique et un alias par ses offres d'emploi, un point de détail.
Maintenant, il est vrai que chaque service supplémentaire nécessite d es ressources, à un coût. Si cela n'est pas facturé, n'apporte pas de plus-value, aucun intérê t.
Dans la réalité, le webmaster s'en occupe rarement, même si c'est s on boulot.
Devant la multitude des offres, pour se différencier, un hébergeur a tout intérêt à mettre en avant les atouts de son infrastructure technique sous forme d'avantages fonctionnels client.
Pour ces raisons, et dans le cadre d'usage professionnel, le catch-all
me semble incontournable.
heu.... les logs des serveurs de mails ne suffisent pas pour avoir une
trace que le mail est bien passé par l'infrastructure de mail et de
recuperer les informations pertinentes (message d'erreur) sur la raison
pour laquelle la personne n'a pas recu le mail ?
Tu as raison, après il s'agit de niveau de service.
Retrouver la trace ou retrouver le mail.
Ce n'est pas une règle d'or, juste un feed back ...
Chaque hébergeur fournit le service qu'il veut.
En tout cas, ce sont souvent sur des petits détails qui se font les
choix. Le type d'arguments qui facilite la vie du commercial.
C'est comme le mode d'emploi pour le service RH du client, pour créer u n
répondeur automatique et un alias par ses offres d'emploi, un point de
détail.
Maintenant, il est vrai que chaque service supplémentaire nécessite d es
ressources, à un coût.
Si cela n'est pas facturé, n'apporte pas de plus-value, aucun intérê t.
Dans la réalité, le webmaster s'en occupe rarement, même si c'est s on
boulot.
Devant la multitude des offres, pour se différencier,
un hébergeur a tout intérêt à mettre en avant les atouts de son
infrastructure technique sous forme d'avantages fonctionnels client.
Pour ces raisons, et dans le cadre d'usage professionnel, le catch-all me semble incontournable.
heu.... les logs des serveurs de mails ne suffisent pas pour avoir une trace que le mail est bien passé par l'infrastructure de mail et de recuperer les informations pertinentes (message d'erreur) sur la raison pour laquelle la personne n'a pas recu le mail ?
Tu as raison, après il s'agit de niveau de service. Retrouver la trace ou retrouver le mail.
Ce n'est pas une règle d'or, juste un feed back ... Chaque hébergeur fournit le service qu'il veut. En tout cas, ce sont souvent sur des petits détails qui se font les choix. Le type d'arguments qui facilite la vie du commercial.
C'est comme le mode d'emploi pour le service RH du client, pour créer u n répondeur automatique et un alias par ses offres d'emploi, un point de détail.
Maintenant, il est vrai que chaque service supplémentaire nécessite d es ressources, à un coût. Si cela n'est pas facturé, n'apporte pas de plus-value, aucun intérê t.
Dans la réalité, le webmaster s'en occupe rarement, même si c'est s on boulot.
Devant la multitude des offres, pour se différencier, un hébergeur a tout intérêt à mettre en avant les atouts de son infrastructure technique sous forme d'avantages fonctionnels client.
Le classique est une erreur d'imprimerie ou de mailing, nécessitant de mettre en place un alias ou une réponse automatique. Il est intéressant de pouvoir s'en apercevoir.
Hum, si une entreprise n'est pas capable de s'apercevoir de ça _avant_ de diffuser, elle ne fait pas correctement son boulot de communication. Et je la trouve aussi bien généreuse de se farcir du spam à cause de la négligence d'un employé ou prestataire...
Pour ces raisons, et dans le cadre d'usage professionnel, le catch-all me semble incontournable.
CQFD Qualité de service
Mon entreprise a assuré sa qualité de service sans catch-all pendant 18 ans, sans anicroche. Il est vrai que dans toute sa com', toutes les adresses étaient écrites sans fautes :-)
Cornelia
-- Be out and be proud - today is the first day of the rest of your life Support Transgenre Strasbourg : http://www.sts67.org BoW : http://www.bownbend.com GPG key ID 83FF7452, 659C 2B9F 7FD5 5C25 8C30 E723 4423 F8B8 83FF 7452
LJVD <ljvd@freeeeeeeeeeee.fr.invalid> wrote in news:4656b30f$0$31046
$426a74cc@news.free.fr:
Le classique est une erreur d'imprimerie ou de mailing,
nécessitant de mettre en place un alias ou une réponse automatique.
Il est intéressant de pouvoir s'en apercevoir.
Hum, si une entreprise n'est pas capable de s'apercevoir de ça _avant_ de
diffuser, elle ne fait pas correctement son boulot de communication. Et je
la trouve aussi bien généreuse de se farcir du spam à cause de la
négligence d'un employé ou prestataire...
Pour ces raisons, et dans le cadre d'usage professionnel, le catch-all
me semble incontournable.
CQFD Qualité de service
Mon entreprise a assuré sa qualité de service sans catch-all pendant 18
ans, sans anicroche. Il est vrai que dans toute sa com', toutes les
adresses étaient écrites sans fautes :-)
Cornelia
--
Be out and be proud - today is the first day of the rest of your life
Support Transgenre Strasbourg : http://www.sts67.org
BoW : http://www.bownbend.com
GPG key ID 83FF7452, 659C 2B9F 7FD5 5C25 8C30 E723 4423 F8B8 83FF 7452
Le classique est une erreur d'imprimerie ou de mailing, nécessitant de mettre en place un alias ou une réponse automatique. Il est intéressant de pouvoir s'en apercevoir.
Hum, si une entreprise n'est pas capable de s'apercevoir de ça _avant_ de diffuser, elle ne fait pas correctement son boulot de communication. Et je la trouve aussi bien généreuse de se farcir du spam à cause de la négligence d'un employé ou prestataire...
Pour ces raisons, et dans le cadre d'usage professionnel, le catch-all me semble incontournable.
CQFD Qualité de service
Mon entreprise a assuré sa qualité de service sans catch-all pendant 18 ans, sans anicroche. Il est vrai que dans toute sa com', toutes les adresses étaient écrites sans fautes :-)
Cornelia
-- Be out and be proud - today is the first day of the rest of your life Support Transgenre Strasbourg : http://www.sts67.org BoW : http://www.bownbend.com GPG key ID 83FF7452, 659C 2B9F 7FD5 5C25 8C30 E723 4423 F8B8 83FF 7452
LJVD
LJVD wrote in news:4656b30f$0$31046 $:
Le classique est une erreur d'imprimerie ou de mailing, nécessitant de mettre en place un alias ou une réponse automatique . Il est intéressant de pouvoir s'en apercevoir.
Hum, si une entreprise n'est pas capable de s'apercevoir de ça _avant _ de diffuser, elle ne fait pas correctement son boulot de communication.
L'erreur est humaine, en tout cas, c'est mon environnement :-)
Et je la trouve aussi bien généreuse de se farcir du spam à cause de la négligence d'un employé ou prestataire...
IL y a peut-être quiproquo alors. Il ne s'agit pas de router le catch-all vers une adresse email de travail, mais de le router vers une email poubelle dans laquelle tu peux jeter un oeil au besoin.
Mon entreprise a assuré sa qualité de service sans catch-all pendan t 18 ans, sans anicroche. Il est vrai que dans toute sa com', toutes les adresses étaient écrites sans fautes :-)
Du bonheur de travailler dans les grosses structures, avec du petit personnel pour lire et relire. Tu as bien de la chance.
Les entreprises que j'accompagne sont plus souvent des PME ... Ceci explique sûrement cela. -- Laurent J.V. Dubois - 06 65 45 82 86 http://www.ljvd.com
LJVD <ljvd@freeeeeeeeeeee.fr.invalid> wrote in news:4656b30f$0$31046
$426a74cc@news.free.fr:
Le classique est une erreur d'imprimerie ou de mailing,
nécessitant de mettre en place un alias ou une réponse automatique .
Il est intéressant de pouvoir s'en apercevoir.
Hum, si une entreprise n'est pas capable de s'apercevoir de ça _avant _ de
diffuser, elle ne fait pas correctement son boulot de communication.
L'erreur est humaine, en tout cas, c'est mon environnement :-)
Et je
la trouve aussi bien généreuse de se farcir du spam à cause de la
négligence d'un employé ou prestataire...
IL y a peut-être quiproquo alors.
Il ne s'agit pas de router le catch-all vers une adresse email de
travail, mais de le router vers une email poubelle dans laquelle tu peux
jeter un oeil au besoin.
Mon entreprise a assuré sa qualité de service sans catch-all pendan t 18
ans, sans anicroche. Il est vrai que dans toute sa com', toutes les
adresses étaient écrites sans fautes :-)
Du bonheur de travailler dans les grosses structures,
avec du petit personnel pour lire et relire.
Tu as bien de la chance.
Les entreprises que j'accompagne sont plus souvent des PME ...
Ceci explique sûrement cela.
--
Laurent J.V. Dubois - 06 65 45 82 86
http://www.ljvd.com
Le classique est une erreur d'imprimerie ou de mailing, nécessitant de mettre en place un alias ou une réponse automatique . Il est intéressant de pouvoir s'en apercevoir.
Hum, si une entreprise n'est pas capable de s'apercevoir de ça _avant _ de diffuser, elle ne fait pas correctement son boulot de communication.
L'erreur est humaine, en tout cas, c'est mon environnement :-)
Et je la trouve aussi bien généreuse de se farcir du spam à cause de la négligence d'un employé ou prestataire...
IL y a peut-être quiproquo alors. Il ne s'agit pas de router le catch-all vers une adresse email de travail, mais de le router vers une email poubelle dans laquelle tu peux jeter un oeil au besoin.
Mon entreprise a assuré sa qualité de service sans catch-all pendan t 18 ans, sans anicroche. Il est vrai que dans toute sa com', toutes les adresses étaient écrites sans fautes :-)
Du bonheur de travailler dans les grosses structures, avec du petit personnel pour lire et relire. Tu as bien de la chance.
Les entreprises que j'accompagne sont plus souvent des PME ... Ceci explique sûrement cela. -- Laurent J.V. Dubois - 06 65 45 82 86 http://www.ljvd.com
Stephane Kanschine
Le Fri, 25 May 2007 11:35:50 +0200, Xavier Roche exprimait :
smaphi wrote:
peut tu m'en dire plus sur le spf
SPF déclare, pour un (sous) domaine donné, une liste de serveurs ayant l'autorisation d'envoyer du courrier avec ce nom. [...]
Evidemment, cela a quelques inconvénients: vous devez ensuite interdire les .forward, et interdire aux nomades d'envoyer du courrier en passant par autre chose que le serveur qui va bien (SMTP+auth).
Le .forward est une excellente raison d'utiliser un système qui a une rfc (qui a été calqué sur la vie réelle quoi) : http://www.ietf.org/html.charters/dkim-charter.html
-- Stephane Kanschine Association APINC : http://www.apinc.org/
Le Fri, 25 May 2007 11:35:50 +0200, Xavier Roche exprimait :
smaphi wrote:
peut tu m'en dire plus sur le spf
SPF déclare, pour un (sous) domaine donné, une liste de serveurs ayant
l'autorisation d'envoyer du courrier avec ce nom.
[...]
Evidemment, cela a quelques inconvénients: vous devez ensuite interdire
les .forward, et interdire aux nomades d'envoyer du courrier en passant
par autre chose que le serveur qui va bien (SMTP+auth).
Le .forward est une excellente raison d'utiliser un système qui a une
rfc (qui a été calqué sur la vie réelle quoi) :
http://www.ietf.org/html.charters/dkim-charter.html
--
Stephane Kanschine
Association APINC : http://www.apinc.org/
Le Fri, 25 May 2007 11:35:50 +0200, Xavier Roche exprimait :
smaphi wrote:
peut tu m'en dire plus sur le spf
SPF déclare, pour un (sous) domaine donné, une liste de serveurs ayant l'autorisation d'envoyer du courrier avec ce nom. [...]
Evidemment, cela a quelques inconvénients: vous devez ensuite interdire les .forward, et interdire aux nomades d'envoyer du courrier en passant par autre chose que le serveur qui va bien (SMTP+auth).
Le .forward est une excellente raison d'utiliser un système qui a une rfc (qui a été calqué sur la vie réelle quoi) : http://www.ietf.org/html.charters/dkim-charter.html
-- Stephane Kanschine Association APINC : http://www.apinc.org/
