There are lots of known cryptographic weaknesses in MD5 which make it unusable as a message digest algorithm, but not all of these also apply in the context of password hashing. But even when we assume that these do not exist, MD5 is still a bad password hashing algorithm for one simple reason: It's too fast.
In any scenario where an attacker obtained the hashed passwords, you have to assume that they also obtained the salt of each password and the pepper.
The only reason to use a pepper is so you can't use a rainbow table precomputed before the attack, because you need a different one for each database. The only reason to use a salt is so you can't use the same rainbow table for the whole password database, because the same password for two different accounts will have a different hash.
The length of pepper and salt don't matter that much. Their only purpose is to make sure that each value is unique. More length doesn't make the attack notably harder (there is more data to hash, but that's a linear increase at most).
Bottom line is, a short salt is all that is needed to make sure that the attacker has to brute-force all possible passwords to find the correct hash for every single account.
And that's where MD5's weakness comes into play: It's a fast and memory-conserving algorithm. That means an attacker can compute the hash of a large number of passwords per second. Using specialized hardware (like FPGA arrays or ASICs) worth a few thousand dollar you can compute the hashes of all possible 8-character passwords for a given salt in mere hours.
For better security, use a slow algorithm like bcrypt. It means that your system needs some more CPU cycles to authenticate users, but the payoff is usually worth it because an attacker will also need a whole lot more processing power to brute-force your password database should they obtain it.