If you start from the premise of not accepting an answer like "no, not under any circumstances", then the request certainly seems like the logical escalation.
Hence the need to develop systems for which the first "no" is the only "no": "no, we don't have the client-side encryption keys, and there's no way for us to give them to you, nor is there any way for you to surreptitiously insert them into the Open Source client software without being noticed, nor are we obligated to accept your patches introducing security holes which will effectively destroy our entire business/project credibility".
It needs to be more difficult to use your project as a tool for surveillance than it is to personally compromise a specific end-user system.
(That's not to say we shouldn't pursue legislative solutions eliminating the requests in the first place: we need to fight surveillance capabilities on both fronts, legal and technical.)
I spent two years working on a secure, web-based email provider. In order to actually make it secure, you have to abandon all aspects of usability. In order to use it, you have to have native client-side code (javascript is not secure). The user has to be responsible for her key, and if she loses it (or forgets the password, if using generating keys from passwords), her email is gone. Before the user can send a message to somebody else, the other person has to install and configure everything so keys can be swapped. All of this, and you get paid squat because email is seen as a "free" service.
And, to really make it secure, you need to go outside of the smtp world, because all smtp has some amount of meta-data that gets transmitted in the envelope. And that meta-data can be just as damning as the contents of the messages.
I don't expect there to really ever be a truly secure email service, unfortunately.
Hence the need to develop systems for which the first "no" is the only "no": "no, we don't have the client-side encryption keys, and there's no way for us to give them to you, nor is there any way for you to surreptitiously insert them into the Open Source client software without being noticed, nor are we obligated to accept your patches introducing security holes which will effectively destroy our entire business/project credibility".
It needs to be more difficult to use your project as a tool for surveillance than it is to personally compromise a specific end-user system.
(That's not to say we shouldn't pursue legislative solutions eliminating the requests in the first place: we need to fight surveillance capabilities on both fronts, legal and technical.)