"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.).
gem install bundler
)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
/opt/bouncefetch/bin
(or whatever you have choosen) to your path (recommended)ln -s /opt/bouncefetch/bin/bouncefetch /usr/local/bin/bouncefetch
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
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.
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| "…" }
If you'd run bouncefetch and then take a look into your IMAP account you might find:
leave
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.
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 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"]
}
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:
git checkout -b my-new-feature
)git commit -am 'Add some feature'
)git push origin my-new-feature
)Copyright © 2014 Sven Pachnit (sven@bmonkeys.net).
Released under the MIT License, see LICENSE.txt for details.