<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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.
<br>
<br>
I could nitpick things but overall it's a good system he's designed and
the paper accurately describes the goal and protocol. <br>
<br>
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.<br>
<br>
So with that said, here are some comments.<br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
1 - including the product / version used for auto-ham/spam and the
automated score & threshold of a spam<br>
<br>
2 - including virii/malware as a note<br>
<br>
3 - dangerous attachments and a filename<br>
<br>
4 - dangerous content<br>
<br>
5 - reverse DNS failures<br>
<br>
6 - improper HELO/EHLO statements<font color="#000000"><br>
<br>
7 - invalid MX records<br>
<br>
<br>
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".<br>
<br>
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.<br>
<br>
<br>
<br>
</font>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.<br>
<br>
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<br>
<br>
<br>
Does " a priori knowledge" mean something or is it a grammar/spelling
issue?<br>
<br>
<br>
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.<br>
<br>
regards,<br>
KAM<br>
<br>
<br>
On 4/30/2010 10:23 AM, David F. Skoll wrote:
<blockquote cite="mid:4BDAE7E8.2080204@roaringpenguin.com" type="cite">
<pre wrap="">-----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: <a class="moz-txt-link-freetext" href="http://www.roaringpenguin.com/draft-dskoll-reputation-reporting-00.txt">http://www.roaringpenguin.com/draft-dskoll-reputation-reporting-00.txt</a>
HTML: <a class="moz-txt-link-freetext" href="http://www.roaringpenguin.com/draft-dskoll-reputation-reporting-00.html">http://www.roaringpenguin.com/draft-dskoll-reputation-reporting-00.html</a>
Working Perl client code can be downloaded from
<a class="moz-txt-link-freetext" href="http://www.mimedefang.org/download">http://www.mimedefang.org/download</a>; 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 <a class="moz-txt-link-rfc2396E" href="mailto:sales@roaringpenguin.com"><sales@roaringpenguin.com></a> if you are interested.
You can try them out (low-volume, manual lookups only!) at
<a class="moz-txt-link-freetext" href="http://www.roaringpenguin.com/node/repcheck">http://www.roaringpenguin.com/node/repcheck</a>
Regards,
David.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - <a class="moz-txt-link-freetext" href="http://enigmail.mozdev.org/">http://enigmail.mozdev.org/</a>
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 <a class="moz-txt-link-freetext" href="http://www.mimedefang.org">http://www.mimedefang.org</a> and <a class="moz-txt-link-freetext" href="http://www.roaringpenguin.com">http://www.roaringpenguin.com</a>
MIMEDefang mailing list <a class="moz-txt-link-abbreviated" href="mailto:MIMEDefang@lists.roaringpenguin.com">MIMEDefang@lists.roaringpenguin.com</a>
<a class="moz-txt-link-freetext" href="http://lists.roaringpenguin.com/mailman/listinfo/mimedefang">http://lists.roaringpenguin.com/mailman/listinfo/mimedefang</a>
</pre>
</blockquote>
<br>
</body>
</html>