|Search Pine Information Center|
In Pine's message composer, with the cursor in the message headers area, press "^R rich headers". Then read the context-sensitive help screens for the Bcc: and Lcc: fields, by pressing "^G Get Help".
Many Pine users, who may have seen this feature in other email systems (such as those on a Local Area Network, where it is common), have asked if there is a way to confirm whether or not a message they send over the Internet has been received, or even whether it has been read, by the recipient. The answer is "perhaps"--reasons against generation of return receipts include:
If a message cannot be delivered due a technical problem--such as connectivity interrupted, or mailhost down or misconfigured--the sender will almost always receive a diagnostic message to that effect, which they can forward to their computing support staff for interpretation and troubleshooting. The best solution to the "lack of return-receipt" problem is therefore to include a line requesting confirmation from the recipient that a message was received in that message itself.
This is not a new idea. It's a very old idea, in fact, and just about everyone who has ever dealt with email has had it at one time or another. Regrettably, it has come to be recognized as a bad idea. Here's why:
An email address without a host name is not syntactically valid according to RFC-822. Now, it is true that RFC-822 only specifies what must be done in messages which are transmitted over the network, and that strictly local messages are not under RFC-822's dictates.
This means that there are two formats of email, one that conforms to RFC-822 and one that does not. Careful efforts must be made to ensure that the non-conforming mail format never escapes the local system onto the network. Twenty years of experience has shown that it is impossible to guarantee that the non-conforming format does not escape into the network, even in the face of traps to catch such messages on their way out and convert them to RFC-822 conforming format. Indeed, such traps have often contributed additional problems on their own.
The non-conforming format is ambiguous as to what host is intended. Although the off-the-cuff solution (and the one that everyone implements) is "use the local host", numerous examples have occurred in which this leads to wrong behavior. For example, it may be the "local mail center" instead of the "local machine which is a single-user workstation". Or, if a one of the non-conforming messages escaped on to the network, it's some remote system and we have no idea at all what system that may be! There's no way for the mail reader to tell; a human may infer from context but often does so by using information that is not available to the program.
The Pine team has spent long (and at times heated) meetings reviewing this issue, before coming to the conclusion (as other email groups have independently done) that it's a no-win situation. The policy of the email development community for years (since the RFC-733 discussions) has been to exterminate the non-conforming format by not implementing it in modern mail tools.
It may be feasible to implement a feature in a future version of Pine that would suppress the display of the local host name in email addresses. That is, the host name would still be in the file on disk, but would not show up on the screen.
When viewing the FOLDER INDEX, you can force Pine to check for new mail by pressing ^L, or if on the last item in the Index, by pressing "N". The eXpunge command will also force a new-mail check. If you would like to have some visual indication of when Pine is checking for new mail, set the enable-mail-check-cue feature and watch for an asterisk to flash in the upper-left-hand corner of the screen. (Two asterisks mean that Pine is check-pointing --saving state changes in-- your INBOX.)
|Search Pine Information Center|