Philippe Strauss wrote:
>
> tssk tssk :)
>
> ok pour la doc de courier, mais courier le fait apres le download
> complet, avant la fin de la session smtp.
En plus désolé pour ce copier-coller loupé, c'était pas ma machine
habituelle et il y'avait un line-wrap qui rendait tout ça salement
illisible.
> Il semble que sendmail puisse potentiellement le faire alors que
> le transfert est en cours.. pratique pour rejeter un message infecte/spam
> et qui plus est volumineux.. sauve la bande passante :-))
Comment?
- un serveur smtp ne peut pas dire stop lorsqu'il a répondu 354 ok après
que le client ait dit DATA
- fermer la connexion méchamment au milieu serait pris par le client
comme une erreur temporaire 4xx, donc retry, donc même peut-être + de
bande passante
- une solution ignoble: que le serveur se souvienne du message par rapport
au mail from, rcpt to, ip du serveur et réponde carrément 5xx quelque
chose à la deuxième tentative :) Dommage que le client ne donne pas une
id unique pour le mail, pour être sur de refuser définitivement le bon.
> Mais bon j'en ai pas besoin pour le moment, de cet 'feature' et j'imagine
> pas le hack que cela doit etre dans sendmail... :^)
Je me pose plutôt la question de savoir ce que ça amène vraiment car par ex.
la récursivité à outrance de mime n'aide pas à extraire des blocs pour
les analyser avant d'avoir la totalité du mail
Déjà qu'une lib pour parser du mime c'est pas simple mais le faire sur un
stream avec interdiction de seeker ... (en avant du moins)
Nicolas
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question.
