The purpose of this document is to give you an idea on how data get's processed by this program. This can be quite helpful for Group Administrators and Site Operators -- especially when you have to solve problems.
Basically the processing of mail is handled in stages. The mail flows throught all the stages and might get modified there. Depending on system or user settings, stages might also be skipped.
Let's start with a picture
In this stage each incoming message is verified and transformed into a canonical form.
is the e-mail address correct?
Does the e-mail come from us (Mail loop prevention)
Does the incoming e-mail an mailer error (operator notification)
Also, unnecesary parts like comments are stripped. Aliases are reversely resolved, that is, the e-mail johnny@aol.com might be resolved to johannes@public.org.
Configuration: check the variables @TabooSenders, %TabooHeader and %OurNames in the siteconfig file.
This stage currently only does happen if an e-mail goes to the command line processor. However, it might be the case that I turn this feature on generally, because I am not yet totally aware on how I should encrypt file attachments.
The unfolding stage get's rid of alternate e-mail parts (e.g. HTML formatted e-mail) or attachments (e.g. attached business cards). This is to make the command line processor happy. They seldom like those data :-)
Any e-mail might be sent encrypted or as plain text to the PGP Forwarding Server. When it was encrypted and the used key was one of the Server's public keys, then the e-mail will automatically be decrypted.
It might also be the case that one sends an e-mail throught the server that was encrypted with another key. In this case the server detects this fact in this stage and set's an internal variable. This variable is later used in the encryption stage. Otherwise the outgoing e-mail might get encrypted a second time. Althought technical this is not a problem, this would be somewhat un-userfriendly.
Also the signature of any incoming mail is checked here. If the signature matches one of the signatures of the local users, then the server goes from guest context to user or administrator context, depending on the settings of the user. This actually means that the server put's the trust not in the used e-mail address, but in a cryptographically strong signature.
Commands: set key keyid controls with which key an e-mail must be signed in order to be accepted as an e-mail from you.
Configuration: check the variables $GPGKeyId and $PGPKeyId in the siteconfig file.
Now the e-mail is handed over to the command line processor. The processor reads one line after the other until the processor either reaches
The end of the mail.
The command end.
A well-formed signature. According to the Netiquette a well formed signatures start with two consecutive hyphens on a new line. It's a shame that almost no one cares for this and invents his own asterisks based artwork).
A certain amount of errors. The ratio behind this is that some people might accidentally send a normal e-mail (with a letter, not commands) to the command line processor. Now this should not generate 1240 errors when the e-mail has 1240 lines ... so we bail out after a certain amount of errors.
The result of the command line processor is sent back to the user. This is not necessarily to the e-mail address the command came from. When the incoming e-mail was signed, the system realizes the user identity based on the PGP signature. Then the e-mail is processed in a user context and the reply is sent to the e-mail address the user specified via set forward.
Commands: end stops the processing of commands.
Configuration: check the variable $MaxCmdErrors in the siteconfig file.
Some people actually prefer to receive unencrypted e-mail, because of local circumstances. This is no problem for the PGP Forwarding Server, you just use the command set encryption off. However, then any e-mail would come throught unencrypted.
The stop word stage would prevent this. It would look into the message text and, if some words do exist, reject the message and send an according note back to the sender.
Note: this stage is not implemented. I can program it at any time, but others must do the work and collect the stop words.
This stage takes the message (or the reply of the command processor) and encrypts it. Before doing this, a list of all the receivers is gathered and sorted into three categories: receivers without encryption, receivers with a PGP 2.x key and receivers with a PGP 5/6 key. Then the message is encrypted according to the key information.
Note that in this case only the existence of key ring counts. This is individual from local users. Just send the public key of your friend to the PGP Forwarding Server and the system will use this key for any e-mail to your friend.
Only when you are a user of this system you can actively disable encryption. Use the command set encryption off for this purpose.
Commands: set encryption onoff controls if e-mail to you should be encrypted or not. set key keyid controls which key should be used for e-mail to you.
Finally the e-mail get's delivered to the recipient. This is done throught the SMTP protocol if then e-mail is going to an outside receiver. Users of the PGP Forwarding Server can turn on local delivery. In this case they have to use POP3 over SSH to get their e-mail.
Commands: use set forward emailaddress to specify where e-mail for you should be sent to. Use set forward off to turn forwarding off (and this, in turn, turns on local delivery to your POP3 mailbox).
Configuration: @SmtpHost in siteconfig specifies which SMTP host to use for outgoing e-mail (can be localhost. $MyDomain specified which domain name should be used outgoing e-mail.