Salut jibe et sibsib,
Pardon de n'avoir pas donné signe de vie mais je rentre aujourd'hui des US et je découvre vos réponses.
Ouais! bon, je vois que ma config vous laisse perplexe. Il faut sans doute que je précise quelques détails:
Jibe a écrit:
Si j'ai bien tout compris, il me semble que j'aurais installé fetchmail sur la 6.5 directement. Quant à la contrib d'authentification SMTP, je n'en vois pas trop l'intérêt, mais bon, je n'ai pas de problèmes pour utiliser le proxy transparent alors que c'est peut-être ton cas ?
Fetchmail sur la 6.5 aurait pu effectivement s’envisager, mais je suis resté dans la logique d’un traitement initial des flux en DMZ pour l’analyse (je sais ça se discute…) mais surtout je pensai que Fetchmail n’était pas opérationnel sur la 6.5. Je sais aujourd’hui que sibsib a réglé le problème.
De plus j'ai ScanVirusWall de Trend Micro sur la SME en DMZ.
Pour l’authentification SMTP, elle m’est imposée par mon hébergeur. Je pourrais passer par mon fournisseur d’accès mais mon hébergeur est plus efficace et cela me paraît plus propre et cohérant de passer par un seul serveur externe.
Maintenant, je ne suis pas sûr non plus d'avoir tout compris dans ton histoire de fetchmail qui renvoie vers la 6.5 ? Si j'avais voulu faire un truc de ce style, j'aurais renvoyé dans une boite temporaire que la 6.5 viendrait relever...
Oui j'ai pensé à cette solution, mais deux fetchmail à la file me paraissait pour le coup "usine à gaz"
Réponse à sibsib:
En fait, mon intension première était de conserver l’import des emails externes avec fetchmail, qui plutôt que de les délivrer localement sur la machine en DMZ, devait les forwarder vers mon nouveau serveur sur le LAN. Ce serveur est destiné à recevoir egroupware (magnifique groupware !) et fonctionne en IMAP avec Cyrus pour le partage de certaines BALs. Des règles de filtrage pour un classement auto de certains emails de fournisseurs et la sauvegarde des emails archivés.
Le serveur en DMZ étant un passage obligé des flux SMTP FTP et HTTP pour analyse par SVW de Trend. ClamAV pour POP3 et Spam Assassin complètent l’arsenal guerrier de ma config.
Mon problème était que le forward vers le LAN des emails « fetchés » ne passait pas. Les règles du Firewall IPCop étaient bonnes puisque je passais en attaquant avec un telnet sur le port 25 de la DMZ vers le LAN.
En fait, j’ai trouvé l’astuce que tu pourras certainement m’expliquer SibSib: fetchmail ajoute devant l’adresse email de destination la chaîne suivante : « fm_fm- »
ce qui signifie que pour chaque compte de réception sur mon serveur dans le LAN, il faut créer un alias de types : « fm_fm-compte-user »
Ainsi l’email
toto@mondomaine.fr reçoit en fait sur
fm_fm-toto@mondomaine.frBizarre mais ça marche très bien! Seul bémol, le scan d’ISVW de trend micro n’y voit que fifre…
Par contre AMAVIS laisse bien sa marque dans l’en-tête du mail.
Autre possibilité : délivrer le mail « Fetché » dans une Bal Locale et forwarder la BAL vers l’adresse sur SME 6.5 du LAN. On peut lire dans l’en-tête que c’est toujours Fetchmail qui réalise le transfert et en fait rien ne change par rapport à l’envoi direct.
Voilà donc comment je m’en suis sorti.
J’abandonne la solution qui consiste à recevoir directement les emails sur le port 25 de mon Firewall à cause des risques de relais SMTP.
Maintenant, pour la sortie :
Si tu souhaites que ton serveur Interne utilise ton serveur de DMZ comme serveur mandataire, je pense que tu as en affet un gros problème :
En mode server & Gateway, le choix des adresses IP susceptibles de pouvoir envoyer du mail au monde entier sont déterminées : typiquement le serveur et les réseaux connus comme locaux.
Je ne crois pas que ceci existe en mode 'server only'
De plus, au niveau flux, les mails externes et internes proviennent tous par la même interface réseau. Bon, çà, çà se gère ! Mais pas forcément par défaut.
Ta réponse Sibsib n’est pas tout à fait claire pour moi. Bien sûr mon SME en DMZ est en mode « server only » puisqu’il est en DMZ d’IPCop. Mais ceci ne pause pas de problème pour lui déléguer l’envoi des emails vers l’extérieur. Il suffit pour cela de renseigner le champ « Adresse du serveur de courrier du fournisseur de services Internet » sur SME 6.5 du LAN avec l’ip de la SME en DMZ et tous les emails sont ainsi passés à l’antivirus avec une signature lisible pour le client qui reçoit l’email avec l’assurance que celui-ci n’est pas vérolé.
Ce qui me semblerait plus prudent (à gérer au niveau des règles IPCOP :
Tout SMTP rentrenat forwardés à SME DMZ.
SME DMZ peut se connecter à SME interne
SEM Interne peut envoyer directement sur le NET.
Tout autre trnasfert SMTP est interdit. (En gros, SME DMZ ne peut pas envoyer sur le NET).
Après, si les règles sont béton sur SME DMZ et SME Interne, çà devrait passer.
Mais j’avoue que les règles que tu me suggère sont à étudier.
J'avais pensé à utiliser smtproute pour interdire l'envoi qui ne serai pas initier par mondomaine.
Mais ceci est moins important maintenent étant donné que je n'envisage plus pour le moment d'ouvrir mon port 25...
Merci encore pour vos réponses!
Naoru
S'attacher à l'arme de l'ennemi, c'est s'attacher à la blessure. Morihei UYESHIBA
)(@sibsib : c'est juste une histoire de compét
