Skip messages with bad email addresses

[AeonJJohnson]

I just started with mailmerge, fits the job perfectly. One issue I have noticed is mailmerge encountering an email address that the sendmail client function, or the server, rejects. People move jobs or email accounts get deleted from time to time.

Instead of the mailmerge failing out on a bad address, is there a method to log the failures to an error file and keep going through the csv database? Doing a manual resume and specifying the next record on the command-line can be an issue if the job is running in a window you're not monitoring in real-time.

Thanks!

[awdeorio]

Thanks for the input, @AeonJJohnson , this is a great idea. Perhaps the default should be to continue on an error due to a bad email address. Then we could add a flag like --stop-on-error.

I'm not sure what exact exception is thrown in the situations you're describing. Would you be able to add a detailed list to this issue? I think that mailmerge should fail on catastrophic errors like a bad SMTP password, while it should log and continue on errors like "SMTP server doesn't like email address X".

[philpagel]

I would find it most useful if mailmerge didn't just log the failed attempts but (optionally) created an output file that contains the rows of the original input csv file which failed. Possibly adding an extra column that contains the error message.
That way I could easily check the failed email addresses, correct them and run mailmerge again on the edited file. Alternatively, it could output the full input database with the error message column added and I would filter that myself before processing the failed items.
Maybe this behavior could be triggered by a flag --dump-failed or something similar. The filename would be something like mailmerge_fails.csv by default and could be changed via --faildb.

[awdeorio]

WDYT about including a unique log message in #9 so that you could grep the most recent log for failed messages?

[philpagel]

So the workflow would be

1. grep "sending failed" mailmerge.log > failed.txt
2. Open the database in a spreadsheet or editor
3. less failed.txt
4. Go through database by fail-log; edit as appropriate and introduce an indicator column so I can filter the re-send worthy rows
5. Save the parts of the database that I want to send after my edit
6. run mailmerge on that.

I guess it would work but to my personal taste (i.e. lazy) it feels more convenient to directly dive into the output file and start checking/correcting my bad email addresses without having to navigate to them one by one based on the grep output or putting together some shell magic to re-run mailmerge on just those lines, again. That's why I like the idea of an indicator column I can quickly filter by for editing and export.

Of course, if you feel that shouldn't be handled inside mailmerge itself, that could be done by an external helper script, too...

[awdeorio]

You make a good point that this could get complicated. Now that I think about it, your suggestion of writing a CSV with failed rows makes sense. Perhaps this should simply be the default behavior. A user could always simply ignore the fail log.