[cassiopee]

Justement, c'est les billets-internationaux-SNCF, demande de réintialisation de password sur des sites, bref tous ces trucs que tu fais une fois tous les dix-huit mois, pour lesquels tu attends une réponse quasi immédiate, et qui arriveront "plus tard" avec un délai qui n'est pas sous ton contrôle.

Oui, je comprends ton argument mais jusqu'à présent je n'ai pas eu de souci de ce genre
(+3500 emails rentrants légitimes par jour sur ce serveur).

Même sans greylist, les réinit de password et autres mails de ce genre mettent parfois du temps à arriver
(pas forcément 3 heures non plus mais 5, 10 ou 15 minutes facilement) , alors du coup ça ne change pas grand chose.

Tu sais que j'en arrive à me demander si ce ne sont pas des équipement IoT qui ont été hackés, des DVR ou caméras de surveillance.

Un peu de lecture -> http://www.scmagazineuk.com/malware-...rticle/505932/

Oui, j'avais vu passer ce gros piratage de caméras ; ça va être super lorsque tous les objets de la maison
vont pouvoir être :

1) connectés à 12h00
2) piratés à 12h01
3) et commencer à spammer à 12h02

Comment blacklister ça ?

Si c'est possible : repérer les points communs, par exemple ici les noms présentés dans le HELO
et y mettre un filtre.

Je viens justement de faire ça hier afin de filtrer un ransomware qui avait la bonne idée de reprendre
le nom de quelqu'un qui existe mais qui ne pouvait pas reprendre exactement le nom (il manquait
un point entre le prénom et le nom) pour cause de SASL;

La partie "nom utilisateur" de l'adresse email était constante mais pas la partie "nom de domaine"
qui changeait très souvent.

Je ne pouvais pas non plus filtrer sur l'IP ou le nom du serveur SMTP émetteur car lui était
légitime (par exemple Wanadoo UK). L'IP de départ était au Bangladesh mais le message
parvenait à travers des PC (vraisemblablement infectés/piratés) répartis dans toute l'Europe
et qui eux utilisaient des serveurs SMTP légitimes pour émettre le message.

Du coup j'ai mis un filtre via l'option "check_sender_access" dans la directive "smtpd_recipient_restrictions".

ça renvoie vers un fichier texte dans lequel il y a simplement :

jeandupont@    REJECT

ce qui filtre "jeandupont@domaine1.fr", "jeandupont@domaine2.org", "jeandupont@domaine3.net", "jeandupont@domaine4.com", etc.
comme adresse email d'émission du message.

et boum, plus de ransomware diffusé :

Jun 30 14:42:40 mail postgrey[30872]: action=greylist, reason=new, client_name=sout1.wanadoo.co.uk, client_address=193.252.22.95, sender=jeandupont@katrinasmith.orangehome.co.uk, recipient=jean.dupont@domaine.fr

Jun 30 14:42:40 mail postfix/smtpd[3400]: NOQUEUE: reject: RCPT from sout1.wanadoo.co.uk[193.252.22.95]: 554 5.7.1 : Sender address rejected: Access denied; from= to= proto=ESMTP helo=

Le corps du message n'était composé que d'un lien hypertexte qui changeait très souvent +
le nom de la personne en 'signature', donc pas de filtrage possible à ce niveau là.

Dans cet exemple le filtre est sur l'adresse email d'émission mais on peut quasiment tout filtrer de la sorte.
("check_helo_access" pour filtrer le HELO)

Bien entendu, il n'y a pas de réponse absolue, tout dépend des caractéristiques de "l'attaque".

Autre exemple en cas d'affluence record : de la même façon que l'on doit parler "doucement" à Orange/Wanadoo,
pas plus de X connexions simultanées, etc. on peut restreindre les connexions rentrantes dans son serveur SMTP :

http://www.postfix.org/TUNING_README.html#conn_limit

[fritz2cat]

La gestion est intelligente dans le sens où ça n'est pas du tout "je refuse tout message rentrant
pendant 5 bonnes minutes", l'algorithme s'adapte, reconnait les IP récurrentes, etc.
ce qui fait les principaux correspondants ne sont quasiment plus filtrés/retardés au bout
de quelques temps.

Justement, c'est les billets-internationaux-SNCF, demande de réintialisation de password sur des sites, bref tous ces trucs que tu fais une fois tous les dix-huit mois, pour lesquels tu attends une réponse quasi immédiate, et qui arriveront "plus tard" avec un délai qui n'est pas sous ton contrôle.

- - - Mise à jour - - -

Lol Si même les spammeurs ont des enregistrements SPF à jour ...

D'un autre côté, ça donne une plage d'adresses IP qu'il serait peut-être intéressant de filtrer ...

Tu sais que j'en arrive à me demander si ce ne sont pas des équipement IoT qui ont été hackés, des DVR ou caméras de surveillance.
Comment blacklister ça ?
Un peu de lecture -> http://www.scmagazineuk.com/malware-...rticle/505932/

[cassiopee]

Je n'ai filtré que les lignes concernant le invalid HELO.
Il y a aussi des montagnes de zen.spamhaus et cbl.abuseat.org (les 2 incontournables à mon avis)

Oui, comme leurs IP ne sont pas (encore ?) filtrées par les listes, ils arrivent jusqu'au test du HELO.

Et tant qu'on y est les gros bourrins de megabulkmessage ont compris qu'ils devraient s'améliorer, mais ce n'est pas encore bon

Ils ont l'air bien pénibles en effet ...

A ce niveau là, je collerais carrément un filtre sur " 'megabulkmessage' dans l'adresse d'émission ?" => REJECT dans Postfix

Et pour le greylisting, j'ai essayé, je n'ai pas aimé. Je n'emploierais plus jamais sur des adresses mail personnelles (à la rigueur on laisse sur les génériques info@domaine ou contact@domaine). Je l'avais expliqué dans cet article en 2013 qui n'est peut-être plus tout-à-fait à jour http://blog.demees.net/?p=7

Moi aussi au début j'avais des a priori négatifs mais j'ai essayé et franchement c'est efficace.

En général, on refuse plutôt des retours trop rapides plutôt que l'inverse

Exemple :

Jun 28 09:07:11 mail postgrey[30872]: action=greylist, reason=early-retry (271s missing), [...]
Jun 28 09:07:43 mail postgrey[30872]: action=greylist, reason=early-retry (239s missing), [...]
Jun 28 09:08:14 mail postgrey[30872]: action=greylist, reason=early-retry (208s missing), [...]
Jun 28 09:08:45 mail postgrey[30872]: action=greylist, reason=early-retry (177s missing), [...]
Jun 28 09:09:16 mail postgrey[30872]: action=greylist, reason=early-retry (146s missing), [...]
Jun 28 09:09:46 mail postgrey[30872]: action=greylist, reason=early-retry (116s missing), [...]
Jun 28 09:10:17 mail postgrey[30872]: action=greylist, reason=early-retry (85s missing), [...]
Jun 28 09:10:49 mail postgrey[30872]: action=greylist, reason=early-retry (53s missing), [...]
Jun 28 09:11:20 mail postgrey[30872]: action=greylist, reason=early-retry (22s missing), [...]

( 9 re-essais par un seul émetteur, le tout en moins de 5 minutes après le refus initial ...)

La gestion est intelligente dans le sens où ça n'est pas du tout "je refuse tout message rentrant
pendant 5 bonnes minutes", l'algorithme s'adapte, reconnait les IP récurrentes, etc.
ce qui fait les principaux correspondants ne sont quasiment plus filtrés/retardés au bout
de quelques temps.

- - - Mise à jour - - -

Et ces $*£%& de spammeurs ont bien enregistré leurs domaines

Lol Si même les spammeurs ont des enregistrements SPF à jour ...

D'un autre côté, ça donne une plage d'adresses IP qu'il serait peut-être intéressant de filtrer ...

[fritz2cat]

Et ces $*£%& de spammeurs ont bien enregistré leurs domaines

$ dig agglutinativep.megabulkmessage79.com any

; <<>> DiG 9.10.3-P4 <<>> agglutinativep.megabulkmessage79.com any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65530
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;agglutinativep.megabulkmessage79.com. IN ANY

;; ANSWER SECTION:
agglutinativep.megabulkmessage79.com. 5 IN A 46.121.98.208
agglutinativep.megabulkmessage79.com. 5 IN MX 10 mail.megabulkmessage79.com.
agglutinativep.megabulkmessage79.com. 5 IN TXT "v=spf1 mx a ip4:46.121.98.208/28 ~all"
agglutinativep.megabulkmessage79.com. 5 IN TXT "v=DMARC1; p=none; rua=mailtoostmaster@agglutinativep.megabulkmessage 79.com"

;; ADDITIONAL SECTION:
mail.megabulkmessage79.com. 2433 IN A 149.154.64.43

;; Query time: 279 msec
;; SERVER: 192.168.68.5#53(192.168.68.5)
;; WHEN: Fri Jul 01 20:29:17 CEST 2016
;; MSG SIZE rcvd: 257

[fritz2cat]

Je n'ai filtré que les lignes concernant le invalid HELO.
Il y a aussi des montagnes de zen.spamhaus et cbl.abuseat.org (les 2 incontournables à mon avis)
Et tant qu'on y est les gros bourrins de megabulkmessage ont compris qu'ils devraient s'améliorer, mais ce n'est pas encore bon

Jul 1 20:05:01 v2 postfix/smtpd[26564]: NOQUEUE: reject: RCPT from unknown[186.34.148.165]: 550 5.1.8 : Sender address rejected: Domain not found; from= to= proto=SMTP helo=
Jul 1 20:14:23 v2 postfix/smtpd[26591]: NOQUEUE: reject: RCPT from unknown[179.211.190.187]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 20:24:01 v2 postfix/smtpd[26683]: NOQUEUE: reject: RCPT from unknown[46.121.98.208]: 554 5.7.1 Service unavailable; Client host [46.121.98.208] blocked using cbl.abuseat.org; Blocked - see http://www.abuseat.org/lookup.cgi?ip=46.121.98.208; from= to= proto=SMTP helo=

3 manières de rejeter comme vous pouvez le voir

Quant à spamassassin, c'est très gourmand en CPU, dont tout ce qu'on a filtré en amont avec les règles Postfix ne sont que bénéfice. Il est efficace.
Et pour le greylisting, j'ai essayé, je n'ai pas aimé. Je n'emploierais plus jamais sur des adresses mail personnelles (à la rigueur on laisse sur les génériques info@domaine ou contact@domaine). Je l'avais expliqué dans cet article en 2013 qui n'est peut-être plus tout-à-fait à jour http://blog.demees.net/?p=7

Greylisting (voir http://fr.wikipedia.org/wiki/Greylisting). En bref, pour un nouveau serveur/correspondant qui m’expédie un message, le serveur simulera un souci temporaire. Le serveur de l’expéditeur devra donc réessayer un peu plus tard. Très intéressant pour les adresses génériques du genre contact@example.com. Par contre, c’est parfaitement casse-pieds pour les adresses d’individus comme vous et moi. Je prends un exemple: à 19h30 je commande on-line un ticket de cinéma pour la séance de 21 heures. Le ticket électronique est bloqué et n’arrive pas à cause du greylisting. Il me parviendra plus tard, avec un retard dont la durée ne dépend pas de moi mais de la bonne volonté du serveur d’envoi de mail du cinéma. Dans les meilleurs cas 5 minutes, mais parfois plusieurs heures…

[cassiopee]

Est-ce que SpamAssassin intégré à Plesk peut m'aider ? Je l'ai déjà en place mais je ne sais pas si il est très efficace...

Si si, il est très efficace.

Après une période d'observation où tu peux regarder les notes moyennes des messages,
tu peux même abaisser la note à partir de laquelle un message est considéré comme spam.

De toute façon, la lutte contre le spam passe par une défense en profondeur.

Il n'y a pas de solution unique, qui intercepte à elle seule 100% des spams.

Il faut en général 2-3 niveaux successifs, du genre :

1) bien configurer Postfix
2) utiliser SpamAssassin ou équivalent
3) utiliser une ou plusieurs blacklist du genre SpamHaus ou équivalent

etc.

On peut également utiliser du greylisting, très efficace.

Avec Plesk, cf là : https://kb.plesk.com/en/6359

[cassiopee]

mouais. je vais ajouter un extrait de log TRES TRES spammy ; et pour ne pas devoir passer par la modération un vendredi à 18h40 je vais éditer mon message juste après l'avoir posté.

[...]

Voici le log sur un des serveurs, rien que pour aujourd'hui

Ah oui effectivement, chez toi c'est très présent !

Chez moi je crois que c'est SpamHaus qui les bloque en amont (au niveau de l'adresse IP de connexion).
C'est peut-être pour ça que je n'en vois quasiment pas/plus.

gna gna gna on va voir des tas de newbies pour les vacances. Ceux qui ont raté leur année, ne savent pas lire un how-to, et vont faire les calimero pour qu'on réfléchisse à leur place

... et vite surtout, non parce que ça urge

[fritz2cat]

Or ce genre de situations, fréquents dans le passé, tend à disparaître de nos
jours (blocage du port 25 par les FAI un peu partout dans le monde notamment).

mouais. je vais ajouter un extrait de log TRES TRES spammy ; et pour ne pas devoir passer par la modération un vendredi à 18h40 je vais éditer mon message juste après l'avoir posté.

Voici le log sur un des serveurs, rien que pour aujourd'hui

Jul 1 00:00:45 v2 postfix/smtpd[21979]: NOQUEUE: reject: RCPT from unknown[177.230.234.112]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 00:10:32 v2 postfix/smtpd[22005]: NOQUEUE: reject: RCPT from unknown[187.245.178.234]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 00:30:02 v2 postfix/smtpd[22038]: NOQUEUE: reject: RCPT from unknown[104.192.95.124]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 00:39:10 v2 postfix/smtpd[22058]: NOQUEUE: reject: RCPT from unknown[189.60.249.69]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 00:39:15 v2 postfix/smtpd[22062]: NOQUEUE: reject: RCPT from modemcable038.131-70-69.static.videotron.ca[69.70.131.38]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 00:48:23 v2 postfix/smtpd[22074]: NOQUEUE: reject: RCPT from unknown[177.239.222.229]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 00:58:21 v2 postfix/smtpd[22085]: NOQUEUE: reject: RCPT from host81-139-235-198.in-addr.btopenworld.com[81.139.235.198]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 01:36:47 v2 postfix/smtpd[22150]: NOQUEUE: reject: RCPT from unknown[23.31.17.181]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 02:06:30 v2 postfix/smtpd[22204]: NOQUEUE: reject: RCPT from 122-116-48-117.HINET-IP.hinet.net[122.116.48.117]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 02:16:05 v2 postfix/smtpd[22217]: NOQUEUE: reject: RCPT from unknown[112.170.246.166]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 02:36:11 v2 postfix/smtpd[22261]: NOQUEUE: reject: RCPT from unknown[210.1.211.182]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 02:42:48 v2 postfix/smtpd[22281]: NOQUEUE: reject: RCPT from unknown[171.248.156.231]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 02:46:09 v2 postfix/smtpd[22285]: NOQUEUE: reject: RCPT from c-107-4-172-231.hsd1.mn.comcast.net[107.4.172.231]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 02:46:12 v2 postfix/smtpd[22286]: NOQUEUE: reject: RCPT from host-174-45-85-163.bzm-mt.client.bresnan.net[174.45.85.163]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 02:46:16 v2 postfix/smtpd[22287]: NOQUEUE: reject: RCPT from host-64-17-68-231.beyondbb.com[64.17.68.231]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 02:56:09 v2 postfix/smtpd[22300]: NOQUEUE: reject: RCPT from unknown[192.34.131.183]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 02:56:11 v2 postfix/smtpd[22304]: NOQUEUE: reject: RCPT from unknown[46.227.245.182]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 03:05:58 v2 postfix/smtpd[22310]: NOQUEUE: reject: RCPT from cpe-96-28-103-15.kya.res.rr.com[96.28.103.15]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 03:25:39 v2 postfix/smtpd[22352]: NOQUEUE: reject: RCPT from unknown[149.156.92.135]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 03:45:41 v2 postfix/smtpd[22382]: NOQUEUE: reject: RCPT from unknown[118.189.63.24]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 04:44:53 v2 postfix/smtpd[22497]: NOQUEUE: reject: RCPT from unknown[119.198.164.163]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 04:45:03 v2 postfix/smtpd[22504]: NOQUEUE: reject: RCPT from unknown[91.222.210.138]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 05:06:36 v2 postfix/smtpd[22536]: NOQUEUE: reject: RCPT from unknown[187.247.8.64]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 05:16:38 v2 postfix/smtpd[22557]: NOQUEUE: reject: RCPT from unknown[187.244.203.109]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 05:40:33 v2 postfix/smtpd[22591]: NOQUEUE: reject: RCPT from 178-167-82-20.dynvpn.flex.ru[178.167.82.20]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 05:40:41 v2 postfix/smtpd[22606]: NOQUEUE: reject: RCPT from fl-71-3-20-30.dhcp.embarqhsd.net[71.3.20.30]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 05:40:43 v2 postfix/smtpd[22608]: NOQUEUE: reject: RCPT from 24-139-41-19.fidnet.com[24.139.41.19]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 05:46:40 v2 postfix/smtpd[22612]: NOQUEUE: reject: RCPT from unknown[187.64.31.121]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 05:46:42 v2 postfix/smtpd[22620]: NOQUEUE: reject: RCPT from broadband-95-84-216-91.nationalcablenetworks.ru[95.84.216.91]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 05:54:09 v2 postfix/smtpd[22628]: NOQUEUE: reject: RCPT from unknown[179.210.75.163]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 05:54:12 v2 postfix/smtpd[22629]: NOQUEUE: reject: RCPT from unknown[177.240.209.72]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 05:57:51 v2 postfix/smtpd[22635]: NOQUEUE: reject: RCPT from unknown[191.191.133.188]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 06:13:20 v2 postfix/smtpd[22673]: NOQUEUE: reject: RCPT from unknown[187.247.171.99]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 06:24:46 v2 postfix/smtpd[22690]: NOQUEUE: reject: RCPT from unknown[179.4.252.123]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 06:35:34 v2 postfix/smtpd[23248]: NOQUEUE: reject: RCPT from unknown[89.169.45.37]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 06:49:22 v2 postfix/smtpd[23273]: NOQUEUE: reject: RCPT from unknown[14.161.6.29]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 06:58:34 v2 postfix/smtpd[23282]: NOQUEUE: reject: RCPT from 75-109-202-64.nacdcmta01.com.dyn.suddenlink.net[75.109.202.64]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 07:08:45 v2 postfix/smtpd[23307]: NOQUEUE: reject: RCPT from unknown[175.202.78.10]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 07:29:34 v2 postfix/smtpd[23363]: NOQUEUE: reject: RCPT from unknown[201.52.136.151]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 08:31:34 v2 postfix/smtpd[23520]: NOQUEUE: reject: RCPT from unknown[187.45.121.137]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 08:41:10 v2 postfix/smtpd[23549]: NOQUEUE: reject: RCPT from unknown[187.252.186.142]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 08:41:23 v2 postfix/smtpd[23557]: NOQUEUE: reject: RCPT from unknown[177.230.214.149]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 08:50:21 v2 postfix/smtpd[23566]: NOQUEUE: reject: RCPT from 189.215.45.19.cable.dyn.cableonline.com.mx[189.215.45.19]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 10:04:01 v2 postfix/smtpd[23804]: NOQUEUE: reject: RCPT from unknown[42.114.174.21]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 10:04:06 v2 postfix/smtpd[23830]: NOQUEUE: reject: RCPT from unknown[113.171.184.82]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 10:11:35 v2 postfix/smtpd[23864]: NOQUEUE: reject: RCPT from unknown[115.74.87.44]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 10:22:54 v2 postfix/smtpd[23937]: NOQUEUE: reject: RCPT from cpe-67-48-135-38.rgv.res.rr.com[67.48.135.38]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 10:31:08 v2 postfix/smtpd[23954]: NOQUEUE: reject: RCPT from static.145.48.63.178.clients.your-server.de[178.63.48.145]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=ESMTP helo=
Jul 1 10:32:47 v2 postfix/smtpd[23954]: NOQUEUE: reject: RCPT from unknown[210.181.118.163]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 10:33:06 v2 postfix/smtpd[23974]: NOQUEUE: reject: RCPT from unknown[76.77.42.230]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 11:15:19 v2 postfix/smtpd[24187]: NOQUEUE: reject: RCPT from unknown[67.138.92.178]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 11:25:53 v2 postfix/smtpd[24232]: NOQUEUE: reject: RCPT from cm-84.208.221.185.getinternet.no[84.208.221.185]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 11:36:18 v2 postfix/smtpd[24275]: NOQUEUE: reject: RCPT from unknown[118.136.177.187]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 11:36:22 v2 postfix/smtpd[24287]: NOQUEUE: reject: RCPT from unknown[162.17.83.60]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 11:47:09 v2 postfix/smtpd[24343]: NOQUEUE: reject: RCPT from unknown[178.156.86.230]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 11:57:46 v2 postfix/smtpd[24375]: NOQUEUE: reject: RCPT from fl-67-76-214-176.sta.embarqhsd.net[67.76.214.176]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 11:57:48 v2 postfix/smtpd[24394]: NOQUEUE: reject: RCPT from unknown[192.162.215.105]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 12:39:19 v2 postfix/smtpd[24618]: NOQUEUE: reject: RCPT from unknown[181.73.90.94]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 12:51:41 v2 postfix/smtpd[24673]: NOQUEUE: reject: RCPT from 207.63.205.77.rev.sfr.net[77.205.63.207]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 13:10:15 v2 postfix/smtpd[24752]: NOQUEUE: reject: RCPT from unknown[138.75.152.227]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 13:49:21 v2 postfix/smtpd[24967]: NOQUEUE: reject: RCPT from unknown[27.75.81.95]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 14:02:16 v2 postfix/smtpd[25059]: NOQUEUE: reject: RCPT from cpc81666-leic20-2-0-cust23.8-1.cable.virginm.net[86.18.51.24]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 14:12:25 v2 postfix/smtpd[25130]: NOQUEUE: reject: RCPT from unknown[189.199.42.63]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 14:23:30 v2 postfix/smtpd[25202]: NOQUEUE: reject: RCPT from unknown[175.136.135.141]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 14:23:43 v2 postfix/smtpd[25203]: NOQUEUE: reject: RCPT from unknown[216.215.120.2]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 14:33:57 v2 postfix/smtpd[25257]: NOQUEUE: reject: RCPT from pool-109-191-155-204.is74.ru[109.191.155.204]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 14:55:23 v2 postfix/smtpd[25353]: NOQUEUE: reject: RCPT from bzq-79-176-50-52.red.bezeqint.net[79.176.50.52]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 14:55:46 v2 postfix/smtpd[25357]: NOQUEUE: reject: RCPT from unknown[31.29.112.203]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 15:16:47 v2 postfix/smtpd[25487]: NOQUEUE: reject: RCPT from 128-72-200-200.broadband.corbina.ru[128.72.200.200]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 15:47:52 v2 postfix/smtpd[25633]: NOQUEUE: reject: RCPT from h83-209-48-26.cust.se.alltele.net[83.209.48.26]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 15:47:53 v2 postfix/smtpd[25634]: NOQUEUE: reject: RCPT from produkt.starlink.ru[77.50.36.191]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 15:59:50 v2 postfix/smtpd[25740]: NOQUEUE: reject: RCPT from unknown[177.240.101.170]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 16:20:23 v2 postfix/smtpd[25846]: NOQUEUE: reject: RCPT from unknown[189.34.168.180]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 16:20:27 v2 postfix/smtpd[25850]: NOQUEUE: reject: RCPT from unknown[61.4.255.37]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 16:31:31 v2 postfix/smtpd[25899]: NOQUEUE: reject: RCPT from cpe-75-83-229-200.socal.res.rr.com[75.83.229.200]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 16:51:35 v2 postfix/smtpd[26003]: NOQUEUE: reject: RCPT from unknown[98.124.87.63]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 17:44:26 v2 postfix/smtpd[26163]: NOQUEUE: reject: RCPT from unknown[187.245.149.62]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 17:54:13 v2 postfix/smtpd[26176]: NOQUEUE: reject: RCPT from unknown[187.64.89.70]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 17:54:39 v2 postfix/smtpd[26176]: NOQUEUE: reject: RCPT from unknown[177.152.177.6]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 18:15:35 v2 postfix/smtpd[26246]: NOQUEUE: reject: RCPT from unknown[177.240.219.48]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 18:25:18 v2 postfix/smtpd[26289]: NOQUEUE: reject: RCPT from unknown[187.253.152.189]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=
Jul 1 18:36:08 v2 postfix/smtpd[26362]: NOQUEUE: reject: RCPT from unknown[77.82.17.68]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=

- - - Mise à jour - - -

megabulkmessage est visiblement en train de harceler un de mes utilisateurs, toujours le même.

- - - Mise à jour - - -

PS : non, vous n'avez pas le droit de partir en vacances ! Vous devez rester scotché au forum !!!

gna gna gna on va voir des tas de newbies pour les vacances. Ceux qui ont raté leur année, ne savent pas lire un how-to, et vont faire les calimero pour qu'on réfléchisse à leur place

[Chabi01]

Je n'avais pas vu tous vos derniers messages ! (ah bah bravo !).
Merci beaucoup à vous 2 : je vais regarder tout ça et faire comme me l'a écrit Frédéric : regarder à quoi correspond chaque ligne et comparer avec mon main.cf pour voir les différences (à force de l'avoir lu, je vois déjà de multiples différences !).

Merci encore : je m'attaquerai à ça la semaine prochaine (vendredi soir, un peu fatigué, encore pleins de boulot à faire "en urgence").

Merci, merci, merci (je ne l'écrirai jamais assez)
Xavier
PS : non, vous n'avez pas le droit de partir en vacances ! Vous devez rester scotché au forum !!!

[Chabi01]

Est-ce que SpamAssassin intégré à Plesk peut m'aider ? Je l'ai déjà en place mais je ne sais pas si il est très efficace...

[cassiopee]

Ce main.cf est en production pour plusieurs domaines et je n'ai pas de plaintes de faux positifs.

Oui, c'est justement parce que tu utilises "permit_sasl_authenticated," *avant*
le "reject_invalid_helo_hostname" et le "reject_non_fqdn_helo_hostname".

Les gens se servant de ton dédié pour émettre des messages se seront
identifiés via SASL au préalable et donc ensuite, qu'ils aient ou pas
un HELO conforme, ça va passer.

Le seul cas où ça pourra coincer c'est si quelqu'un (pas un utilisateur
d'un des noms de domaine hébergés dans le dédié) émet un message
qui arrive directement sur ton serveur Postfix, sans passer par un serveur SMTP
intermédaire.

Or ce genre de situations, fréquents dans le passé, tend à disparaître de nos
jours (blocage du port 25 par les FAI un peu partout dans le monde notamment).

- - - Mise à jour - - -

oui mais attention si tu tournes sous Plesk, de ne pas casser ton installation.

Oui, il faut y aller prudemment et faire des sauvegardes des fichiers de conf au cas où.

Virtualmin est très souple à ce niveau mais Plesk, je ne sais pas.

[fritz2cat]

oui mais attention si tu tournes sous Plesk, de ne pas casser ton installation.

[cassiopee]

Par contre, ce que j'aimerai avoir, c'est lors de la réception de l'email une règle qui disent "Si le nom de domaine qui envoie ne correspond pas à l'email ou à l'ip du serveur du domaine, alors rejeter".

C'est peut-être ça qu'il te faut :

http://www.robertain.com/post/2012/0...-pour-postfix/

Autrement dit, vérifier le SPF des émetteurs de messages à destination de quelqu'un dans ton serveur
avant d'accepter ou non la réception d'un message.

[fritz2cat]

Avant de regarder to dernier post ci-dessus venant du Mexiaue, voici une partie de mon main.cf

recipient_delimiter = +
#inet_interfaces = all
queue_run_delay = 180
minimal_backoff_time = 180
policy_time_limit = 3600
smtpd_error_sleep_time = 5s
smtpd_soft_error_limit = 1
smtpd_hard_error_limit = 3
message_size_limit = 40960000
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_client_connection_count_limit = 5
smtpd_client_connection_rate_limit = 5
unknown_address_reject_code = 550
unknown_client_reject_code = 550
smtpd_helo_required = yes
strict_rfc821_envelopes = yes
smtpd_client_restrictions =
   cidr:/etc/postfix/client.cidr
smtpd_sender_restrictions =
   check_sender_access hash:/etc/postfix/sender_access,
   reject_non_fqdn_sender,
   reject_unknown_sender_domain
smtpd_recipient_restrictions =
   permit_mynetworks,
   permit_sasl_authenticated,
   check_sender_access hash:/etc/postfix/relay_access,
   check_recipient_access hash:/etc/postfix/white_addresses,
   reject_invalid_helo_hostname,
   reject_non_fqdn_helo_hostname,
   reject_unauth_destination,
   sleep 12,
   reject_unauth_pipelining,
   reject_unlisted_recipient,
   reject_rbl_client cbl.abuseat.org
   reject_rbl_client zen.spamhaus.org
#   reject_unknown_client_hostname
   check_policy_service inet:127.0.0.1:60000
smtpd_data_restrictions = reject_unauth_pipelining
header_checks = pcre:/etc/postfix/header_checks
body_checks = pcre:/etc/postfix/body_checks

Il y a des _checks pour pouvoir faire des traitements à la volée que je n'ai probablement jamais dû utiliser.
Ce main.cf est en production pour plusieurs domaines et je n'ai pas de plaintes de faux positifs.
En outre j'ai spamassassin installé. Mais c'est une autre histoire.
Tu peux t'inspirer de mon fichier en vérifiant une par une à quoi servent chaque ligne.

[Chabi01]

Je viens de trouver un email qui m'est envoyé !
Je masque les éléments volontairement mais si il faut que je les donne, alors dites le moi.
Voilà la source du mail :

Return-Path: 
X-Original-To: contact@mondomaine.com
Delivered-To: contact@mondomaine.com
Received: from mondomaine.com (domaineduserveur.com [Ip de mon serveur ici])
	by nom_de_mon_serveur.com (Postfix) with ESMTPS id 1A52A5A60119
	for ; Mon,  2 May 2016 03:32:16 +0200 (CEST)
Received: by nom_de_mon_serveur.com (Postfix, from userid 30)
	id 301C670C00CE; Mon,  2 May 2016 03:32:18 +0200 (CEST)
X-Original-To: contact@mondomaine.com
Delivered-To: contact@mondomaine.com
Received: from customer-COL-207-1.megared.net.mx (unknown [177.246.207.1])
	by nom_de_mon_serveur.com (Postfix) with ESMTP id BC69070C00CB
	for ; Mon,  2 May 2016 03:32:15 +0200 (CEST)
DomainKey-Signature: a=rsa-sha1;  q=dns; c=nofws;
  s=default; d=mondomaine.com;
  b=eU9V9GnvT3NpoannoDe4pycs3AMHta6l9HiyU2yKMdCdDo2deFrTETfsCTMKvceKkgXJ9DMUOUxMWkOIOz2LzXVQvw70RVxBSGbTeFmN6vaiD/NS1bPXIaTmGeoPvVABWLdbXpUpEtzqETfk+rocNfxOqDldiKykQKfQchpavew=;
  h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:x-cr-hashedpuzzle:x-cr-puzzleid;

Si je regarde, le message est reçu depuis "megarred.net.mx". Ok.
Mais le mail au final m'est envoyé par une adresse no_answer@mondomaine.com
J'ai plein de personnes qui me disent qu'elles reçoivent des emails "envoyés par eux même" (peu importe le serveur).
Dans la règle de messagerie pour les domaines, j'ai "rejeter" si l'email ne correspond à personne. Mais cela ne fonctionne que pour les destinataire, pas les expéditeurs. Je sais également que je ne peux pas empêcher l'envoi en mail forgery depuis un autre serveur d'un email "en mon nom". Par contre, ce que j'aimerai avoir, c'est lors de la réception de l'email une règle qui disent "Si le nom de domaine qui envoie ne correspond pas à l'email ou à l'ip du serveur du domaine, alors rejeter".
C'était le but des règles que j'avais tenté d'insérer dans main.cf, pour tenter de refouler ses emails qui font perdre du temps à tout le monde..

Merci encore

[Chabi01]

Attention, les directives de Postfix ont parfois des noms très proches :

moi je parlais de "smtpd_recipient_restrictions"
et toi de "smtpd_relay_restrictions"

Perso, je ne conseille pas trop de vérifier les HELO

Intelligente remarque (pour les emails en clair dans le post) ! Je viens de le faire : désolé de ne pas y avoir pensé moi même.
Merci

Et pour l'autre, my mistake : j'ai :
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination


- - - Mise à jour - - -

tenir à jour la base des mails c'est super important... Les bounces des mailings doivent revenir aux gestionnaires de ces mailings pour qu'ils puissent faire le tri justement.

Acymailing gère les bounce de lui-même : si le destinataire est "injoignable" pour une raison ou une autre, il est automatiquement désactivé dans la liste des destinataires.
Merci

[sich]

tenir à jour la base des mails c'est super important... Les bounces des mailings doivent revenir aux gestionnaires de ces mailings pour qu'ils puissent faire le tri justement.

[fritz2cat]

Trouvé ! C'est un composant (Acymailing) qui a envoyé une newsletter à différente personnes. Ce n'est donc pas un hack ici mais bel et bien 2 destinataires actifs qui sont dans la base de données des destinataires de la personne qui utilise Acymailing.
Ce n'est donc pas un hack mais bien un envoi ayant été réalisé par une lettre d'info.
(soupir)
Merci
Xavier

Edite ton post qui contient ces deux adresses pour éviter qu'un robot collecteur de pages web ne les enregistre dans des spam list.
Mets par exemple xxx à la place de la 1è partie devant le @

[cassiopee]

Attention, les directives de Postfix ont parfois des noms très proches :

moi je parlais de "smtpd_recipient_restrictions"
et toi de "smtpd_relay_restrictions"

Perso, je ne conseille pas trop de vérifier les HELO

[Chabi01]

Tu a copié des lignes du mail.log avec les lignes to: à 9h00:07
Il serait utile d'avoir les quelques lignes qui précèdent et qui montrent comment ce mail est rentré dans ton postfix (page web piratée, relais via un utilisateur authentifié, etc)

Trouvé ! C'est un composant (Acymailing) qui a envoyé une newsletter à différente personnes. Ce n'est donc pas un hack ici mais bel et bien 2 destinataires actifs qui sont dans la base de données des destinataires de la personne qui utilise Acymailing.
Ce n'est donc pas un hack mais bien un envoi ayant été réalisé par une lettre d'info.
(soupir)
Merci
Xavier

[Chabi01]

Ah ben non, il n'y a pas moyen d'éviter ce genre de retours. Le message de bounce est 100% légitime
(contrairement au message de départ).

Eventuellement rajouter un enregistrement SPF avec un "-all" pourra, peut-être, diminuer un peu
le nombre de retours en bounce mais il n'y a pas tant que ça de serveurs SMTP destinataires
qui vérifient le SPF d'un nom de domaine avant d'accepter un message.
(même si les "gros" (Gmail, Hotrmail, Yahoo, etc.) le font de plus en plus)



Ok.

Est-ce que tu déposes bien tes messages via SASL ?

Normalement dans le sens de l'émission de messages, il doit y avoir une authentification (sinon = open relay)
donc il faut que tu ajoutes cette vérification *avant* de rejeter les messages.

smtpd_recipient_restrictions =

    [...]

    permit_sasl_authenticated,

    [...]

    reject_non_fqdn_helo_hostname,

L'ordre des directives a de l'importance : ici on autorise d'abord les émissions de messages authentifiées
avant de refuser les HELO non conformes. De cette façon, que tes clients de messagerie présentent ou non
un bon HELO, du moment qu'ils sont authentifiés par SASL, leurs messages pourront partir vers Internet.

Perso, je ne vérifies pas trop les HELO (trop de faux positifs, de messages légitimes refusés à cause d'un HELO non conforme).

Dans un contexte où l'on peut mettre au carré tous les HELO (genre messagerie interne en LAN), pourquoi pas
mais autrement, c'est difficile. En général, on peut modifier les HELO de ses propres machines (émettrices)
mais pas les HELO des machines venant déposer des messages dans Postfix à destination de ton nom
de domaine.

Au niveau des restrictions smtpd, j'ai ceci :
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination

Je dois ajouter à la fin reject_non_fqdn_helo_hostname, ?
Merci

[fritz2cat]

Tu a copié des lignes du mail.log avec les lignes to: à 9h00:07
Il serait utile d'avoir les quelques lignes qui précèdent et qui montrent comment ce mail est rentré dans ton postfix (page web piratée, relais via un utilisateur authentifié, etc)

[cassiopee]

J'ai déjà vérifié : cela ne vient pas du serveur mais de l'extérieur. Comme le bounce revient sur le serveur, je me demandais si il y avait un moyen d'éviter cela. Si tu me dis que c'est bénin, alors "ça va"

Ah ben non, il n'y a pas moyen d'éviter ce genre de retours. Le message de bounce est 100% légitime
(contrairement au message de départ).

Eventuellement rajouter un enregistrement SPF avec un "-all" pourra, peut-être, diminuer un peu
le nombre de retours en bounce mais il n'y a pas tant que ça de serveurs SMTP destinataires
qui vérifient le SPF d'un nom de domaine avant d'accepter un message.
(même si les "gros" (Gmail, Hotrmail, Yahoo, etc.) le font de plus en plus)

Le retour était celui-ci :
504 5.5.2 : Helo command rejected: need fully-qualified hostname

où "Pstypampouille" est le nom de la machine Windows utilisée.

Ok.

Est-ce que tu déposes bien tes messages via SASL ?

Normalement dans le sens de l'émission de messages, il doit y avoir une authentification (sinon = open relay)
donc il faut que tu ajoutes cette vérification *avant* de rejeter les messages.

smtpd_recipient_restrictions =

    [...]

    permit_sasl_authenticated,

    [...]

    reject_non_fqdn_helo_hostname,

L'ordre des directives a de l'importance : ici on autorise d'abord les émissions de messages authentifiées
avant de refuser les HELO non conformes. De cette façon, que tes clients de messagerie présentent ou non
un bon HELO, du moment qu'ils sont authentifiés par SASL, leurs messages pourront partir vers Internet.

Perso, je ne vérifies pas trop les HELO (trop de faux positifs, de messages légitimes refusés à cause d'un HELO non conforme).

Dans un contexte où l'on peut mettre au carré tous les HELO (genre messagerie interne en LAN), pourquoi pas
mais autrement, c'est difficile. En général, on peut modifier les HELO de ses propres machines (émettrices)
mais pas les HELO des machines venant déposer des messages dans Postfix à destination de ton nom
de domaine.

[Chabi01]

oui.
Tous les domaines ont : v=spf1 +a +mx -all
+ defaut domainkey pour chaque domaine

[sich]

As tu des enregistrements SPF sur ton domaine ? en -all au passage...

[Chabi01]

Quand je vois ça

Je crie "danger"
Si c'est un mail qui provient d'un de tes utilisateurs et n'est pas un spam, alors c'est OK.
Mais ça m'en a tout l'air que ton serveur émet du spam. Il faut d'urgence voir comment il est rentré dans ton système.

Comment je peux trouver ça ? Comment puis je "tracer" cela ? J'ai un "suspect" qui est un client qui travaille sur mac/iphone (je vois Icloud) : je viens de lui envoyer un email pour lui demander...

[Chabi01]

Oui, c'est dans les entêtes des messages qu'il faut rechercher la source d'émission
du message :

- est-ce que c'est ton serveur ? (auquel cas, il y a un loup à retrouver)
- est-ce un autre serveur ?

Si c'est un autre serveur, alors c'est bénin comme situation.

Dans la messagerie Internet, il n'y a pas d'authentification forte de l'émetteur d'un message.

Donc si quelqu'un en Australie émet un message en utilisant comme adresse email d'émission
"toto@ton_domaine.fr" adressé à "titi@un_domaine_quelconque.com" et que ce message
ne peut être délivré, ton serveur va recevoir le message de bounce.

Dans ce message de bounce, il faudra aller regarder les entêtes, non pas du message de
bounce lui-même mais les entêtes du message d'origine, cité à la fin du message de bounce.

Et c'est là que tu verras si c'est ton serveur ou pas qui est le point de départ du message
d'origine.

J'ai déjà vérifié : cela ne vient pas du serveur mais de l'extérieur. Comme le bounce revient sur le serveur, je me demandais si il y avait un moyen d'éviter cela. Si tu me dis que c'est bénin, alors "ça va"

de quoi parles-tu :

1) de relever sa boîte aux lettres, donc de simplement lire ses messages reçus

2) d'émettre un message à destination d'Internet

?

Quel est texte exact du message d'erreur ?

Le retour était celui-ci :
504 5.5.2 : Helo command rejected: need fully-qualified hostname

où "Pstypampouille" est le nom de la machine Windows utilisée.

Je réponds ensuite au message de Frédéric en dessous.

[fritz2cat]

Quand je vois ça

Code:
1 09:00:07 xlcrea373030 postfix/smtp[15532]: 8DFC370C00AF: to=, relay=mta7.am0.yahoodns.net[63.250.192.46]:25, delay=4.3, delays=0.28/0/1.3/2.8, dsn=2.0.0, status=sent (250 ok dirdel)
Jul 1 09:00:07 xlcrea373030 postfix/qmgr[5849]: 8DFC370C00AF: removed
Jul 1 09:00:08 xlcrea373030 postfix/smtp[15527]: 3BDAB70C00AE: to=, relay=mx3.mail.icloud.com[17.142.163.12]:25, delay=5, delays=0.27/0.01/1.5/3.2, dsn=2.5.0, status=sent (250 2.5.0 Ok.)

Je crie "danger"
Si c'est un mail qui provient d'un de tes utilisateurs et n'est pas un spam, alors c'est OK.
Mais ça m'en a tout l'air que ton serveur émet du spam. Il faut d'urgence voir comment il est rentré dans ton système.

[cassiopee]

Oui, c'est dans les entêtes des messages qu'il faut rechercher la source d'émission
du message :

- est-ce que c'est ton serveur ? (auquel cas, il y a un loup à retrouver)
- est-ce un autre serveur ?

Si c'est un autre serveur, alors c'est bénin comme situation.

Dans la messagerie Internet, il n'y a pas d'authentification forte de l'émetteur d'un message.

Donc si quelqu'un en Australie émet un message en utilisant comme adresse email d'émission
"toto@ton_domaine.fr" adressé à "titi@un_domaine_quelconque.com" et que ce message
ne peut être délivré, ton serveur va recevoir le message de bounce.

Dans ce message de bounce, il faudra aller regarder les entêtes, non pas du message de
bounce lui-même mais les entêtes du message d'origine, cité à la fin du message de bounce.

Et c'est là que tu verras si c'est ton serveur ou pas qui est le point de départ du message
d'origine.

- - - Mise à jour - - -

Lorsque tu dis :

elle a donc une refus lorsqu'elle tente de se connecter à sa messagerie via un client comme Outlook

de quoi parles-tu :

1) de relever sa boîte aux lettres, donc de simplement lire ses messages reçus

2) d'émettre un message à destination d'Internet

?

Quel est texte exact du message d'erreur ?

[buddy]

Pour les spams que tu reçois depuis toi même, regarde les entêtes des mails. Tu verras quel serveur a envoyé le mail.

[Chabi01]

Bonjour tous les 2
Le Postfix est sur un dédié Ovh.
Au niveau des scripts malveillant, j'ai déjà vérifié tous les sites à l'aide de différents outils : rien trouvé au niveau d'un quelconque script injecté dans un fichier.
Ce qui m'arrive en détails :
- Plusieurs spams sont envoyés de "moi" à "moi" (factures, faux scan, etc..)
- J'ai beaucoup de message "undelivered" qui reviennent sur le serveur, ceci étant du j'imagine à de l'usurpation d'identité (si le destinataire du spam n'existe pas, le message semble revenir sur le serveur avec un "undelivered" provenant de "mailer-daemon".

Je ne pense pas que le serveur soit compromis d'une manière ou d'une autre mais comme j'aime comprendre comment améliorer les choses ou garantir la meilleure sécurité en fermant les possibles failles existantes, je me pose la question.

Au niveau des logs dans mail.err, j'ai des lignes qui ressortent fréquemment (je ne mets pas tout), je vous les donne si cela vous parle :

Jun 30 04:07:35 xlcrea373030 postfix-local[1990]: Unable to forward original message. sendmail status: 100
Jun 30 13:22:19 xlcrea373030 plesk_saslauthd[26170]: Invalid mail address 'test@
Jun 30 14:52:17 xlcrea373030 /usr/lib/plesk-9.0/psa-pc-remote[5713]: Error during 'dd51-domainkeys' handler
Jun 30 16:19:04 xlcrea373030 dk_sign[23088]: DK_STAT_SYNTAX: Message is not valid syntax. Signature could not be created/checked
Jun 30 20:27:41 xlcrea373030 plesk_saslauthd[7743]: Invalid mail address 'admin@'
Jul  1 07:32:29 xlcrea373030 postfix-local[9326]: Unable to get sender domain by sender mailname
Jul  1 09:17:39 xlcrea373030 /usr/lib/plesk-9.0/psa-pc-remote[5713]: Message aborted.
Jul  1 09:43:46 xlcrea373030 /usr/lib/plesk-9.0/psa-pc-remote[5713]: Unable to get sender domain by sender mailname
Jul  1 09:43:46 xlcrea373030 /usr/lib/plesk-9.0/psa-pc-remote[5713]: message repeated 2 times: [ Unable to get sender domain by sender mailname]

Au niveau de mail.log, j'ai des log du type :

 1 09:00:07 xlcrea373030 postfix/smtp[15532]: 8DFC370C00AF: to=, relay=mta7.am0.yahoodns.net[63.250.192.46]:25, delay=4.3, delays=0.28/0/1.3/2.8, dsn=2.0.0, status=sent (250 ok dirdel)
Jul  1 09:00:07 xlcrea373030 postfix/qmgr[5849]: 8DFC370C00AF: removed
Jul  1 09:00:08 xlcrea373030 postfix/smtp[15527]: 3BDAB70C00AE: to=, relay=mx3.mail.icloud.com[17.142.163.12]:25, delay=5, delays=0.27/0.01/1.5/3.2, dsn=2.5.0, status=sent (250 2.5.0 Ok.)
Jul  1 09:00:08 xlcrea373030 postfix/qmgr[5849]: 3BDAB70C00AE: removed
Jul  1 09:00:14 xlcrea373030 postfix/smtpd[15391]: connect from mail-oi0-f66.google.com[209.85.218.66]
Jul  1 09:00:15 xlcrea373030 postfix/smtpd[15391]: AB99770C00AE: client=mail-oi0-f66.google.com[209.85.218.66]
Jul  1 09:00:15 xlcrea373030 postfix/cleanup[15394]: AB99770C00AE: message-id=

Jul  1 09:33:15 xlcrea373030 postfix/smtpd[17785]: connect from 14.mo4.mail-out.ovh.net[46.105.40.29]
Jul  1 09:33:16 xlcrea373030 postfix/smtpd[17785]: 0C66B70C00AE: client=14.mo4.mail-out.ovh.net[46.105.40.29]
Jul  1 09:33:16 xlcrea373030 postfix/cleanup[17787]: 0C66B70C00AE: message-id=

Jul  1 09:54:25 xlcrea373030 postfix/master[5834]: warning: master_wakeup_timer_event: service qmgr(public/qmgr): Connection refused
Jul  1 09:54:25 xlcrea373030 postfix/master[5834]: warning: master_wakeup_timer_event: service pickup(public/pickup): Connection refused
Jul  1 09:54:37 xlcrea373030 postfix/smtpd[19720]: warning: hostname ip-11-170.dataclub.biz does not resolve to address 185.29.11.170: Name or service not known

Est-ce que ces lignes sont inquiétantes ou pas ? Y'a t'il un souci ?
Dans le cas présent, je ne sais pas quoi chercher ou vérifier.

Merci à vous
Xavier

[fritz2cat]

Le problème du spam entrant c'est qu'il faut le rejeter en temps réel au niveau de la transaction SMTP.
Le problème du spam sortant (un de tes utilisateurs est un spammeur ou bien a été infecté par un malware spammeur) est qu'il faut aspirer silencieusement ces spams et bloquer l'accès au service de mail sortant.
Envisage de découpler les deux problèmes. Pour le premier postfix a plein de règles déjà pas mal pour éliminer 80% du spam, sans procéder à une analyse du contenu des messages.
En plus postfix est fantastique pour laisser sur la carpette les abuseurs qui font trop de connexions, violent les protocoles, tentent du bruteforce.

Ton postfix sera-t-il un serveur de sortie, d'entrée, les deux ?

[cassiopee]

Première question : où est installé ce serveur Postfix ?

Dans un serveur dédié sur Internet ou dans un serveur présent dans ton réseau local ?

[Chabi01]

Bonjour à tous,
Sur Postfix, j'ai fait une modif de mon main.cf.
J'ai ajouté les choses suivantes :

# HELO restrictions:
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, permit

# Sender restrictions:
smtpd_sender_restrictions = permit_mynetworks, reject_non_fqdn_sender, reject_unknown_sender_domain, permit

Cela fonctionne à 99%.
Pourquoi 99% ?
Sur la majorité des postes clients, j'ai les postes qui sont soit en "Workgroup", soit en "domaine" identique au domaine existant sur le serveur.
Pour un poste, j'ai la personne qui est en "local.domainexxx.com"
En sachant que le domaine "domainexxx.com" existe sur le serveur mais que la personne a ce poste qui est connecté à ce "domaine" (reste d'un ancien réseau interne), elle a donc une refus lorsqu'elle tente de se connecter à sa messagerie via un client comme Outlook.

Ma question est alors : est-ce lié à son poste ? Est-ce une erreur dans ma config de postfix ?

Pourquoi cette question ?
Avec les spams qui sont émis de n'importe où, j'ai de plus en plus de message "undelivered message" qui reviennent et qui sont renvoyés sur le domaine alors que ce n'est pas le serveur qui les a envoyé. Je voudrais être sur qu'aucun mail non légitime ne parte du serveur afin d'écarter la possibilité d'un spam potentiel depuis le serveur (j'ai scanné à plusieurs reprises le serveur pour être sur, je n'ai pas de script planqué sur un site, je ne suis pas en open relay).

Merci de votre aide
Xavier