SMTP_SetPrefs
version 6.7 (Modified)
SMTP_SetPrefs (lineFeed; bodyType; lineLength) 
Integer
| Parameter | Type | Description | |
| lineFeed | Integer | | 1 = [default] Add, 0 = Don't Add, -1 = No Change |
| bodyType | Integer | | Body-Content-Type (1 = [default] Auto-detect, |
| -1 = No Change) | |||
| lineLength | Longint | | Maximum line length (0 = [default] Auto-detect, |
| -1 = No Change) |
Function result Integer 
Error Code
Description
The SMTP_SetPrefs command sets the preferences of messages to be sent using the SMTP commands. The command has a global scope and will affect all subsequent messages created with the SMTP commands. The configurable options affect the format of a mail message as it is sent to a SMTP server using the SMTP_QuickSend or SMTP_Send commands. The preference settings have an interprocess scope and effect mail creation in any 4D process.
SMTP servers recognize the end of a line to be a combined carriage return/line feed (CR/LF) character pair. This differs from most Macintosh applications, which view a single carriage return as the end of line/paragraph marker.
lineFeeds is an integer value which specifies how to handle carriage returns within the body of a mail message. Passing a value of zero in this parameter will leave the message body text untouched, permitting the developer to control their own line feed additions. A value of 1 (default setting) will replace all carriage return/line feed pairings with carriage returns for you. A value of -1 will leave the current value of the preference unchanged. If you are unsure which option to choose, you should choose 1, the default value.
bodyType specifies the character set used in the message body to be sent (Body-Content-Type) as well as the encoding to apply to the message body (Content-Transfer-Encoding), according to the values in the table below. For example, "US-ASCII & 7 bit" (value 2) means that the message body charset currently in use is supposed to be US ASCII — includes only standard ASCII codes (0 through 127) which are common to Windows and Macintosh— and that 4D IC will encode the message body using the 7 bit encoding. Note that the SMTP_SetPrefs command does NOT convert the message body using the specified character set, this has to be managed by the user if necessary. If you want to force the character set conversion, refer to the SMTP_Charset command description.
If not changed, the default content type is 1, which will allow the SMTP commands to auto-detect an appropriate setting based on the contents of the message body.
| -1 | No change |
| 0 | Application & binary; no encoding |
| 1 | Default; will choose either "US-ASCII & 7bit" or "ISO-8859-1 & quotable-printable" based |
| on message content. | |
| 2 | US-ASCII & 7bit |
| 3 | US-ASCII & quotable-printable |
| 4 | US-ASCII & base64 |
| 5 | ISO-8859-1 & quotable-printable |
| 6 | ISO-8859-1 & base64 |
| 7 | ISO-8859-1 & 8bit |
| 8 | ISO-8859-1 & binary |
| 9 | Reserved |
| 10 | ISO-2022-JP (Japanese) & 7 bit |
| 11 | ISO-2022-KR (Korean) & 7 bit |
| 12 | ISO-2022-CN (Traditional & Simplified Chinese) & 7 bit |
| 13 | HZ-GB-2312 (Simplified Chinese) & 7 bit |
| 14 | Shift-JIS (Japanese) & base64 |
lineLength specifies a maximum SMTP line length for text within the message body. The SMTP commands will "line wrap" the body text by inserting a carriage return/line feed pair at the nearest word break before the maximum line length. Any number may be specified but it is recommended that line lengths be kept below 80 characters. A value of -1 will leave the current value unchanged.
The lineLength parameter defaults to zero. A value of zero will cause the SMTP commands to use the recommended values specified within the RFC definitions for the bodyType. If the lineLength parameter is set to zero, wrapping will occur based on the following table:
| Body Type | Wrap at |
| Base64 | 76 |
| Quoted-Printable | 76 |
| Other… | no wrapping |
Line wrapping is strongly suggested since many systems and mail programs have problems handling messages containing unlimited line lengths. Also, keep in mind that mail often travels through a number of systems before reaching its final destination and any computer along the delivery path may reject a message if it is unable to handle the message's format.
See Also