Very cool You may want to ship them in gzip format now.
For failure reports (aka forensic). I suggest you put this feature to add an email address where all the failure reports will be sent to (regardless of the ruf, or if you want to send failure reports). This allows a mail admin to know all the incoming email to his/her infrastructure that fail DMARC. This is invaluable for debugging and finding emails that do not comply with your DMARC policy (if you publish one). There is an interoperability test suite at https://dmarcian.com/interop_qa/ You may want to try it too. On Jun 24, 2013, at 8:14 AM, Roman Prokhorov <r...@stalker.com> wrote: > Hello, > > I finally had implemented DMARC plugin for CommuniGate Pro mail server. It > verifies incoming messages and sends aggregate reports in ZIP. The > implementation is based on pure Perl and files without using external > database engines. > > As a test you can email to rep...@test.mobileoffice.biz and it will send you > back aggregate reports (no per-message forensic reports yet). I had checked > them against script from http://www.taugh.com/rddmarc/ so I believe they're > being composed correctly. > > Will share the sources a few days later after I polish up everything... > > On 08.05.2013 8:14, Matt Simerson wrote: >> On May 7, 2013, at 7:55 PM, Roman Prokhorov <r...@stalker.com> >> wrote: >> >>> On 08.05.2013 4:36, Matt Simerson wrote: >>> >>>> We are both running DMARC in production but neither Davide's nor >>>> my modules have the reporting elements completed. I'm writing the >>>> report aggregation functions right now. >>> >>> I'm planning to write my own; it won't require an external >>> database. >> >> I gave serious thought to implementing my report store with AnyDBM. >> I could serialize my $dmarc->result object during each connection and >> store the serialized data in whatever DBM backing perl has >> available. >> >> But, I'd need a spool directory configured. And each report row would >> take up more storage than in a RDBMS. Since there will be multiple >> processes storing reports, and another that handles the aggregate >> reporting, there are concurrency issues, which a RDBMS handles with >> aplomb. >> >> With SQL, I also gain foreign key constraints, so invalid data can't >> make its way into the DB, causing XML validation errors hours later. >> I'm targeting MySQL and Sqlite but my implementation should work on >> any RDBMS that has a DBI plugin and supports foreign keys. If someone >> were horrified at using MySQL or Sqlite, it would be fairly trivial >> to remove the foreign key constraints and use DBD::DBM instead. >> >> Matt >> > > > -- > Roman > _______________________________________________ > dmarc-discuss mailing list > dmarc-discuss@dmarc.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) _______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.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)
