I just started to wonder how comes that the windows/ version gets away with not defining any specific font color for signatures here in the messageBody.css file, but then found that they are defined in the quoted content, http://mxr.mozilla.org/comm-central/source/mail/themes/windows/mail/messageQuotes.css#18> .moz-txt-sig,
> .moz-signature {
> color: rgb(136,138,133); /* Aluminum 4 */
> }
>
> .moz-txt-sig > a,
> .moz-signature > a {
> color: rgb(114,159,207); /* Sky Blue 1 */
> }
Since those are not restricted to blockquote constructs they should also apply to the main text. Similar definitions can also be found for the linux/ theme.

Ok, so the reason that the signature is defined in messageQuotes.css for Linux and Windows but not for Mac OSX is that gMsgEditorCreationObserver uses it in the observe function to style the signature during message composition. For some reason, Mac OSX doesn't have that file and defines it in messageBody.css instead.
These should be enough pointers to come up with a patch, I'll give it a try but can only verify it for Linux and Windows, not Mac OSX (don't have one around).

Looks good on Windows already, especially with the background color changed to something different than white. Basing the signature on opacity rather than that greyish font really helps in this case, and custom-colored links show up nicely.
I'll test the Linux version tomorrow and should have a patch up for your review after that, unless I run into any unexpected issues.

Created attachment 730150[details][diff][review]
Proposed patch
Here the patch for all platforms. This works fine on Linux as well, now the preference colors are obeyed without the "Allow content to choose its own colors" box unchecked, and the signature has opacity applied rather than a fixed color to also consider custom text colors.
Tested with both plain-text and HTML messages, including the signature on message composition (which doesn't use the display text and background colors though, but that's a different issue). In Simple HTML, the user-defined anchor color is chosen; in Original HTML, color specifications in the document are observed.
As said, I'm unable to test this on Mac OSX, but don't see a reason why it shouldn't work in a similar way.

Note that you shouldn't see any opacity applied to the signature in message composition on Mac OSX given that it doesn't have a messageQuotes.css file (I don't see any bug report pending to add it, thus I can't tell if it was on purpose or by omission). The comment in the composition code points to bug 517919 and bug 516322 for related discussion.

Created attachment 730977[details]
Comparison on Windows 7
Interesting, I assume that you determined this from Mac OSX?
The signature text color there is #505050 [rgb(114,159,207)] and #7777ff [rgb(119,119,255)] for the signature. In contrast, Windows and Linux define rgb(136,138,133) for the text and rgb(114,159,207) for links in signatures, thus are brighter than on Mac OSX for whatever reason.
Now, an opacity of 0.6 corresponds to rgb(101, 101, 101) for black, and 0.5 is rgb(127, 127, 127). As the latter is closer to the current shade (and that's what I've ended up using in bug 855684 for the SeaMonkey version of this patch, given that they currently use a matching 50% gray for the signature text), I've tried it as shown in this screenshot comparison. However, the link color is now lighter in Thunderbird (but not in SeaMonkey), thus it looks too pale now despite the gray text approximately matching the current shade.
Thus, unless you tell me to switch the opacity to 0.5 for Windows and Linux, I'd stick with 0.6 for all platforms given that it looks better for the in-signature links.

(In reply to rsx11m from comment #7)
> Interesting, I assume that you determined this from Mac OSX?
That refers to:
(In reply to Blake Winton (:bwinton) from comment #1)
> (0.6 seems to get it close to the current values to me…)

(In reply to Blake Winton (:bwinton) from comment #9)
> I guess my only review-question for this patch is "Why did you remove this line?"
That's how I've noticed that something was wrong in the first place. On Linux, that rule currently overrides browser.anchor_color, thus a change there doesn't affect anything at all. I'd assume that this was introduced initially for the same reason the default link color was changed in bug 845807, to make the blue a bit lighter. This has been taken care of now by globally changing the default, thus the rule can go for that reason as well.