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<[email protected]> 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 [email protected]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
_______________________________________________
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 [email protected]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
