I like to think that any problem can be solved, and view this as an interesting intellectual challenge.
From a communications standpoint, your colleague might have picked up on your vibe of “not my problem” and “you need to explain what you want”. This already sets up a slightly adversarial framework for discussion, kind of contradicting your colleague’s assumptions (“it is your problem”, and “I already explained what you need to do”).
I don’t know how best to address the issue of “not my problem”, so I’ll ignore that part. As for the flow part, wouldn’t it be possible to define the high-level business-process flow as:
- Customers use feature A (email).
- The feature does not work.
- Engineers address the problem.
Then, the “broken logic for sending email” falls under point 1 (or possibly a preceding point 0, the engineering processes used to develop that feature). The lack of logs falls under point 2 (how the system behaves when it fails). The lack of process for emergencies falls under point 3 (how the organization responds to problems). This analysis also separates concerns based by role: the role of the end-user sending the email, and the role of the corporate engineering team that needs to investigate the problem.
Making a simple flow diagram within the parameters that were suggested by your colleague might have helped your colleague feel that you were cooperating with instead of contradicting him.
I’ve dealt with problematic, and sometimes downright rude and condescending, customers before, and the one thing that seems to set them off is if you try to contradict them. That means sometimes you have to bend over backwards to conceive of some possible alternate universe in which their ideas could make sense, make positive overtures to show acceptance of their ideas, then gently try to guide them back onto a more reasonable path.