[Mimedefang] IP Reputation data collection (announcement, Internet draft)

[Kevin A. McGrail]

PREFACE: I've been running the event reporter in our milter 
implementation and using the data stream via DFS' RBLs on one production 
system with nothing but good news so far.  I also trust DFS 
interpretation of RFCs and mail protocols as he is very knowledgeable.

I could nitpick things but overall it's a good system he's designed and 
the paper accurately describes the goal and protocol.

I support this and think a wide-network of reports from systems to 
aggregators would be huge step in blocking spammers.  I can also comment 
that I've seen (and worked with) quite a few systems that are downright 
hodgepodge compared to DFS's implementation of reporting various 
information.

So with that said, here are some comments.


I think adding more events are needed to be considered for the initial 
draft.  There is also the potential need for additional information on a 
report that should be considered.  So not all of these are EVENTS.

For example, these are 7 more items that I think would be invaluable to 
report.  Brainstorming to come up with more to add EVEN if you don't use 
them but to define them in the RFC would be good in my opinion.

1 - including the product / version used for auto-ham/spam and the 
automated score & threshold of a spam

2 - including virii/malware as a note

3 - dangerous attachments and a filename

4 - dangerous content

5 - reverse DNS failures

6 - improper HELO/EHLO statements

7 - invalid MX records


I liked that in in #3 that REPUTATION database is not specific to 
indexing by IPv4 or IPv6.  The system should be extensible to report 
more data such as the email address of the sender or recipient, the 
subject of the email, etc.  In theory, the system could even replace 
Razor so it could include a hash of the email, etc.  But I would likely 
caveatthe first sentence with "index by IPv4 or IPv6 address as oner 
example".

In the same way, #2 Introduction, specifically talks about IP based 
lists.  You might want to broaden that to keep people in a broad mindset.



The use of port 6568 could be expanded to stated something like unless 
the AGGREGATOR utilizes an alternate port or something.  I have other 
listeners on 6568 already, for example.

4.2 would be best organized into 4.2.0 for reserved, 4.2.1 for 
GREYLISTED, etc. so that all event types have a clear report 
restriction.  Then 4.2 should be restrictions for all events like IPv4


Does " a priori knowledge" mean something or is it a grammar/spelling issue?


I would include an extract definition of [GREY] in section 7 in addition 
to the reference.  It's a term that confuses a lot of people that I 
discuss anti-spam with that aren't anti-spam researchers.

regards,
KAM


On 4/30/2010 10:23 AM, David F. Skoll wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> We've been working on an IP reputation system for our commercial product
> for a while now.  I'm soliciting comments on an Internet draft; it explains
> the wire protocol we use to collect data.  I think having a standard
> way to collect reputation data would be a good idea.
>
> Anyway, the Internet draft is available at:
>
>   TXT: http://www.roaringpenguin.com/draft-dskoll-reputation-reporting-00.txt
> HTML: http://www.roaringpenguin.com/draft-dskoll-reputation-reporting-00.html
>
> Working Perl client code can be downloaded from
> http://www.mimedefang.org/download; it's the RPS::Mail::EventReporter module.
>
> We have been collecting IP reputation for several months now.  We have
> about 900 million individual reputation events in our database, and
> we've created for DNSBLs.  We are selling rsync access to the DNSBLs;
> please contact<sales at roaringpenguin.com>  if you are interested.
>
> You can try them out (low-volume, manual lookups only!) at
> http://www.roaringpenguin.com/node/repcheck
>
> Regards,
>
> David.
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iD8DBQFL2ufowYQuKhJvQuARAtDFAJ9d3swbjK8mZvp98t44/YhUf1zQ2QCgiVc/
> OoTLz0iIJ99v+zD9jzVeIvY=
> =Br+7
> -----END PGP SIGNATURE-----
> _______________________________________________
> NOTE: If there is a disclaimer or other legal boilerplate in the above
> message, it is NULL AND VOID.  You may ignore it.
>
> Visit http://www.mimedefang.org and http://www.roaringpenguin.com
> MIMEDefang mailing list MIMEDefang at lists.roaringpenguin.com
> http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mimedefang.org/pipermail/mimedefang_lists.mimedefang.org/attachments/20100430/9c535b3c/attachment.html>