GitLab

The schleuder command does not give any machine-readable hints as to the nature of the error encountered when processing e-mail. It always exists with exit code 1, and human readable error messages are not usable in order to automatically handle different kinds of errors differently.

Consider the following log. These are three completely different kinds of errors.

1. An internal error related to a -request message not being properly authenticated (with the error message sent correctly to the list admin):

root@30e6caa2a707:/var/schlocker/mail/.tmp/test# cat 1532175290_0.1.0c6aa2ce0ea3\,U\=167\,FMD5\=7e33429f656f1e6e9d79b29c3f82c57e\:2\, | schleuder work 'test-request@occrp.org'
Error: Schleuder::Errors::MessageUnauthenticated

Kind regards,
Your Schleuder system.
root@30e6caa2a707:/var/schlocker/mail/.tmp/test# echo $?
1

2. An error caused by the SMTP server disappearing:

root@30e6caa2a707:/var/schlocker/mail/.tmp/test# cat 1532175290_0.1.0c6aa2ce0ea3\,U\=167\,FMD5\=7e33429f656f1e6e9d79b29c3f82c57e\:2\, | schleuder work 'test@occrp.org'
Error: A serious, unhandleable error happened. Please contact the administrators of this system or service and provide them with the following information:

getaddrinfo: Temporary failure in name resolution
root@30e6caa2a707:/var/schlocker/mail/.tmp/test# echo $?
1

3. An error caused by a misconfiguration of the SMTP server:

root@30e6caa2a707:/var/schlocker/mail/.tmp/test# cat 1532175290_0.1.0c6aa2ce0ea3\,U\=167\,FMD5\=7e33429f656f1e6e9d79b29c3f82c57e\:2\, | schleuder work 'test@occrp.org'
Error: A serious, unhandleable error happened. Please contact the administrators of this system or service and provide them with the following information:

550 Invalid recipient
root@30e6caa2a707:/var/schlocker/mail/.tmp/test# echo $?
1

These situations need to be handled differently. It would be okay to kill the message from case 1., since the admins have been notified successfully; but it would not be okay to delete the messages from 2. and 3., since this might be a temporary failure and we don't want valid e-mail to be lost.

Currently there seems to be no way to differentiate between these cases, which means either e-mail will get deleted (and lost) regardless of the kind of issue encountered, or it will remain in the queue to be handled again and again (with errors about old erroneous messages being sent and resent constantly to admins).

One simple solution would be to have different exit codes for different errors/error classes (with some documentation to boot).