For Windows

Jerry gnupg.user at
Mon Mar 14 15:44:21 CET 2011

On Mon, 14 Mar 2011 09:17:59 -0400
Robert J. Hansen <rjh at> articulated:

> On 3/14/2011 8:23 AM, Jerry wrote:
> > The point being that at some point you have to move on.
> Yes, exactly.  At some point *you* have to move on -- but you don't
> get to say if, or when, other people decide to move on.
> For the time being, a lot of people are still on platforms that use
> outdated software.  In this case, Outlook Express (although I agree
> with Doug: I believe Windows Mail still has the same problem).  The
> question is whether in our desire to move on we're willing to write
> off the possibility of communicating with people who have not yet
> moved on.
> > Outlook Express is dead.
> "Dead" is a subjective term, and not one I believe is appropriate
> here.
> > Would you have the creators of every piece of software out there
> > continuing to waste time and resources on making their software
> > backward compatible?
> Of course not: however, that's not what we're talking about here.
> What we're talking about is inline signatures.  The code for this
> already exists, is stable, and isn't going away anytime soon.  The
> question is not whether we are going to spend resources specifically
> targeting OE, but whether we are going to use *already developed*
> resources in order to facilitate communication with OE.
> > Many of the complaints from FOSS users is that Microsoft's products
> > are bloated. To continue to support architectures that are no longer
> > viable is to bring the same criticism upon us.
> Quite the opposite: one of the big selling points of the free UNIXes
> is how well they function on old, outdated hardware.  I could install
> one on the very first PC I ever owned, a 386DX/20.  Support for old
> systems is a feature, not a bug!

Excuse me, but where did the term "bug" come from in this discussion? I
specifically stated "bloat". It you don't know the difference then this
discussion is never going to go anyway. Might I suggest:
<> for further reading.

> > Now, start the creation of a new branch that supports only modern,
> > fully RFC approved standards.
> Inline signatures /are/ standards.  RFC 4880 is far newer than RFC
> 3156: by your logic, 4880 should supersede 3156 and we should all
> move to the current standard and abandon 3156 support.

Actually, yes I would suggest that we all move. However, that would be
extremely naive of me like believing that readers actually view a
signature and pay heed to a posters requests. Now, RFC does explicitly
obsolete other RFCs, specifically: Obsoletes: 1991, 2440 as stated in
the RFC. There is no specific mention of any other RFC so obviously
obsolescence is not the question here. There are always going to be
slackers; it is just the nature of the beast.

> Note: I'm not advocating everyone use inline signatures, the same way
> I don't advocate everyone use PGP/MIME signatures.  Use what works for
> you.  At the end of the day, that's the final analysis, the only
> interesting result.

I have no problem with that basic philosophy. If some user wants to use
a seriously comatose method, that is their right I suppose. However, I
find rather interesting the number of users who would state that I
should be willing to accept inline signatures even though it breaks the
functionality of sig-delimiters, plus adds garbage to the actual message
which inevitably some other moron then forwards or replies to with that
same garbage still visible, ad infinitum, yet bitch like little school
girls if some user posts using HTML or attempts to make use of a
Microsoft ".doc" formatted item. For the record, I am opposed to both;
however, that does not change the fact that, that same behavior is

I have seriously considered adding some body checks to my Postfix mail
server to reject messages with inline signatures. I would only then
need to whitelist a few actual bona fide senders that I actually need to
correspond with that still employ the older protocol. Now that sounds
like a real win-win compromise.

Jerry ✌
GNUPG.user at
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.

More information about the Gnupg-users mailing list