techsneeze/dmarcts-report-parser

Feature: support for other DBI connections

fluffy-critter opened this issue · 5 comments

I run a personal mail server that only occasionally gets spoofed by spammers. I can see no reason to need to go through the admin overhead of running MySQL just to process like 10 records a day (max), and would like to use SQLite instead. Any chance the script could be modified to take an arbitrary DBI connection string instead of being hardcoded to MySQL?

This would also let people in the Postgres camp continue to use Postgres.

It is certainly an interesting idea. Most people already have MySQL running for a dozen other things, so it hasn't been requested before. That being said, I'd probably hope for someone to provide a pull request with the feature, as it isn't going to be a priority to work on.

Yeah I've been stubborn about not installing MySQL because I feel like it's usually overkill for things, and backing up an SQLite database is a lot easier. :) Glad to hear you're open to the possibility, though. It seems like it should be pretty straightforward to do, and I'll consider being the one who does it.

Also remember that your MySQL server doesn't have to be local to the mail server. The original inspiration of this was rddmarc that assumed the files were local (accessed the raw maildir) but I knew I couldn't do that. Our email was in a proprietary format/server. I figured IMAP would be a way to transcend formats and different server infrastructures, while allowing remote polling for processing. So, as long as you have a MySQL server "somewhere" in the world, you can host the DB there. This is what I do. All the parsing AND DB are in a totally separate environment from production. Originally, it was my personal workstation, until other people wanted to start seeing the info as well! :)

Yeah, I recognize that; my stubornness is such that I don't have any mysql server anywhere. :)

I might actually go back to the original scripts and set it up as a procmail filter, since that seems better for my use case.

SQLite support probably would be better if it were in a procmail filter, since you don't have to worry about a report coming in and being parsed while the database server is shut down for an update.

In my own case, I use Maildir on my server, and at 4am local time every morning I move everything in the DMARC report inbox to a separate directory (outside the Maildir structure) before running the parser on that directory. I feel pretty sure I'm not going to be up at that time of night running an OS update on my personal VPS :-)