The general situation looks like this:
A signature relies on some certificates, that assert the ownership of public keys. Certificates are primarily designed to be validated now (e.g. the certificate's date of validities are compared with the current date).
These objects tend to degrade over time. CRL expire (usually rather fast). Certificates expire; when a certificate has expired, it ceases to be included in CRL, so even if you can download a new CRL, you won't be able to know whether the now-expired certificate was still unrevoked at expiration time. Possibly, a CA may go out of business. And, as you note, involved cryptographic algorithms may also become deprecated.
The really important point is that when you want to verify a signature, you want to know whether the signature was valid at the time it was produced. Suppose, for instance, that somebody sent you a signed email (with S/MIME) on November 12th. Three weeks later (early December), the sender's computer is compromised and his key stolen; he dutifully contacts his CA, and the CA revokes his certificate. Does that mean that his signature ceases to be valid ? We certainly hope not !
When you sign, you really are building a legal weapon pointed at you. In the example above, if Bob sends you a signed email, then you want to keep it in order to sue Bob if he wants to default on his responsibilities described in the email. It would be too easy if Bob could escape your legal retaliation by simply losing his private key !
However, once Bob's certificate has been revoked, it can no longer be validated in the X.509 sense. What that implies is that S/MIME signature validation is transient. It works for some time, then ceases to work.
To really support long-term archival of signed object, you need to freeze things in time. The tool for that is a time stamp.
Suppose that Bob signs the email on November 12th, 2014. Two days later, you open your mailbox and you verify the signature; at that point, Bob's certificate is still valid and unrevoked, and you can obtain a set of CA certificates and CRL that demonstrate (within the X.509 model) that, on November 14th, Bob had really signed the email. Then you take the email, CA certificates and CRL, put all of these in a big bag (e.g. some archive format), and then obtain a time stamp from some time stamping authority. The time stamp is, basically, a short document containing both the time stamping date (November 14th) and the hash of the time stamped data (a hash of the Zip file containing the email, its signature, the extra CA certificate and CRL); and the time stamp is signed by the time stamping authority.
Then fast forward to December 11th. At that time, Bob's certificate is revoked, because he claimed to have been robbed of his private key on December 3rd. You want to revalidate the signature. To do that, you verify the signature on the time stamp; if it is correct, then it is a proof that the archive contents already existed "as is" on November 14th. So you can then validate the S/MIME signature, using the objects from the archive, as if the current date was still November 14th. At that date, no certificate was revoked, archived CRL were not expired, SHA-1 was still trustworthy, so everything is fine.
A time stamp is thus a time-travelling machine. The time stamp demonstrates that a set of objects existed at some date T; so it allows you to run any validation algorithm using these objects (and only them) as if the current date was T.
Now the problem becomes: how to organize that time stamping process ? In particular, the time stamp is itself a signature, that is verified at the current date (it is because the time stamp is valid now that you can then jump back to date T when using the archived objects). That signature, with standard time stamps, also uses X.509 certificates and is subject to the same kind of degradation. So what you really need is to chain time stamps: whenever the top time stamp is getting close to cessation of verifiability (typically the expiration date of the TSA certificate), freeze it with another time stamp. And so on.
Theoretically, there are standards for that. S/MIME relies on CMS, an extensible format for encrypted and signed objects. Among defined extensions for CMS are the CAdES attributes; when you get all of them, you have a CAdES-A object, which is basically the archive-with-chain-of-time-stamps that I was talking about.
(However, I strongly doubt that you will find any S/MIME-aware tool that also knows how to process CAdES attributes.)
The same concept is also applied for XML documents (and the XAdES standard), and for PDF (with PAdES). Recent versions of Adobe Acrobat support PAdES.