Many people create Maven dependencies like this:
This means that they allow Maven to automatically update their dependencies.
The meaning of the brackets such as [ and ) is explained in the answers to this StackOverflow question: How do I tell Maven to use the latest version of a dependency? That page is riddled with cautions about always using the latest version for your dependencies. It reduces reproducibility of your builds. If you have a Maven problem that refers to iText, you should fix your Maven scripts.
2.1.7 (July 2009) was the last version of iText released by the company iText Group NV (or its legal predecessor), with the com.lowagie groupId. The next version of iText, released by the company iText Group NV, was version 5.0.0, with the com.itextpdf groupId, which means it's binary incompatible with your current code. There's also the matter of some technical and legal issues with iText 2.1.7 and earlier versions and there is the license change to AGPL to take into account.
Any other versions of iText between 2.1.7 and 5.0.0, like 4.2.0 and 4.2.1, are forks by other companies. According to Apache's Guide to uploading artifacts to the Central Repository, those companies should have used a different groupId, as the Apache FAQ clearly states:
I have a patched version of the foo project developed at foo.com, what groupId should I use? When you patch / modify a third party project, that patched version becomes your project and therefore should be distributed under a groupId you control as any project you would have developed, never under com.foo. See above considerations about groupId.
The situation created by the companies that "hijacked" the com.lowagie groupId created a problem where you could inadvertently introduce software that the infringes the copyright or trademarks of third parties (or worse) into your project. To stop this, iText has regained control over com.lowagie and we have made sure that this no longer happens.
If you decide to stick with an old version of iText, you can do so at your own risk. For instance, you can change your Maven dependency like this:
This will fix your builds. Obviously, this doesn't fix the technical and legal issues that have been fixed since 2009, but it solves the immediate problem of your broken build.