Aide postfix sur blocage d'une extensions de domaine

dodo.deejay · Le 24/10/2019, à 17:09

Bonjour,

J'ai besoin de votre aide svp

J'ai un serveur postfix qui fonctionne bien.

Dans mon main.cf j'ai :

smtpd_recipient_restrictions =

check_sender_access pcre:/etc/postfix/reject_domains,
check_sender_access pcre:/etc/postfix/reject_domains_all

Dans reject_domains il y a les extensions de domaine que j'accepte, jusqu’à la tous fonctionne exemple

/\.fr$/ OK

Dans reject_domains_all il y a

]/\.*$/ REDIRECT .....

Sa fonctionne plutôt pas mal !
J accepte les extensions de domaine que je veux puis, je refuse tous les autres (ça tourne déjà depuis 6 mois comme sa)
Mais j'ai certains mail légitime qui saute le reject_domains on dirais ! j'ai pas mal d'accuser de réception & de réponse automatique qui sont renvoyer sur mon adresse xxx@xxx.xx alors que c'est bien un .FR
Mais seulement sur des accuser de réception & de temps en temps sur réponse automatique! tous les autres mail passe correctement ou sont bloquer si il ne sont pas dans la liste.
Je ne comprend pas pourquoi...

Merci

bruno · Le 24/10/2019, à 18:02

Bonjour,

Peux-tu expliquer la pertinence d'un check_sender_access (vérification sur le MAIL FROM) avec smtpd_recipient_restrictions (restrictions sur le RCPT TO) ?

dodo.deejay · Le 24/10/2019, à 19:11

Bonjour Bruno

C’est la ou je suis un peu perdu..
Il aurais fallu mettre les ligne dans smtpd_client_acces ?

bruno · Le 24/10/2019, à 20:15

dodo.deejay a écrit :

Bonjour Bruno
C’est la ou je suis un peu perdu..
Il aurais fallu mettre les ligne dans smtpd_client_acces ?

Où as-tu vu cette directive dans la doc ? Lire la doc, re-lire la doc, en cas de doute se référer à la doc.
À ma connaissance, elle n'existe pas.

Si tu es capable de configurer postfix avec du filtrage via des expressions régulières, tu es capable de comprendre qu'il n'y aucune logique à mettre un filtre sur l'adresse de l’expéditeur (check_sender_access) dans une directive qui teste l'adresse du destinataire (smtpd_recipient_restrictions). Je me demande bien quel est l'objectif de cette tentative de filtrage d'ailleurs…

Dernière modification par bruno (Le 24/10/2019, à 20:23)

dodo.deejay · Le 24/10/2019, à 21:55

je crois que j'ai compris

du coup sa sa serais plus logique comme ceci :

smtpd_recipient_restrictions =
 check_recipient_access pcre:/etc/postfix/reject_domains,
 check_recipient_access pcre:/etc/postfix/reject_domains_all

Dernière modification par dodo.deejay (Le 24/10/2019, à 22:03)

bruno · Le 25/10/2019, à 07:58

Oui comme cela c'est cohérent.
Postfix vérifie l'adresse du destinataire, si l'adresse se termine par .fr, le courriel est envoyé à son destinataire et les règles suivantes sont ignorées. Si ce n'est pas le cas, le courriel n'est pas envoyé à son destinataire mais redirigé à l'adresse indiquée après le REDIRECT et les règles suivantes seront ignorées.

Je ne comprends toujours pas à quoi cela peut bien servir… En principe un serveur Postfix est censé permettre à ses utilisateurs d'envoyer des courriels vers n'importe quel destinataire (n'importe quel domaine) et recevoir les courriels pour tous ses destinataires finaux (domaines pour lequel il est configuré).

dodo.deejay · Le 25/10/2019, à 09:14

Bonjour Bruno

En faite c'est l'inverse que je veux faire,

Je t'explique.
Voici mon main.cf

smtpd_recipient_restrictions =
     check_sender_access hash:/etc/postfix/sender_checks,
     check_client_access hash:/etc/postfix/whitelist_antispam,
     reject_non_fqdn_sender,
     reject_unknown_sender_domain,
     reject_non_fqdn_recipient,
     permit_mynetworks,
     permit_sasl_authenticated,
     reject_non_fqdn_recipient,
     reject_unauth_destination,
     reject_unknown_recipient_domain,
     reject_rbl_client sbl.spamhaus.org,
     reject_rbl_client xbl.spamhaus.org,
     reject_rbl_client zen.spamhaus.org,
     reject_rbl_client cbl.abuseat.org,
     reject_rbl_client all.spam-rbl.fr,
     reject_rbl_client korea.services.net,
     reject_rbl_client bl.spamcop.net,
     reject_rbl_client dnsbl.inps.de,
     reject_rhsbl_sender dbl.spamhaus.org,
     reject_rhsbl_sender dbl.spamhaus.org,
     check_policy_service inet:127.0.0.1:10023,
     check_policy_service unix:private/policyd-spf,
     check_sender_access pcre:/etc/postfix/reject_domains,
     check_sender_access pcre:/etc/postfix/reject_domains_all

Dans le fichier /etc/postfix/sender_checks j'ai des domaines pour par exemple éviter xxx@xxx.fr passe par SPF a la réception du mail.
sa c'est ok sa fonctionne.
Dans le fichier /etc/postfix/reject_domains il ya les extensions que j'accepte (.fr,.com....)
Dans le fichier /etc/postfix/reject_domains_all je refuse tous les domaines.
Donc si je fais comme tu mas dis a place de check_sender_access je mes check_recipient_access, on dirais que cela fonctionne, mais que pour le domaine principal. pas pour les autres domaines. (c'est un serveur multi domaine)
Exemple : Avec la nouvelle configuration, j'envoi un mail de l'extérieur qui fini par .online si j'envoi sur une adresse ou le domaine est le principal, sa fonctionne. si je refais la même manip et que j'envoi sur un domaine qui n'est pas le principal, le mail passe, il n'est pas rediriger.
Il y a quelques chose que je ne comprend pas, car quand je remet check_sender_access, sa fonctionne pour tous les domaines, mais j'ai quelques mail, surtout des accuser de réception qui passe quand même. je ne comprend pas.
Mon but final, est que ; Je reçois un mail de l'extérieur, si il est en .fr, il passe. si c'est un .tu, redirection.
Mais seulement sur le réception d'un mail extérieur, pas si j'envoi un mail de mon serveur postfix.
J'ai le droit d'envoyer un mail vers un .tu, par exemple mais pas d'en recevoir.
Depuis que j'ai cette config, en plus de spamassassin, postgrey et j'en passe. j'évite énormément de spam, car souvent c'est des adresses qui finisse par .tu,.ui.... depuis que j'ai mis cette régler je n'ai pratiquement plus de spam.

bruno · Le 25/10/2019, à 10:02

Je ne comprends rien à ton charabia
Et tu fais cette fois ci l'erreur inverse ! Tu filtres sur une adresse d'expéditeur (check_sender_access) via une restriction qui teste l'adresse du destinataire (smtpd_recipient_restrictions)

Tout ce que je peux dire c'est que tu devrais faire très attention à l’ordre de tes règles. Lorsqu'une une règle de la liste est satisfaite, les suivantes sont ignorées.

Sur le principe, et en dehors de toute règles de filtrage, Postfix permet aux machines spécifiées dans $mynetworks (pour plus de sécurité uniquement l'interface de bouclage) d'envoyer des courriels vers n'importe quelle destination. Il ne peut recevoir que les courriels à destination des domaines spécifiés dans $mydestination et $virtual_mailbox_domains si tu utilises des domaines virtuels.

Ensuite tu peux filtrer avec des contrôles et restrictions basés sur :
- le client qui se connecte (IP, nom d‘hôte ou les deux) : smtpd_client_restrictions ;
- le «EHLO » envoyé par le client : smtpd_helo_restrictions ;
- l‘expéditeur du courriel (MAIL FROM ) smtpd_sender_restrictions ;
- le destinataire du courriel (RCPT TO) : smtpd_relay_restrictions et smtpd_recipient_restrictions
- le contenu du courriel (DATA) : smtpd_data_restrictions

Si tu ne veux pas recevoir de courriels provenant d'un expéditeur ayant une adresse en ****@****.tu, il faut filtrer sur l'expéditeur donc smtpd_sender_restrictions et mettre une règle qui vérifie l'adresse de l'expéditeur, donc check_sender_access. Exemple :

smtpd_sender_restrictions = permit_mynetworks,
                            permit_sasl_authenticated,
                            reject_unknown_sender_domain,
                            check_sender_access pcre:/etc/postfix/reject_domains,
                            check_sender_access pcre:/etc/postfix/reject_domains_all
                            permit

Dernière modification par bruno (Le 25/10/2019, à 10:02)

dodo.deejay · Le 25/10/2019, à 10:43

Je pense avoir compris
je test

Du coup

smtpd_sender_restrictions =

                            permit_sasl_authenticated,
                            reject_unknown_sender_domain,
                            check_sender_access hash:/etc/postfix/sender_checks,
                            check_sender_access pcre:/etc/postfix/reject_domains,
                            check_sender_access pcre:/etc/postfix/reject_domains_all
                            permit

C'est pas logique aussi d'avoir du coup check_sender_access hash:/etc/postfix/sender_checks dans smtpd_recipient_restrictions
Faut le rajouter dans smtpd_sender_restrictions

J'ai des domaines virtuels, qui sont dans une base SQL, normalement je n'ai pas a rajouter quoi ce se sois ?
Je test et je te dis sa début aprem

Merci a toi

Dernière modification par dodo.deejay (Le 25/10/2019, à 13:12)

dodo.deejay · Le 25/10/2019, à 13:13

Hello

Pour l'instant ça fonctionne avec cette config.
Je test quelques jours et je reviens vers toi
Merci beaucoup

Edit :

Je continue a recevoir des messages légitime
je ne comprend vraiment pas pourquoi! c'est que des réponse automatique et des accuse de réception...

Imagine :

toto@toto.fr envoi un mail a l'exterieur a bibi@bibi.fr. toto demande un accuse de reception.
le serveur de bibi repond avec postmaster@bibi.fr que c'est ok!
et la le mail est rediriger !!!
mais pourquoi ? postmater@bibi.fr est en .FR ! le mail devrai baypasser mon ficher /etc/postfix/reject_domains_all! et bah non:
Ce qui est incroyable dans l'histoire c'est que tous les autres mail fonctionne ! il y a que les accuser de réception et les réponse automatique!

Edit :

il y a même un mail (toujours un accuse de réception) d'un domaine qui est dans etc/postfix/sender_checks qui a était rediriger ! je trouve sa incroyable.
Çà veux dire quoi ? que les accuse de réception ne passe pas par le serveur ?
Merci

Edit :

A force de chercher j'ai trouver le point commun dans tous les mails qui était rediriger:

Return-Path: <>

Return-Path est VIDE !
Du coup je pense que c'est normal qui sois rediriger...
Je viens de voir que les règle fonctionne a partir du Return-Path

Mercii

Dernière modification par dodo.deejay (Le 25/10/2019, à 16:50)

dodo.deejay · Le 25/10/2019, à 20:29

Y a t'il une solution ? pourquoi le Return-Path: <> est vide dans certains accuse ?

Dernière modification par dodo.deejay (Le 25/10/2019, à 20:29)

bruno · Le 26/10/2019, à 10:51

Je ne sais pas trop quoi te dire surtout que je ne connais pas ta configuration (seulement un petit bout de restrictions), ni les en-têtes des courriels concernés, ni les logs du serveur.
D'autant plus qu'à mon humble avis, ta configuration de filtrage sur des TLD est complètement tordue et inefficace.

Une ou deux choses quand même.

dodo.deejay a écrit :

toto@toto.fr envoi un mail a l'exterieur a bibi@bibi.fr. toto demande un accuse de reception.
le serveur de bibi repond avec postmaster@bibi.fr que c'est ok!

Ce n'est pas le serveur bibi.fr qui répond. Un accusé de réception est renvoyé par le destinataire final, selon son bon vouloir. Il peut l'accepter, le refuser ou l'ignorer, voire bloquer globalement toute demande d'accusé de réception.
Si le destinataire bibi@bibi.fr accepte l'accusé de réception, son client de courriel va renvoyer automatiquement un message à toto@toto.fr. Et ceci, en principe avec bibi@bibi.fr comme expéditeur et non postmaster@bibi.fr. Un courriel envoyé par postmaster@bibi.fr est en général un retour d'erreur envoyé par le MTA de bibi.fr.

Ensuite un message peut très bien être envoyé avec un MAIL FROM toto@xample.com lors de la transaction SMTP et un champ From: toto@bibi.fr. Postfix filtre l'accès sur le MAIL FROM (commande SMTP), c'est à dire l’expéditeur réel et non celui spécifié dans les en-têtes du courriel.

Normalement l'en-tête return-path contient l'adresse de l'expéditeur réel : celui indiqué dans la commande MAIL FROM. Cette en-tête est ajouté (ou modifié) uniquement par le serveur SMTP qui reçoit le courriel. Cet en-tête est destiné, comme son nom l'indique, à savoir ou envoyer les retours d'erreurs. Il est fort probable (et logique) qu'il ne soit pas ajouté dans des courriels qui sont redirigés.

Dernière modification par bruno (Le 26/10/2019, à 10:53)

dodo.deejay · Le 26/10/2019, à 11:30

Je te confirme quand il y aux serveur exchange derrière, la plus part du temps c'est postmaster qui répond pour dire que le message a était remis.
Je t'assure que je bloque bcp de spam, car la plus part du temps ce qui est modifier justement c'est le FROM, et la il filtre sur le return-path
Je te montre une preuve :

Return-Path: <3120206.contact=masdeloncle.com@mpdkim2.ch>
Delivered-To: tech@xxx.xx
Received: from xxx.xx
	by xx.xx(Dovecot) with LMTP id WcxsMg4Ws12+jgAA6fLNtQ
	for <tech@xxx.xx>; Fri, 25 Oct 2019 17:34:38 +0200
X-Greylist: delayed 1929 seconds by postgrey-1.36 at xx.xx; Fri, 25 Oct 2019 17:34:38 CEST
Authentication-Results: xxx.xx; dkim=none; dkim-atps=neutral
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=194.158.17.5; helo=mail17-5.mail.maxony.net; envelope-from=3120206.contact=masdeloncle.com@mpdkim2.ch; receiver=<UNKNOWN> 
Received: from mail17-5.mail.maxony.net (mail17-5.mail.maxony.net [194.158.17.5])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by xxx.xx (Postfix) with ESMTPS id 75D2B4D603A9
	for <secretariat@xxx.xx>; Fri, 25 Oct 2019 17:34:37 +0200 (CEST)
Received: by mail101-59.mail.maxony.net id hmcb0s24meoq for <secretariat@xxx.xx>; Fri, 25 Oct 2019 17:02:27 +0200 (envelope-from <3120206.contact=masdeloncle.com@mpdkim2.ch>)
To: <secretariat@xxx.xx>
From: "=?utf-8?B?TUFTIERFIEwnT05DTEUgLSBQSUMgU0FJTlQgTE9VUA==?=" <contact@masdeloncle.com>
Subject: =?utf-8?Q?Retrouvez=20nous=20au=20Salon=20Vins=20et=20Terroirs=c2=a0=20en=20Novembre=202019?= 
Reply-To: contact@masdeloncle.com 
X-Sender: <contact@masdeloncle.com> 
X-AW1: 3120206 
X-AW2: 1022309045 
X-AW3: 1649548 
X-AW4: 81980 
X-AW5: 1289592 
X-AW6: 1 
MIME-Version: 1.0
Content-Type:multipart/alternative; boundary="mpadd22b11c04f427896880782749192c9"
Message-ID: <0.0.6.135.1D58B45376A9BAE.2BD9A@mail101-59.mail.maxony.net>
Date: Fri, 25 Oct 2019 17:34:38 +0200

Ce mail a bien était filtrer.
Regarde le FROM c'est un .com
Regarde le Return-Path c'est un ch.
Donc le filtre dans postfix filtre bien sur le Return-Path.
Donc normal quand il sois vide, il ne les filtres pas....
Il sont vide dans les accusées de réception par exemple.
Tu veux que je te montre le main.cf ?

Dernière modification par dodo.deejay (Le 26/10/2019, à 11:32)

bruno · Le 26/10/2019, à 12:35

Cecl confirme ce que je t'explique en #12.
Postfix ne filtre pas sur Return-Path mais sur la commande MAIL FROM. Return-Path est ajouté par Postfix.
Lorsque tu mets des restriction sur smtpd_sender_restrictions postfix examine le contenu de la commande MAIL FROM, il applique les règles que tu as défini et ajoute un champ Return-Path aux en-têtes du courriel avec le contenu de MAIL FROM.

Si tu vois un Return-Path vide ou pas de Return-Path, c'est que Postfix ne l'a pas ajouté.

dodo.deejay · Le 26/10/2019, à 12:55

Alors comment faire ?
Pourquoi quand les return-Path sont vide, il ne les filtres pas?

dodo.deejay · Le 26/10/2019, à 12:59

voici un mail filtrer qui ne devrais pas l'etre :

Return-Path: <>
Delivered-To: tech@xxx.xx
Received: from xx.xx
	by xxx (Dovecot) with LMTP id GfAdJfEXs12PkQAA6fLNtQ
	for <tech@xxxx.xx>; Fri, 25 Oct 2019 17:42:41 +0200
Received-SPF: Pass (helo) identity=helo; client-ip=40.92.64.107; helo=eur01-db5-obe.outbound.protection.outlook.com; envelope-from=<>; receiver=<UNKNOWN> 
Authentication-Results: xxx.xx; dkim=none; dkim-atps=neutral
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-oln040092064107.outbound.protection.outlook.com [40.92.64.107])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits))
	(No client certificate requested)
	by xx.xx (Postfix) with ESMTPS id 1B8214D6045A
	for <smacchi@xxxx.fr>; Fri, 25 Oct 2019 17:42:40 +0200 (CEST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Jfk3mI+f2x3PdLq77REyrKwp7/u+hy5c+bt9GkbUO1UPZbEHXqJAwWdnv5c2SA6NycEP71O/4CJTg+plx8ZSdyScz0YHu1UX5LkfQvQ2tAFYTlltJkymgPcnBDqYymmzA1FDtM0a8un7UWP0bDhhdOt82NAsl02bHHt+8U6akRvWOAHCsiMCnbiztyTuEYNLxFQBdgloB1I9O7CbWywrCaYqw02gJRqIFSW9jNVJZGZnPkf8QroOyY2jj/HegJjVEQ9ScrhRzGfAvRu73eESsjJMg2DCs/giYnyklg28+oTxlefhDp8li2NEkKVvTLWBHOd0u6gzSjy3Z0bDKZeyDw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=cuWTHUAZUaPOrcuOgBT6TJmXv7ruyiSL7/cZl4Bsvhg=;
 b=P1Yo7TkkHBcE00cgk09vr15TFTgSovHPCvLFw2RvQGiI+G7POe5zHZzSMOJw4KjWvlTqA5t3X0hH0JrWNRkSqoRHTJp1UgK71QZxRWpGksUzTF9cbfXVYjUkILR8Ypnp2UNiquU310CIHZ+W4zd0yvQaZCuWIr7NmLEBLwWpOb6Eirzfpe/ifk8ZaZLTR/CopP/Ua7HlekNRTzLTmPWCKDUM4X07X1ngyDwneKoWNL2YL2ry09cvYguftJu8JnECxTh+T76GeN1HY5nv3M+2y+PfSKsp1AIKG7miUhxpichUJpZ7jYAQAI9jJA2KYcmyVt7qQfUwsIwB6FFvxVKXbA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass; dmarc=pass
 action=none header.from=outlook.com; dkim=pass header.d=outlook.com; arc=none
MIME-Version: 1.0
From: <postmaster@outlook.com>
To: <smacchi@xxx.fr>
Date: Fri, 25 Oct 2019 15:42:39 +0000
Content-Type: multipart/report; report-type=delivery-status;
	boundary="a4a4c604-af02-4b69-b375-8dbac8e29949"
Content-Language: fr-FR
Message-ID:
 <66859ac9-5ef1-4121-8949-cdaf20fc1ea7@VE1EUR01HT171.mail.protection.outlook.com>
In-Reply-To: <e4cb510286d741d1a8043096efee78a2@xxx.fr>
References: <755d2af4420a45a5b80da187aa80da96@espacebois31.fr>
 <e4cb510286d741d1a8043096efee78a2@xxx.fr>
Thread-Topic: Documentation Espace Bois l'Apostrophe
Thread-Index: AdWLSZwUgli07TU7SEC4NVXiIYpDDwAAbfCQAAAfpfM=
Subject: Remis : TR: Documentation Espace Bois l'Apostrophe
Auto-Submitted: auto-replied
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: VE1EUR01HT171:
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	7fHCs+SaOUhhs3cjeIhTGCeF6Uy/Gs6cilOsRjBd4GPQGjCtSqshyqz6CvBmSJrzPureEkt0W0uGrmtlvsVu9wr4IiZg30m+DmQ2cKeuXNpXNI9KH0N3ctVFdJuu/aqb5UJ3qrmaF9YLSmwYUI6ofM7bGpr7Wh2RTH6TKKTGdehCzNyzVZJosGrKZgm1zWoZ
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Oct 2019 15:42:39.8846
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Network-Message-Id:
	0a4b4c12-d67a-40c9-cbd7-08d75961f7b6
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1EUR01HT171

Dernière modification par dodo.deejay (Le 26/10/2019, à 13:39)

bruno · Le 26/10/2019, à 15:11

Cela ne sert pas à grand chose. C'est le courriel redirigé vers tech@xxx.xx. Il faudrait voir le courriel d'origine (en enlevant tes filtres su le nom de domaines) et examiner les logs.
En plus c'est du outlook, la pire chose qui soit pour essayer de déboguer l'envoi ou la réception de courriel. Les serveurs Microsoft font plein de trucs bizarres et non documentés et ne respectent pas les RFC.

dodo.deejay · Le 26/10/2019, à 17:08

Bruno j'ai désactiver le filtre et j'ai envoyer le mail vers une adresse en orange qui a une réponse automatique. du coup le mail est passé car pas de filtre, mais il il y avais le filtre ce mail aurais était rediriger pourquoi ? voici :
(j'ai pris c'est log sur roundcube de mon serveur postfix.)

Return-Path: <>
Delivered-To: sav@client.fr
Received: from monserveur.pro
    by monserveur.pro (Dovecot) with LMTP id 5+h1H1hstF1iOwAA6fLNtQ
    for <sav@client.fr>; Sat, 26 Oct 2019 17:55:04 +0200
Received: from localhost (localhost [127.0.0.1])
    by monserveur.pro (Postfix) with ESMTP id 7D29C4D60531
    for <sav@client.fr>; Sat, 26 Oct 2019 17:55:04 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at monserveur.pro
Received: from monserveur.pro ([127.0.0.1])
    by localhost (monserveur.pro [127.0.0.1]) (amavisd-new, port 10024)
    with ESMTP id dQqraISGA6Mx for <sav@client.fr>;
    Sat, 26 Oct 2019 17:55:04 +0200 (CEST)
Received-SPF: None (no SPF record) identity=no SPF record; client-ip=193.252.22.211; helo=out.smtpout.orange.fr; envelope-from=<>; receiver=<UNKNOWN>
Authentication-Results: monserveur.pro; dkim=none; dkim-atps=neutral
Received: from out.smtpout.orange.fr (out02.smtpout.orange.fr [193.252.22.211])
    (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
    (No client certificate requested)
    by monserveur.pro (Postfix) with ESMTPS id 22C9F4D604E6
    for <sav@client.fr>; Sat, 26 Oct 2019 17:55:03 +0200 (CEST)
Received: from mwinb2606.me-wanadoo.net ([10.223.3.77])
    by mwinf5d06 with ME
    id JFv3210071fhwUy03Fv3hs; Sat, 26 Oct 2019 17:55:03 +0200
X-ME-Helo: mwinb2606.me-wanadoo.net
X-ME-Date: Sat, 26 Oct 2019 17:55:03 +0200
X-ME-IP: 10.223.3.77
Received: by mwinb2606.me-wanadoo.net (SMTP Server, from userid 1001)
    id 243641800085; Sat, 26 Oct 2019 17:55:03 +0200 (CEST)
Message-ID: <cmu-sieve-21537-1572105303-0@mwinb2606>
Date: Sat, 26 Oct 2019 17:55:03 +0200
X-Sieve: CMU Sieve 2.3
From: <lapetitemuretaine31@orange.fr>
To: <sav@client.fr>
Subject: Auto: Test
In-Reply-To: <EBAB0E7C-542F-4250-89EB-380AEDD78D41@client.fr>
Auto-Submitted: auto-replied (vacation)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Je ne veux pas donner mon serveur en public,
du coup client.fr = mon adresse mail sur postfix
le serveur postfix = monserveur.pro

Merci Bruno

Dernière modification par dodo.deejay (Le 26/10/2019, à 19:36)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 24/10/2019, à 17:09

Aide postfix sur blocage d'une extensions de domaine

#2 Le 24/10/2019, à 18:02

Re : Aide postfix sur blocage d'une extensions de domaine

#3 Le 24/10/2019, à 19:11

Re : Aide postfix sur blocage d'une extensions de domaine

#4 Le 24/10/2019, à 20:15

Re : Aide postfix sur blocage d'une extensions de domaine

#5 Le 24/10/2019, à 21:55

Re : Aide postfix sur blocage d'une extensions de domaine

#6 Le 25/10/2019, à 07:58

Re : Aide postfix sur blocage d'une extensions de domaine

#7 Le 25/10/2019, à 09:14

Re : Aide postfix sur blocage d'une extensions de domaine

#8 Le 25/10/2019, à 10:02

Re : Aide postfix sur blocage d'une extensions de domaine

#9 Le 25/10/2019, à 10:43

Re : Aide postfix sur blocage d'une extensions de domaine

#10 Le 25/10/2019, à 13:13

Re : Aide postfix sur blocage d'une extensions de domaine

#11 Le 25/10/2019, à 20:29

Re : Aide postfix sur blocage d'une extensions de domaine

#12 Le 26/10/2019, à 10:51

Re : Aide postfix sur blocage d'une extensions de domaine

#13 Le 26/10/2019, à 11:30

Re : Aide postfix sur blocage d'une extensions de domaine

#14 Le 26/10/2019, à 12:35

Re : Aide postfix sur blocage d'une extensions de domaine

#15 Le 26/10/2019, à 12:55

Re : Aide postfix sur blocage d'une extensions de domaine

#16 Le 26/10/2019, à 12:59

Re : Aide postfix sur blocage d'une extensions de domaine

#17 Le 26/10/2019, à 15:11

Re : Aide postfix sur blocage d'une extensions de domaine

#18 Le 26/10/2019, à 17:08

Re : Aide postfix sur blocage d'une extensions de domaine

Pied de page des forums