How does that work with encrypted transport? Yahoo, Microsoft, Google and of course many others, all provide IMAP over TLS so sending email to them and receiving from them doesn't go in the clear.
My personal belief is that they dont. Best they could achieve is trapping the ISP's sending mail server in Norway before the mail is encrypted but there is no capability to decrypt SSL without obtaining the keys.
They could still store metadata like sending IP address, timestamp etc.
Using foreign webmail via HTTPS would not be intercepted in any possible way. Unless they get support from the service provider in question. I think the service providers you mention will comply with law enforcement and give out your data. But those are isolated cases and mass data required by intelligence services is a different thing. National security letters are only for US Govt use and other governments have no access.
I also think legislation like this is years late now that about every protocol has encrypted variants and they don't get any meaningful results compared to the money spent.
In the majority of cases, TLS for SMTP (delivery between MTAs) is still trivially downgradeable. So they could presumably downgrade and read SMTP traffic that's going between MTAs in Norway and MTAs outside Norway.
Of course, as long as you're one of the parties involved in the SMTP communication.
The problem is that even though you're trivially able to detect that TLS is not in use, the vast majority of mail providers won't act on that knowledge by refusing to send mail unencrypted (except maybe for some hosts explicitly whitelisted for that approach).
Why? Too many broken TLS setups, historically. Might be better now, I vaguely remember some push towards that from the big providers.
From one party's perspective, it may just look like the other party does not support TLS. Without another point of reference, MTAs can't tell the difference between a lack of TLS support and a downgrade attack.
Alternatively, the government could also conduct a TLS certificate man-in-the-middle, which would work in most cases since almost no MTAs validate certificates outside of occasionally trying DANE (a spec for pinning certs over DNSSEC).
Even the data is encrypted is worth to save for the future. They will be able to access when they have the key or when some quantum computing breaks it.
There are currently no publicly trusted CAs participating in such a scheme. If there were, it'd be trivially detectable due to the millions of fraudulent certificates showing up in Certificate Transparency logs.
They _have_ to tell you, there's no alternative option. If they don't publish the certs in multiple logs, then they aren't considered valid by browsers.