In simple mode, you are supposed to hash header fields without unfolding them, including the DKIM-Signature header field. BUT, you MUST treat the b= param of the current signature as if it were the empty string. That leaves an ambiguity in the spec. What if the b= value, which is long, is then folded? When replacing the b= value with empty string, should you also remove any FWS inside the value? Adjacent to the value? I can see different interpretations. dkimpy puts b= as the last sig param, and does not fold again after signing (thus the b= line can be longer than 72 chars). However, perhaps your mail relay is folding the headers? And google is actually being more tolerant than it should? Or the difference is folding in the b= param.
In simple mode, you are supposed to hash header fields without unfolding them, including the DKIM-Signature header field. BUT, you MUST treat the b= param of the current signature as if it were the empty string. That leaves an ambiguity in the spec. What if the b= value, which is long, is then folded? When replacing the b= value with empty string, should you also remove any FWS inside the value? Adjacent to the value? I can see different interpretations. dkimpy puts b= as the last sig param, and does not fold again after signing (thus the b= line can be longer than 72 chars). However, perhaps your mail relay is folding the headers? And google is actually being more tolerant than it should? Or the difference is folding in the b= param.