I'm seeing some issues with signing in recent kernels. The problem seems to have been introduced with the patches that switch cifs over to use the crypto APIs.
When I send large SMB's win2k8 seems to consistently fail the signature check. The threshold seems to be at 16705 byte SMBs. This corresponds to a WriteAndX of 16641 bytes. One byte less than that, and the signature check consistently passes.
I think that the reason we're just noticing this now is a confluence of changes:
1) Shirish's conversion to use the crypto APIs. This spans several patches and follow-on bugfixes.
2) commit ca83ce3d changed the code to always use "zero-copy" writes, even when signing is enabled, so signed connections now use larger SMBs
I first noticed this while backporting some patches from upstream, so I was able to do some experimentation. The older crypto code does not exhibit this problem, even when I turn on "zero-copy" writes.
To make this even more confusing, the new crypto code never seems to make samba fail. It passes those signature checks just fine.
Obviously more work is needed to box in this problem, but it seems like a clear regression in the crypto code. Why samba doesn't seem to care is thus far a mystery.

Yep, this seems to be a "stealth" limitation in windows. The CAP_LARGE_READX/WRITEX bits are set, which should mean that the server can handle these larger frames. It doesn't seem to however.
I've sent a note to MS dochelp to get come clarification in the hopes that we can come up with a way to detect these problems automatically and deal with them.

Thanks Jeremy, but I think I've got this figured out. I posted a message to dochelp and cifs-protocol lists:
http://lists.samba.org/archive/cifs-protocol/2011-June/001921.html
...George Colley and Hongwei Sun pointed out that this is expected behavior and that we should just ignore the CAP_LARGE_WRITEX bit when signing is enabled. I've got a patch that I'm testing now that should take this into account when the wsize is negotiated.