Postfix odre des "smtpd_recipient_restrictions"

Uggy · Le 07/02/2008, à 00:58

B@rtounet a écrit :

ha donc si je comprend bien
check_client_access hash:/etc/postfix/whitelist_client,= adresse IP
check_sender_access hash:/etc/postfix/whitelist_sender = adresse mail

Voila... en gros c'est ça.

B@rtounet a écrit :

Mais donc le check_client_access ne concerne que les ip ? dans ce cas si je met
domaine.com dans cette liste le serveur esaiera simplement de résoudre ce nom par une IP c'est bien ca?

Oui.
T'as lu la doc ??

B@rtounet a écrit :

Par contre une question: le check_sender_access peut t'il contenir seulement
@domaine.com ? et ainsi laisser passer le domaine entier putot que les adresse mails une par une ??

A priori oui.
T'as lu la doc ??

B@rtounet a écrit :

et cela sans verifier l'ip

Qu'est ce que tu me reparle encore d'IP pour check_sender_access ? ??? ???

B@rtounet · Le 07/02/2008, à 01:11

Merci uggy je vais repotasser la doc

B@rtounet · Le 07/02/2008, à 01:43

Ok j'ai un peu lu la doc et je comprend mieux l'utilisation de ces 2 paramètres, par contre,
Par defaut quand on veut whitelister une adress mail on place cette adresse dans le sender_access et pour les ip dans le client_access
la forme est par exemple tutu@domaine.com OK

Par contre j'ai vu dans pas mal de site que certaint mettait a la place de OK permit pour accepter et reject pour rejeter...
est que par defaut quand on ne met rien ou OK la paramètre est sous entendu permit.?

Uggy · Le 07/02/2008, à 10:59

Pour les tables Hash, t'es obligé d'avoir une valeur dans la 2eme colonne
Ceci MEME si la 2eme colonne n'est pas utilisée (comme dans relay-recipients-maps par exemple)

man postmap

INPUT FILE FORMAT
The format of a lookup table input file is as follows:
o A table entry has the form
key whitespace value

doc access

OK Accept the address etc. that matches the pattern.
REJECT optional text...
Reject the address etc. that matches the pattern.[...]

Dernière modification par Uggy (Le 07/02/2008, à 11:00)

B@rtounet · Le 08/02/2008, à 15:34

Peux tu me confirme que si on met
i

netgw:~ # cat /etc/postfix/whitelist_sender
tutu.toto@titi.fr OK
patrick.tutu@domaine.com OK
dell.com

tous le domaine dell.com passera outre les filtrages ? j'ai jamais essayé de mettre un domaine entier plutot qu'une adresse mail

Uggy · Le 08/02/2008, à 16:31

B@rtounet a écrit :

Peux tu me confirme que si on met
i
netgw:~ # cat /etc/postfix/whitelist_sender
tutu.toto@titi.fr OK
patrick.tutu@domaine.com OK
dell.com
tous le domaine dell.com passera outre les filtrages ? j'ai jamais essayé de mettre un domaine entier plutot qu'une adresse mail

Meme réponse que celle dans mon message du 06/02/2008, à 23:58

je mettrais plutot
@dell.com
(que
dell.com
)
A tester... c'est simple, tu fais le test en telnet.. et tu verras...

A noter que n'importequ'el spam qui mettrait spam@dell.com en mail from bypasseras tes rbls et compagnie...

Dernière modification par Uggy (Le 08/02/2008, à 16:32)

B@rtounet · Le 08/02/2008, à 16:37

Ok, mais pour tester, il faudrai que le domaine en question soit blacklisté... sinon c'est pas significatif

Uggy · Le 08/02/2008, à 16:56

T'as qu'a faire un reject sur une regle derriere... si ca passe quand meme c'est que ta whiteliste est ok..

Tu whitelist des trucs qui sont pas bloqués ? Mmmmm... J'espére que tu as des bonnes raisons... surtout pour le sender qu ipeut etre spoofé...

B@rtounet · Le 08/02/2008, à 18:39

Non en général ils sont bloqués, mais ne t'inquiète pas pour l'instant on a pas beaucoup d'adresse dans la white list c'est au coup par coup quand un fournisseur/client n'arrive pas a nous envoyer les mails...

Le probleme de dell est un peu plus embetant... on travaille bcp avec eux et ces rigolos on configuré leur spf avec un softfail...
Le softfail n'est pas un probleme en soit, car dell est censé envoyé par les serveurs qui sont définis dans son spf, le probleme c'est que c'est pas toujours le cas...

Et comme nous avons décidé de ne pas accepter les softfails, il peut arriver qu'il soit Rejecté...

D'ailleurs, je suis interessé de savoir quels sont vos actions quand tu es confronté
au même probleme.
Tu as bien aussi des clients qui ne connaissent pas forcément comment configuré leur spf ou autres... dans ce cas tu laisse les bloquages??
De nombreux clients sont bloqués par spamhauss qui est quand meme une des black lists les plus utilisés

Uggy · Le 08/02/2008, à 18:55

B@rtounet a écrit :

Tu as bien aussi des clients qui ne connaissent pas forcément comment configuré leur spf ou autres... dans ce cas tu laisse les bloquages??

PermFail et softFail -> Dans les 2 cas j'ajoute un en-tete au niveau de Postfix (PREPEND au lieu de REJECT) et j'ai une règle dans le soft de mon content Filter qui rajoute un Warning dans le sujet du mail que je délive au user.. (Un warning qui dit que l'expediteur n'est pas authorisé blahblah )

B@rtounet · Le 08/02/2008, à 19:56

Oui mais je trouve qu'on perd le but du spf...

Sinon toi pour d'éventuels clients/fournisseurs qui seraient blacklistés tu procède comment?

Uggy · Le 08/02/2008, à 20:13

B@rtounet a écrit :

Oui mais je trouve qu'on perd le but du spf...

Oui
Mais c'est le meilleur compromis que j'ai trouvé pour
- Bien signifier que le message est suspect et que l'IT les a bien prévenu. (en gros on a fait notre boulot)
- Ils ont le message comme ca ils font chier personne en disant "je recois pas mes mails"

B@rtounet a écrit :

Sinon toi pour d'éventuels clients/fournisseurs qui seraient blacklistés tu procède comment?

Au boulot: Je n'utilise pas de RBL publique mais un policy_service qui rejette sur l'IP (le resultat est le meme mais sans avoir a faire des requetes DNS... la liste des IPs est updatée localment en HTTP toutes les 5 min). La base n'est pas publique, c'est un des composants d'un soft commercial.
Depuis 6 mois cette unique regle de rejet des IPs rejette environ 1 million de spams par jour.
Sur cette quantité je n'ai jamais eu une seule fois un false positive. J'ai eu 3 fois un client/partenaire qu ietait bloqué... mais il envoyait vraiment des spams/virus. (Nous n'avons pas creer de whiteliste.. la sécurité prioritaire sur un peu de business).

Toi tu utilise trop de RBL... dans le lot il y en a probablement trop des non fiables.

Sur des serveurs "persos" ou j'ai des RBLs, je n'ai que:
bl.spamcop.net
sbl.spamhaus.org
xbl.spamhaus.org
(pas zen)
cbl.abuseat.org

Je n'ai jamais eu de false positive non plus.. mais la les volumes ne sont pas du tout les memes.

B@rtounet · Le 08/02/2008, à 20:41

Bah disons qu'on a fait pas mal le tri et regarder lesquels etaient utiles...
sur une assez longue période on a établi cette liste de rbl qui ont chacune bloquées significativement du spam

Uggy · Le 08/02/2008, à 21:58

B@rtounet a écrit :

on a établi cette liste de rbl qui ont chacune bloquées significativement du spam

Elles bloquent toutes du spam... Ce qui n'est pas simple c'est de trouver celles qui ne génèrent pas de false positive.

B@rtounet · Le 13/01/2009, à 11:53

Bonjour à tous, je me permet de relancer le post, je fais encore appel à vous.
Notre système marche plutot pas mal, depuis la dernière foi son a réduit pas mal la liste des rbl...

J'ai depuis quelques temps des mails qui passent que l'on arrive pas à bloquer...
ce sont souvent des adresse hotmails par exemple, elle ne sont ni bloquées par les rbl, ni pas spamassassin....

Existe t'il un paramétre postfix qui comme le sender_whitelist, permet aussi de faire du blacklistage en entrée...
je vois bien aussi un fichier qu'on pourrait alimenter manuellement avec les adresses non bloquées qui sont récurentes..
Je suppose que c'est le paramètre du type: smtpd_sender_restrictions = check_sender_access hash :/etc/postfix/sender_checks

Bon ca à l'air de fonctionner avec un

smtpd_sender_restrictions = reject_unknown_sender_domain, reject_non_fqdn_sender, check_sender_access hash:/etc/postfix/sender_checks, permit_mynetworks

et

root@ns:~# cat /etc/postfix/sender_checks
mail@toto.fr 554 BLOCK

Par contre apperement on est obligé de mettre un texte??

Que pensez vous de la mise en place de cette bl

Dernière modification par B@rtounet (Le 13/01/2009, à 13:32)

toniotonio · Le 13/01/2009, à 15:25

ca ne sert pas a grand chose malheureusement car le mailfrom change regulierement.

pour les types de spams qui passent les controles basiques, il faut pousser plus loin avec Spamassassin.
et si meme la detection heuristique ne bloque pas le message alors ce sera le filtre bayesien qui sera la plus efficace.

Il faut voir ton header avec les resultats des score SA pour aller plus loin.

B@rtounet · Le 13/01/2009, à 15:59

Oui je sais bien, mais bon.. certains utilisateurs se plaignent que c'est toujours les meme adresses.. mais bon c'est faux...
Mais bon meme si ils passent en spam ca les genent tu comprends...:| car il les recoivent avec l'entête SPAM mais le recoivent quand meme...
Le mieux serait de bloquer tous les hotmails lol

Dernière modification par B@rtounet (Le 13/01/2009, à 16:05)

toniotonio · Le 13/01/2009, à 16:04

d'autant que postfix ne regarde que le envelope sender et souvent celui ci est different du mailfrom du header.

mais bon sinon techniquement parlant ta regle est correcte meme si perso je la mettrait apres reject_unauth_destination

et oui il faut indiquer un texte apres le code d'erreur

Uggy · Le 13/01/2009, à 17:40

A ma connaissance, pas besoin d'appliquer su texte avec le mot clé REJECT:

toto@toto.fr REJECT
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
220 nom.intra ESMTP Server --=[ xcvxvxcv ]=--
helo de
250 nom.intra
mail from:<toto@toto.fr>
250 2.1.0 Ok
rcpt to:<dest@sdfsdfsdf.com>
554 5.7.1 <toto@toto.fr>: Sender address rejected: Access denied

B@rtounet · Le 13/01/2009, à 18:44

Ok,
Je suis en train de relire mon fichier de conf postfix, et quelquechose m'interpelle...

smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unknown_sender_domain, check_client_access hash:/etc/postfix/whitelist_client, check_sender_access hash:/etc/postfix/whitelist_sender, reject_rbl_client zen.spamhaus.org, reject_rbl_client ix.dnsbl.manitu.net, reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.ahbl.org, reject_rbl_client virbl.dnsbl.bit.nl, reject_rbl_client list.dsbl.org, reject_rbl_client ircbl.ahbl.org, reject_unauth_pipelining, check_policy_service unix:private/spf, check_policy_service inet:127.0.0.1:6000

J'aivais mis à l'époque les rejet rbl dans smtpd_recipient_restrictions est-ce bien logique ? ne vaut t'il pas mieux le placer avec l'option smtpd_client_restrictions ?

Ceci dit ca fonctionne très bien, j'ai un serveur configuré avec les rbl comme ca et un autre avec le smtpd_client_restrictions et les deux font leur boulot

toniotonio · Le 13/01/2009, à 18:57

reprend le début du topic sur l'ordre d'application tu comprendras pourquoi

Uggy: pour le texte c'est obligatoire dans le cas ou on met un code de retour 4xx ou 5xx.
si on met REJECT le texte devient optionnel

Uggy · Le 13/01/2009, à 19:18

tonio: On est d'accord, ma phrase n'est plas claire.. je lui indiquait maladroitement que s'il ne voulait pas mettre de texte, il pouvait utiliser REJECT.

B@rtounet · Le 14/01/2009, à 10:43

toniotonio a écrit :

L’ordre global d’application est le suivant :
- SMTPD Restrictions
- Header/body Checks
- Content Filter
Postfix établit 5 étapes de tests (stages) au niveau des SMTPD Restrictions qui correspondent chacune à une commande SMTP :
smtpd_client_restrictions connection du client
smtpd_helo_restrictions HELO
smtpd_sender_restrictions MAIL FROM
smtpd_recipient_restrictions RCPT TO
smtpd_data_restrictions DATA
Par defaut Postfix est configuré pour évaluer les tests au moment de la commande RCPT TO, donc dans la section smtpd_recipient_restrictions.
C’est à dire que le blocage n’interviendra qu’au moment ou le client envoie la dernière commande.
A l’intérieur d’un restriction stage il existe des access lists. Dès qu’une de ces access lists renvoient OK, on passe au stage suivant. (la fin d’un stage par défaut est PERMIT)
Si une access list renvoie REJECT le message est bloqué. Si une access list ne matche pas, on passe a l’access list suivante dans le stage. (DUNNO)

J'ai bien relus, mais du coup qu'est ce qui m'empeche de faire le bloquage rbl plus haut carrément à la connexion du client "smtpd_client_restrictions" ok le bloquage n'interviendra qu'au smtpd_recipient_restrictions mais il aura dejà matché au premier donc moins de consomation de ressources non?

toniotonio · Le 14/01/2009, à 11:12

tu peux le faire, mais il y aura la meme consommation de ressources car les regles sont parsées jusqu'au bout smtpd_recipient_restrictions (dans le mode par defaut)

le fait de le mettre dans recipient plutot que dans client c'est plus dans un concept de simplification et pour eviter les erreurs et effets de bords de l'enchainement des acl.

il y a certain cas ou il faut separer les stages, d'autres non.
dans ton cas pour les rbl ce n'est pas la peine.

B@rtounet · Le 14/01/2009, à 11:19

Ok merci de ces conseils, mais c'est vrai que tu coup j'ai du mal à comprendre à quoi sert de placer des règle dans les autres stages vu que de toutes facon le bloquage se fera à la fin...

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 07/02/2008, à 00:58

Re : Postfix odre des "smtpd_recipient_restrictions"

#27 Le 07/02/2008, à 01:11

Re : Postfix odre des "smtpd_recipient_restrictions"

#28 Le 07/02/2008, à 01:43

Re : Postfix odre des "smtpd_recipient_restrictions"

#29 Le 07/02/2008, à 10:59

Re : Postfix odre des "smtpd_recipient_restrictions"

#30 Le 08/02/2008, à 15:34

Re : Postfix odre des "smtpd_recipient_restrictions"

#31 Le 08/02/2008, à 16:31

Re : Postfix odre des "smtpd_recipient_restrictions"

#32 Le 08/02/2008, à 16:37

Re : Postfix odre des "smtpd_recipient_restrictions"

#33 Le 08/02/2008, à 16:56

Re : Postfix odre des "smtpd_recipient_restrictions"

#34 Le 08/02/2008, à 18:39

Re : Postfix odre des "smtpd_recipient_restrictions"

#35 Le 08/02/2008, à 18:55

Re : Postfix odre des "smtpd_recipient_restrictions"

#36 Le 08/02/2008, à 19:56

Re : Postfix odre des "smtpd_recipient_restrictions"

#37 Le 08/02/2008, à 20:13

Re : Postfix odre des "smtpd_recipient_restrictions"

#38 Le 08/02/2008, à 20:41

Re : Postfix odre des "smtpd_recipient_restrictions"

#39 Le 08/02/2008, à 21:58

Re : Postfix odre des "smtpd_recipient_restrictions"

#40 Le 13/01/2009, à 11:53

Re : Postfix odre des "smtpd_recipient_restrictions"

#41 Le 13/01/2009, à 15:25

Re : Postfix odre des "smtpd_recipient_restrictions"

#42 Le 13/01/2009, à 15:59

Re : Postfix odre des "smtpd_recipient_restrictions"

#43 Le 13/01/2009, à 16:04

Re : Postfix odre des "smtpd_recipient_restrictions"

#44 Le 13/01/2009, à 17:40

Re : Postfix odre des "smtpd_recipient_restrictions"

#45 Le 13/01/2009, à 18:44

Re : Postfix odre des "smtpd_recipient_restrictions"

#46 Le 13/01/2009, à 18:57

Re : Postfix odre des "smtpd_recipient_restrictions"

#47 Le 13/01/2009, à 19:18

Re : Postfix odre des "smtpd_recipient_restrictions"

#48 Le 14/01/2009, à 10:43

Re : Postfix odre des "smtpd_recipient_restrictions"

#49 Le 14/01/2009, à 11:12

Re : Postfix odre des "smtpd_recipient_restrictions"

#50 Le 14/01/2009, à 11:19

Re : Postfix odre des "smtpd_recipient_restrictions"

Pied de page des forums