Skip messages with bad email addresses about mailmerge HOT 5 OPEN

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".

from mailmerge.

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.

from mailmerge.

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

from mailmerge.

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...

from mailmerge.

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.

from mailmerge.