> Le 25, 23 c'est telnet. Cf. /etc/services . Mais je préfère désigner les
> ports par leur nom symbolique : postfix écoute sur le port smtp.
Oups, répondu trop vite ...
> Je pense qu'on n'est pas obligés d'ouvrir le port.
On peut préciser sur quelles interfaces / adresses postfix écoute
ou attend des connexions. Exemple ici :
http://olivieraj.free.fr/fr/linux/information/firewall/fw-02-05.html#II-5-8
<extrait>
mynetworks_style = subnet
mynetworks = 192.168.0.0/24
inet_interfaces = phoenix0.sky.net
mydestination = 192.168.0.0/24
</extrait>
Mais apparemment, on ne peut pas lui spécifier un fichier local ou
une socket UNIX (cf documentation : http://www.postfix.org/basic.html)
On peut bien évidement limiter le fonctionnement de postfix à
l'interface loopback ("lo") et aux adresses IP localhost (127.x.y.z).
Cependant, ne connaissant pas le code de postfix, je ne sais pas si c'est
suffisant, et comment il interprète l'option "inet_interfaces". Un paquet
formaté pour faire un buffer overflow sur postfix, arrivant de ppp0/eth0
et prétendant venir de 127.0.0.1, peut-il passer le test du
"inet_interfaces", et être au final suffisamment interprété pour faire
planter le serveur ? Aucune idée, mais c'est un risque...
Certains dirons que l'on peut configurer netfilter et le
"/proc/sys/net/ipv4/conf/*/rp_filter" pour éviter ce type de spoofing,
mais c'est en fait accepter une faiblesse (potentielle) d'un démon en
transférant la gestion du problème sur le kernel lui-même...
> Postfix est très
> modulaire, constitué d'un ensemble de petits démons. Le port smtp est
> ouvert par le démon smtpd, qui ne sert que pour recevoir des mails de
> l'extérieur. Si la machine ne reçoit pas des mails, on doit pouvoir se
> passer de smtpd.
>
>> et attend qu'un client de mail ("mozilla", "kmail", "sylpheed",
>> "mail", etc...) le sollicite pour envoyer un mail.
>
> Ce que le client fait en appelant la commande sendmail (*) et en lui
> passant le message à son entrée standard. Au moins mail et mutt font
> comme ça, la commande mail() de PHP aussi me semble-t-il. C'est je crois
> la façon canonique d'envoyer un mail sous Unix. sendmail met le message
> dans la queue maildrop où un autre démon (pickup) le prend en charge.
> Pas besoin de smtpd pour tout ça.
Quelques uns des programmes que je connais n'utilisent pas la
commande sendmail : Mozilla mail ouvre tout seul le port 25 du serveur
SMTP. Le module "Net::SMTP" de Perl aussi (il permet de créer un mail de
toute pièce, en Perl). De même que le bon vieux "telnet HOST 25", où l'on
écrit soit-même les commandes de mails (EHLO, FROM, TO, BODY, etc...).
> Si on a un script qui envoie des mails en se connectant sur le port smtp
> de localhost, on peut toujours avoir un smtpd qui écoute uniquement sur
> l'interface loopback. Cf. /etc/postfix/master.cf .
Oui, mais comme dit plus haut : Est-ce suffisant ?
Olivier
