There are two alternatives:

1.) Update PHP.  The issue has been fixed.  This requires no further 
development work.

2.) Write a new quoted-printable encoding backend.  Not only would 
this be *many* times less efficient than the PHP C-based version, but 
it is unneeded (see #1), but it would require significant developer 
resources to do something that has already been fixed.

If someone wants to pay me to do option 2, I would gladly do it.  I 
don't see how it is my (or anybody else's) responsibility to do this 
though when the issue has already been fixed the correct way (option 
1).  (see, e.g., the current releases of PHP, which have totally 
broken SSL behavior.  The correct resolution is to fix PHP, not for us 
to try to workaround this behavior)

Sorry, I read the ticket from top to bottom, so I thought that the php 
version was not the solution. This is really a strange order for the 
comments. I will check the php version.

Anyway, I still think that this should be fixed in Horde. Sometimes it 
is not possible to update php on managed servers. In my humble 
opinion, Horde should not create broken signatures then. It should 
either say that creating signatures is not supported with this version 
of php, or there should be a workaround which e.g. removes spaces 
before signing or whatever. However, creating broken signatures is 
really a bad thing to do.

What is there to reopen?  As this ticket history indicates, the only 
issue would be that you are using a broken version of PHP.

I can verify there are no issues with sending messages with a current 
version of IMP using a non-broken PHP version.

This issue persists.
Could you please check the most recent comments on
http://sourceforge.net/p/enigmail/bugs/248/
and consider reopening this issue?

Currently i have no test system available to run an upgraded php. 
Please close the ticket and thanks for your support.

Are you going to be able to upgrade to test?  Otherwise, I will close 
this ticket.

My php version is 5.4.4 (Debian 7) - looks like the problem is related 
to this version.

You need at least PHP 5.4.17/5.5.0 (Bug #64166):
http://www.php.net/ChangeLog-5.php#5.4.17
https://bugs.php.net/bug.php?id=64166

And due to partial regression introduced with original fix, you really 
need at least 5.4.20/5.5.4 to work properly:
http://www.php.net/ChangeLog-5.php#5.4.20
https://bugs.php.net/bug.php?id=65483

What version of PHP?  The PHP quoted-stream stream filter was broken 
until recently - I provided a stream of patches upstream to PHP to fix 
the issue.

i.e. this sounds exactly like this issue:

commit 600d6deef9c8983eb8023171c6c5ae90ca60b6c1
Author: Michael M Slusarz <slusarz@curecanti.org>
Date:   Thu Feb 7 12:37:52 2013 -0700

     Fix #64166: quoted-printable-encode stream filter incorrectly 
discarding whitespace

     If trailing whitespace on a line is detected, mark the linebreak as a
     soft linebreak.

You should be using at least PHP 5.4.25 when testing.

After some tests with plain text mail encoding and PGP it shows that 
automatically flowtext inserted line breaks will also destroy 
signature detection in thunderbird.

E.g. the phrase "[SP]gestern[SP]bei[SP]" got broken to   
"[SP]geste=[LF][SP][SP][LF]rn[LF]bei[SP]" (hex: 20 67 65 73  74 65 3d 
0a 72 6e 20 20 0a 62 65 69 20 )

For me the problem became more serious because plain text encoding 
with pgp seems to be not usable in combination with thunderbird 
reception.  My workaround is to use html encoding.

This is a good time to move the logic ensuring the text parts are Q-P 
encoded from the MUA into the library itself, if just for abstraction 
purposes and for cleaner code.

But the point remains that trailing spaces remain perfectly legal and 
expected in OpenPGP-MIME signed data.

Why do you have to do this?  There's no reason to.  In fact, we could 
send signature separators as "--[SP][SP][SP][SP][SP][SP][SP]" if we 
wanted to.  It's totally irrelevant.  There is no limitation on 
trailing spaces within the actual PGP-MIME data itself.  (There's a 
limitation on trailing spaces **AFTER** content-transfer encoding has 
been employed.  But that's a totally different topic, and not an issue 
here since we protect trailing spaces by using q-p encoding.)
Please read 3676.  It refers to precisely this issue, while directly 
referencing 3156.  In short, there is nothing wrong with trailing 
spaces for ANY data (let alone signature separators) as long as you 
are using OpenPGP-MIME (instead of raw OpenPGP format).

"--[SP]" is just the problem. To make thunderbird/enigmail run pgp 
validation successfully you have to deselecet the usenet style 
signature tag. For the user this dependency is not obvious and causes 
mistrust to the horde/pgp-functions.

Thunderbird/Enigmal refers to RFC3156 and Horde quotes from RFC3676 
and the problem persists.

Meaning IMP sends "--[SP]", not "--[SP][SP]" as would be expected 
under the other flowed rules.

http://tools.ietf.org/html/rfc3676#section-4.3

    There is a long-standing convention in Usenet news which also
    commonly appears in Internet mail of using "-- " as the separator
    line between the body and the signature of a message.  When
    generating a Format=Flowed message containing a Usenet-style
    separator before the signature, the separator line is sent as-is.
    This is a special case; an (optionally quoted or quoted and stuffed)
    line consisting of DASH DASH SP is neither fixed nor flowed.

IMP correctly sends this separator (i.e. in flowed mode, we do NOT add 
an additional space at the end of the line).

A mail with IMP standard mechanism to append a user defined signature 
(delimited with "-- \n") is sent addionally signed with PGP. The 
verification of the signature is successful in IMP and mutt,  but 
fails in thunderbird/enigmail.

The problem is reported to enigmail (see also for details 
https://sourceforge.net/p/enigmail/bugs/248) but meanwhile i got stuck 
in the discussion if the trailing blank in the signature delimiter is 
correct or not. Although i tend to the opinon that this is not a 
problem of Horde/Imp i have to admit that my level of competence is 
exceeded.

Please continue the discussion with enigmail by a Horde developer to 
achieve a mutually agreed pragmatic solution.