German lawful interception measures...any hints?

[wyrdforge]

Hello,

we are using roundcube for quite a while now in a city carrier setting, so we are (unfortunately) forced to implement lawful interception measures for webmail services
(v1.1.4 for now, but plan to switch to latest stable around jan/feb next year with a new custoemr frontend) .

Up to now, there has never been a problem, but it seems, the German BNetzA defined some stricter filtering and interception rules:

1. We have to inject the x-originating-ip into the imap stream AFTER login. The dovecot_ident plugin does this, but before logging in.
In theory, it would suffice to send A0002 NOOP <client ip> or A0002_<client ip> as soon as possbile after logging in.

2. If a customer logs into Roundcube, the inbox is listed via header FETCH request for every email (hope I'm right with this). Not included in the response is the message ids.
These are only available in the 2nd and 3rd FETCH request (when a mail is selected for preview). Because of the interception guidelines, the message id must always be present
in the first FETCH for being triggered. It is not possible to drop the first packet from the tcp stream.

Does anyone know, if this was even possible without a major rewrite of the core system? As it is planned to implement several ISO certifactions for our company, we would have a time intensive
development, documentation and change/release cycle for every small security fix, when patching the core system with custom code.


Regards

Marcel

[alec]

1. So, an imap command as soon as possible after authentication? I don't see that possible. However, we could consider extending storage_connected hook with 'conn' property. That would allow executing any rcube_imap_generic method from the plugin. You could use existing id() method, or create a new one for NOOP. I'd accept such pull request to the core.

2. See show_additional_headers plugin's storage_init() method for how to add a header that should be always fetched. PS. that header is also always fetched when messages_cache is in use, but then the FETCH might be skipped (if all messages are in cache)

[wyrdforge]

Thanks for your input, this really helps a lot

1. Regarding the x-originating-ip I got a response from our interception service providers just some minutes ago.
Against expectation ( at least from their point of view ), it conforms to BNA guidelines and is possible in their implementation to trigger on this, if the IP is sent in the imap ident request, as we do now by the roundcube_ident plugin. I think, this resolves injecting "dummy requests" into the stream.

2. I will gladly try to implement it this way and check back with our partners for conformity. I will definitely report back, after we found a working solution, but I assume it may take 2 to 3 weeks until I get the test results.