DMARC.org un pas en avant dans la lutte contre le phishing?

[Teraoctet]

Bravo à Caméléon qui a su lever un lièvre appétissant et bravo à Geckozone qui a permis d'en débattre un peu

[MacIntoc]

Teraoctet>T'es quand même conscient que toutes les boites mails disposent d'un filtre bayésiens depuis prêt de 10 ans et qu'on en est toujours au même point depuis ?
Les filtres bayésiens sont très bien pour ceux qui ne cherchent pas à passer au travers.

[Teraoctet]

Affirmatif. Certes cela n'a jamais évolué veux tu dire
l'efficacité laisse beaucoup à redire. C'est pour cela que Dmarc tente des nouveautés en alliant DKIM avec le système qu'ils tentent de mettre au point; Accoler le phishing avec le spam, ce n'est jamais gagné d'avance dans le discernement .
Il serait intéressant de voir si une éventuelle possibilité de filtrage au départ du mail ne serait pas plus efficace. Par exemple, dès le départ du spam ou phishing, l'adresse IP de l'envoyeur serait aussitôt répertoriée dans une blackliste. Evidemment cela serait inopérant face à une adresse cachée derrière un proxy.
Je serais curieux de connaître le pourcentage de spam passant par une adresse IP légitime et le pourcentage des spams passant derrière un proxy.

[calimo]

Il serait intéressant de voir si une éventuelle possibilité de filtrage au départ du mail ne serait pas plus efficace. Par exemple, dès le départ du spam ou phishing, l'adresse IP de l'envoyeur serait aussitôt répertoriée dans une blackliste. Evidemment cela serait inopérant face à une adresse cachée derrière un proxy.

Tu commences à comprendre. Il est impossible de savoir d'où le spam provient effectivement, et qui l'a envoyé. On peut facilement truquer les entêtes et faire croire que le spam provient d'ailleurs...

Je serais curieux de connaître le pourcentage de spam passant par une adresse IP légitime et le pourcentage des spams passant derrière un proxy.

Tu trouveras peut-être ton bonheur ici : http://spamlinks.net/stats.htm#dnsbls-proxies
Pas mal de ces serveurs sont blacklistés, mais tous les fournisseurs n'utilisent pas les blacklistes...

[Teraoctet]

Bonjour

Tu commences à comprendre. Il est impossible de savoir d'où le spam provient effectivement, et qui l'a envoyé. On peut facilement truquer les entêtes et faire croire que le spam provient d'ailleurs...

Je le savais il y a longtemps

Tu trouveras peut-être ton bonheur ici : http://spamlinks.net/stats.htm#dnsbls-proxies
Pas mal de ces serveurs sont blacklistés, mais tous les fournisseurs n'utilisent pas les blacklistes...

Il est aberrant de constater que beaucoup de fournisseurs n'en tiennent pas compte Ils se gardent bien de pousser des cris d'orfraies
Le silence gardé doit être la règle entre eux. Autre constatation, Les proxy sont plus nombreux chaque jour.

[Teraoctet]

Bonsoir
Nouveaux messages et un lien significatif sur ce qui peut déclencher ou non Dmarc avec les pièces jointes
http://www.iana.org/assignments/media-types/index.html

On 02/25/2012 12:41 PM, Rolf E. wrote:

what was the rationale for choosing zip?
At least one party was already seeing very large reports with the
pre-draft mechanisms that were in place, so it was clear that support
for large files would be necessary from the start. And it wasn't clear
if a report transport mechanism other than email would be up and running
in time for the draft to be published.
ZIP handles compression and multiple files (if needed), and it was ready
to go - it was already a properly registered MIME application type with
IANA. As something that I would always direct to a service mailbox, I
wasn't thinking so much about end-user oriented filtering processes as
being an obstacle - but it is certainly something we should make note of
in the FAQ, at a minimum.

_______________________________________________________________________________________________________________________________________________________
_______________________________________________________________________________________________________________________________________________________

>postfix/cleanup[4221]: C0FF125406C: reject: header Content-Type:
>application/zip;
>??name="google.com!DOMAIN.LTD!1329523200!1329609599.zip" from
>mail-iy0-f201.google.com[209.85.210.201];
>from=<noreply-dmarc-supportdepuisgoogle.com> to=<postmasterdepuisDOMAIN.TLD>
>proto=ESMTP helo=<mail-iy0-f201.google.com>: 5.7.1 message content
>rejected
>
>I realized that I have been rejecting the DMARC reports due to this
>longstanding postfix mime check
>
>~$ cat mime_header_checks
>/name=[^>]*\.(bat|com|exe|dll|vbs)/ REJECT

Perhaps I'm more nearsighted than usual, but the Google reports
are type application/zip and the filename ends with .zip, but I
don't see the string "zip" in that pattern.

There has certainly been plenty of malware sent around in ZIP files
that I can believe that people have ZIP killers in their spam filters,
but that's not one of them.

I've suggested that it would be better to use application/gzip rather
than zip for other reasons, mostly that it's a stream cipher you can
decode without storing it into a file first, but not getting stuck in
spam filters would also be an advantage.

At the moment there's no application/gzip MIME type, but that turns
out to be an oversight from a decade ago. I have the paperwork to add
it grinding through the IETF process and it should be official in a
month or so.
_______________________________________________
dmarc-discuss mailing list
dmarc-discussdepuisdmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)

______________________________________________________________________________________________________________________________________________________
______________________________________________________________________________________________________________________________________________________

Sent: Saturday, February 25, 2012 3:56 PM
> To: dmarc-discussdepuisdmarc.org
> Subject: Re: [dmarc-discuss] DMARC reports from Google
>
> >postfix/cleanup[4221]: C0FF125406C: reject: header Content-Type:
> >application/zip;
> >??name="google.com!DOMAIN.LTD!1329523200!1329609599.zip" from
> >mail-iy0-f201.google.com[209.85.210.201];
> >from=<noreply-dmarc-supportdepuisgoogle.com> to=<postmasterdepuisDOMAIN.TLD>
> >proto=ESMTP helo=<mail-iy0-f201.google.com>: 5.7.1 message content
> >rejected
> >
> >I realized that I have been rejecting the DMARC reports due to this
> >longstanding postfix mime check
> >
> >~$ cat mime_header_checks
> >/name=[^>]*\.(bat|com|exe|dll|vbs)/ REJECT
>
> Perhaps I'm more nearsighted than usual, but the Google reports are
> type application/zip and the filename ends with .zip, but I don't see
> the string "zip" in that pattern.

It doesn't appear, bug "google.com" does, and that's a match.

______________________________________________________________________________________________________________________________________________________
______________________________________________________________________________________________________________________________________________________

>postfix/cleanup[4221]: C0FF125406C: reject: header Content-Type:
>application/zip;
>??name="google.com!DOMAIN.LTD!1329523200!1329609599.zip" from
>mail-iy0-f201.google.com[209.85.210.201];
>from=<noreply-dmarc-supportdepuisgoogle.com> to=<postmasterdepuisDOMAIN.TLD>
>proto=ESMTP helo=<mail-iy0-f201.google.com>: 5.7.1 message content
>rejected
>
>I realized that I have been rejecting the DMARC reports due to this
>longstanding postfix mime check
>
>~$ cat mime_header_checks
>/name=[^>]*\.(bat|com|exe|dll|vbs)/ REJECT
>
>That check has been around, and much advised, for ages. It blocks
>file attachments known to contain common Windows vulnerabilities.
>

With respect to section 12.2.4 of the DMARC specification, if a Mail Receiver (as google.com here) failed to send the report, then an attempt MUST be made to send an Error Report.
I am inquisitive that , as your mail server rejected the reports from google before, can you receive any Error Report from google.com, or your mail server rejects them too?-

______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

2012/2/26 p:
>
> With respect to section 12.2.4 of the DMARC specification, if a Mail
> Receiver (as google.com here) failed to send the report, then an attempt
> MUST be made to send an Error Report.
>
> I am inquisitive that , as your mail server rejected the reports from google
> before, can you receive any Error Report from google.com, or your mail
> server rejects them too?

The report was rejected due to the attachment name containing ".com"
(as in .bat, .dll, .com, etc). No error report was received nor
rejected, normal email from google.com generally passes through quite
nicely.

-J