I am looking for a copy of CryptUI.h file which used to be in Win32 Platform SDK, but was replaced with CryptUIAPI.h.  I need it to call CryptUIDlgViewCertificate which is undocumented.  The function displays a dialoging showing details about certificates.  Microsoft recommends CryptUIDlgViewContext but it's available only on XP and Windows Server 2003.  There is another recently documented fuction CertViewProperties, but that works only on XP, Windows 2000 Pro adn Server.  CryptUIDlgViewCertificate works on all of these platforms as well as Windows 98+.  I could use CAPICOM but that will add 450K to the footprint just to display a cert.  I could also write my own cert display dialog, but that involves more work than I am willing to put into this.

So…Help!

If you don't understand what I wrote above, don't feel bad.  This stuff is so geeky that not even Google can find enough material to fill a page.

Update – 2003/10/21 01:36PM PST

Michel Gallant came to my rescue with his open source KeyPal utility which has the necessary declarations – Gallant indeed!  Declartations are in C# so I'll translate it to C and post it here for future reference.  I might even wrap all this into a DLL for others.  I still haven't figured out how to coax these APIs to display a cert chain like the way Acrobat 6 does it.

Bjarke Viksoe released source code for BVRDE, Win32 IDE for developing UNIX/Linux software which I mentioned before.  Thanks Bjarke.  BVRDE is basically a full GUI front-end to command-line oriented tools running on remote UNIX/Linux boxes.  BVRDE source is a great starting point for Windows IDE projects.  It's written in WTL so your IDE can be lean and fast.

Tomcat 5 is currently stable enough for me to use, but I think it's use of Jakarta Commons Logging framework is going to cause headaches for webapps using Log4J.  For some reason, Tomcat fails to start if there is an webapp using Log4J.  After spending several hours of fiddling with configuration, I had to stub out all log4j calls from a webapp to get it to work.

XForms 1.0 is finally a W3C Recommendation.  No comment.

There is a lot of discussion going on about ways for user agents (read browsers) can locate site metadata.  People are even arguing about what constitutes a site.  Beside the discussion within W3C TAG, RSS developers are discussing this topic with RSS feed discovery in mind.  Consensus seems to be moving away from using robots.txt style solution which uses fixed-URI.

Tim Berners-Lee wrote back in February:

The architecture of the web is that the space of identifiers on an http web site is owned by the owner of the domain name.  The owner, "publisher",  is free to allocate identifiers and define how they are served.

Any variation from this breaks the web.

Hogwash.

1. Web is just not that brittle.
2. Other solutions are not as easy.
3. User agents should protect themselves from unexpected data.
4. People will not revolt if W3C reserves some range of names if they are reasonably unique.

Simplest solution IMHO is to introduce a special file extension for metadata and a default file name for directory metadata.

For example, if ".w3c" file extension is used for metadata and default file name for directory metadata is empty string, metadata for the resource "/application/foobar.html" can be found in "/application/foobar.w3c" and metadata for the path "/application/" can be found in "/application/.w3c".

Add to this a hierarchical inheritance rule which basically say metadata not specific to a resource can be overriden by subpaths.  For convenience sake, subpaths starting with "_w3c" should be reserved.

Using this solution, my blog's RSS feed list can be located by fetching "https://blog.docuverse.com/.w3c".  Problem solved.

To me, current discussions are no different than discussions about where the toilet flush lever should be placed.  Should it be on the right-side because there are more right-handed people or at the center to be fair?  I say let the manufacturers place the damn lever anywhere convenient and noticeable.  'Users' will do the rest.

SQLLite

While LAMP (Linux, Apache, MySQL, PHP/Perl/Python) is still going strong as a web application platform, MySQL is being challenged as the default database by SQLLite (home, download, wiki).  SQLLite is an embeddable SQL database engine, meaning it runs inside your program.  Beside being embeddable, it has these attractive features:

• Speed – SQLLite is faster than MySQL (benchmark)
• Code Size – just 25K lines of C
• Data Size – much smaller backup file than MySQL
• Data Storage – everything is stored in one file
• Transaction – built-in and default unlike MySQL
• Dependency – SQLLite has no external dependencies

Upcoming PHP 5 will include and use SQLLite as its default database engine.  This PHP Internals message outlines the benefits SQLLite brings to PHP.  Interestingly, MySQL client libraries will no longer be bundled with PHP due to some licensing issues.  I am not sure if this is a major trend in the making, but MySQL is taking the embeddable threat seriously enough to work on its own version of embeddable MySQL (mentioned in the October issue of Linux Magazine).

QDBM

If you don't need to use SQL, Mikio Hirabayashi's QDBM is an attractive xDBM-style (GDBM, NDBM, SDBM, Berkeley DB, etc.) database management library.  This benchmark (PDF) compares QDBM with other xDBM libraries.  It's main competitor is Berkeley DB which also offers both hash table and B+ tree API.  In comparison to Berkeley DB, QDBM has a nice speed/data-size ratio.  Only problem is that QDBM is still in beta.  Hopefully, this post will give the open source project more exposure and attract more resources to it.

This is a non-crypto wack at the spam problem.  It's half-baked at the moment, but I am sure you guys will provide the necessary heat to cook fully or burn it crisp.

Today, e-mail senders have no way of knowing whether a message sent has been erroneously flagged as a spam on the receiver side by either receiver-SMTPs or SMTP clients.  Being able to check whether my message is likely to be flagged as a spam has some value to me.  Starting with that idea, let's see if a solution comes together.

Spam-Filtered Outgoing Mail

A sender-SMTP that uses spam-filters on outgoing messages returns messages flagged as a spam or a likely spam back to the sender instead of sending them, allowing the sender to revise the message or use another communication channel like telephoning.  Sender-SMTP is basically saying that the message is being returned because chance of the message getting through the spam filter on the receiving side is low, a valuable service IMHO.

Sender-SMTP can weed out spammer's mail accounts by monitoring spam ratio on each account.

Filtering spam on the sender-side has two side-effects:

1. outgoing mail volume drops.
    
2. spam ratio decreases.

These effects will be visible to both receiver-SMTPs and mail recipients, meaning less spams for them.  Sender-SMTP can also actively weed out spammers by monitoring spam ratio on each mail account.

Identifying sender-SMTP by IP address

To encourage sender-SMTPs to use spam-filters on outgoing mail, they have to be identified.  One cheap solution is by IP address.

If sender-SMTPs are encouraged to have static IP addresses, receiver-SMTPs can identify sender-SMPTs and rate each accordingly, giving higher marks to those that seems to be filtering spam.  Penalties to those who rate low can range from limiting frequency of connections and/or limiting volume per connection.

To encourage sender-SMTPs to use a static IP address, receiver-SMTPs can apply penalties to unknown sender-SMTPs.  To avoid the penalty, sender-SMTPs must use a senderid assigned to the IP address on first connection.

Recipient Feedback

Receiver-SMTPs can append a URL to each message to collect recipient feedback which can be used to differentiate good SMTPs from masquerading bad SMTPs.  Feedback can be sent as part of receiver-SMTP's response when the suspect sender-SMTP connects next time.  Sender-SMTP can use the information to throttle back the suspect sender's mail volume.

I am not sure if the solution I just sketched will work or not, but it is definitely more scalable than TEN or SMTP4All.  Please let me know what you think.

Update - 2003/10/14 12:32PM PST

 Mitch Ratcliffe is looking at the spam problem from a similar angle:

Push the responsibility back onto the sources of spam, not the end-user who generally doesn't spam one iota.

Right on, Mitch.