Postfix et restrictions d'accès SMTP = flou artistique

[wpriz]

Bonjour,

J'aimerai avoir des précisions sur la façon dont on peut configurer postfix (v2.3.7) car malgré mes nombreuses lectures il y a pas mal de zones d'ombres.

donc je commence par ceci :

Code :

1
2
3
4
5
6
7
8
9
10
 
# RESTRICTIONS SMTPD suivant cet ordre :
# (client, helo, etrn) ou (client, helo, expéditeur, destinataire, data)
# smtpd_client_restrictions	 	Optionel	 Permet de rejetter toutes les commandes du client
# smtpd_helo_restrictions	 	Optionel	 Permet de rejetter les informations HELO/EHLO
# smtpd_sender_restrictions		Optionel	 Permet de rejetter l'information MAIL FROM
# smtpd_recipient_restrictions		Obligatoire	 Permet de rejetter l'information RCPT TO
# smtpd_data_restrictions	 	Optionel	 Permet de rejetter la commande DATA
# smtpd_data_end_of_restrictions	Optionel	 Permet de rejetter la commande END-OF-DATA
# smtpd_etrn_restrictions	 	Optionel	 Permet de rejetter la commande ETRN

Jusque là ça va, j'ai donc mis cela :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
 
smtpd_client_restrictions =
  permit_mynetworks,
  reject_unauth_pipelining,
  hash:/etc/postfix/client_access,
  reject_unknown_reverse_client_hostname
 
smtpd_helo_required = yes
smtpd_helo_restrictions =
  permit_mynetworks,
  reject_invalid_helo_hostname,
  reject_non_fqdn_helo_hostname,
  check_helo_access hash:/etc/postfix/helo_access,
  check_helo_access regexp:/etc/postfix/helo_checks
 
smtpd_sender_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  reject_unauth_pipelining,
  reject_non_fqdn_sender,
  reject_unknown_sender_domain,
  permit
 
smtpd_recipient_restrictions =
  reject_non_fqdn_hostname,
  reject_non_fqdn_sender,
  reject_non_fqdn_recipient,
  reject_unauth_pipelining,
  reject_unknown_recipient_domain,
  reject_invalid_hostname,
  reject_unlisted_recipient,
  reject_unlisted_sender,
  reject_unauth_destination,
  permit_mynetworks,
  permit_sasl_authenticated,
  hash:/etc/postfix/deny,
  hash:/etc/postfix/access,
  reject_rbl_client zen.spamhaus.org,
  permit

Je vais commencer par 3 questions

1. Si je met une instruction (ex: reject_unauth_pipelining) dans la restriction "smtpd_client_restrictions", va t-elle s'appliquer à toutes les restrictions smtpd (ex: "smtpd_helo_restrictions", "smtpd_recipient_restrictions", etc.)
2. L'ordre des instructions a t-elle une importance dans une restriction smtpd ?
3. Je vois souvent sur les exemples de configuration qui traîne sur le net une instruction comme "reject_non_fqdn_helo_hostname" dans la restriction "smtpd_recipient_restrictions". Ne devrait-elle pas être dans la restriction "smtpd_helo_restrictions" ?

merci de vos lumières

[wpriz]

Bon j'ai une réponse claire à ma question 2 dans la documentation mais pour le reste...

Chaque liste de restrictions est évaluée de la gauche vers la droite jusqu'à ce qu'une restriction produise un résultat parmi PERMIT, REJECT ou DEFER (essayer plus tard). La fin de liste est équivalente à PERMIT. En plaçant une restriction PERMIT avant une restriction REJECT vous pouvez faire des exceptions pour des clients ou utilisateurs particuliers. C'est ce qu'on appelle liste blanche ; le dernier exemple ci-dessus autorise le courrier depuis le réseau local mais rejete autrement les destinations arbitraires.

et j'ai une réponse partielle à ma question 1 et 3 :

A ce niveau le lecteur peut se demander pourquoi nous avons besoin des restrictions sur le client, HELO ou l'adresse de l'expéditeur quand leur évaluation est remise à la commande RCPT TO or ETRN. Certaines personnes recommandent de placer TOUTES les restrictions d'accès dans la liste smtpd_recipient_restrictions. Malheureusement, celà peut entraîner un accès trop permissif. Comment est-ce possible ?

[wpriz]

Si je récapitule les principales commandes SMTP :

HELO site-émetteur Commence une session SMTP par une identification des deux parties. Le récepteur s’identifie dans sa réponse
MAIL FROM : émetteur Commence une nouvelle transaction. Spécifie l’expéditeur, pour le renvoi des messages d’erreur éventuels
RCPT TO : destinataire Spécifie un destinataire. Cette procédure peut être répétée autant de fois que nécessaire. Si le destinataire n’est pas valide, un code d’erreur est renvoyé aussitôt
DATA Envoie le message (en-tête + corps) terminé par une ligne ne contenant qu’un point.
Pour ne pas interférer avec le message à transmettre, toute ligne du message contenant un point en première position est modifiée en insérant un point supplémentaire en début. Ce point supplémentaire est supprimé par le récepteur (hidden dot algorithm)
QUIT Termine la session SMTP

Et que je prend un exemple de discussion SMTP :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
220 mail.toto.fr ESMTP Postfix
HELO mail.titi.com
250 mail.toto.fr
MAIL FROM:<tutu@tata.fr>
250 tutu@tata.fr ... Sender ok
RCPT TO:<toto@web.net>
250 2.1.0 Recipient ok
DATA
354 Enter mail, end with "." on a line by itself 
From : tutu@tata.fr
To : toto@web.net
Subject : essai 

ceci est un essai 
. 
250 OK Message accepted for delivery 
QUIT

Et enfin que je découpe cet exemple afin d'insérer les restrictions correspondantes :

220 mail.toto.fr ESMTP Postfix -> évaluation du smtpd_client_restrictions
HELO mail.titi.com -> évaluation du smtpd_helo_restrictions
250 mail.toto.fr
MAIL FROM:<tutu@tata.fr> -> évaluation du smtpd_sender_restrictions
250 tutu@tata.fr ... Sender ok

RCPT TO:<toto@web.net>

exécution dans l'ordre du REJECT ou DEFER rencontré dans les restrictions précédentes :
1 - smtpd_client_restrictions
2 - smtpd_helo_restrictions
3 - smtpd_sender_restrictions
4 - smtpd_recipient_restrictions

250 2.1.0 Recipient ok
DATA
354 Enter mail, end with "." on a line by itself

smtpd_data_restrictions -> évaluation et exécution du REJECT ou DEFER

From : tutu@tata.fr -> évaluation de header_checks
To : toto@web.net -> évaluation de header_checks
Subject : essai -> évaluation de header_checks

ceci est un essai -> évaluation de body_checks
.

smtpd_data_end_of_restriction -> évaluation et exécution du REJECT ou DEFER

250 OK Message accepted for delivery
QUIT

Je pense pouvoir répondre à ma question 2 :
L'évaluation s'effectue dans l'ordre des listes de restrictions et l'une après l'autre.

Pour la question 3, il semble que c'est la documentation qui répond le mieux :
Afin d'éviter les effets de bords, il vaut mieux indiquer les instructions correspondantes à chaque restriction smtpd soit l'instruction reject_invalid_helo_hostname dans la restriction smtpd_helo_restriction.

Y a t-il une personne qui pourrait me confirmer tout cela ?
Merci

[mrtonio]

regarde un article que j'ai ecrit sur ce point
https://www.starbridge.org/spip/spip.php?article7

cela se base sur une config que je detaille dans un tuto sur le meme site, mais la logique est expliquée et reste la meme pour toute install de postfix.

dis moi si il demeure des zones d'ombres

et puis sinon comme tu le soulignes la doc est tres precise sur le sujet.

mais c'est vrai que cela peut aider d'avoir d'abord une vue d'ensemble



globalement l'ordre des restrictions est capital.

[wpriz]

Ah enfin un tutorial sur la configuration de postfix digne de ce nom !
ça change du faites comme ci, et comme ça, me demandez pas pourquoi chez moi ça marche...
Merci beaucoup mrtonio !

je comprend mieux pourquoi il y a un reject_non_fqdn_helo_hostname qui se ballade souvent dans smtpd_recipient_restrictions.

reject_non_fqdn_helo_hostname
rejette le HELO lorsqu’il n’est pas un FQDN. Par exemple lorsque le HELO est le hostname de la machine cliente.
C’est la cas de figure des clients Outlook. c’est pour cela que cette règle se situe APRES l’authentification SASL pour permettre aux clients du domaine de pouvoir envoyer un email malgré ce non respect des RFC par outlook : Les clients authentifiés ont deja pu envoyer leur mail et cette règle ne s’applique donc pas pour eux...

Dans mon cas, c'est inutile les clients sont tous extérieurs donc forcément authentifiés.

Par contre quel intérêt de mettre reject_invalid_helo_hostname dans smtpd_recipient_restrictions après reject_non_fqdn_recipient, reject_non_fqdn_sender et reject_unknown_recipient_domain ?
Ne devrait-il pas se trouver dans smtpd_helo_restrictions ?

Le schéma n'a plus l'air d'exister...

Pour l'instruction reject_unauth_pipelining qui se situe dans smtpd_data_restrictions, n'y a t-il pas un intérêt à le mettre dans les autres listes d'accès smtpd ?

Cela permet de bloquer les client SMTP qui "parlent" trop tôt dans la transaction.
C’est le cas des scripts mal écrits et de quelques softs de spamming.

j'avoue ne pas savoir à quoi ressemble une discussion SMTP trop verbeuse d'un logiciel mal écrit, alors je me dit que le répéter dans les autres listes d'accès smtpd à peut-être un intérêt...

[mrtonio]

le fait de mettre les acl concernant le helo dans le stage smtpd_recipient est lié a la structure des verifications que fait postfix par defaut.

comme je le precise dans l'article, par defaut postfix evalue toute les restrictions a la fin du dernier stage, donc basiquement on peut placer toutes les acls dans smtpd_recipient .

Seul quelques cas particuliers ou il faut jouer avec des reject et des conditions (comme dans le tuto de mon site) impose de dispatcher les acl dans les stages requis.

c'est toute la puissance de postfix, cette finesse dans le filtrage.
Mais il faut bien comprendre cette notion d'ordre a l'interieur des stages et le concept de l'evaluation des restrictions en fin de cycle.

pour le reject_unauth_pipelining il a sa place logiquement plutot dans le stage data.



(pour le schema il faut s'authentifier sur le forum de support de mon site)

[wpriz]

pour le reject_unauth_pipelining, je n'ai pas trouvé d'explications vraiment pertinentes, mis à part effectivement qu'il n'est pas conseillé de l'utiliser dans les autres contextes de restriction.

reject_unauth_pipelining n’est pas pratique en dehors de smtpd_data_restrictions lorsque:
1) le client utilise ESMTP (EHLO au lieu de HELO)
2) avec "smtpd_delay_reject = yes" (valeur par défaut).

Un début de réponse dans un échange d'avis sur une main.conf :

ça sert à rien ici. RCPT TO est une commande "asynchrone". le standard autorise donc de faire du pipelining ici (ici=smtpd_recipient_restrictions).

je me suis donc penché sur le sens de pipelining, le schéma est assez parlant (même si c'est du HTTP) et on comprend vite l'utilité du principe. J'ai trouvé la RFC2920 qui correspond au "pipelining" soit en français "l'intubation" dont le comparatif par des exemples de transactions SMTP est révélateur.

Considérons le dialogue SMTP suivant qui n’utilise pas l’intubation :

Code :

Le client attend une réponse du serveur neuf fois dans ce simple exemple. Mais si on utilise l’intubation, le dialogue suivant est possible :

Code :

Le nombre total d’allers-retours a été réduit de 9 à 4.

Le prochain exemple illustre une forme de comportement possible lorsque l’intubation est utilisée et que tous les receveurs sont rejetés :

Code :

On s'aperçoit que l'intubation permet de cumuler les commandes sans attendre la réponse du serveur pour un gain de vitesse et de transactions. J'imagine que reject_unauth_pipelining permet de rejetter les dialogues qui utilisent des commandes qui ne sont pas "intubable" :

les commandes RSET, MAIL FROM, SEND FROM, SOML FROM, SAML FROM, et RCPT TO peuvent toutes apparaître à tout endroit d’un groupe de commandes intubées. Les commandes EHLO, DATA, VRFY, EXPN, TURN, QUIT, et NOOP ne peuvent apparaître que comme dernière commande dans un groupe car leur réussite ou leur échec produit un changement d’état dont le client SMTP doit s’accommoder. (NOOP est incluse dans ce groupe de sorte qu’elle peut être utilisée comme point de synchronisation.)

et qui ne sont pas listées comme extension possible dans la réponse du EHLO :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
220 size.does.matter.af.MIL (More ESMTP than Crappysoft!)
EHLO heaven.af.mil
250-size.does.matter.af.MIL offers FIFTEEN extensions:
250-8BITMIME
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-EXPN
250-HELP
250-SAML
250-SEND
250-SOML
250-TURN
250-XADR
250-XSTA
250-ETRN
250-XGEN
250 SIZE 51200000

Bref, tout cela pour dire que positionner le reject_unauth_pipelining seulement à partir de smtpd_data_restrictions s'explique par le fait que la réponse du serveur s'effectue seulement à ce moment là ! tout simplement...

Finalement une explication précise trouvée dans un échange d'avis sur une main.conf:

RCPT TO est une commande asynchrone (on peut en envoyer plein sans attendre la réponse du serveur). donc postfix ne
jettera rien. par contre, tu peux la mettre dans smtpd_data_restrictions
(car DATA est une commande synchrone: le client doit attendre le "300
tapez votre mail et terminiez par un point")

[wpriz]

Concernant l'intérêt de mettre reject_invalid_helo_hostname dans smtpd_recipient_restrictions, je pense plutôt suivre les recommandations de la documentation soit de le mettre dans smtpd_helo_restrictions. A moins que le but est de faire passer en premier des restrictions moins gourmandes en ressources, dans ce cas précis, je veux bien. Mais peut-être il y a t-il une autre raison qui m'échappe...

Dans votre schéma, il y a deux fois reject_unknown_sender_domain dans SMTPD_SENDER_RESTRICTIONS et SMTPD_RECIPIENT_RESTRICTIONS, cela fait doublon non ?

[mrtonio]

je conseillerai de mettre a chaque fois que cela est possible, les acl sous smtpd_recipient_restrictions.

tu peux regarder les discussions a ce sujet sur la ML de postfix et ce point de vue est celui de Wenema et Duchovni.
La doc donne une vue d'ensemble mais ce sujet est tres tres vaste, et a donné lieu a de multiples discussions.


il faut bien saisir cette notion d'ordre et surtout de coherence dans l'application des acl et c'est pour cela qu'il est conseillé de faire comme ceci.

comme j'ecrivais plus haut l'interet de separer les acl par stage se trouve dans certains cas particuliers, ou l'on a besoin d'eliminer plus tot une transaction et que des ACL se chavaucheraient.

pour le reject_unauth_pipelining c'est bien cela, du moins dans les conditions que tu cites (smtpd_delay_reject = yes et EHLO dans la transaction du client) ce qui est le mode par defaut.

Si on places ailleurs le reject_unauth_pipelining, ce n'est pas tres grave, juste inutile.

j'ai effectivement mis 2 fois reject_unknown_sender_domain, un dans le stage sender et l'autre dans recipient, et effectivement j'aurai pu ne le mettre que dans le sender. La verif etant en cache cela ne pose pas de reels pbs de perfs mais le doublon existe bien.

il faut bien comprendre que quoiqu'il en soit les acl sont parsées jusqu'au bout (fin de recipient), donc le temps de traitement reste a peu pres le meme

[wpriz]

Bonjour M. Tonio, je ne remet pas du tout en question vos conseils bien au contraire toutes mes démonstrations les confirment et vous semblez bien maîtriser votre sujet. Cependant je suis un peu tétu, j'aime bien comprendre le comment du pourquoi...

Alors, j'ai cherché dans la Mailing-List de postfix à l'aide de google mais j'ai l'impression de rechercher une aiguille dans une botte de foin. Avez vous des exemples de discussion avec Wenema et Duchovni...

Bref voici la configuration postfix que je suis en train de mettre en place :
(elle n'est pas figée, ni terminée, je vais la mettre à jour suivant vos conseils et au fur et mesure de la réflexion)

smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
notify_classes = 2bounce, bounce, delay, policy, protocol, resource, software
biff = no
strict_rfc821_envelopes = yes
append_at_myorigin = no
append_dot_mydomain = no
show_user_unknown_table_name = no
disable_vrfy_command = yes
proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks $smtpd_recipient_restrictions $smtpd_sender_login_maps

#smtpd_client_restrictions vide

smtpd_helo_required = yes
smtpd_helo_restrictions = reject_invalid_helo_hostname

smtpd_sender_login_maps = proxy:mysql:/etc/postfix/mysql_sasl_sender_maps.cf
smtpd_sender_restrictions =
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_unlisted_sender,
reject_authenticated_sender_login_mismatch

smtpd_recipient_restrictions =
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
reject_unlisted_recipient,
permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_helo_hostname,
warn_if_reject
reject_unknown_helo_hostname,
reject_unauth_destination,
reject_unknown_reverse_client_hostname,
check_client_access hash:/etc/postfix/internal_networks,
check_sender_access hash:/etc/postfix/not_our_domain_as_sender,
reject_rbl_client zen.spamhaus.org,
check_client_access proxy:mysql :/etc/postfix/mysql-client.cf,
check_sender_access proxy:mysql :/etc/postfix/mysql-sender.cf

smtpd_data_restrictions =
reject_unauth_pipelining,
reject_multi_recipient_bounce

header_checks = regexp:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks

smtpd_etrn_restrictions = permit_mynetworks, reject

J'ai tendance à préférer mettre dans l'ordre des listes de restrictions d'accès, je trouve cela plus lisible et permet surtout de faire plus facilement le rapport avec un dialogue SMTP (EHLO, MAIL FROM, RCPT TO, DATA) et de plus comme vous dites cela ne change rien : les instructions sont évaluées dans l'ordre et exécutées à la fin du stage smtp_recipient_restrictions.
Cela permet de mettre en exergue une exception comme reject_non_fqdn_helo_hostname qui est mis dans smtp_recipient_restrictions au lieu de smtpd_helo_restrictions.

[mrtonio]

salut
on peut se tutoyer se sera plus simple

j'ai pas d'exemple sous la main, c'est plutot au fil des lectures que ce constat s'est fait.

le fait de tout reunir au maximum sous recipient est principalement axé sur un besoin de clarté mais surtout pour eviter des effets de bords dans les restrictions.

Si l'on comprends bien les restrictions rien n'empeche effectivement de dispatcher proprement dans les stages relatifs.

les effets de bords peuvent se produire justement quand l'interet de cette separation des stages se fait sentir: le besoin de plusieurs conditions.


quand un OK ou un permit apparait dans le stage smtpd_recipient le message part tout de suite, ce qui parfois n'est pas le but recherché car l'on souhaite appliquer d'autre verifications avant d'accepter le mail.

c'est la tout l'interet de la separation des stages.
si l'on n'entre pas dans un tel cas de figure alors peu importe dans quel stage l'acl est mise (enfin presque c'est la qu'il fautbien maitriser ces acl)

ainsi un permit sur un HELO specifique dans le stage recipient placé avant permit_mynetwork et reject_unauth_dest aurait commme effet de creer un relais ouvert pour ce helo en question, car le mail serait accepté immediatement des l'acl en question.
on comprend le risque etant donnée qu'un helo peut simplement se forger.

donc dans ce cas, si l'on a reellement besoin d'autoriser un HELO specifique on place l'ACL relative dans le stage HELO.
celui ci terminera par un PERMIT mais le mail ne partira pas directement car il faudra passer par le stage rcpt avec justement les verifs relatives au network et aux destinations.
et la le mail ne partira pas si il n'est pas explicitement autorisé par ces regles.

je sais pas si c'est clair, car je reconnais que pour s'en rendre compte il faut etre en fait confronté a un cas de figure en pratique.


Dans ton main.cf que tu proposes:
-tu as 2 fois permit_mynetworks
-le warn_if_reject est tout seul ? pourquoi ?
-reject_unknown_reverse_client_hostname est assez risqué, cela genere pas mal de faux positifs
- dans le fichier internal_networks as tu mis la meme chose que dans mon tuto ?

- mettre les checks: check_client_access proxy:mysql :/etc/postfix/mysql-client.cf, check_sender_access proxy:mysql :/etc/postfix/mysql-sender.cf tout a la fin reduit leur interet, notamment pour whiotelister sender ou client sur une RBL (que tu as placé avant)


il y a peut etre d'autre choses que j'ai pas vu (j'ai un peu lu vite)

[wpriz]

tu m'as surpris en pleine rédaction...

Pour l'ordre des restrictions, je pense que j'ai bien compris.
->le fait d'avoir deux fois permit_mynetworks vient de mon incompréhension de l'utilisation de la commande ETRN (mais je voulais l'analyser dans un second temps après m'être informé)

• le warn_if_reject est là justement pour ignorer le rejet de l'instruction reject_unknown_reverse_client_hostname qui peut générer des faux positifs : je l'ai mis pour connaître un peu la situation de la configuration des MTA aujourd'hui sur internet. En effet, la lutte anti-spam a obligé un certain nombre de postmaster à configurer correctement le HELO pour respecter la RFC. C'est mon cas pour un de mes serveurs Exchange ou j'utilisais le helo par défaut soit la dénomination en local et non un HELO avec un domaine pleinement qualifié (FQDN).
• Pour le fichier internal_networks, je vais y venir (j'analyse d'abord avant de poser des questions stupides)
• Pour les check_client_access et check_sender_access, il est vrai qu'ils ont l'air inutile ici vu que je n'ai pas mis la restriction qui concerne l'anti-spam. La raison pour laquelle je les mets après le reject_rbl_client est que je veux ménager mon serveur mysql qui a tendance à saturer donc je préfère que les serveurs de listes noires fassent le ménage avant...

j'ai une question déjà par rapport au smtpd_sender_login_maps. J'ai bien compris l'intérêt du reject_authenticated_sender_login_mismatch qui est d'obliger un compte authentifié en SASL d'utiliser un MAIL FROM correspondant aux domaines que l'on gère. Mais je ne comprend pas quel intérêt, il y a de faire la requête SQL sur la table "alias" plutôt que "mailbox" :

Code :

query = SELECT goto FROM alias WHERE address='%s'

[mrtonio]

ce que je voulais dire c'est que la syntaxe est: warn_if_reject suivi de l'ACL sur la meme ligne

ici tu mets warn_if_reject et l'acl sur 2 lignes separés, ce qui a ma connaissance est sans effet (pas de warn)

pour le smtpd_sender_login_maps, je fais le lookup sur la table alias plutot que mailbox car cela permet a un user d'envoyer tout de meme un email avec un de ces alias plutot que de le restreindre a son email de base (table mailbox)

l'essentiel c'est que le mailfrom qu'il utilise soit un email qui finissent dans sa boite. (pour le retour de mail)

un user avec un mailbox toto@domain.com, peut posseder l'alias tata@domain.com,voire meme l'alias tata@autredomaine.com (tant que celui ci est géré par le serveur evidemment) et sera autorisé a envoyer un email avec le compte de base de sa mailbox c'est a dire toto@domain.com

j'en parle dans l'article sur mon site, en detaillant justmeent l'interet de toujours diriger un alias vers une boite physique (mailbox) et non vers un autre alias.
précision importante: la table alias dans ma config contient egalement l'entree toto@domain.com ==> toto@domain.com
donc un alias vers lui meme

[wpriz]

Ok pour warn_if_reject, heureusement postfix est assez souple dans l'interprétation de sa configuration : il ignore ma virgule mais je corrige.

C'est ça que j'ai du mal à comprendre :
on fait appel à la colonne goto qui contient l'adresse finale.

1. si on suit ton conseil, c'est à dire toujours diriger vers une boite physique on va finalement obtenir la colonne maildir de la table mailbox avec des tonnes de doublons.
2. si un gestionnaire de domaine décide de créer un alias de type toto@domainegéré.com vers titi@domaineextérieur.com cela veut dire que l'on donne la possibilité à titi@domaineextérieur.com d'utiliser le serveur SMTP en SASL.
3. si ce même gestionnaire un peu casse pied décide de créer un alias de type toto@domainegéré.com vers des destinataires multiples titi@domainegéré.com, tutu@domainegéré.com, tata@domainegéré.com comment réagit postfix ? prend t'il l'ensemble comme référent "titi@domainegéré.com, tutu@domainegéré.com, tata@domainegéré.com" ?

Je me demande si la requête mysql ne devrait pas être :

Code :

query = SELECT address FROM alias WHERE address='%s'

[mrtonio]

1- peux tu preciser sur les doublons ?

2- non c'est l'inverse en fait
le concept c'est que le mailfrom du mail est la colonne address, on verifie par la table que celui ci soit bien lié a un goto vers la boite physique (le compte sasl si tu preferes)

toto@domainegéré.com vers titi@domaineextérieur.com

cela correspond a address: toto@domainegéré.com
goto: titi@domaineextérieur.com

soit aucune autorisation car le compte sasl titi@domaineextérieur.com n'existe pas.
personne ne pourra envoyer avec en mailfrom toto@domainegéré.com, ni bien sur titi@domaineextérieur.com


je sais pas si c'est clair.


3- si l'alias est crée vers des boite physiques, alors chaque user présent dans la colonne goto pourra envoyer un mail avec comme mailfrom toto@domainegéré.com

c'est le but de la manoeuvre en fait.

si tu ne desires pas ce comportement pour certains alias généraux alors il suffit de créer cet alias d'une autre maniere (en passant par maildrop dans ma conf)
mais pour moi dans la majorité des cas de figure il est normal d'autoriser les users a envoyer un mail avec un mailfrom dont ils sont destinataires, meme si c'est un alias global.

[wpriz]

Je vais prendre un exemple concret pour voir si j'ai bien compris.
Nous avons Alain Dupont qui à une mailbox : alain.dupont@domainegere.com
Création des alias en conséquence :

Code :

1
2
3
4
5
6
7
8
9
 
Table ALIAS (tronquée sur 2 colonnes)
address				goto
alain.dupond@domainegere.com	alain.dupont@domainegere.com
alain-dupont@domainegere.com	alain.dupont@domainegere.com
ad@domainegere.com		alain.dupont@domainegere.com
a.d@domainegere.com		alain.dupont@domainegere.com
a-d@domainegere.com		alain.dupont@domainegere.com
groupe@domainegere.com		alain.dupont@domainegere.com,robert@fai.fr,martin@domaineexterieur.com

Si on utilise la requête suivante :

Code :

query = SELECT goto FROM alias WHERE address='%s'

Cela veut donc dire que l'on donne la possibilité à Alain Dupont de se connecter avec ses alias donc %s peut contenir
alain.dupond@domainegere.com alain-dupont@domainegere.com ad@domainegere.com a.d@domainegere.com a-d@domainegere.com

Par contre, groupe@domainegere.com ne pourra pas fonctionner car le résultat du select sera "alain.dupont@domainegere.com,robert@fai.fr,martin@domaineexterieur.com"

[mrtonio]

eclaircissons un point:

on parle bien de la possibilité pour un user d'utiliser un mailfrom depuis son compte SASL.
tu parles de "se connecter" et j'ai peur qu'il y ait confusion

ici le user ne se connectera pas avec les identifiant SASL de ses alias.
On verifie juste que son identifiant SASL (c'est a dire son email principal, mailbox dans sql) soit autorisé a utiliser comme adresse de mailfrom les alias en question.

(mailfrom c'est l'adresse email que l'on mets dans un client mail et qui apparaitrat chez le destinataire sous la forme: De: alain.dupont@domainegere.com)

donc dans ton exemple le user alain.dupont@domainegere.com qui s'identifie donc en SASL par le compte alain.dupont@domainegere.com, sera autorisé a utiliser comme MAILFROM les alias que tu cites:

alain.dupond@domainegere.com alain-dupont@domainegere.com ad@domainegere.com a.d@domainegere.com a-d@domainegere.com

MAIS AUSSI: groupe@domainegere.com


car il apparait dans les users autorisés a utiliser cet alias.


robert@fai.fr,martin@domaineexterieur.com eux ne sont pas concernés car evidemment il ne possedent pas de compte sur le serveur (pas d'identifiant SASL)
la regle pour eux ne matche pas.


donc pour que soit clair on parle de mailfrom et non de connection SASL, celle ci restant toujours la meme c'est a dire celle du compte mailbox.

[wpriz]

Effectivement, je me suis mal exprimé : je parle bien du MAIL FROM mais pas de la connexion SASL dont le login (nom d'utilisateur + mot de passe) est défini dans la table MAILBOX (ouf, on va y arriver).

Par contre je ne pige pas que "groupe@domainegere.com" puisse être utilisé dans le MAIL FROM car la requête devrait être :

Code :

query = SELECT goto FROM alias WHERE address LIKE '%%s%'

non ?

[mrtonio]

parce qu'en fait il faut comprendre que la verif est faite dans l'autre sens

pour faire simple:

champ address: le MAILFROM
champ goto: le login SASL (c'est a dire l'email du user comme dans le champ mailbox)

donc quand le login sasl qui est présenté par le user lors de la connection est le meme que celui qui est resolu par la requete c'est OK

[wpriz]

oui exact, décidément j'ai un problème avec cette requête : je fais constamment l'inversion...
mais dans ce cas précis :
goto=alain.dupont@domainegere.com,robert@fai.fr,martin@domaineexterieur.com et address=groupe@domainegere.com donc cela ne colle pas.
A moins que postfix ne fasse pas la comparaison et attend juste que la requête soit valide (vrai ou faux)