Redirection doesn't do what you expect because jmail actually fires up a grid job for processing the email; so the redirection sends output from the job /submission/ not its actual execution.

Right now, jmail uses the fairly common convention that if the mail handler fails for any reason, it generates a bounce with the output. It doesn't seem unreasonable to provide for a parameter to jmail to allow different handling (e.g.: accept the mail quietly and log to a file) but then the sender is left without an indication that whatever it tried to do by sending mail didn't actually happen.

I actually meant the output from the jmail submission -- if job submission fails (e.g. SGE queue out of space), jmail (I assume) sends the error to stderr, and then the mail daemon mails it back. That's the error I'd like to receive -- anything further on can be handled in the shell script jmail invokes.

Ah! Hm. I'll need to consider the right way to do that; that behaviour comes from exim itself. Perhaps an additional level of error checking around the jsub would work.