a few more thoughts to chew on

as I was moving boxes and furniture out of my aunt's apartment this=20
weekend, it occurred to me that if anyone felt like experimenting,=20
twopenny blue has all of the components you need to build a client-side=20
stamper that can use either na=EFve or Send once stamping protocols.  The=
=20
current downfall will be the inability to communicate message delivery=20
failures to the user.  It's not say it can't be done, but we will need=20
to do things a little differently.

If I had infinite spare time and money, I would start with=20
postfix_stamp_feed as the SMTP level interface to the MUA.  If you=20
follow the code, it would put messages immediately onto the queue=20
(file_queue).  Then the daemon postfix_stamper generates the stamp and=20
sends a message to the designated upstream SMTP receiver.  This rough=20
system has the properties of MUA independence, platform independence,=20
resilience across power failures and hiding spam generation delays from=20
the user.  Problems include manual configuration issues and that=20
messages that don't need stamps must wait behind any messages in the=20
queue of meeting stamps.  I see that as a future feature.  :-)

the prototype suggested is not perfect and may not even be practical but=20
it puts you a step closer to client-side stamp generation that is=20
platform and MUA independent.

Have at it.  As soon as I figure out how to run a bzr public repository,=20
I will even support it here.

---eric