password is embedded in the view page itself as html hidden input fieldsencrypted or obfuscatedand html escaped delete message (client to cgi server to pop server)finallythe password is again passed from client to cgi serverthis time as hidden form field valuesthe cgi script decodes it and passes it to the pop server to delete along the wayscripts have passed the password between pages as both url query parameter and an html hidden input fieldeither waythey have always passed its encrypted or obfuscated string and have never passed an unencoded password and username together in any transaction upon delete requestthe password must be decoded here using the secret module before passing it to the pop server if the script can access the pop server again and delete the selected messageanother confirmation page appearsas shown in figure - (there is currently no verification for the deleteso be carefulfigure - pymailcgi delete confirmation one subtlety for replies and forwardsthe onviewpageaction mail action script builds up >-quoted representation of the original messagewith original "from:""to:"and "date:header lines prepended to the mail' original text noticethoughthat the original message' headers are fetched from the cgi form inputnot by reparsing the original mail (the mail is not readily available at this pointin other wordsthe script gets mail header values from the form input fields of the view page because there is no "datefield on the view pagethe original message' date is also passed along to the action script as hidden input field to avoid reloading the message try tracing through the code in this listings ahead to see whether you can follow dates from page to page processing fetched mail