There maybe complications in choosing at the detailed level, so this is at an overview level.

1. Although both Perl and Python have a full range of interprocess communication and multiprocessing routines, Python's approach to threading is to provide a class with methods for managing processes in a way that I question is multi-threading. Reading the Python documentation makes my stomach churn because I feel that as comprehensive as the class looks, the authors don't really know the difference between a thread and a parallel subprocess. Perl documentation and practice make a more understandable distinction between forks and threads that tallies with what was understood by these concepts long before Perl or Python came into existence. In particular, although threads and classes seem at first sight to be incompatible techniques with Python not convincing me that this conceptual clash is even properly understood in Python land -- but Perl gets around this by allowing the programmer to define the code inside the thread in a procedural way while keeping the thread classware well under the hood and out of the way of the programmers multithreaded coding style.

2. For asynchronous (ie non-thread-style) parallel processes, Python has slightly more flexibility in the management of pipes, but broadly the languages are similar in this capacity. Python does provide thread capability but the interface is much harder to use and maintain than Perl's. BUT when using library modules, they have to be thread-safe in Perl, whereas although much more difficult to use, at least Python has no such limitation.

3. Both have message queue capabilities - But Perl's IPC::Msg module provides access to unix message queues more readily (IMO) than Python.

4. Both Perl and Python have about similar access to sendmail, but Perl's library has additional capabilities, most notably in the CGI module for example for accessing sendmail from within a webserver script.