Re: [FRnOG] [MISC] Mails bloqués par Free.fr depuis Tenant Office365 Microsoft.

[Francois Petillon]

On 3/20/24 17:38, frnog via frnog wrote:
Depuis plus d'une semaine, quasi plus aucun de nos mail n'arrivent chez free.fr 
depuis notre tenant Microsoft Office 365 (Au moins un centaine de mails 
quotidiens).


Les IP de M$ sont refusées : LED=451 too many errors detected from your IP, 
depuis les IP M$ 40.107.XXX.XXX entre autre.


Voici une des réponses que j'ai fait hier sur ce type d'incident :

------

D'après nos logs, voici les statistiques des sessions SMTP établies depuis l'IP 
40.107.105.132 :


Mar  5 :  2210 SMTP sessions,  2022 RCPT TO,   142 do not exist ( 7.02%)
Mar  6 : 28482 SMTP sessions, 26408 RCPT TO,  1488 do not exist ( 5.63%)
Mar  7 :   119 SMTP sessions,   112 RCPT TO,13 do not exist (11.61%)
Mar  8 :   282 SMTP sessions,   264 RCPT TO,20 do not exist ( 7.58%)
Mar  9 :96 SMTP sessions,90 RCPT TO, 2 do not exist ( 2.22%)
Mar 10 :94 SMTP sessions,85 RCPT TO, 4 do not exist ( 4.71%)
Mar 11 :91 SMTP sessions,88 RCPT TO, 7 do not exist ( 7.95%)
Mar 12 :   294 SMTP sessions,   276 RCPT TO,15 do not exist ( 5.43%)
Mar 13 :   267 SMTP sessions,   244 RCPT TO,22 do not exist ( 9.02%)
Mar 14 :   108 SMTP sessions,98 RCPT TO, 7 do not exist ( 7.14%)
Mar 15 :  2639 SMTP sessions,  2486 RCPT TO,  1363 do not exist (54.83%)
Mar 16 : 27246 SMTP sessions, 24791 RCPT TO,  3787 do not exist (15.28%)
Mar 17 : 22251 SMTP sessions, 20483 RCPT TO,  4475 do not exist (21.85%)
Mar 18 : 15059 SMTP sessions, 14164 RCPT TO,  4005 do not exist (28.28%)
Mar 19 : 19830 SMTP sessions, 18884 RCPT TO, 11721 do not exist (62.07%)

et celles du trafic mail (hors période de blacklistage) :

Mar  5 : 151 mails,  50 accepted spams ( 33.1%), 0 rejected spams (  0.0%), 
14.4% of unknown recipient
Mar  6 : 149 mails, 132 accepted spams ( 88.6%), 3 rejected spams (  2.0%), 3.8% 
of unknown recipient
Mar  7 :  99 mails,  87 accepted spams ( 87.9%), 1 rejected spams (  1.0%), 
11.6% of unknown recipient
Mar  8 : 243 mails, 173 accepted spams ( 71.2%), 5 rejected spams (  2.1%), 7.6% 
of unknown recipient
Mar  9 :  88 mails,  67 accepted spams ( 76.1%), 1 rejected spams (  1.1%), 2.2% 
of unknown recipient
Mar 10 :  81 mails,  68 accepted spams ( 84.0%), 1 rejected spams (  1.2%), 4.7% 
of unknown recipient
Mar 11 :  81 mails,  49 accepted spams ( 60.5%), 0 rejected spams (  0.0%), 8.0% 
of unknown recipient
Mar 12 : 260 mails, 191 accepted spams ( 73.5%), 1 rejected spams (  0.4%), 5.4% 
of unknown recipient
Mar 13 : 220 mails, 163 accepted spams ( 74.1%), 3 rejected spams (  1.4%), 9.0% 
of unknown recipient
Mar 14 :  90 mails,  59 accepted spams ( 65.6%), 0 rejected spams (  0.0%), 7.1% 
of unknown recipient
Mar 15 :  10 mails,   9 accepted spams ( 90.0%), 0 rejected spams (  0.0%), 
74.4% of unknown recipient
Mar 16 :  48 mails,  43 accepted spams ( 89.6%), 0 rejected spams (  0.0%), 2.0% 
of unknown recipient
Mar 17 :   0 mails,   0 accepted spams (  0.0%), 0 rejected spams (  0.0%), 0.0% 
of unknown recipient
Mar 18 :   0 mails,   0 accepted spams (  0.0%), 0 rejected spams (  0.0%), 0.0% 
of unknown recipient
Mar 19 :   0 mails,   0 accepted spams (  0.0%), 0 rejected spams (  0.0%), 0.0% 
of unknown recipient


Cette IP a été bloquée à plusieurs reprises aussi bien en raison du ratio de 
mails expédiés à destination de comptes inexistants (le taux "normalement" 
constaté est inférieur à 1%) qu'en raison du ratio de mails détectés comme étant 
des spams.


Voici la liste des principaux domaines expéditeurs de mails à destination de 
comptes inexistants :


 1: 24603 / 101965 (24.13%) : t1.moe.edu.eg
 2: 834 / 4548 (18.34%) : viss.ae
 3: 504 / 964 (52.28%) : t2.moe.edu.eg
 4: 229 / 766 (29.90%) : mkm-haifa.co.il
 5: 116 / 682 (17.01%) : infos-eco-system.com
 6: 82 / 141 (58.16%) : cba.edu.kw
 7: 26 / 60 (43.33%) : ogr.deu.edu.tr
 8: 26 / 105 (24.76%) : viss.onmicrosoft.com
 9: 25 / 78 (32.05%) : agrup-alcains-svb.com
10: 23 / 109 (21.10%) : alunos.ipb.pt
11: 22 / 79 (27.85%) : um5.ac.ma
12: 20 / 176 (11.36%) : stuabroad.moe.edu.eg
13: 18 / 91 (19.78%) : arts.s-mu.edu.eg
14: 18 / 130 (13.85%) : student.ksu.edu.sa
15: 18 / 88 (20.45%) : ogr.alanya.edu.tr
16: 17 / 23 (73.91%) : leerling.wico.be
17: 16 / 69 (23.19%) : uzem.education
18: 16 / 23 (69.57%) : emadu.ueuromed.org
19: 16 / 99 (16.16%) : esjp.pt
20: 15 / 78 (19.23%) : ujk.edu.pl

Et les principaux domaines expéditeurs de mails détectés comme étant des spams :

 1: 604 / 604 (100.00%) : t1.moe.edu.eg (rcpto failure : 24.13%)
 2: 339 / 339 (100.00%) : viss.ae (rcpto failure : 18.34%)
 3: 17 / 17 (100.00%) : ogr.akdeniz.edu.tr (rcpto failure : 11.96%)
 4: 13 / 13 (100.00%) : mkm-haifa.co.il (rcpto failure : 29.90%)
 5: 11 / 11 (100.00%) : eng.asu.edu.eg (rcpto failure :  8.03%)
 6: 10 / 10 (100.00%) : student.ksu.edu.sa (rcpto failure : 13.85%)
 7: 10 / 10 (100.00%) : nku.edu.tr (rcpto failure : 15.09%)
 8: 10 / 10 (100.00%) : hayatboyu.education (rcpto failure :  2.50%)
 9: 8 / 8 (100.00%) : 

Re: [FRnOG] Re: [MISC] dgfip refusé par gmail

[Francois Petillon]

On 3/1/24 09:35, Stephane Bortzmeyer wrote:

Encore faut-il que les ips sortantes soient celles des « MX » ( au sens
enregistrement DNS ).

Il n'y a pas que "mx". Si le serveur sortant est smtp.dom.example,
mettre un "a:smtp.dom.example" est nettement préférable à lister les
adresses IP (cf. le problème de DGFIP, justement).


$ host smtp.free.fr
smtp.free.fr has address 212.27.48.4
smtp.free.fr has IPv6 address 2a01:e0c:1::25
$ host -t TXT _spf.free.fr
_spf.free.fr descriptive text "v=spf1 ip4:212.27.42.1 ip6:2a01:e0c:1:1599::10 
ip4:212.27.42.2 ip6:2a01:e0c:1:1599::11 ip4:212.27.42.3 ip6:2a01:e0c:1:1599::12 
ip4:212.27.42.4 ip6:2a01:e0c:1:1599::13 ip4:212.27.42.5 ip6:2a01:e0c:1:1599::14 
ip4:212.27.42.6 ip6:2a01:e0c:1:1599::15 ip4:212.27.42.9 ip6:2a01:e0c:1:1599::18 
ip4:212.27.42.10 ip6:2a01:e0c:1:1599::19 -all"


J'imagine que la DGFIP doit avoir une configuration encore plus alambiquée qu'un 
simple FAI.


François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] problème de distribution de mail entre microsoft et free pour un jeton d'authentification

[Francois Petillon]

On 1/31/24 14:27, Erwan David wrote:

De ce que j'ai vu sur les newsgroups free un autre mécanisme arrive :
2) C'ets excessivement facile de se faire un compte de spam sur outlook.com


J'ai l'impression que cette partie là s'est calmée. C'était encore le cas il y a 
un an mais je vois moins qu'avant des domaines bidons créés pour spammer depuis 
Office365. Le gros du volume aujourd'hui semble sortir de domaines légitimes 
mais qui se retrouvent à héberger des comptes compromis.


3) les serveurs de sortie de MS se retrouvent donc flaggués en basse confiance 
rien que sur le taux de fausses adresses de destinataire (les spammeurs ne 
nettoient pas leurs listes)


Pour être un peu plus précis, ce que je vois arriver est essentiellement du 
phishing bancaire et des arnaques en tout genre (fausse convocations 
judiciaires, relance d'amendes ou de loyers impayés, fausse vignette crit'air, 
etc.).


Et sur ce type d'envois, les spammeurs semblent s'appuyer sur des listes de 
comptes compromis dans lesquels il y a beaucoup d'adresses supprimées ou bloquées.


Ponctuellement, je tente d'évaluer les taux de spams sur quelques IPs 
d'Office365 et les dernières évaluations étaient dans la fourchette de 80 à 95% 
de mails envoyés par des domaines aux comportements anormaux.


François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] problème de distribution de mail entre microsoft et free pour un jeton d'authentification

[Francois Petillon]

On 1/31/24 08:39, Mickaël Dequidt wrote:
c'est à vérifier, mais cela me fait penser à un écueil de certaines 
implémentations du greylisting face à des domaines hébergés chez microsoft 
(entre autres).


Il n'y a pas de greylisting chez Free. Par contre, il y a un très gros problème 
de comptes compromis sur les domaines hénergés chez Office365 et ce problème a 
tendance à devenir particulièrement visible sur la période qui précède et qui 
suit Noël.


François




---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [tech][DNS][FREE] : mails bloqués vers les serveurs ouvaton

[Francois Petillon]

On 1/2/23 18:51, Stephane Bortzmeyer wrote:

On Mon, Jan 02, 2023 at 06:09:02PM +0100,
  Stephane Bortzmeyer  wrote
  a message of 15 lines which said:


Ticket [trs #497813] chez le .coop (je les ai prévenus). Ils sont en
tort mais le résultat dépend du niveau de libéralisme du résolveur.

Plus précisement, le serveur faisant autorité a tort (RFC 4035,
section 2.2) mais les résolveurs qui refusent de résoudre .coop ont
tort aussi (RFC 6480, section 5.11, merci à Shaft pour la référence).


Histoire de finir le thread, le TLD .coop semble avoir corrigé le problème la 
nuit dernière et nos DNS récursifs ont été mis à jour...


François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [tech][DNS][FREE] : mails bloqués vers les serveurs ouvaton

[Francois Petillon]

On 1/2/23 14:41, Stephane Bortzmeyer wrote:

Mais il est plus probable que ce soit dû à la déconnance DNSSEC de
.coop (gros bordel entre les DS et DNSKEY et les signatures).
https://dnsviz.net/d/coop/Y7LdQg/dnssec/


À mon niveau, j'ai effectué différent tests pour essayer d'identifier la cause 
du problème.


J'ai bien les résolutions DNS dans le cache d'unbound mais une requête sur les 
MX d'ouvaton renvoie un SERVFAIL (donc ce n'est pas un problème réseau).


Désactiver DNSSEC permet d'obtenir une réponse du serveur et le soucis se 
situerait bien à ce niveau. Utiliser un daemon unbound plus récent permet aussi 
d'obtenir une réponse.


Je n'ai pas la moindre idée de l'élément responsable du problème mais on va 
probablement planifier une mise à jour des serveurs DNS récursifs...


François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Contact postmas...@proxad.net

[Francois Petillon]

On 6/3/22 5:34 PM, yoshi wrote:
> J’essaie depuis mi mai d'entrer en contact avec postmas...@proxad.net sans
> succès malgré plusieurs relances de ma part.

La seule référence à un "yoshi" que je trouve dans la boite postmaster semblait
vouloir me vendre du v1agr4. J'imagine que ce n'est pas à ça que vous faites
référence.

La probabilité d'avoir une réponse sur postmaster est assez variable et très
dépendante de mon activité du moment (voir de ma totale inactivité) et
possiblement de la complexité du problème.

Et vu les problèmes générés par Office365 et Gmail, j'ai malheureusement un
volume de requêtes qui dépasse ma capacité de réponse (sans compter que les
réponses nécessitent généralement d'être étayées).

> J'ai ouïe dire qu'une personne derrière cette adresse était présente sur la
> liste. Si elle pouvait entrer en contact avec moi hors liste, ça serait 
> parfait.

Donner suite à votre requête reviendrait à inciter tout mécontent à cette ML
pour obtenir des passe-droits. Cela me semble contre-productif.

François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Règles antispam chez free.fr ?

[Francois Petillon]

On 11/17/21 6:57 PM, Grégoire G wrote:
>> Si vous tentez d'envoyer des mails depuis une IP partagée, il est 
>> effectivement
>> probable que vous tapiez assez rapidement dans les limites de volumétrie 
>> autorisées.
> envoyer 4 ou 5 emails d'un coup suffisait à l'époque quand j'utilisais les 
> services mails SMTP de free.

Cela ne correspond à aucune des rêgles qui ont pu êtres mises en place sur les
serveurs SMTP sur les ~21 dernières années.

> Sinon, plusieurs connexion IMAPs "trop" proches suffisent aussi pour être 
> bloqué.

Des connexions IMAPs qui aboutissaient au blocage des accès aux serveurs SMTP ou
aux serveurs IMAP ?

Là, vu ce que vous me décrivez, j'aurais tendance à soupçonner une application
mail brouillone qui tente encore et toujours d'envoyer un mail (qu'il soit
rejeté par les serveurs ou introuvable par l'application) ce qui pourrait
aboutir effectivement au blocage des accès aux serveurs SMTP.

François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Règles antispam chez free.fr ?

[Francois Petillon]

On 11/17/21 11:20 AM, Philippe M wrote:
> Je remarque que l'antispam chez Free me semble de plus en plus capricieux.

Sauf que ce n'est pas vraiment de l'antispam.

> J'ai régulièrement des erreurs de type" 4.7.0 smtp6-g21.free.fr Error: too
> many connections from xxx"

Je serais curieux de savoir ce que vous avez fait pour obtenir cette erreur.

Il s'agit ici des serveurs SMTP et non des MX. Il serait donc plutôt question
d'envoi de mails et non de reception. Vu le message de rejet, il s'agit
probablement un problème de connexions simultannées ou d'overquota.

> au bout de seulement quelques mails envoyés en bloc, et cela ne serésoud
> qu'au bout de quelques jours.
> Je constate cela depuis Gmail ou autres serveurs de mail internes.

Si vous tentez d'envoyer des mails depuis une IP partagée, il est effectivement
probable que vous tapiez assez rapidement dans les limites de volumétrie 
autorisées.

François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] [SMTP] outlook.com bloque online.net ?

[Francois Petillon]

On 8/24/21 10:25 AM, Pierre Colombier via frnog wrote:
> Oui mais dire que le mail a été délivré alors qu'en fait non, me semble
> nettement plus grave.
> D'ailleurs, Outlook le fait aussi (code 250 dans mes logs mais jamais reçu par
> le destinataire)

Attention, le mail a peut-être réellement été délivré mais viré après coup. J'ai
cru lire il n'y a pas longtemps qu'ils avaient activé une seconde passe de
filtrage antispam après délivrance. Ils ne sont pas les seuls à faire ça.

> Et je conseille à qui veut l'entendre de faire appel à n'importe quel
> fournisseur de mail plus sérieux, ou à défaut de vendre son âme à gmail qui 
> est
> sans doute le diable mais qui, au moins, remplis correctement sa part du 
> contrat.

À mon niveau, on a des problèmes sur des campagnes de spams/phishing provenant
d'Office365 & de Gmail. J'observe plus de réactions coté Office365 que coté 
Gmail.

François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] [SMTP] Free :: des mails qui n'arrivent pas.

[Francois Petillon]

On 4/28/20 4:26 PM, Jacques Lavignotte wrote:
> Le Mardi, Avril 28, 2020 13:39 CEST, Romain  a écrit:
>> Effectivement depuis une adresse free aucun retour.
> C'est donc confirmé : Free vient d'inventer le trou noir SMTP.
> Bon, je ne jure pas que le loup puisse être dans ma bergerie.

Grmpf...

root@smtp1-g21:~# telnet 213.215.35.70 25
Trying 213.215.35.70...
telnet: Unable to connect to remote host: Connection timed out
root@smtp1-g21:~# telnet 213.215.35.70 80
Trying 213.215.35.70...
Connected to 213.215.35.70.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.1 302 Found
Date: Tue, 28 Apr 2020 14:36:13 GMT
Server: Apache/2.4.38 (Debian) OpenSSL/1.1.1d
Location: https://melusine.eu.org/
[...]

François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Profitons bien de l'épidémie pour violer un peu la neutralité

[Francois Petillon]

On 3/16/20 10:10 AM, David Ponzone wrote:
> Des sources de quoi ?
> Ben EcoleDirecte de mon fils: inutilisable à l’heure actuelle.

Je confirme. Ce matin, il n'était plus possible de s'authentifier. Là, ça semble
marcher mais encore plus lentement que d'habitude.

François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Incident Free depuis 1h du matin

[Francois Petillon]

On 11/28/19 5:04 PM, Radu-Adrian Feurdean wrote:
> Ca reste l'equivalent d'un /8 par OUI.
> Et de nos jours pas mal de fabricants ont plusieurs (parfois dizaines) d'OUI.
> Et c'est valable que pour les hotes qui n'utilisent aucune extension (ni 
> privacy, ni CGA)
> Tout ca, pour trouver ce qu'il y a chez un seul client.
> Je te laisse le loisir de re-faire ca plusieurs (??? dizaines de ??? 
> centaines de ???) milliers de fois pour commencer a monter  un botnet.

Je n'aurais jamais cru que des pirates allaient faire de l'attaque
dictionnaire(*) sur des comptes et, pourtant, c'est bel et bien ce qui
semble se passer.

(*) mots de passe simples et ré-utilisation de mots de passe compromis
légèrement modifiés

Aujourd'hui, les attaquants se montent des plateformes massivement
réparties et fortement asynchrones. Ils ne supportent pas le coût des
attaques et quand bien même il faut du temps pour récupérer des comptes,
la volumétrie des attaques font qu'ils en récupèrent suffisamment pour
leur activité.

En tant que particulier, j'aurai tendance à avoir le même point de vue
que toi (peu probable et pas rentable). En tant qu'employé FAI, je sais
que je vais avoir des centaines de milliers d'utilisateurs qui vont se
faire trouer le cul.

>> Si l'attaquant a accès aux logs de serveurs (site web par exemple), la
> Sauf pour les privacy extensions (adresses temporaires).

Non, (1) tu pars sur une situation idéale et (2) l'attaque peut être
immédiate.

Pour le (1), je vois comment c'est le bordel quand la chaîne hifi ou
l'imprimante changent d'IP ; le programmateur pour l'arrosage ne
supporte même pas de changer de canal wifi (*sic*), etc...

Les utilisateurs ont des objets connectés sur lesquels l'interface de
gestion peut être minimaliste et dont la durée du support est inférieur
à l'espérance de vie. Leur utilisabilité peut être contraire à certains
principes de sécurité et, ici, ce n'est pas la sécurité qui gagnera.

> A force d'avoir abuse du firewall (NAT ou pas) comme la solution a tous les 
> maux (reels mais surtout immaginaires), les black-hats ont commence a 
> apprendre a passer au travers. Aujourd'hui, le "deny all incoming 
> connections" est nettemant moins efficace qu'avant.
> Certes, quand quelqu'un sur un acces fixe/statique est vise explicitement, la 
> situation change un peu. Mais le "au secours, MAINTENANT je suis tout nu sur 
> Internet", ca tien pas. Surtout que tu peux mettre ton "plus ou moins 
> firewall" derriere la box. Y compris pour du v6 

Chez des utilisateurs lambda ? Non, je n'y crois pas. Tout est branché
au cul de la box avec la configuration par défaut.

François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Incident Free depuis 1h du matin

[Francois Petillon]

On 11/28/19 11:38 AM, Radu-Adrian Feurdean wrote:
> On Thu, Nov 28, 2019, at 09:38, Oliver varenne wrote:
>> (combien de machines vont se retrouver "toutes nues" sur internet ?)
> Est-ce que t'as jamais essaye de trouver les machines actives dans un subnet 
> client ? Le premier /64 suffit.
> On est en IPv6 la, chaque subnet ca donne 18446744073709551616 adresses. 
> Chaque client peut avoir plusieurs subnets.

Si on cherche toutes les machines d'un subnet, oui.

Si l'attaquant vise un type de périphérique bien précis, il peut se
contenter de scanner les IPs correspondantes aux blocs d'adresses MAC du
fabricant.

Si l'attaquant a accès aux logs de serveurs (site web par exemple), la
question ne se pose même plus. Je peux aussi renvoyer à la faille d'iLnkP2P.

François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Besoin d'avis pour mon avenir professionnel

[Francois Petillon]

On 11/18/19 2:42 PM, Grégory Poudrel wrote:
> Tant que tu es dans les études, va le plus loin que tu peux bac+2,+3 voire
> +5, si possible en alternance.
> En informatique les études ne servent à avoir qu'un papier, quelques bases.
> Le reste c'est expérimenter et mettre les mains dedans mode passionné comme
> tu le fais.

J'ai un peu de mal avec ce qui peut être dit dans ces échanges et je
serais curieux de connaître les formations suivis par les uns et les autres.

Contrairement à de nombreux avis, j'ai plutôt une bonne opinion de la
formation que j'ai suivi (à l'époque, un DEUG de sciences, une licence &
une maîtrise en informatique & un DEA en
micro-électronique/micro-informatique) et je pense sincèrement y avoir
acquis un certain nombre de briques théoriques qui me servent
quotidiennement dans ma vie professionnelle.

Oui, je bidouillais bien avant ma formation, j'ai bidouillé pendant et
après. Mais il s'agit, de mon point de vue, de deux aspects
complémentaires du boulot d'informaticien.

Bref, j'aurais moi aussi tendance à conseiller de continuer les études
autant que ce que peut mais pas que pour le diplôme. Les connaissances
qu'on peut y acquérir sont toujours bonnes à prendre.

François





---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Solution/Software pour corrélation d'IPs unitaires avec une liste de subnets

[Francois Petillon]

On 2/4/19 3:01 PM, David Ponzone wrote:
> Python est ton ami:
> https://docs.python.org/3/library/ipaddress.html 
> 

Et, pour PERL, il y a le module Net::IP::Match::Regexp

François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Incident de sécurité et contact Orange

[Francois Petillon]

On 12/22/2017 11:08 AM, Alain BERNARD wrote:
> Notre structure subit une vague de pourriels à destination d'une seule
> adresse. L'attaque transite majoritairement par les infra de messagerie
> de l'opérateur Orange.

Je ne sais pas s'il s'agit du même incident mais je suis touché par un
soucis similaire (jusqu'à ~3 mails/minute, les retours de WE sont
difficiles) depuis la mi-octobre.

> Plusieurs comptes orange ont été usurpés par l'attaquant.

Je pense qu'il s'agit de comptes compromis (d'où la difficulté d'Orange
de bloquer définitivement le problème). J'ai également trouvé quelques
tentatives du même spammeur sur nos serveurs.

> J'ai signalé l'incident sur l'adresse ab...@orange.fr sans réponse pour
> le moment.

J'ai retransmis à la bonne personne.

François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Mystere antispam Orange

[Francois Petillon]

On 09/29/2017 11:46 AM, François Otho wrote:
> Voici tout de même un extrait des Headers d'un message reçu : 
> X-me-spamcause : 
> (200)(1000)gggruggvucftvghtrhhoucdtuddrfeelledrjeekgddujecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfogfdpggftiffpkfenuceurghilhh
>  
> ouhhtmecugedttdenucgorfhhihhshhhinhhgqdetfeekuddqudduucdlvddttddmnecujfgurhepvffuhfffrhgjkfggtgesmhdtjhfotddtjeenucfhrhhomhepfdfor
>  
> ghrihgvucfjfgftgfdfuceomhhhuhhrvgestghkrhhlrgifrdgtohhmqeenucfkphephedrudeliedrledrudejpddugeelrddvtddvrddvudeirdduleenucfrrghrrgh
>  
> mpehhvghlohepmhigrggurghpphhsuddrrggufihinhhfrhgrnhgtvgdrtghomhdpihhnvghtpeehrdduleeirdelrddujedpmhgrihhlfhhrohhmpehmhhhurhgvrdgsv
>  
> ggrrghvohgtrghtsh--ssehorhgrnhhgvgdrfhhr
>  

Ton mail match une rêgle antiphishing, il faut remonter le mail à
VadeSecure via (de mon point de vue) Orange (il n'est pas dit que la
règle se déclenche chez d'autres fournisseurs si la règle s'attaquait à
un phishing ciblant Orange).

> Ce qui m'énerve dans l'histoire c'est le 'field' X-me-spamcause... cause 
> qu'il ne me cause pas trop ^^ 

C'est un log/debug de VadeSecure sur l'analyse des filtres antispams.

François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Mystere antispam Orange

[Francois Petillon]

On 09/28/2017 06:14 PM, François Otho wrote:
> Merci d'avance à ceux qui pourraient reproduire ce défaut et éventuellement 
> de me dire comment je pourrais contacter le sav orange , mais disons au moins 
> le niveau 2 ^^. 

C'est, à ma connaissance, le service abuse qui gère tout ce qui concerne
la messagerie.

François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: RE : [FRnOG] [TECH] Free Spam Detected

[Francois Petillon]

On 12/18/2016 11:50 AM, Stéphane Gilliers wrote:
> J’ai effectivement oublié de mentionner ceci dans mon email d’origine.

> J’avais suivi (et le client aussi de son côté) la procédure donnée dans
> postmaster.free.fr
> Le dernier email envoyé (de ma boîte) à 'postmas...@proxad.net' était
> vendredi 16 décembre à 18h22 (avec une copie de mail en PJ, et des
> copies d’entêtes).

Le seul mail que je trouve dans la boite "nospam" depuis le domaine de
votre client date de vendredi 18h16.

Je ne trouve aucun mail expédié depuis le domaine de votre client dans
la boite postmaster.

Le seul mail que j'ai de votre domaine dans la boite postmaster est de
votre part et date de vendredi 18h22.

Et c'est après une longue attente interminable de 11 minutes que vous
avez jugé nécessaire de lancer un appel à l'aide sur FrnOG...

> Je vais le transférer sur la boîte ab...@proxad.net que tu mentionnes.

Non, le service abuse est relatif aux comportements inapproprié des
utilisateurs, pas de la gestion des serveurs de messagerie.

François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Free Spam Detected

[Francois Petillon]

On 12/16/2016 06:33 PM, Stéphane Gilliers wrote:
> Si par hasard un admin de free lit cette liste est-ce qu'il peut me contacter.
> Depuis plusieurs mois nous avons des erreurs « spam detected » qui empêche 
> tout envoi d'emails (ce n'est même pas un blacklistage d'IP).

Il y a une procédure en place pour signaler les faux-positifs :

http://postmaster.free.fr/#faux_positifs

François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage mail free

[Francois Petillon]

On 06/07/2016 09:34 PM, DiDi Abaric wrote:

Comme le dit Adrien il doit y avoir un drop sur le corps du message, le
test que vous faite va dans ce sens.


Un drop silencieux ressemble plutôt à un filtre utilisateur.


Est t'il possible que free, via vaderetro ou d'autres mécanismes, filtre
automatiquement plus agressivement les mails a destination d'utilisateurs
qui  reçoivent plus de spams que d'autres ?


À partir du moment où les filtres antispams analysent le contenu du 
mail, le contenu du champs To/CC peut avoir une incidence. Par contre, 
il ne me semblerait pas judicieux de renforcer l'antispam pour les 
comptes "spammés" (on aurait juste l'impression que ces comptes seraient 
d'autant plus spammés et on ne sortirait plus de cet état).


François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Besoin de vos feedback pour très gros projet

[Francois Petillon]

On 12/15/2015 03:24 PM, Bruno Pagani wrote:
> C’est très fort ça, puisque si on voulait donner un sens au verbe
> crypter dans ce contexte¹ en faisant un parallèle avec décrypter, il
> signifierait quelque chose du style : « Chiffrer sans la clé de
> chiffrement. ». Et puis à quoi ça servirait…

J'ai déjà vu ce verbe être utilisé pour décrire une opération de
chiffrement a priori non réversible (par exemple une signature).

François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Solution de redirection mail

[Francois Petillon]

On 07/08/2015 11:20 AM, Dorian BECKER wrote:
 Le 7 juillet 2015 18:57, Francois Petillon fan...@proxad.net a écrit :
 Après, il y a d'autres écueils que je n'ai jamais vu être traités.
 Est-ce que le destinataire peut confirmer la redirection ? Peut-il la
 supprimer a posteriori sans avoir accès à l'interface de configuration ?
 En cas de boites mails supprimées, la redirection disparait-elle ou le
 futur nouvel utilisateur de la boite mail aura-t-il le droit d'hériter
 des mails redirigés ?
 Nous avons une interface de gestion des redirections où nos utilisateurs
 peuvent ajouter / supprimer des adresses de redirection (sortie), les
 adresses sources ( donc avec nos domaines) étant imposées. Les adresses que
 nous proposons ne sont jamais réattribuées. Et en cas de problème tout est
 modifiable de notre coté après une demande au support.

Vous avez une approche qui est centrée sur le demandeur mais que
proposez-vous comme outils au destinataire ?

Pour reprendre de manière plus explicite ce que j'ai dit, quand un de
vos utilisateurs demande à ce que sa boite soit redirigée sur
toto@nomail.invalid, comment savez-vous que toto@nomail.invalid souhaite
bien recevoir cette redirection ? Je pense notamment aux typos voir aux
inscriptions abusives.

Si, par la suite, cet utilisateur supprime sa boite mail
toto@nomail.invalid, que se passe-t-il à votre niveau ? Vous continuez à
envoyer des mails vers une boite mail inexistante ? Après quelques mois,
un tiers recrée cette boite mail toto@nomail.invalid, va-t-il recevoir
les mails de la redirection de l'utilisateur précédent ? Aura-t-il accès
à une information lui permettant de supprimer cette redirection ?

François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Solution de redirection mail

[Francois Petillon]

On 07/07/2015 06:19 PM, Fabrice Vincent wrote:
 Peu importe que ça soit toi qui le fasse ou quelqu'un d'autre, le
 forward vers des domaines tiers n'est plus le bienvenu depuis au moins
 5/6 ans.
 Même avec SRS (http://www.openspf.org/SRS) ???

Le forwarding pose un certain nombre de problème.

Avec SRS par exemple, c'est le serveur intermédiaire qui va se retrouver
à générer des bounces ou à retransmettre des bounces vers le domaine
expéditeur supposé.

Après, il y a d'autres écueils que je n'ai jamais vu être traités.
Est-ce que le destinataire peut confirmer la redirection ? Peut-il la
supprimer a posteriori sans avoir accès à l'interface de configuration ?
En cas de boites mails supprimées, la redirection disparait-elle ou le
futur nouvel utilisateur de la boite mail aura-t-il le droit d'hériter
des mails redirigés ?

François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] SMTP orange : mails rejetés.

[Francois Petillon]

On 03/31/2015 12:31 PM, OCEANET - Cédric BASSAGET wrote:
 il ne s'agit pas de la fameuse erreur too many connections, slow down.

Il ne s'agirait pas de votre quincaillier ? Auquel cas, le problème
pourrait être lié avec le taux de spams détectés.

François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [BIZ] Appel d'offre Relay SMTP sortant

[Francois Petillon]

On 06/03/2014 11:28 AM, Benjamin BILLON wrote:
 Rien ne garantit de ne pas se faire blacklister ; par contre tu diminues
 grandement les risques si tu n'envoies que des mails désirés et attendus
 par les destinataires =)

Je ne sais pas ce qu'il sous-entend par la garantie de non-blacklistage.
Cela va de l'IP dédié (ie on est seul responsable de ce qui sort de l'IP
et donc seul fautif en cas de blacklistage) à la mise en place de
mesures de contournement dans le cas où les IPs utilisées seraient
blacklistées.

François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] de nombreux bounce depuis les mx de free

[Francois Petillon]

On 11/20/2013 01:04 PM, Alexandre wrote:

On m'a fait la remarque en privé, J'aurais donc 181 clients avec une
boite pleine ? ca me semble étrange, non ?


Pas plus que le postmaster qui, en matant la liste que tu lui a envoyé, 
retrouve des adresses qui ont été supprimées il y a plusieurs années, 
d'autres qui n'ont jamais existées, des boites qui ne sont plus 
utilisées depuis plusieurs années et des boites overquotas qui ne sont 
plus consultées depuis plusieurs semaines/mois.


Ce serait bien de gérer proprement la base de mailing. Genre 
double-optin à l'inscription, suppression rapide des boites mails qui 
bouncent sur des user unknown (5.1.1) et suppression lente des boites 
mails qui bouncent sur des over-quotas/inactivité (5.2.2/5.2.1).


François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Contact orange (Too many SMTP connections)

[Francois Petillon]

On 05/02/2013 01:02 PM, Jérôme Nicolle wrote:

Ou encore à un sender qui utilise plusieurs blocs d'IP (il les loue et
les change régulierement) pour envoyer ses mails (non sollicités en ce
qui concerne ceux que je reçois) en espérant passer sous les radars
(quelques centaines de mails envoyés par IP).

Si je comprends bien, toutes ces règles ne sont là que pour limiter
l'usage des ressources, apparemment trop limitées.


Si je vous comprends bien, si un sender veut patater à 1 mails/s 
pour pouvoir envoyer la newsletter d'un de ses clients en moins d'une 
minute, il faut que la plateforme soit capable de suivre ?



Je suis d'accord avec le fait que vous ne puissiez pas contrôler le
volume en entrée, et que probablement 98% du volume soit de la merde.
Vous n'en êtes pas moins un simple intermédiaire technique et devez
accepter toute la charge sans discrimination.


Vous prenez le temps de reflechir avant d'écrire ? Là, avec 98% de 
merdes, le surdimensionnement atteint un facteur de 50. Soit 500 Netapp 
et 2000 serveurs là où 10 NetApp  40 serveurs seraient nécéssaires pour 
les mails légitimes. Je suis curieux de vous voir justifier la mise en 
place d'une telle architecture pour pouvoir gérer les spams sans aucune 
discrimination.


Et que ferez-vous le jour où les merdes représenteront 99.9% du volume 
? Quel est le ratio de surdimensionnement qui vous parait toujours 
acceptable ?


François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Contact orange (Too many SMTP connections)

[Francois Petillon]

On 05/01/2013 02:10 AM, Eric ROLLAND wrote:

~# cat /etc/postfix/transport
wanadoo.com slow:
wanadoo.fr slow:
orange.com slow:
orange.fr slow:
free.fr slow:
yahoo.fr slow:
yahoo.com slow:
sfr.fr slow:


Certes mais il y a quoi dans le transport slow ?

François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Contact orange (Too many SMTP connections)

[Francois Petillon]

On 05/01/2013 12:23 AM, Jérôme Nicolle wrote:

Perso, quand je tombe sur ce genre de magouille (ie paralleliser
massivement pour contourner des limites), c'est blacklistage direct.

C'est pas un botnet puis qu'il a un range clean et contigu, c'est pas
juste un spammer de base parce qu'il a un peu réfléchi à la façon
d'envoyer proprement malgré le zèle des postmasters à faire chier le
monde, et tu vas quand même empêcher tes util^Wclients de recevoir ses
messages ?


Vous expliquerez ça à deux senders qui ont eu la bonne idée de balancer, 
au même moment, un mailing depuis une /24 (chacun) histoire de patater 
(toujours chacun) à plus de 80 mails/s en pleine heure de pointe. Là, la 
reflexion semblait surtout viser à contourner les regles concernant les 
limites de connexions simultannées afin de piquer un maximum de ressources.


Ou encore à un sender qui utilise plusieurs blocs d'IP (il les loue et 
les change régulierement) pour envoyer ses mails (non sollicités en ce 
qui concerne ceux que je reçois) en espérant passer sous les radars 
(quelques centaines de mails envoyés par IP).


Pour ce qui est des serveurs que je gère, les regles mises en place 
correspondent à des contraintes techniques. Et oui, mettre en place des 
solutions pour contourner ces rêgles est une action que je considère 
comme aggressive.


En temps normal, j'en ai rien à carrer. Mais s'il y a un problème et que 
j'ai besoin d'aller voir ce qu'il se passe...


François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] se passer des box FAI : technique, juridique (Was : Mieux que l'HADOPI, Free !)

[Francois Petillon]

On 01/13/2013 01:49 PM, Sylvain Vallerot wrote:

Aider l'utilisateur à mettre son poste en réseau, si c'est un peu
le boulot du FAI tout de même, sinon je me demande bien de qui ce
serait le boulot.


Du support de l'OS concerné, non ?

Sinon, cela voudrait dire que le FAI devrait également avoir des 
compétences pour configurer l'accès au réseau de tous :
- les smartphones (quelqu'en soit la marque  le firmware) et autres 
tablettes,
- les imprimantes réseaux (si, si, la mienne fait IPv6 et n'importe qui 
peut imprimer dessus, il y a bien des ACLs en IPv4 mais pas en IPv6),

- les téléviseurs connectés (pareil : toutes marques  tous modèles),
- sans oublier les tout derniers frigos communiquants.

J'ai un peu du mal à comprendre pourquoi le FAI serait responsable de la 
configuration du poste de travail et pas de tout le reste.


François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] se passer des box FAI : technique, juridique (Was : Mieux que l'HADOPI, Free !)

[Francois Petillon]

On 01/14/2013 12:27 PM, Guillaume Barrot wrote:

Je crois que l'approche de certains FAI dans ce cas est développons une
application pour ça.

Ordinateur : le retour des kits de connexions ?
Smartphone : appli Free/Freemobile et consors.
TV Connectés : des protos d'applis pour TV Samsung


*hum*

L'appli est censée être téléchargée depuis internet ? ;-)

François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] En tant que FAI, preferez vous beaucoup de connexion courtes, ou du keepalive?

[Francois Petillon]

On 11/09/2012 11:45 AM, François wrote:

Pour vous opérateurs, ça change quelque chose le modèle push serveur - client 
(et donc le fait d'avoir des connexions persistantes)?


Le problème du push est que cela implique des contraintes 
supplémentaires à gérer (quels sont les clients connectés et où) qui 
peuvent devenir assez lourdes lorsqu'il s'agit d'un pool de serveur.


On risque de se retrouver avec des serveurs qui finissent par faire du 
polling pour faire le push (l'avantage est que, dans ce cas, c'est 
l'admin qui décide de l'intervalle de temps utilisé).



Comme vous l'aurez compris, je n'ai pas beaucoup de notions de ce que c'est 
beaucoup de clients. Si des dizaines de milliers c'est peu, on peut parler de
centaines de milliers. C'est juste pour avoir une idée des bottleneck auquel 
vous êtes confrontés.


C'est très dépendant du service géré, des contraintes à satisfaire et du 
daemon utilisé.


François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Changement de FAI ou VPN ?

[Francois Petillon]

On 11/07/2012 10:07 AM, Denis Alligand wrote:

L'affaire devient lancinante : les détenteurs d'eyeballs se battent
pour financer l'infrastructure, chercher des financements alternatifs
(en l'espèce Google pour financer le transit) : je te tiens, tu me
tiens... ça avance pas, mais y'a quand même espoire.



Allez pour les nostalgiques:
http://www.journaldunet.com/solutions/0301/030122_freeft.shtml


Les problèmes ne sont pas les mêmes. L'évènement auquel vous faites 
référence provoquait des répercussions sur les services de Free 
(typiquement, le lien était tellement saturé qu'il fallait plusieurs 
dizaines de secondes pour qu'un client wanadoo puisse s'authentifier en 
POP et les slots des serveurs étaient saturés par les connexions des 
clients de Wanadoo). Du coup, c'étaient tous les utilisateurs qui 
étaient impactés et pas juste les abonnés Wanadoo.


François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Le jour où internet a changé

[Francois Petillon]

On 06/09/2012 06:44 AM, Xavier Beaudouin wrote:

Je ris assez doucement quand je vois la marque avec la couleur du fruit (non 
pas apple) qui a mis juste son zoli site web en IPv6, mais par contre le 
mail... oula... il reste toujours en IPv4.
Déjà 1 ans de déploiement pour mettre du dual stack... bravo pour le dual stack 
qui existe depuis aller...  10 ans au moins.
Perso en IPv6 sur mon asso, pas vu de différence. Pourtant ca fait 2 ans qu'il 
est en réél production (pas juste un /48 annonce vers /dev/null hein) : web, 
mail, dns, ssh...


Vous ne pouvez pas comparer la migration d'une association avec celle 
d'un FAI. Il ne s'agit généralement pas juste de mettre en place une 
dual stack mais de vérifier que l'ensemble des outils maisons sont 
pleinement compatibles. Et, dans certains cas, il faut faire des mises à 
jour. Dans d'autres, il n'y a pas de solution et donc pas de migration 
IPv6 prévue.


Par exemple, chez Free, il y a de l'IPv6 sur les serveurs SMTP mais pas 
sur les MXes : il n'y a, aujourd'hui, pas de bonne manière de gérer une 
base de réputation sur l'IPv6 (du fait du volume d'espace d'adressage).


François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Le jour où internet a changé

[Francois Petillon]

On 06/09/2012 10:16 AM, Xavier Beaudouin wrote:

Passer ses SMTP en IPv6 aucun problemes, par contre les serveurs MX resteront 
surement en IPv4 a cause du SPAM.
La première ligne de défense anti spam sont base sur de la reputation des IP, 
en IPv6 cela ne marche plus trop.



Ce fait plusieurs années que les défenses antispam basées sur IP sont 
vraiment moyennes. En général un geoip est mieux, voire avec p0f


c'est fou le nombre de windows qu'il peut y avoir chez hotmail...


le nombre de hop (ttl) de l'ip source: il est plus souvent clair qu'un MX qui a 
une ip a 30 hop n'est peut-être pas vraiment pour une fois un mx désiré.


si vous gerez un petit domaine avec peu de comptes, oui. Quand vous 
gérez un domaine de taille conséquente avec un volume non négligeable à 
l'internationnale (même si en ratio ça reste faible), vous ne pouvez pas 
vous reposer sur geoip ou sur le nombre de hop.



Après une RBL c'est pas non plus ce qu'il y a mieux en terme de collateral 
damage...


Nous ne parlions pas de RBL mais de base de réputation.

François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Le jour où internet a changé

[Francois Petillon]

On 06/09/2012 10:31 AM, Xavier Beaudouin wrote:

Vous ne pouvez pas comparer la migration d'une association avec celle d'un FAI. Il ne 
s'agit généralement pas juste de mettre en place une dual stack mais de vérifier que 
l'ensemble des outils maisons sont pleinement compatibles. Et, dans certains cas, il faut 
faire des mises à jour. Dans d'autres, il n'y a pas de solution et donc pas de 
migration IPv6 prévue.

Un proxy (nginx, whatever) est la méthode plus kick and dirty qu'on peux mettre 
(cf des choses passées dans le coin sur l'implémentation de ipv6 chez facebook).


C'est quick, pas kick...

Et c'est pas forcément dirty : les serveurs sont déjà probablement 
derrière un loadbalancer. Si celui-ci gère aussi le trafic retour, on 
peut se contenter de mettre le support IPv6 dessus.



Sur du mail, y a carrément plus de taf car l'ip source est très importante :)


Il y a des serveurs web, ftp, autres qui sont protégés en fonction de 
l'IP source (ne serait-ce que pour limiter le nombre de sessions 
simultanées).



Justement ça serait pas mal d'y réfléchir car vu l'espace d'adressage ce 
problème vas un jour se poser (ex un fournisseur de contenu qui n'as pas de v4, 
ca arrivera un jour non ?).


Pour les serveurs ? Pas avant de nombreuses années...


J'avais pensé a travailler a coup de /64 ou autres... mais ca fait quand même 
du monde...


Il n'y a aucune solution pour connaitre la taille des délégations. Vous 
risquez d'être trop large d'un coté (1) et trop petit de l'autre (2).


(1)
- un hébergeur mutualisé peut se retrouver avec un serveur compromis, 
vous risquez de bloquer l'hébergeur au complet au lieu d'un serveur
- il y a des hébergeurs de serveurs dédiés qui distribuent des 
sous-réseaux inférieurs à un /64
- certains sites répartissent leur trafic mail vers des serveurs propres 
(ie sans spams) et des serveurs poubelles, vous allez agréger les deux 
profils


(2) si un spammeur récupère un /48, ça lui laisse 64K positions dans la 
base, si les règles se déclenche au bout de 10 mails, ça fait 640K mails 
délivrables


Je crois qu'il y a un draft sur une histoire de whiteliste (pour 
limiter le nombre d'IP qui peuvent envoyer du mail en IPv6). Des 
discussions que j'ai pu avoir au MAAWG cette semaine, les avis seraient 
plutôt de partir vers de la réputation sur le domaine (avec comme 
conséquence de rendre obligatoire DMARC ou un équivalent sur les 
serveurs SMTP).


François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] records SPF des domaines de messagerie des FAI ADSL/cable

[Francois Petillon]

On 04/26/2012 01:29 PM, Eric Fourage wrote:

J'ai constaté que peu de FAI ADSL/cable français renseignent les records
SPF dans le nom de domaine de messagerie de leurs abonnés.
Outre le fait que ne ne comprends pas bien cette situation, c'est très
gênant avec les antispam Google (Gmail / Postini) et pour les inbox de
nos utilisateurs (PME Fr de qq milliers d'utilisateurs/~300 agences).
Sauf lacune de ma part, je n'en vois pas la raison si des spécialistes
de la question ou les admin/postmaster concernés peuvent m'éclairer...


Le problème de SPF est qu'il faut supporter le SMTP authentifié pour 
l'ensemble du parc d'abonné (dans le cas de Free, seul les comptes qui 
ont activé l'authentification SMTP peuvent l'utiliser). Rien que la mise 
en place de quotas sur le SMTP authentifié a permis de diviser par cent 
le volume de mails à destination du continent nord-americain (j'ai 
quelques spammeurs qui semblent se spécialiser dans l'utilisation de 
serveurs SMTP authentifiés). Accessoirement, on trouve aussi des SSII 
qui mettent en place des serveurs de messagerie utilisant nos serveurs 
comme relais via l'authentification (je présume que c'est pour éviter 
d'avoir à gérer la réputation de leurs serveurs).


Du coup, avoir plusieurs millions de comptes exploitables sur le SMTP 
authentifié signifie être capable d'être particulièrement réactif sur 
les abus (par réactif, je ne sous-entends pas lire abuse mais être 
capable de faire de la réputation sur les expéditeurs en temps réel pour 
bloquer les comptes à problème).


François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [TECH] records SPF des domaines de messagerie des FAI ADSL/cable

[Francois Petillon]

On 04/30/2012 04:36 PM, Stephane Bortzmeyer wrote:

C'est inexact. Uniquement si les gens veulent un Return-Path:
m...@free.fr. Le From: n'étant pas testé par SPF, je peux parfaitement
utiliser un From: m...@free.fr depuis un accès Nerim avec le serveur
SMTP de Nerim.


Penses-tu que ce soit exploitable par les clients lambda d'un FAI ?

François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks

[Francois Petillon]

On 03/20/2012 05:12 PM, RobOEM wrote:

Merci pour le document et son analyse, qui a au moins le mérite de
poser des bases de travail. Remédier à l'infection des utilisateurs
par des maliciels devrait être, et je ne pense pas être le seul à le
penser, un des service fournis par les FAI.


Pourquoi ? Si je veux bien croire que les FAIs soient bien placés pour 
détecter/signaler un problème, la source de l'infection se situe 
rarement sur son domaine de compétence.



Peut être pour éviter de dire une évidence, qui est que la quasi
totalité des machines des end-users sont des machines windows.


Sauf que la donne va petit à petit changer. Il y a de plus en plus de 
périphériques réseaux (imprimantes, télévisions, lecteurs multimédias, 
refrigérateurs) conçus par des sociétés ayant peu d'expériences en terme 
de sécurité. Se focaliser sur Windows risque de n'aboutir qu'à une 
solution à court terme.


François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [FRnOG] Le FTTH, une impasse ?

[Francois Petillon]

Le 07/10/2011 17:06, j...@nexedi.com a écrit :

Prenez 2 petits serveurs silencieux chez vous (je vous les donne) et on vous 
paiera votre abonnement fibre.


Il y a quoi comme abonnement fibre pro à 30 €/mois ? Parce que là, 
votre service fait que l'abonné sort du cadre d'un abonnement personnel 
(à moins que vous n'ayez l'accord du FAI).


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] Re: [FRnOG] RespectMyNet : Une plate-forme citoyenne recense les restrictions d'accès au Net

[Francois Petillon]

On 09/27/2011 06:22 PM, Jérôme Nicolle wrote:

J'ai bien précisé que je parlais du réseau, pour la partie service,
c'était probablement juste un mauvais exemple.


Pourquoi ? Le problème de fond est pourtant similaire.


Cela dit, j'aimerais
bien savoir comment tu gères ce genre de cas de figure, et si les
possibles dégradations ponctuelles de service dues à ses mesures sont
indiquées aux utilisateurs de la plate-forme en toute transparence...


ses ou ces mesures ? En cas de problèmes, des messages explicites 
sont renvoyés et n'importe qui peut connaitre l'état d'une IP (cf 
http://postmaster.free.fr ).



Et que si on suit ton raisonnement,
un opérateur a le droit de se proteger d'une attaque DDoS de 60 Gbps
momentanée mais pas s'il s'agit d'une attaque permanente.

Je parle de pollution (ou plutôt d'attaque) ponctuelle car c'est le
cas le plus fréquent. maintenir une attaque continue sur plusieurs
heures, jours ou semaines est techniquement peu réaliste (et au moins
coûteux).


Je ne voudrais pas me montrer taquin mais c'est pourtant ce qu'il se 
passe au niveau de la messagerie depuis _des_années_ !



Mais si c'est le cas, on en arrive à une autre question : la
légitimité du trafic, et surtout qui peut en décider.


Non. Là, on parle de ce qui peut être considéré comme des attaques, 
quelque chose de suffisamment agressif pour que cela pose un problème de 
charge (que ce soit sur le système ou sur le réseau).


Et dans certains cas, ça peut même être du trafic légitime. J'avais 
bloqué deux emaileurs il y a quelques années : les mails étaient 
légitimes mais ils étaient envoyés :

- aux heures de pointes
- depuis une plateforme conçue pour contourner les limitations des 
MXes en patatant un maximum (en gros, plusieurs dizaines d'IP pour 
chacun avec un maximum de connexions simultannées)
- au même moment (il y en aurait eu qu'un à la fois, le problème 
n'aurait pas forcement été visible).


Bref, un mode d'envoi qui ne tient absolument compte ni de la charge 
induite sur notre plateforme ni des autres serveurs qui pourraient 
vouloir nous envoyer également des mails.



Le problème qui se pose entre la neutralité et le droit, c'est qu'on
ne peut pas en tant qu'opérateur prendre la décision de bloquer
quelque chose parce que ça nous arrange. La notion de force majeure
est alors invoquée.


Non, pas forcément. Par exemple, dans le code des postes et 
télécommunications, il est question d'obligations pour un opérateur. On 
peut citer par exemple l'article D98-7 :


l'opérateur prend les mesures utiles pour :
- assurer le fonctionnement régulier de ses installations ;
- protéger ses installations, par des mesures appropriées, contre les 
risques, menaces et agressions de quelque nature qu'elles soient ;
- garantir la mise en oeuvre, dans les meilleurs délais, de moyens 
techniques et humains susceptibles de pallier les conséquences les plus 
graves des défaillances, neutralisation ou destruction des installations




Mais cette notion mentionne explicitement des
circonstances exceptionnelles et ponctuelles : si le cas invoqué est
ou devient la norme, alors des mesures de protections conformes à la
fois au droit, au principe de neutralité et à celui de proportionalité
devraient être trouvées.


Dans mon article à moi; je lis juste agressions de quelque nature 
qu'elles soient, il n'est pas trop fait état de circonstances 
exceptionnelles.



Sauf que... Le trafic vient bien de quelque part. D'un réseau, d'un
transit, d'un end-user, peu importe. Celui ci est sensé être soumis à
un minimum de règles. Et chaque acteur du réseau est sensé traiter les
abuse en cas d'infraction à ses règles.


Tiens, en parlant de règle  de blacklistage, je vais te preter un autre 
exemple. Depuis un peu plus d'un an, je reçois régulièrement des 
plaintes d'abonnés d'un gros hébergeur de messagerie du fait du 
blacklistage de certains des serveurs utilisés. Après analyse des logs, 
je m'aperçois qu'il y a environ la moitié des serveurs qui sont bloqués 
régulierement (l'analyse ne portait que sur un classe d'IP et ne 
représente pas la totalité du traffic mail de cet hébergeur) :


Jan  1 : 59482 mails, 46321 spams ( 77.9%), 11.5% of unknown recipient
Jan  2 : 47445 mails, 36758 spams ( 77.5%), 10.4% of unknown recipient
Jan  3 : 62340 mails, 47924 spams ( 76.9%), 10.3% of unknown recipient
Jan  4 : 21636 mails, 14680 spams ( 67.8%), 13.3% of unknown recipient
Jan  5 : 22350 mails, 14995 spams ( 67.1%), 14.7% of unknown recipient
Jan  6 : 24280 mails, 17862 spams ( 73.6%), 13.6% of unknown recipient
Jan  7 : 28698 mails, 20960 spams ( 73.0%), 13.8% of unknown recipient
Jan  8 : 24383 mails, 18016 spams ( 73.9%), 15.3% of unknown recipient
Jan  9 : 23362 mails, 17278 spams ( 74.0%), 14.9% of unknown recipient
Jan 10 : 27522 mails, 19841 spams ( 72.1%), 12.5% of unknown recipient
Jan 11 : 26622 mails, 19052 spams ( 71.6%), 13.8% of unknown recipient
Jan 12 : 28261 mails, 20052 spams ( 71.0%), 14.8% of unknown recipient

[FRnOG] Re: [FRnOG] RespectMyNet : Une plate-forme citoyenne recense les restrictions d'accès au Net

[Francois Petillon]

On 09/27/2011 05:31 PM, Jérôme Nicolle wrote:

En l’occurrence, concevoir et exploiter une plate-forme de mail, ça
veut dire être capable d'encaisser 99% de trafic de merde pour 1% de
charge utile. Ca doit être dimensionné en conséquence, ou bien le
service ne doit pas être proposé.


Et donc tu surdimensionnes ta plateforme mail d'un facteur 100 ? Le jour 
où un nouveau botnet débarque et fait passer le ratio à 200, tu suis 
dans la journée ? Et quand on parle de 99% de trafic de merde, c'est du 
lissé sur 24h voir un mois. Et les variations dans la journée peuvent 
être plus conséquentes que cela (j'observe régulièrement des pointes à 
plus de *10 le trafic moyen). Et là, pour éviter de voir ta plateforme 
tomber, il va falloir prendre une très couteuse marge de manœuvre.


Légalement, les opérateurs _doivent_ protéger les infrastructures. Un 
gentil botnet qui ouvre des connexions par dizaines de milliers par 
seconde depuis des PCs compromis (donc depuis des connexions lentes) 
se montre beaucoup plus agressif qu'un MTA standard et abouti assez 
facilement à l'équivalent d'un DDoS permanent sur une plateforme. Et que 
si on suit ton raisonnement, un opérateur a le droit de se proteger 
d'une attaque DDoS de 60 Gbps momentanée mais pas s'il s'agit d'une 
attaque permanente. J'aimerais bien voir la tête de Nerim dans cette 
situation (ce n'est pas une critique, juste une manière de souligner 
qu'il y a toujours une limite au niveau de pollution supportable).


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Soirée Configuration d'ipv6 dans votre reseau / IPv6 REAL Working Group

[Francois Petillon]

On 06/27/2011 10:57 AM, Sylvain Vallerot wrote:

Ça m'interpelle qu'une « feature » sur un service puisse peser aussi
lourd sur une couche bien plus basse, et donc sur tous les autres
services qui reposent sur cette couche basse.


Les IPs n'ont jamais été prévues pour être utilisées dans le cadre de la 
gestion d'une base de réputation et la situation actuelle est plus ou 
moins bancale.


Si les bases de réputation sont aujourd'hui essentiellement basées sur 
les IPs, c'est parce que l'on sait (plus ou moins) gérer l'espace 
d'adressage correspondant (disons que je sais gérer quelques dizaines de 
millions d'IPs, la base actuelle concerne environ 6 millions d'IPs qui 
se sont connectées à nos MX sur les deux dernières semaines, le max 
étant de l'ordre de 14 à 15 millions) et que les particularitées 
(plusieurs domaines sur une IP, plusieurs IPs pour un expéditeur) n'ont 
que peu d'impact.


Par contre, en IPv6, c'est plus ou moins mort. Il faudrait pouvoir 
agréger les résultats mais, chaque réseau ayant sa propre politique de 
délégation (untel fourni à ses clients des /64, un autre des /48, les 
serveurs des opérateurs risquent de se trouver dans quelques /64, les 
clients d'un hébergeur risquent d'avoir des délégations plus petites), 
les particularités sont la règle générale.


Du coup, on risque surtout de voir une migration des bases de réputation 
vers des systèmes basés sur les domaines (et donc avec une signature du 
domaine dans les mails).


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Soirée Configuration d'ipv6 dans votre reseau / IPv6 REAL Working Group

[Francois Petillon]

On 06/27/2011 12:20 PM, Rémi Bouhl wrote:

La bonne nouvelle c'est que le RIPE envisage de faire mentionner la
taille du sous-réseau attribué à chaque end-user:


Dans un monde de bisounours, ce serait une bonne nouvelle si ce n'est 
que la mesure serait sans objet (pas de spam).


Dans le monde réel, on risque surtout de voir des annonces bidons de 
spammeu^Whébergeur peu scrupuleux qui annonceront des /128.



L'autre solution serait d'attribuer à tout le monde un /48 ;)


Ce qui peut se concevoir à destination des utilisateurs. Je me vois mal 
configurer un /48 pour chaque serveur que l'on compte mettre dans la 
salle serveur.


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [FRnOG] Soirée Configuration d'ipv6 dans votre reseau / IPv6 REAL Working Group

[Francois Petillon]

On 06/27/2011 01:32 PM, Alain RICHARD wrote:

Je ne vois pas bien l'intérêt de connaitre la taille, sauf éventuellement de se dire 
c'est un /64, donc un petit utilisateur, donc je le blacklist !! C'est un peu 
discriminatoire non ?


Non, l'interet de connaitre la taille, c'est de pouvoir aggréger les 
résultats par utilisateur (maintenant, à partir du moment où c'est 
l'opérateur que annonce la taille, le principe me parait inexploitable).



Une RBL ipv6 pose le problème qu'une machine peut changer 2^64 fois d'adresse 
avant d'être vraiment blacklistée


À votre avis, après 2^64 IPs différentes, dans quel état est votre base 
de réputation ?



, mais ce type de comportement est difficile à cacher sur un serveur rootkité.


Pourquoi difficile à cacher ? On met l'interface en mode promiscuous et 
on balance des connexions avec des IPs aléatoires.


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [FRnOG] Soirée Configuration d'ipv6 dans votre reseau / IPv6 REAL Working Group

[Francois Petillon]

On 06/27/2011 03:06 PM, Radu-Adrian Feurdean wrote:

Non, l'interet de connaitre la taille, c'est de pouvoir aggréger les
résultats par utilisateur

Ca change quoi (d'essentiel) par rapport a l'etat actuel ?


Éviter qu'un utilisateur rende inexploitable la base de réputation en la 
polluant avec une quasi-infinité d'IPs différentes.



À votre avis, après 2^64 IPs différentes, dans quel état est votre base
de réputation ?

A mon avis ca pourra escalader au /32 du FAI avant d'arriver a 2^16 IPs
differentes.


Et on se retrouve à bloquer des blocs propres (du fait que la part des 
mails légitimes est aujourd'hui anecdotique au regard du trafic de spams.



A cause du traffic de retour et NDP exhaustion sur le routeur d'en
face ?


Là, ça sort un peu de mes compétences mais, de ce que j'en sais, la 
table NDP est locale (ie c'est chez le client que le problème se 
poserait si j'ai bien compris).


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Soirée Configuration d'ipv6 dans votre reseau / IPv6 REAL Working Group

[Francois Petillon]

On 06/25/2011 06:32 PM, Radu-Adrian Feurdean wrote:

A cours de cette soirée chacun dans son coin interviendra sur son réseau
pour mettre des ipv6 sur ses routeurs / interfaces / vlans / Clients /
Machines / Serveurs / Services...

Vous passez vos MX en IPv6 ?


Non, ce n'est pas prévu. La question s'est déjà posé mais IPv6 pose de 
gros problème pour la gestion de la base de réputation.



Par contre, comme il reste meme chez vous des choses a faire, faudra
probablement pas pousser le sarcasme trop loin.


Les choses se font petit à petit.

François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] IPV6 day

[Francois Petillon]

On 06/08/2011 09:47 AM, Aurélien Beaujean wrote:

Coté trafic, on a récement mis en place l'IPv6 sur le webmail et ça
représente 5% du trafic du service.


Et les stats IPv6 sont disponibles pour/sur le serveur ftp.free.fr (ce 
qui permet de voir des disparités entre les différents miroirs).


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Une idée rigolote pour prévenir les utilisateurs infectés

[Francois Petillon]

On 02/24/2011 05:58 PM, Stephane Cremel wrote:

Oui ou l'envoi d'un mail. c'est suffisant (si on suit la logique d'HADOPI,
le FAI est sur de joindre sont client par mail.)
-  pour moi c'est le moins pire techniquement.


Ben non. Certains troyens ont accès à la boite mail de l'abonné et il 
n'est pas très compliqué de supprimer tous les mails faisait référence à 
un virus/troyen/piratage/etc.


Si un opérateur veut que le client soit informé, le mail n'est pas une 
bonne solution (maintenant, rien n'empêche de considérer cela comme une 
première étape).


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Une idée rigolote pour prévenir les utilisateurs infectés

[Francois Petillon]

Le 24/02/2011 15:05, Christophe Lohr a écrit :

L'effet final devrait être le même : le client négligent surf lorsque
soudain apparaît un message de son FAI lui demandant de faire le ménage
sur son PC.


Votre proposition revient à demander aux utilisateurs négligents de ne 
pas l'être. Sans vouloir me montrer critique, je crains que cela ne soit 
légèrement inadéquat.


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] black list d'IP en IPv6

[Francois Petillon]

On 11/22/2010 11:32 PM, Rémi Bouhl wrote:

Même si on peut imaginer qu'à terme les botnets seraient peut-être
capables de demander un renouvellement de l'IPv6 au système s'ils
voient qu'ils sont bloqués.


Ça ne marche plus le mode promiscuous en IPv6 ? À la place des 
concepteurs de botnets, au lieu de juste changer d'IP une fois 
blacklisté, j'aurais plutôt tendance à utiliser une IP par connexion : 
ça rempli les tables des bases de réputation mal conçues en les rendant 
inutiles.


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Contact Skynet pour mailing list

[Francois Petillon]

On 10/06/2010 04:32 PM, Marc De Saya wrote:

Benjamin, ça part certes, mais est-ce que ça arrive et est-ce que ça
arrivera (ne sera pas marqué SPAM sur la route).
Thomas, si de telles boîtes existent, il doit y avoir une solution pour
faire ce qu'elle font.


Sauf que ça bouffe du temps d'acquérir l'expertise du comportement des 
gros hébergeurs de messagerie (je doute que les règles soit d'un 
hébergeur à l'autre), de mettre en place les outils de validation 
antispam correspondant aux filtres de ces différents hébergeurs et qu'il 
peut-être utile d'avoir quelques contacts chez les uns et chez les 
autres. Bref, non, pour un simple mailing, vous aurez du mal à faire ce 
qu'elles font.


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Contact Skynet pour mailing list

[Francois Petillon]

On 10/06/2010 07:44 PM, Marc De Saya wrote:

Merci Thomas, si tu en as d'autre je suis preneur.
Pour le reste je partage totalement l'avis de Pierre, une fois que tu es
inscrit à une mailing-list tu signifies clairement ton acceptation. C'est
pourquoi TOUTE liste de diffusion DOIT prévoir un mécanisme automatique de
désincription (avec un minimum de vérification). Si ça n'est pas le cas,
pour les liste française, la répression des fraudes et la CNIL sont la pour
ça.


Ça, c'est la version bisounours. Si un serveur (entreprise, emailer ou 
assimilé) balance un mail (autre qu'une unique demande de confirmation 
d'inscription) sur une adresse mail dont je sais qu'elle n'a jamais fait 
la moindre demande et encore moins confirmé l'inscription, c'est 
blacklistage direct.


C'est typique des newsletters qui utilisent des listes d'email 
commerciales voir, dans des cas plus rare, ne font pas de double-optin 
(il y a quelques petits malins qui trouvent spirituel de s'inscrire 
comme postmas...@free.fr/r...@free.fr/etc.)



Ma question reste ouverte au sujet des seuil de req/s, syn/s,
SMPT EHLO /s etc ... qu'un opérateur/gros maileur est en droit de limiter
pour une mailing liste totalement légitime.


Le problème est que ce genre de seuil n'a strictement aucun interet (à 
la limite, c'est plutôt l'évolution dans le temps qui pourrait être pris 
en compte). La réponse que je fait lorsqu'on me pose ce genre de 
question est d'être server-friendly. En gros, vous pouvez balancer 
autant de mail que vous voulez mais en ouvrant un nombre raisonnable de 
connexions simultanées. Si les serveurs sont chargés, votre débit sera 
effectivement faible (et c'est dans ce cas que je trouve la limite req/s 
absurde : si vous êtes en deça de la limite, vous allez vous retrouver à 
ouvrir d'autant plus de connexions alors que le serveur est déjà à la rue).



Un des premier éléments de réponse mis en évidence par Thomas, est de load
balancer les mails sur un pool d'IP en sortie ceci permet d'éviter la
propagation d'une IP dans les RBL.


Il m'est déjà arrivé d'aller chercher les raisons pour lesquelles nos 
MXes étaient à la rue. Lorsque je tombe sur un pool de serveurs utilisés 
en // pour envoyer rapidement un grand nombre de mails, j'ai tendance à 
shooter les IPs assez rapidement (j'ai souvenir d'être tombé une fois 
sur deux expediteurs qui nous balançaient, en pleine heure de pointe, 
plus de 80 mails/s chacun en multipliant les connexions depuis quelques 
dizaines d'IP différentes).


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] RE: [FRnOG] Re: [FRnOG] RE: [ FRnOG] Neutralité du Net

[Francois Petillon]

On 08/18/2010 04:55 PM, Giles R DeMourot wrote:

S'il y a un point qui se justifie et en même temps n'a pratiquement aucune chance d'être adopté, 
c'est celui du libre choix du modem-routeur. Les boxes permettent à chaque FAI de se 
différencier des autres au point de vue des services supplémentaires. Rien ne vous empêche 
actuellement de connecter un modem-routeur adsl (la fibre FTTH est une autre histoire): vous aurez 
bien l'internet mais ni service de téléphonie IP ni de TV IP. L'Arcep a refusé de contraindre les 
FAI à fournir à l'utilisateur les paramètres de téléphonie IP. Quant à la télévision IP, dans les 
configurations actuelles c'est assez compliqué. Les FAI ont assez investi dans leur boxes et des 
services différenties pour s'opposer à toute générisation des terminaux adsl.


Le problème est à mon humble avis un peu plus complexe et les FAIs ne 
sont pas les seuls intervenants. Par exemple et pour le cas du 
multimedia, les ayants-droits peuvent souhaiter que leurs contenus ne 
puissent pas être accessibles aux utilisateurs (je pense notament à la 
VOD mais certaines chaines télévisées ont également demandé à ce que 
l'accès à leur contenu soit limité). La box de l'utilisateur ne pourra 
pas être remplacé par un standard ouvert dans ce cas.


François

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] IPv6 Ripeness, et la France alors ?

[Francois Petillon]

On 06/15/2010 12:34 PM, Clement Cavadore wrote:

On Tue, 2010-06-15 at 12:49 +0200, Xavier Nicollet wrote:

Le problème se situe chez nous au niveau applicatif.

Comme chez beaucoup de monde, malheureusement...
Déployer de l'IPv6 dans un backbone, en contexte de FSI, c'est pas très
compliqué, et tend à se généraliser un peu partout. Mais de là à rendre
tous les services dispo en IPv6, c'est encore bien difficile, surtout
s'il y a du loadbalancing, ou des applis métier non développées en
interne.


Et il faut prendre en compte tous les services dont les protections 
sont basées sur des listes d'IPs (que ce soit pour lister les abuseurs 
avec des RBL ou des listes locales, ou juste pour limiter le nombre de 
connexions simultanées ou consécutives).


Vu le nombre d'IPv6s accessible à un utilisateur final, ces listes d'IPs 
sont tout simplement inutilisable telles quelles. On peut probablement 
limiter la complexité en agrégeant les informations par /64 mais ça 
laisse encore beaucoup d'agrégats (2^64 à comparer aux 2^26 ou 2^27 
agrégats que je pourrais probablement gérer avec un serveur sévèrement 
burné dans le cadre de la blackliste sur les MXes de Free).


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Filtre antispam

[Francois Petillon]

On 05/24/2010 09:24 PM, Giles R DeMourot wrote:

Oui, message à postmas...@free.fr laissé sans réponse.


Je n'ai pas trace d'un mail d'un demourot (champs From des ententes) 
dans la boite de postmaster sur les 12 derniers mois.



Mais c'est du
principe de ce type de filtrage que je voulais discuter, plus que de mon cas
particulier (réglé en dehors de Free) et de ce FAI.


Vu le ratio spam/ham, je vois difficilement comment une plateforme mail 
de taille conséquente peut faire sans écremer un tant soit peu.


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Filtre antispam

[Francois Petillon]

On 05/23/2010 11:36 PM, Rémi Bouhl wrote:

Question subsidiaire: comment se fait-il qu'à 30€/mois on ne puisse
pas recevoir ses mails correctement, alors que ça coûte moins cher de
faire des mails qui marchent, que de faire des mails avec antispam?


Ah ? Vous pouvez justifier ?

Personnellement, je vais me contenter de fondamentaux assez simples :
- la puissance CPU est d'ordre exponentiel
- la capacité des disques durs est d'ordre exponentiel, la bande 
passante d'accès séquentiel est d'ordre linéaire et les temps d'accès 
sont plus ou moins constants


Sur la messagerie, la taille moyenne des fichiers reste petite. De ce 
fait, avec le temps, le facteur limitant a basculé de la capacité de 
stockage à la capacité en IO (le temps d'accès moyen). Bref, le coût de 
la gestion de l'antispam décroit beaucoup plus vite que ne le fait le 
coût du stockage (qui reste quasi-constant donc).


Et avec moins de 5% de mails légitimes dans le traffic spam, le coût est 
actuellement en faveur du filtrage antispam.


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Filtre antispam

[Francois Petillon]

On 05/25/2010 02:48 PM, Clément Game wrote:

ca c'est le monde des bisounours, ou potentiellement un spam ne
mangerait pas d'I/O disque...dans les faits la plupart des mta font un
acces en ecriture avant de passer un mail au content filterdonc un
traffic mail a le meme cout en i/O disques que le traffic soit full
legit ou full spam


Dans le cas de Free, il n'y a pas de stockage sur disque avant filtrage 
(les frontaux sont des proxies qui scannent le mail, le transmettent au 
bon serveur de stockage et retournent le résultat à l'émetteur).


Et même dans le cas d'un MTA qui stockerait le mail sur disque pour le 
scanner, il est moins couteux de limiter ce surdimensionnement aux seuls 
serveurs de reception que d'avoir à le faire également sur les serveurs 
de stockage.


François



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Filtre antispam

[Francois Petillon]

On 05/25/2010 04:28 PM, Jérôme Nicolle wrote:

Cela dit, si tes appliances GOTO étaient un peu mieux foutues, plutôt
que d'être des simples moteurs de regexp sur le contenus des mails, et
bossaient intelligemment au niveau de la couche réseau, tu limiterais
pas mal le niveau de consommation de ressources. Et les faux positifs.


Il ne s'agit d'appliances mais juste une librairie. Et oui, la future 
version est censé faire joujou avec la couche réseau.


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Filtre antispam

[Francois Petillon]

On 05/25/2010 04:37 PM, Clément Game wrote:

Ca parait evident qu'il que chez un gros ISP comme Free il y a egalement
des mechanismes amount.


Moi pas... :-)

François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Hackito Ergo Sum 2010

[Francois Petillon]

stefan wrote:

Par contre prioriser le web par rapport au P2P, ou refuser d'augmenter la
capa parce que les gens font du P2P et pas du gopher, la je vois pas ce
qu'il y a d'enervant: tu vends un tuyau, les gens
le remplissent comme ils veulent. Je crois pas que les vendeurs de toilettes
s'offusquent parce que les gens font caca dedans.


Parce qu'en situation d'engorgement, les gens qui font caca en P2P font 
la queue devant toutes les toilettes simultanément (voir même à multiple 
reprise pour chaque toilette) alors que le tout-venant se contente de 
faire la queue devant une seule toilette. Du coup, il y a au mieux un 
net déséquilibre de la consommation des ressources en faveur des P2Piste 
et au pire une sérieuse famine pour le tout-venant (et Dieu sait si ça 
ne doit pas être agréable).


Bref, situer à un niveau d'égalité différentes applications qui 
n'utilisent pas de la même manière les ressources pose probleme. Une 
bonne solution serait probablement de gerer les ressources par lien 
mais je doute qu'il soit facile de mettre en place ce type de QoS.


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] akamai netsession

[Francois Petillon]

Sebastien WILLEMIJNS wrote:

la recession et le P2P ont donné des idées à AKAMAI pour economiser de
la BP et des serveurs en déportant un peu sur les end users
http://www.akamai.fr/enfr/html/misc/akamai_client/netsession_interface_faq.html
j'avoue c'est uninstallable mais c'est installé par défaut ;)


C'est une impression ou c'est en conflit avec la plupart des contrats 
d'abonnement ADSL à usage _personnel_ où il me parait plus que douteux 
de rétroceder de la BP à un tiers ?


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] probleme de routage avec free

[Francois Petillon]

Xavier Beaudouin wrote:
Le dernier en cours c'est : la portabilité des mails ... (genre le 
nouveau merdier qui nous rendrent encore plus dingue...) :

http://www.clubic.com/actualite-310150-portabilite-adresse-email-etude.html
Voila un *vrai* sujet, le null routing tout le monde sais faire et l'as 
déjà fais... c'est pas nouveau...


C'est pas un vrai sujet, c'est juste une hérésie. Techniquement parlant, 
le but de ce service va être de rediriger des spams (bah oui, à la base, 
l'ancien compte est censé recevoir de moins en moins de mails 
légitimes). Du coup, il faudra s'attendre à des blacklistages répétitifs 
des serveurs concernés...


Et en oubliant la partie spam, le service va être lourd à gerer (il 
faudra demander une confirmation au destinataire avant de mettre en 
place la redirection, ajouter dans les entetes un lien pour supprimer à 
tout moment la redirection) et necessitera d'une manière ou d'une autre 
de conserver un compte utilisateur (pour que l'ancien propriétaire 
puisse changer la redirection si necessaire). Après, il reste quelques 
questions pratiques. Genre que fait-on des mails qui sont refusés par le 
serveur destinataire ? Que fait-on d'une redirection si le serveur 
refuse le destinataire ? etc.


Bref, je suis bien content que Free ne soit pas concerné par le 
probleme... :-)


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Quand free route les IP privées...

[Francois Petillon]

William Gacquer wrote:

ce message est à destination des admin de Free : vous routez certaines
IP privées depuis les freebox.


Et vous pensez que la ML frnog est le support idoine pour leur signaler  ?

François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] Re: [FRnOG] Quand free route les IP privées...

[Francois Petillon]

William Gacquer wrote:

quand on écrit de telles conneries, on se renseigne sur la personne dont
on parle.
Je gère un réseau de 9000 abonnés en FTTH actif, GPON, HFC et DSL. 


Et des choses comme la RFC 2142 ne marchent plus en FTTH ?

François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Facturation au débit ?

[Francois Petillon]

Sebastien WILLEMIJNS wrote:

Pourquoi les 29.9X €'s like ne peuvent pas en faire autant ? Hors
couts fixes incompressibles pourquoi un pompeur fou paye le meme prix
qu'une mémé à 512 kbit/s ? 


Pourquoi un pompeur fou qui ne téléchargerait que hors des heures de 
pointes payerait plus cher que la mémé qui ne se connecterait que la 
nuit ? Pourquoi un pompeur fou qui n'utiliserait que des ressources 
locales paierait plus cher que la mémé qui ferait de la videoconf' 
avec ses petits enfants en nouvelle-zélande ?


Si on voulait réellement faire de la facturation au coût réel, les FAIs 
se retrouveraient à gerer des usines à gaz telles qu'elles impacteraient 
la facture de tous les abonnés.


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Facturation au débit ?

[Francois Petillon]

Pierre Col wrote:

Je me fais l'écho des réflexions d'un des membres de cette ML :
http://www.zdnet.fr/blogs/infra-net/et-si-l-acces-internet-etait-facture-proportionnellement-au-debit-effectivement-disponible-39709701.htm 


Dans le prix de la bouteille de lait, quelle est la part spécifique au 
contenu ? Quelle est la part relative au contenant, transport, 
manutention, stockage, bénéfices des intermédiaires ?


Et qui irait acheter une bouteille de lait sans connaitre effectivement 
son prix avant consommation ?


Pour arreter les analogies foireuses, le succès des accès ADSL 
aujourd'hui en france est dû en grande partie au coût fixe de la facture 
sur l'accès internet.


Et si on devait considerer qu'il s'agit d'un mauvais modele, je vois 
difficilement comment considerer qu'il soit plus judicieux de faire 
payer le débit utilisable (ce n'est pas parce qu'un utilisateur a 28 
Mbps qu'il coute plus cher qu'un utilisateur à 512kbps qui les 
utiliserait en permanence).


On pourrait imaginer faire payer le traffic mais ça nous renvoie aux 
factures astronomiques qu'ont pu recevoir certains abonnés de cybercable 
au début du millénaire (je me souviens d'avoir payé un truc comme 1500 
Fr un mois parce que j'avais un rpost qui tentait d'envoyer à 
intervalles reguliers quelques articles au serveur de news qui les 
refusait après reception). De plus, ce n'est pas le débit qui importe 
mais le débit en pointe au 95percentile. Bref, il faudrait faire une 
facturation en fonction du débit utilisé au moment des heures de pointe, 
des tuyeaux alors sollicités et des coûts qu'ils représentent. Vous 
parlez d'une facturation compréhensible... :-)


Et au final, on obtiendrait une usine à gaz imbittable qui ne 
correspondrait probablement pas aux attentes de m'ame Michu (avoir une 
facture fixe sans surprises).


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Facturation au débit ?

[Francois Petillon]

Alexandre Forest wrote:
Bon Ok l'analogie a ses limites (c'est la crise du lait etc.). 
Elle a le mérite de poser la question de l'équité en termes simplifiés (et

non simplistes).


Non. Le probleme avec l'analogie laitière est qu'elle compare une 
quantité avec un débit. Le débit ne fixe pas la quantité que tu peux 
prendre (mais je concède qu'il fixe une borne supérieure).



L'idée est uniquement d'engager une réflexion autour des pistes pour la montée 
en débit
... qui paye ? 


En quoi le débit représente un coût direct ? C'est ce qui est utilisé 
qui représente un coût (donc sur un gros échantillon, c'est l'usage 
moyen, pas la capacité d'usage). Et cet usage moyen doit être 
sensiblement le même à utilisateurs similaires que la connexion fasse 2 
Mbps ou 16 Mbps.



Et les clients ? Certains voudrait payer moins pour avoir juste ce dont ils
se servent. Plus nombreux sont ceux qui sont prêt à payer plus pour avoir
... plus et qui trouvent ça normal. En tout cas plus juste


Là, j'ai l'impression que ça concerné surtout les utilisateurs 
avertis, pas les utilisateurs moyens.



Dans la tête de Mme Michu (régulièrement citée) les choses sont comment ? Si
elle paye 30 euros pour avoir 1 Mbps alors que Mme Michu(bis) chez qui elle
achète régulièrement des boites à couvercle en plastique lui explique que
elle, pour 30 euros, est abonné à x6, x12 ou x24, elle est en droit de se
poser des questions.


Sauf que là, ce qu'elle demande, c'est du confort. Elle peut télécharger 
la même chose mais plus lentement.


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Dutch ISPs Sign Anti-Botnet Treaty

[Francois Petillon]

Le 29 septembre 2009 13:49, Raphaël Jacquot sxp...@sxpert.org a écrit :

intéressant... le seul cas ou la coupure de l'acces internet a un sens


Il ne s'agit pas de coupures mais de mise en quarantaine. XS4ALL utilise 
typiquement des sandbox à différents niveaux (laissant un accès plus 
ou moins ouverts aux utilisateurs) en fonction du probleme et de la 
durée. Cela va de quelques ports bloqués (pour bloquer certains type de 
virus/troyens) au seul accès de quelques serveurs de mise à jour 
d'antivirus/systeme d'exploitation/etc.


Bref, il s'agit juste d'un partage des informations et d'une 
officialisation des moyens mis en place.


Jérôme Nicolle wrote:

Par contre la déconnexion doit se faire pour UNE machine, et pas
toutes celles du LAN, et donc être relayée par la box IMHO.


Le FAI ne connait que l'IP publique sur son réseau. À moins de mettre de 
quoi analyser le traffic réseau sur la boite (auquel cas on risque 
d'entendre parler d'Hadopi 4 sans même évoquer le probleme du coût), je 
vois difficilement comment faire.


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Botnet qui s'énerve sur un de mes serveurs ?

[Francois Petillon]

Julien Escario wrote:
Depuis le début de l'a.m., j'ai un trafic anormalement élevé sur un 
serveur mail. J'ai cru à une attaque dictionnaire au début et après 
analyse, c'est quasiment toujours sur les mêmes adresses et en 
provenance d'une grand quantité d'hôte différents (ou alors ils sont 
spoofés).


Le spoofing sur des sessions TCP qui véhiculent des mails, on en entend 
souvent parler mais on ne les voit jamais.


J'ai également la sensation qu'ils ont un FROM , ce qui, d'après les 
RFC, n'est pas condamnable ...


Comme cela a été signalé, un From en  correspond souvent avec des 
bounces (normalement, n'importe quelle réponse automatique devrait être 
renvoyée avec un  en from enveloppe pour éviter de générer des 
boucles). Donc probablement un spammeur qui utilise ton domaine poure 
spammer.


Il semblerait qu'ils aient pris 4 ou 5 domaines et essaient d'envoyer 
une 10aine de mails sur chaque adresse. Ensuite ils changent d'adresse 
et réessaient.


S'il s'agit bien de bounces, le spammeur a pris une liste d'adresses et 
les utilise aléatoirement (et je subodore que tu ne vois au final qu'une 
infime fraction des bounces générés).


J'avais déjà vu un spammeur qui rajoutait deux caractères aléatoires à 
la partie gauche de l'email (ce qui du coup impliquait une forte 
probabilité d'inexistance de l'email et je blacklistais les IPs 
bounceuses à tour de bras).


Blacklisté quelques machines qui spamment, je sais faire. 2000, j'ai 
plus de mal ...


# ./liststats
last expire was 8486631s ago
1636912 IP found out of 2099788

Soit 1.6 millions d'IP blacklistée en ce moment (et pour des blacklistes 
qui durent moins de 24h, ça laisse une idée du nombre de PC compromis 
dans la nature) et le record est de presque 2.1 millions...


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Contact chez FREE

[Francois Petillon]

mr.tux wrote:
Super, je m'en suis douté après mon post, visiblement il a eu la réponse 
par un autre biais.

Vous n'auriez pas une adresse valide par hasard ?


Cela dépend pas mal de l'objet de votre requete. La plupart des adresses 
administratives type RFC 2142 sont généralement lues par les bonnes 
personnes.


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Loi création et internet adop tée par l'Assemblée Nationale

[Francois Petillon]

Pierre Col wrote:
Je peux être responsable de ce que fait ma voiture ou mon four à 
micro-ondes, mais pas de ce que fait ma Box ADSL : je n'ai aucun moyen 
de vérifier que son concepteur n'y a pas mis une backdoor.


Pourquoi te focaliser sur ta box ? Et ton frigo communiquant, sais-tu à 
quel point il est bavard et si son concepteur n'y a pas prévu d'y 
installer un réseau TOR pour son usage personnel ? On pourrait parler 
des imprimantes réseaux, PDA, etc.


D'un autre coté, backdoor ou pas backdoor sur ta box, ton FAI est bien 
placé pour usurper ton IP depuis n'importe lequel des équipements réseau 
qu'il peut gerer.


À ce niveau là, tu te retrouves dans l'obligation d'accorder 
malheureusement un minimum de confiance vis à vis de ton FAI. Mais je 
présume que ton attaque vise principalement au déploiement massif d'IPv6 
et à la suppression du NAT... :-)


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Juniper vous offre un livre

[Francois Petillon]

Arthur Fernandez wrote:
ça ne fera pas le troll du jour, mais merci pour l'info, ça tombe bien 
je cherchais ce livre :)


Je ne suis pas sûr qu'il soit judicieux d'encourager ainsi le spam sur 
cette liste...


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Tr: [sd-start] la zone dns de neuf.fr

[Francois Petillon]

o...@ovh.net wrote:

Fantec a été faire un tour dans le code de Qmail, et notre ami Bernstein
fait bien une requete MX pas ANY... La vérité est ailleurs.



int dns_cname(sa)

...

   switch(resolve(sa,T_ANY))


Si j'ai bien compris le code, il fait une requete ANY pour voir s'il n'y 
aurai pas un CNAME histoire de remplacer le domaine avant de faire sa 
requete MX. Malheureusement, dans son code, il oublie l'information 
que la réponse était tronquée et renvoie une erreur lorsqu'un 
enregistrement est erroné (du fait de la troncature). Du coup, il y a 
trois choses qui me genent :  pourquoi oublier que l'enregistrement est 
tronqué alors qu'il y a une valeur recherchée dans la liste qui _est_ 
incomplete ? Pourquoi faire une recherche T_ANY pour récuperer un seul 
CNAME (là, je manque d'historique sur les requetes DNS) ? Et pourquoi 
commencer par un CNAME au lieu d'un MX ? (j'aurais tendance à penser que 
la plupart des domaines ont différentes entrées et qu'il leur faille 
donc un MX alors que le CNAME empeche toute autre entrée dans les DNS)


Pour ce qui est des points :

Le problème est dû à la taille de la repose DNS de la zone neuf.fr.
La réponse dépasse 512 bytes (583 bytes) et donc elle ne se fait pas
en UDP. Elle se fait en TCP. Or QMAIL, en respectant les RFC, ne gère
pas les requêtes DNS en TCP. Et donc il ne trouve pas les serveurs MX
de @neuf.


Non, les réponses peuvent se faire sur 512 octets en tronquant les 
données. Là, cela devrait être clairement indésiré car il s'agit de 
récuperer une entrée dans une liste. Rien n'oblige Qmail à implementer 
les requetes TCP mais ce n'est pas pour autant que les entrées ne 
doivent pas dépasser les 512 octets. Là, Qmail se tire dans le pied et 
cela fait déjà quelques années que cela a été signalé. Sinon et depuis 
presque 10 ans déjà, les requetes en UDP peuvent dépasser les 512 octets 
(RFC 2671), il y a même un patch à qmail qui l'exploite...



D'après les auteurs de Qmail, une zone  à 512 ne respectent pas les
RFC et donc il n'y a pas de patchs ni de correctifs à appliquer sur le
Qmail puisque Qmail respectent les RFC.


Ben non. Sinon, la RFC 1035 n'aurait pas prévu le flag TC pour signaler 
précisement que la réponse était tronquée.



Nous allons publier un patch pour QMAIL afin que nos clients puissent
résoudre ce problème


Il en existe déjà qui utilisent EDNS0 :
http://www.ckdhr.com/ckd/qmail-103.patch


Mais sachant qu'on a presque 50'000 serveurs dédiés
chez Ovh et QMAIL est installé sur plusieurs millions de serveurs dans
le monde, le plus simple serait de corriger la zone neuf.fr afin de
réduire la taille de la réponse et résoudre ce problème rapidement
et avec minimum de travail.


Et donc faire bosser un tiers pour contourner un bug dont il n'est pas 
responsable.


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Tr: [sd-start] la zone dns de neuf.fr

[Francois Petillon]

o...@ovh.net wrote:

Nope. La ligne interessante est avant au niveau de la ligne (367) et (377)
ce qui fait que code ne va pas jusqu'à la ligne (385). ça s'arrete avant. 


(367)  addrmangle(sender,argv[2],flagalias,0);
(377)  addrmangle(reciplist.sa + reciplist.len,*recips,flagalias,!relayhost);

notre ami DJB verifie que le FROM: est un truc catholique ... euhh canonical
 /* host has to be canonical, box has to be quoted */


Non, le dernier argument est à 0 ce qui inhibe la resolution T_ANY.


   addrmangle(reciplist.sa + reciplist.len,*recips,flagalias,!relayhost);
c'est là qu'il y a un plantage avec neuf.fr et le code s'arrete. 


C'est là où il y a un plantage de qmail. Neuf n'a rien à voir là dedans.


En gros, le destinateur a une zone DNS pourri (alias la zone n'existe pas, 
n'a pas
le minimum c'est à ni le A ni le MX ni NS, a une reponse  512 bytes) c'est pas 
la peine d'aller plus loin. et donc pas la peine d'executer dns_mxip.


Non, la réponse est tronquée à 512 octets, qmail l'oublie, la parse et 
s'arrete parce qu'il y a un enregistrement erroné. Des zones à plus de 
512 bytes, il doit y en avoir quelques unes.


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Le fi ltrage d'Internet est-il inéluctable ?

[Francois Petillon]

Jérôme Nicolle wrote:
Il me semble que c'est la première raison qui aie justifié le 
filtrage / QoS sur les réseaux d'opérateurs, non ?


Je ne fait pas de réseau donc je peux me planter mais le traffic est 
généralement shappé par connexion TCP. Le P2P arrivant avec ses 
dizaines/centaines de connexions simultannées par téléchargement, il 
phagocyte litéralement le réseau en cas de saturation d'un lien et est 
susceptible de rendre litéralement inutilisable les protocoles 
normaux. Du coup, il faut d'une manière ou d'une autre ré-équilibrer 
les priorités entre protocoles.


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Free.fr et too many spams from your IP

[Francois Petillon]

Eudes PHILIPPE wrote:

La cause la plus probable d'un blacklistage chez free pourrait provenir du fait 
que vous avez envoyé trop de mails sur des utilisateurs qui n'existent plus.


Qui n'existent plus ? Les gens ont plutôt tendance à laisser mourir leur 
boite mail que de faire la demande de suppression de compte. Le 
blacklistage auquel vous faites référence renvoie plutôt un message 
d'erreur too many errors et se déclenche généralement lorsqu'il y a un 
taux conséquent de destinataires inexistants (le taux moyen/global de 
destinataire inexistant est généralement de 3 à 5%). Mais effectivement 
renvoyer des bounces à tout va (ie sur des spams dont l'emetteur a été 
usurpé) est une raison fréquente pour se retrouver blacklisté.



une autre cause, peu probable dans votre cas, serait que trop d'utilisateurs 
indique que votre email est du spam.


Non.


Et encore une autre, est que votre mail est considéré comme spam (le contenu), 
du coup il blackliste les mails suivant;


Là, le probleme se situe à ce niveau. Certains des envois effectués sont 
systématiquement analysés comme étant des spams. J'ai demandé à recevoir 
des exemples pour qu'il soit possible de faire une analyse.



Etant donné que par défaut sur free, les mails sont supprimés et non déplacés 
dans un répertoire de spam (personnellement je suis contre cette méthode)


Moi de même. Maintenant, j'ai une question pour vous : jusqu'où êtes 
vous pret à surdimensionner un service pour assumer vos principes ? Je 
rappelle juste que les taux de spams ces derniers mois dépassaient les 
95% (voir plus de 97%) et que cela implique un surdimenssionnement d'un 
facteur 20 (voir plus de 34).



Francois petillon qui est derrière postmaster (sauf erreur de ma part) ne vous 
donnera pas beaucoup plus d'informations.


Je vous sens aigri... :-)

François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Coût du spam ?

[Francois Petillon]

Christophe Meessen wrote:
dans la suite de la discussion sur les techniques de filtre anti-spam, 
je souhaiterais savoir si on a une idée du montant du coût (black tax) 
des mails indésirables pour les opérateurs de réseau/FAI.


Vous cherchez des chiffres simples à comprendre et je crains qu'il n'en 
existe pas. Le seul chiffre abordable est le coût du spam pour un 
hebergeur qui déciderait de ne pas faire de tri entre les spams et les 
mails légitimes. Là, c'est facile de minorer le surdimensionnement : 90% 
de spams signifie qu'il faut surdimensionner sa plateforme mail d'au 
moins un facteur 10, 95% de spams donne un surdimensionnement d'un 
facteur 20, 97.5% de spams et on arrive à un surdimensionnement d'un 
facteur 40.


Après, ce coût est fortement dépendant des solutions mises en place pour 
juguler le traffic des spams.



1° le pourcentage de messages indésirables (spam, scam, phishing,...),


Il y a quelques études de temps à autre, le plus souvent financées par 
des éditeurs de logiciels antispam, donnant des chiffres probablement 
pessimistes. Après, on peut avoir une estimation en scannant les mails 
mais ce n'est qu'une estimation des spams _détectés_ et cette estimation 
dépend fortement des mesures de blocage en amont.


Par exemple, en mettant en place un blacklistage pour les IPs qui 
enverraient plus de 50% de spams, le pourcentage moyen de spams est de 
25% en moyenne (avec des pointes plus élévées ponctuelles).


2° le coût financier du traitement des mails (acheminement, tri, 
filtrage, stockage,...),


Dans le cas de Free, il y a une trentaine de serveurs dédiés à la 
detection des spams entrant mais qui sont protégés par un systeme de 
blacklistage (pour éviter d'avoir à scaler sur la volumétrie du spam).


3° le nombre moyen de mails par secondes à traiter en réception et 
émission,


Là, ça m'étonnerait qu'un FAI donne ce type d'information.


4° taille moyenne des mails.


Les spams sont généralement d'assez petite taille mais il faut scanner 
tous les mails. Je n'ai pas de chiffres précis.


Je souhaiterais par exemple être en mesure de déterminer si la surcharge 
de traitement requis pour vérifier des signatures de messages (ex. 
domainKey/PGP) pourrait être compensée par la réduction du nombre de 
messages à traiter. C'est juste un exemple, car je sais déjà qu'il 
existe d'autres solutions moins lourde en traitement.


La présence d'une signature (même validée) n'est pas un indice de 
légitimité du contenu du mail. Il faudra quand même scanner le mail.


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Augmentation des virus et trojans

[Francois Petillon]

Jerome Martin wrote:
Et là, on voit tout de suite 
l'effet pervers : les domaines qui ne l'implémentent pas se prennent une 
volumétrie de spam plus importante du fait de ces doublons (bref, les 
domaines tiers en payent les conséquences).

Exact. Tout comme les voitures portant un autocollant attention alarme
provoquent une augmentation du risque pour les voitures sans alarme.
Comme une maison avec des barreaux aux fenetres pousse les cambrioleurs
vers la maison d'a coté, non protégée.


Non. Pour reprendre votre exemple, les voitures portant un autocollant 
attention alarme et les maisons avec des barreaux aux fenetres ne 
suggèrent pas aux cambrioleurs d'augmenter la fréquence de leur larcin. 
Ces protections se limitent à leur suggerer de s'attaquer à une proie 
plus facile.



Exact. Par contre, les tentatives suivantes (selon l'implementation de
greylisting, les tentatives suivantes ayant le meme couple
expediteur/IP, le meme tuple expediteur/recipiendaire/IP, etc.) ne sont
pas impactées. Et ce que l'on pert d'un coté (expedition), on le gagne
au centuple de l'autre (CPU bouffé par l'AV, connexions aux RBL, etc.).
Bref, au total, je ne sais pas si l'on est a l'équilibre, mais c'est un
calcul trop complexe pour etre simplifié comme cela.


Deux choses. Primo, ce que vous économisez de votre coté est payé par un 
tiers. Il est difficile de parler d'équilibre alors que les pertes et 
les gains ne sont pas assumés par le même acteur. Secundo,le greylisting 
ne vous dédouane pas de faire du filtrage et donc de scanner les mails.


, vous augmentez également la 
charge en IO disque. Si tous les domaines mettaient en place ce type de 
mesure, il faudrait faire un upgrade conséquent sur les serveurs SMTP 
dont le traffic est non négligeable (et vous faites donc une seconde 
fois porter le coût de votre protection à des tiers).

Encore une fois, si l'on globalise la mesure, en supposant qu'elle reste
efficace (ce qui ne serait pas le cas je pense), le gain en CPU/reseau
des messages a filtrer en moins (AV, etc...) est bien supérieur au
simple miss de cache disque coté expediteur. Faut pas charrier, relire
un mail sur disque reste moins couteux que le scanner, en faire un
checksum, se connecter à 5 RBL et lire leur reponse, passer a la
moulinette d'un filtre bayésien, etc...


À nouveau, le gain et les pertes ne sont pas à la charge du même acteur. 
Il est donc difficile de parler d'équilibrage.


Et oui, du fait des courbes d'évolutions de la puissance CPU et de la 
capacité en IO des disques, j'ai souvent plus tendance à préférer 
bouffer du CPU que de bouffer de l'IO disque (bon, reste à voir avec les 
SSD si ceci ne sera pas mis à mal prochainement).


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Augmentation des virus et trojans

[Francois Petillon]

Splio - Benjamin BILLON wrote:
Les RFC parlent aussi du support de la commande VRFY, très mal vue par 
les ISP quand utilisée (et ça flingue la réputation ... ha, on n'a pas 
encore parlé de réputation ?)



RFC 2821 :

  3.5.2 VRFY Normal Response
[...]
   Server implementations SHOULD support both VRFY and EXPN.  For
   security reasons, implementations MAY provide local installations a
   way to disable either or both of these commands through configuration
   options or the equivalent.  When these commands are supported, they
   are not required to work across relays when relaying is supported.
   Since they were both optional in RFC 821, they MUST be listed as
   service extensions in an EHLO response, if they are supported.


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] 900 jours avant la pénurie d'a dresses IP V4 ?

[Francois Petillon]

Olivier Bonaventure wrote:

Je pense que lorsqu'il IPv6 démarera, il pourrait démarrer rapidement.
Certains s'y préparent activement, voir par exemple la présentation de
google au dernier IETF


Je suis assez dubitatif. Comme il n'est actuellement pas raisonnable de 
proposer aux clients l'IPv6 par défaut (pbm de firewall pas compatible, 
etc.), ceux-ci doivent l'activer. Et tant qu'ils n'en ont pas réellement 
besoin (je le comprend comme tant qu'il n'y aura pas du contenu 
uniquement accessible en IPv6), peu de personnes iront l'activer.


Sur ftp.free.fr (donc le cas plutôt idéal où l'utilisateur est plutôt 
technophile et où les utilisateurs locaux ont accès à l'IPv6), le 
traffic IPv6 représente de 2 à 3% de la volumétrie totale. Ce traffic 
part de 60 à 80% vers des IPs Free, la quasi-totalité du reste vers des 
réseaux universitaire/de recherche/etc.


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Wanadoo / Orange SMTP

[Francois Petillon]

Richard BOIX wrote:

La normalisation de SPF permettant, par le biais des DNS,
d'annoncer les IPs sortantes du mail pour un domaine,
me parait être la meilleur réponse aux SPAM.


bof.


Free utilise déjà ce type de protection.


Avez-vous plus d'informations sur le sujet ? Je serais interessé par des 
retours d'experience.


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] Content Delivery Networ k (CDN) à la francaise

[Francois Petillon]

Stephane Bortzmeyer wrote:

Si cela ne pose pas de probleme en temps normal, il est parfois ardu
de récuperer une release dans les heures/jours qui suivent sa
publication. Si usenet est assez bien adapté pour la diffusion en
masse, rares sont les FAIs qui maintiennent ce service.

BitTorrent n'est-il pas l'idéal pour ce genre de cas ?


Non, déjà parce que l'essentiel des utilisateurs ont des connexions 
asymétriques (donc pas tant de débit que cela pour l'upload) et qu'un 
pourcentage non négligeable d'entre eux ne jouent pas le jeu (laisser 
l'application tourner une fois que le téléchargement est fini). 
Toutefois, les logiciels de P2P peuvent être une solution lorsqu'il n'y 
a pas de miroir local/accessible.


Ensuite, tous les softs de P2P utilisent de manière merdiques les 
ressources. Déjà, ils ouvrent de très nombreuses connexions ce qui est 
susceptible de générer un fort déséquilibre de la répartition de la BP 
par rapport aux applications plus raisonnables/respectueuses (bref, le 
jour où on tourne en connexion symétrique, un téléchargement FTP/HTTP 
sur un site n'aurait plus aucune BP). De plus, il n'y a aucune notion de 
réseau dans les logiciels P2P ce qui est susceptible de générer un fort 
traffic sur des connexions non locales.


Pour finir, les logiciels de P2P ne font que déporter le coût de 
l'hebergement (donc celui du fournisseur de contenu) vers le réseau 
(donc celui du fournisseur d'accès).


Donc, à mon humble avis, les applications P2P sont, aujourd'hui,  une 
mauvaise solution au probleme. :-)


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] Re: [FRnOG] Cont ent Delivery Network (CDN) à la franca ise

[Francois Petillon]

Frédéric Gander wrote:

pour faire du streaming faut intégrer rar et par dans vlc avant ;)


Non, je faisais plutôt référence aux images iso de CD/DVD des 
différentes distributions linux... Même si c'est applicable à d'autres 
contenus librement distribués (sur le FTP de Free, le troisieme miroir 
le plus sollicité est celui d'un jeu sous Windows).



et bon il y a un leger overhead à transferer des données binaires en fichier
texte de 30k ? non ? ;)


Tu n'es pas obligé de te limiter à des articles de 30 k. Avec un 
overhead de 1 Ko pour les entetes et quasiment négligeable pour 
l'encodage (il doit y avoir 2 ou 3% d'overhead en yenc), on tourne avec 
3 à 4% d'overhead sur des articles d'un Mo.


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/