In a nutshell
The e-mailed PDF is based on the uploaded PDF. The change is that the original document (the uploaded PDF) contains two annotations which in the changed document (the e-mailed PDF) have been flattened, i.e. stored in the page content instead.
Unfortunately the software doing that flattening simply appended commands for showing the annotation appearances to the page content ignoring the fact that the transformation matrix has been changed (rotated) in the already existing page content. Thus, the signatures are rotated, too, after form flattening.
Thus, the software doing this form flattening has to be repaired (simply appending to the content without considering that the transformation matrix might have been changed actually is a no-go!).
As a short term solution, though, (in case the software doing the flattening cannot be easily replaced) you might consider using base PDFs which do not use rotation for creating landscape PDFs.
In case of documents created with iText(Sharp) (which you mention in your question) this might mean using
new Document(new Rectangle(792, 612));
(cf the iText(Sharp) sample HelloWorldLandscape2.java / HelloWorldLandscape2.cs)
instead of
new Document(PageSize.LETTER.Rotate()));
(cf. the iText(Sharp) sample HelloWorldLandscape1.java / HelloWorldLandscape1.cs)
As explained in iText in Action — 2nd Edition,
there are subtle differences internally [which] will matter when you want to manipulate the PDF.
In detail
In the original PDF, the page dictionary references the signatures by means of annotations
3 0 obj
<<
/Type/Page
/Parent 2 0 R
/MediaBox[ 0 0 612 792]
/Rotate 270
/Contents 5 0 R
/Resources<</Font<</F1 4 0 R>>/ProcSet[/PDF/Text]>>
/Annots 11 0 R
>>
endobj
11 0 obj
[ 12 0 R 15 0 R 16 0 R 19 0 R]
endobj
Objects 12 and 16 are the ink annotations referencing appearance streams in objects 14 and 18 respectively.
The content stream in object 5 sets
0.0000 -1.0000 1.0000 0.0000 0.0000 0.0000 cm
As you see, the page is rotated (/Rotate 270) and the content stream is rotated the other direction (0 -1 1 0 0 0 cm) to enable upright printing. The annotation appearance streams, though, are not subject to this back-rotation and, therefore, do that internally themselves.
In the flattened page it looks like this
3 0 obj
<<
/Type/Page
/Parent 2 0 R
/MediaBox[ 0 0 612 792]
/Rotate 270
/Resources
<<
/Font<</F1 4 0 R>>
/ProcSet[/PDF/Text]
/XObject<</CprRpt2 14 0 R/CprRpt3 18 0 R>>
>>
/Annots 11 0 R
/Contents[ 5 0 R 20 0 R]>>
endobj
11 0 obj
[]
endobj
And the content stream in object 20 contains
q 1 0 0 1 223.453 24.0703 cm /CprRpt2 Do Q
q 1 0 0 1 410.246 59.9062 cm /CprRpt3 Do Q
So, the annotations are removed (empty array in object 11) but the appearance streams of the Ink annotations are now directly included in the content stream itself (/CprRpt2 Do and /CprRpt3 Do defined to reference objects 14 and 18 in the Resources) instead.
Thus, these appearance streams now also are subject to the rotating transformation matrix from object 5 (0 -1 1 0 0 0 cm) as the stream 20 is after stream 5 in the content stream array [ 5 0 R 20 0 R]. They also (see above) counteract the page rotation themselves, though. In essence, therefore, the rotation for them now is counteracted twice and they are rotated the other way.