I believe that it would be the bridge pattern.

The rationale behind the letter/envelope idiom is to allow multiple implementations of an abstract datatype (either over time or in different application domains), but with no change in the client code. This is achieved in C++ by using an abstract base class from which are derived the both the interface (envelope) class, and the implementation (letter) classes. Calls to envelope methods are delegated to the corresponding letter methods.

An example: Suppose you were doing experiments which produced noisy data, and that you wanted to smooth this data to make long-range trends more apparent. However, you might not be sure which smoothing algorithm would work best, and further you would probably want to refine your chosen algorithm over time for greater efficiency. Using the bridge pattern:

public interface Smoothable {
 public double[] smooth (double[] data);
}

public class Envelope {
 private Smoothable impl;
 public Envelope (Smoothable impl) {
  this.impl=impl;
 }
 public double[] smooth(double[] data) {
   return impl.smooth(data);
 }
}

public class Letter implements Smoothable {
 public double[] smooth(double[] data) {
  //do something
  return smoothedData;
 }
}

Actually, the Smoothable interface does not need to be visible to the client, and the signature of the smooth method can be very different in the envelope and letter classes. The bridge pattern allows the client to use the smoothing classes without worrying about changes in the underlying implementation.

Finally, a disclaimer: I don't have Coplien's C++ book, which appears to be the definitive source on the letter/envelope idiom, so my answer may somewhat off the mark.