2called-chaos / bouncefetch

Bouncefetch is a Ruby CLI application which searches an IMAP account for bounce mails, categorizes them and maintains a list of failed recipients which you can export to do whatever you want (unsubscribe, require reconfirmation, etc.).
MIT License
10 stars 1 forks source link

Bouncefetch version 0.1.6 MIT License have faith! weather sunny

"bounces should be read by humans" – we don't think so!

Bouncefetch is a Ruby CLI application which searches an IMAP account for bounce mails, categorizes them and maintains a list of failed recipients which you can export to do whatever you want (unsubscribe, require reconfirmation, etc.).

screenshot

Features

Requirements

Installation

Choose and cd into the directory where you want to install Bouncefetch and clone the project:

cd /opt
git clone https://github.com/2called-chaos/bouncefetch.git
cd bouncefetch

Copy the sample configuration and edit it to your needs (see Configuration):

cp config/config.rb.example config/config.rb
vim config/config.rb

If you want to define custom rules (and you want, sooner or later) do the same with the example rule file. It just contains comments so you don't have to bother with it for now.

cp config/custom_rules.rb.example config/custom_rules.rb

Install dependencies:

bundle install

Optionally: Make the executable available in your $PATH by either

Usage

Usage: bouncefetch [options]

# General settings
-d, --dryrun                     Don't alter IMAP account or registry
-m, --monochrome                 Don't colorize output
-t, --throttle-ignore            Disable IMAP throttle detection
-i, --inspect                    Open pry shell for every mail which is unidentifyable, unmatched or has
                                 no matching crosscheck. Use --shell beforehand to get more help on pry.
--config NAME                    Use a different config file (default: config)

# Registry & Export
-s, --statistics                 show statistics about the registry and candidates
-c, --candidates                 list unsubscribe candidates (use export to get csv)
-e, --export FILE                export unsubscribe candidates to file and remove them from the registry
                                 use with --dryrun to not alter registry (same for --remote)
-r, --remote RESOURCE            post unsubscribe candidates to URL and remove them from the registry
                                 refer to the readme for information about how we post the data
-o, --output col1,col2           columns to include for --candidates --export --remote
                                 default: ref,sbounces,hbounces,sbounces_dates,hbounces_dates,sbounces_reasons,hbounces_reasons

# Miscellaneous
-h, --help                       Shows this help
-v, --version                    Shows version and other info
-z                               Do not check for updates on GitHub (with -v/--version)
    --upgrade                    Update bouncefetch (only works with git)
    --mailboxes                  List all availables mailboxes in your IMAP account
    --shell                      Open pry shell

Configuration

config.rb » identification_header

When a mail bounces you typically get a copy of the original mail you've send. To identify the user it is best to add a custom header to all mails you send out. If your users have the ability to change their email addresses it would be a good idea to set this header to the user database id or some kind of token.

If you can't or don't want to use this you can leave it blank and bouncefetch will try to determine it by other means.

Defining rules

Rules are pretty easy to define. You should add them to custom_rules.rb so that you are able to update the shipped default set rules.rb without hassle. You still may want to take a look inside for examples.

There are 3 different possibilities to define a rule:

You can also pass an second argument crosscheck which defaults to true and can be set to false. When set to false and the mail matches this rule it does not require a matching crosscheck.

rule("foo", false)
rule("blub", false) {|m| "…" }

What happens with unhandled emails?

If you'd run bouncefetch and then take a look into your IMAP account you might find:

Best strategy is to run bouncefetch once normally and then with -i resp. --inspect. This will open up an interactive pry session which let you easily investigate and test new rules.

Export

You can export the candidates to a CSV file to further process the data. Only candidates which have reached your configured limits will be exported.

bouncefetch -e candidates.csv

After successfully writing the CSV to disk the exported candidates will be removed from the internal database. If you don't want this use -d resp. --dryrun.

bouncefetch -de candidates.csv

By default all columns will be exported which are:

You can specify which columns should be exported by passing -o resp. --output argument (note the shortened names):

bouncefetch -e candidates.csv -o ref,sbounces,hbounces,sbounces_dates,hbounces_dates,sbounces_reasons,hbounces_reasons

Remote export

Remote export functions like the normal CSV export (same behaviour/options) but POSTs the data as array to a remote HTTP(S) endpoint.

Bouncefetch POSTs a JSON string on query key candidates "candidates" => "JSON encoded string"

This is an example of the parsed JSON:

> JSON.parse(params[:candidates])
=> "foo@example.com" => {
     "reference" => "foo@example.com",
     "soft_bounces" => 0,
     "hard_bounces" => 1,
     "soft_bounce_dates" => [],
     "hard_bounce_dates" => ["2014-06-03"],
     "soft_bounce_reasons" => [],
     "hard_bounce_reasons" => ["account is disabled"]
   },
   "bar@example.com" => {
     "reference" => "bar@example.com",
     "soft_bounces" => 0,
     "hard_bounces" => 1,
     "soft_bounce_dates" => [],
     "hard_bounce_dates" => ["2014-06-04"],
     "soft_bounce_reasons" => [],
     "hard_bounce_reasons" => ["unrouteable address"]
   }

Todo

Contributing

I started this project to create a comprehensive ruleset to classify bounces so please contribute! You can contribute by giving feedback, propose rules or report issues.

If you want to contribute code directly:

  1. Fork it (click to fork)
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Commit your changes (git commit -am 'Add some feature')
  4. Push to the branch (git push origin my-new-feature)
  5. Create new Pull Request

License

Copyright © 2014 Sven Pachnit (sven@bmonkeys.net).
Released under the MIT License, see LICENSE.txt for details.

More from bmonkeys