Problème Deferred Postfix en MX Backup
Tibo
Je dois installer 2 serveurs de mail pour un client, le primaire avec :
- Postfix, Spamassassin, Clamav
Le MX Backup avec seulement postfix
Le primaire fonctionne tr�s bien mais le MX Backup me pose probl�me car
il garde dans sa "deferred queue" tous les mails "spams" dont le
primaire ne veut pas.
Exemple, un spammeur envoi un courrier � dup...@domaine.com
domaine.com existe bien mais pas l'adresse mail dup...@domaine.com. Le
primaire rejette le mail mais le Backup le garde dans sa deferred queue
alors qu'il sait que le primaire n'en veut pas :
Recipient address rejected: User unknown in virtual mailbox table
Je ne trouve pas o� configurer cela et si c'est possible...
Merci d'avance pour votre aide,
Thibaut
Fabien LE LEZ
>Le MX Backup avec seulement postfix
C'est peut-�tre l� le probl�me.
Si tu as r�ellement besoin d'un MX backup (ce qui me para�t douteux
dans la plupart des cas), assure-toi qu'il a la m�me config que le MX
principal. En particulier, il devrait refuser � l'entr�e les e-mails
vers des destinataires inconnus.
Imagine le cas suivant : ton MX principal est en panne pendant
plusieurs heures (s'il ne s'agissait que de quelques minutes, un MX
secondaire aurait encore moins d'int�r�t), et le MX secondaire re�oit
trois e-mails :
1/ Un e-mail l�gitime, envoy� � ton adresse t.le...@tib1.com
2/ Un e-mail l�gitime, envoy� par erreur � tt.le...@tib1.com
3/ Un spam, envoy� � jo...@tib1.com, avec une adresse
d'exp�diteur bidon.
- Le MX secondaire va indiquer au MTA de l'exp�diteur que (1) est bien
arriv�, alors qu'en fait il est en attente. Moyen.
- Il va aussi indiquer que (2) est accept�, alors que l'adresse du
destinataire est fausse. G�nant. En plus, ton MX principal va devoir
renvoyer un e-mail d'erreur � l'exp�diteur, mais ne va pas pouvoir le
faire tout de suite puisqu'il est en panne.
- Il va �galement accepter (3). Ensuite, le MX principal, s'apercevant
que jo...@tib1.com n'existe pas, va probablement renvoyer le spam vers
l'exp�diteur pr�sum�, qui n'a rien demand�.
Il me semble qu'il n'y a qu'un cas valable pour un MX secondaire : Un
r�el serveur de backup, avec configuration identique au serveur
principal, y compris le serveur POP3.
Dans le cas contraire :
Si le MX secondaire est capable de transmettre l'e-mail
directement au MX principal, je n'en vois pas bien l'int�r�t : le MTA
de l'exp�diteur aurait aussi bien fait de s'adresser au MX principal.
S'il n'est pas capable de transmettre imm�diatement l'e-mail au
serveur principal, il devrait l'indiquer � l'exp�diteur, par un code
4xx.
Tibo
n'en avons d'ailleurs pas nous-m�me.
Or mon client en veut un, il nous a produit un cahier des charges pour
cela, et il paye cher pour �a :-p
Donc �a m'aiderait bien de savoir comment bien configurer le MX Backup...
L�, j'ai l'impression que le MX secondaire a un mail, il le transmet au
MX principal qui lui dit "non non, cet utilisateur n'existe pas".
Ensuite le MX secondaire retente sa chance plut�t que de renvoyer le
mail. Ou alors c'est le MX principal qui n'est pas bien configur� et qui
aurait d� renvoyer la r�ponse directement � l'exp�diteur ?
Fabien LE LEZ a �crit :
Fabien LE LEZ
>j'ai l'impression que
Faut pas avoir d'impressions. Mieux vaut lire les logs, qui te
renseigneront sur la r�ponse du MX principal, et la d�cision du
secondaire.
Tibo
L�, en temps "normal", c'est � dire quand les 2 serveurs fonctionnent :
Le MX secondaire re�oit un mail, il veux le transmettre au MX principal
qui lui dit "non non, cet utilisateur n'existe pas". Ensuite le MX
secondaire place ce mail dans la deferred queue.
Comment lui dire de renvoyer le spam ?
Fabien LE LEZ a �crit :
Erwan David
> Autant pour moi, ce n'est pas une impression ^^
>
> L�, en temps "normal", c'est � dire quand les 2 serveurs fonctionnent :
>
> Le MX secondaire re�oit un mail, il veux le transmettre au MX
> principal qui lui dit "non non, cet utilisateur n'existe pas". Ensuite
> le MX secondaire place ce mail dans la deferred queue.
>
> Comment lui dire de renvoyer le spam ?
C'est d�j� trop tard, il n'aurait pas du accepter ce message.
Il faut qu'il ait un antispam synchronis� avec le MX principal, ainsi que
la liste des adresses accept�es par celui-c-i pour accepter et refuser
les messages exactement comme le premier;
--
Le travail n'est pas une bonne chose. Si �a l'�tait,
les riches l'auraient accapar�
Tibo
>
> C'est d�j� trop tard, il n'aurait pas du accepter ce message.
>
> Il faut qu'il ait un antispam synchronis� avec le MX principal, ainsi que
> la liste des adresses accept�es par celui-c-i pour accepter et refuser
> les messages exactement comme le premier;
>
On peut v�rifier l'utilisateur si le MX principal est actif avec
smtpd_recipient_restrictions = reject_unverified_recipient
Mais s'il tombe ??
Fabien LE LEZ
>On peut v�rifier l'utilisateur si le MX principal est actif avec
>smtpd_recipient_restrictions = reject_unverified_recipient
>
>Mais s'il tombe ?
Il faut le pr�voir avant. Un rsync r�gulier (une fois par minute par
exemple) de la config compl�te du MX principal vers le MX secondaire
devrait faire l'affaire.
Fabien LE LEZ
>Ah oui, aussi, en 1991, on bouncait les adresses incorrectes.
>Aujourd'hui, avec les attaques dictionnaire, on les droppe. (Faudrait
>d'ailleurs que je mette en place une heuristique pour d�tecter les
>fautes de frappe dans les RCPT TO, un de ces jours)
Je ne suis pas s�r de tout comprendre.
Mon MX refuse imm�diatement une ligne "RCPT TO" avec une adresse
incorrecte :
| rcpt to:<nob...@gramster.com>
| 550 5.1.1 <nob...@gramster.com>: Recipient address rejected: User unknown in virtual mailbox table
Du coup, en l'absence d'un destinataire correct, la commande "DATA"
n'est m�me pas accept�e.
Ni bounce, ni drop : un message d'erreur clair.
Ou bien, est-ce le MTA de l'exp�diteur qui s'abstient de cr�er un
bounce ?
Arnaud Launay
> Ca n'est tout simplement pas possible d'avoir un MX2 si on
> veut une archi sï¿œcurisï¿œe spam/virus
Bah si... Mais pas si on veut faire un 550 tout de suite aprï¿œs le
DATA.
Arnaud.
--
Perso: http://launay.org/blog/
Hï¿œbergement: http://www.nocworld.com/
Fabien LE LEZ
<a...@launay.org>:
>Mais pas
Bah si. Si tu as deux serveurs identiques, il n'y a pas de raison pour
qu'ils ne r�agissent pas de la m�me fa�on.
Une solution, moins bonne mais acceptable, serait que le MX secondaire
interroge en temps r�el le MX principal. Bien s�r, en cas de panne du
MX principal, le serveur sera nettement plus permissif, mais comme
c'est rare, ce n'est pas bien grave.
Une autre voie : si le MX secondaire d�tecte de fa�on fiable que le MX
principal fonctionne correctement, il peut carr�ment r�pondre
"4xx -- allez voir le MX principal".
Erwan David
>
> Ah oui, aussi, en 1991, on bouncait les adresses incorrectes.
> Aujourd'hui, avec les attaques dictionnaire, on les droppe. (Faudrait
> d'ailleurs que je mette en place une heuristique pour d�tecter les
> fautes de frappe dans les RCPT TO, un de ces jours)
Non, on les reject...
Tibo
Il n'y a pas une config � faire sur postfix qui :
- soit demande au principal si ok et si non rejette l'�metteur
- soit envoie automatiquement au principal et rejette le mail si le
principal dit que ce n'est pas bon
- soit autre solution mais avec le m�me r�sultat
?
Fabien LE LEZ
>Autant tu n'aimes pas les impressions, autant je n'aime pas le bricolage
Si tu veux que le MX secondaire fonctionne m�me en cas de panne du MX
principal, il faut bien qu'il contienne les m�mes informations que le
MX principal.
Arnaud Launay
> >Autant tu n'aimes pas les impressions, autant je n'aime pas le bricolage
> panne du MX principal, il faut bien qu'il contienne les mï¿œmes
> informations que le MX principal.
base de donnï¿œe rï¿œpliquï¿œe,
address_verify_map = btree:/var/lib/postfix/verify
unverified_recipient_reject_code = 550
etc...
Erwan David
> Le 09-12-2009, Fabien LE LEZ <gram...@gramster.com> a �crit�:
>> >Autant tu n'aimes pas les impressions, autant je n'aime pas le bricolage
>> Si tu veux que le MX secondaire fonctionne m�me en cas de
>> panne du MX principal, il faut bien qu'il contienne les m�mes
>> informations que le MX principal.
>
> base de donn�e r�pliqu�e,
>
> address_verify_map = btree:/var/lib/postfix/verify
> unverified_recipient_reject_code = 550
On peut aussi regarder vers le relay_recipient_maps
Olivier Masson
> Arnaud Launay<a...@launay.org> �crivait :
>
>> Le 09-12-2009, Fabien LE LEZ<gram...@gramster.com> a �crit :
>>>> Autant tu n'aimes pas les impressions, autant je n'aime pas le bricolage
>>> Si tu veux que le MX secondaire fonctionne m�me en cas de
>>> panne du MX principal, il faut bien qu'il contienne les m�mes
>>> informations que le MX principal.
>>
>> base de donn�e r�pliqu�e,
>>
>> address_verify_map = btree:/var/lib/postfix/verify
>> unverified_recipient_reject_code = 550
>
> On peut aussi regarder vers le relay_recipient_maps
>
C'est ce que je fais (copie du relay_recipient_maps � chaque
modification de ce dernier).
Et j'ajoute des reject_rbl_client au MX secondaire (puisqu'il est
principalement utilis� par les spammeurs).
Et j'ajoute m�me du greylisting (ce que je ne fais pas sur le principal
: trop de ressources, trop de d�lais).
Par contre, quel est l'utilit� de renvoyer un code 550 plut�t qu'un 450 ?
Patrick Lamaizière
> C'est ce que je fais (copie du relay_recipient_maps � chaque
> modification de ce dernier).
> Et j'ajoute des reject_rbl_client au MX secondaire (puisqu'il est
> principalement utilis� par les spammeurs).
> Et j'ajoute m�me du greylisting (ce que je ne fais pas sur le principal
> : trop de ressources, trop de d�lais).
> Par contre, quel est l'utilit� de renvoyer un code 550 plut�t qu'un 450 ?
Si l'utilisateur n'existe pas ce n'est pas une erreur temporaire, pas la
peine de r�essayer.
Tibo
backup, il faut avoir la liste des adresses autoris�es par le principal...
Sinon, on garde les mails en deferred le temps configur� dans postfix, �
savoir le param�tre maximal_queue_lifetime, c'est bien �a ?
Patrick Lamaizière
> Finalement, si j'ai bien compris, pour �viter les deferred sur le MX
> backup, il faut avoir la liste des adresses autoris�es par le principal...
Oui, mais c'est plut�t pour �viter de "backscatter". Si tu acceptes un
mail et que le MX principal le refuse, tu vas g�n�rer un bounce vers
une personne innocente (en g�n�ral vu le spam).
L� tu le refuses drectement lors de la session SMTP et le bounce n'est
pas ton probl�me.
Par contre si ton MX backup garde les mails en deferred, �a veut dire
que le MX principal renvoie une erreur temporaire en 4XX quand une
adresse n'existe pas. �a c'est *MAL* (ama).
Fabien LE LEZ
>Sauf que mon MX, n'est qu'un "hub", sans utilisateurs. Il ne fait que
>retransmettre � la passerelle antispam/antivirus. Qui, elle ne peut
>r�pondre que EX_OK, EX_TEMPFAIL ou EX_UNAVAILABLE
Pour paraphraser ton message pr�c�dent : c'est typiquement le genre
d'architecture qui fonctionnait bien il y a dix ans, mais qui ne peut
plus fonctionner maintenant, � cause du spam.
En 2009, �tre capable de d�tecter les utilisateurs inexistants le plus
t�t possible, si possible avant le DATA, me para�t primordial.
Tibo
> Fabien LE LEZ <gram...@gramster.com> wrote:
>
>> En 2009, �tre capable de d�tecter les utilisateurs inexistants le plus
>> t�t possible, si possible avant le DATA, me para�t primordial.
>
>
En passant, merci pour vos pr�c�dentes r�ponses :)
Je me suis pos� une autre probl�matique maintenant :
Si je propose un service de MX backup � nos clients ( les commerciaux
ont jaug�s, beaucoup sont int�ress�s ) et qu'on n'a pas forc�ment acc�s
aux BAL valides, quel peut-�tre le risque ?
Que les mauvais mails passent en deferred jusqu'� ce qu'ils soient
renvoy�s � l'exp�diteur ? (et souvent pas le spammeur mais un pauvre
innocent)
Autre chose ?