problem/bug wrt. -t and trailing whitespace

[Alexander Zangerl]

when one wants to use pgp-mime, ie. multipart/signed, rfc2015 mandates
the use of "mime canonical text mode", which rfc2045++ state as
"crlf for line endings". 

when i generate detached sigs of my mail text using gpg -t, 
gpg unfortunately strips the trailing whitespace before/when generating
the signature. my helper script can not possibly detect what gpg did
internally to the data it signed, and produces a multipart/signed from
the original data with the trailing whitespaces and the 
signature that doesnt fit the data :-((

so, when i try to verify the multipart/signed, each and every tool i've 
tried so far converts the data part of the multipart to CRLF-mode,
and then asks gpg/pgp to verify the signature -- which fails because
of the trailing whites.

i've not found any reference in the relevant rfcs, that mandate 
stripping whitespaces. 

rfc2015 says something about "sometimes it could be useful to encode
trailing whitespace using quoted-printable, because some gateways mangle
such whitespace", but i could not find a single reference to this being
a must or should.

ok, you might tell me to avoid trailing whites, and use qp or the like.
unfortunately, using quoted-printable as content-transfer-encoding
for all text-like data is not feasible, because for example data of 
type message/rfc822
must not be transfer-encoded using anything except 7bit/8bit/binary.
therefore i would still send mails with bad signature when i happen
to attach a mail from someone else who's using for example "-- " as
sig-delimiter.

so, who's wrong here?
imho stripping trailing whites when signing is not the Right Thing on
gpg's part.
or has my mailprogram got to invoke gpg/pgp with special options when
verifying, -t for example? this might be possible, but "doesn't feel right"
for me, because there's still the point that the signed data in the 
mail and the signature by themselves do not agree, and twisting strings like
that would only half-cure the problem by mangling bad input to comply
with the assumption "canonical text mode = CRLF and no trailing whitespace".

any hints are appreciated
az

-- 
++ Dipl.-Ing. Alexander Zangerl          Xsoft GmbH. ++
++ a.zangerl@xsoft.at           http://www.xsoft.at/ ++
++ phone +43 1 7963636 - 28    fax +43 1 7963636 - 18 ++