How do I log tls-encrypted smtp traffic?

I'd like to know what my local postfix says to the Amazon SES smtpd after the STARTTLS. In plain text, so I can understand it. Amazon SES requires TLS, so I can't temporarily turn it off.

I currently log both legs of the traffic with this trick:

mkfifo proxypipe
cat proxypipe | nc -l 11111 | tee -a inflow | nc email-smtp.us-east-1.amazonaws.com smtp | tee -a outflow 1>proxypipe

and then I have postfix talk to localhost:11111 instead of email-smtp.us-east-1.amazonaws.com:25. This produces a nice transcript, as long as they are talking in clear text. As soon as STARTTLS shows up, everything turns gibberish of course.

Is there some trick I can route this through openssl, or post-process using openssl or something like that, to figure out what exactly they said to each other? Googling has not produced any answer.

Don't bother with sniffing the network connection; as @voretaq7 explained, you can't. Instead, have postfix log the connection by adding the IP address of the remote SMTP server to debug_peer_list.

And if that doesn't get you enough detail to understand what's going on, you can set smtp_tls_loglevel 4 to get a complete dump of everything that went over the wire.

Once you're done, be sure to change your configuration back. You don't want to leave debugging on for any longer than absolutely necessary.

Allow me to rephrase your question:

I want to stick something in the middle of an TLS-encrypted connection that shows me the cleartext that's being sent.

. . . Well it wouldn't be very secure now, would it? I mean the whole point of TLS is to prevent exactly what you're trying to do! -- So no, what you're asking for is NOT possible, nor is it anywhere near the level of logging any sane admin would want.
All you want to know is who you connected to (the remote system), what you told them (mail from A to B), and what they said (OK, Deferred, Rejected).

If you really want to eavesdrop on the TLS connection you have to fool your server into connecting to a proxy that presents a fake SSL certificate (for which you have the key), the proxy can then decrypt the data (and log it), and then re-encrypt it to forward along to Amazon's real servers.
You could rig up such a beast with OpenSSL's s_client and s_server subsystems, but implementation of such a beast is left as an exercise for the reader.