NOTE: If you want to use existing Messaging Server 3.0 or 4.0 plug-ins in Messaging Server 4.1, see Appendix A, "Converting Messaging Server Plug-in Files to 4.1." §[Top]
Note The Messaging Server Plug-in API 4.1 is available on the Solaris, HP-UX 11.00, DEC UX, SGI IRIX, AIX, and Windows NT platforms. §[Top]
PostSMTPAccept plug-ins are called immediately after the message is received, at the PostSMTPAccept entry point. This is the most common, and most useful, type of plug-in.
At the PostSMTPAccept point in processing, Messaging Server has not touched either the message body or the envelope, and the message may not be fully standards compliant. In addition, the recipient and sender addresses are not yet verified or expanded. The plug-in developer is responsible for handling this.
PreSMTPDeliver plug-ins are called just before the message is handed off to another host, at the PreSMTPDeliver entry point. These SMTP plug-ins are best for adding or removing message recipients.
NOTE:
You can also write plug-ins that act at the PreSMTPAccept stage, before
SMTP has accepted the incoming message and written it to disk. For more
information, see the Protocol Level Plug-in Programmer's Guide. §
You set the processing stage in the configuration file. For more information, see "Configuring SMTP Plug-ins." The user can also set the processing stage through the Netscape Console user interface. For information about this, see the Messaging Server 4.1 Administration Guide.
There are several steps in SMTP plug-in processing. For example, this is the sequence that a PostSMTPAccept plug-in takes with a message:
PostSMTPAccept plug-in, the message must first be accepted by the server. After this, the SMTP plug-in is called with the message. Message structure that points to the file that contains the entire message, including the header and body information.
name:value pair format that include all envelope information, such as sender, recipients, sender and per-recipient extensions, and so on. Message structure is passed into the SMTP plug-in through the main plug-in function, which must be based on the pFunc function prototype.
The configuration data accessed by the Messaging Server Plug-in API is specific to Netscape Messaging Server. This data is stored in the plugins.cfg file in serverroot/instance/smtp-bin/plugins/.
Configuration data for a message is passed to the SMTP plug-in through the plug-in initialization function, which must be based on the pInitFunc function prototype. Once loaded, the configuration data should be maintained by the plug-in. If several "function" entry points for a single plug-in exist, the server calls them in the order in which they appear in the plugins.cfg configuration file. See "Configuring SMTP Plug-ins."
Messaging Server 4.1 is multithreaded; make sure that your plug-in code is thread-safe. If possible, avoid using global variables. If you do, make sure that they are synchronized to avoid multiple calls to the plug-in. For example, the globals could be encapsulated in a class that synchronizes access.
SMTP plug-ins for 4.x servers should handle restartable system calls, such as signals.
[Top]
plugins.cfg, in serverroot/instance/smtp-bin/plugins/. This file contains the configuration data for all installed SMTP plug-ins. You can also change plug-in configuration or deactivate an installed plug-in by editing this file.
Each plug-in is listed with its configuration information on its own line in the file, in the order in which it was installed in Messaging Server. The plug-ins will execute in this order as well. When an SMTP plug-in is initialized, Messaging Server passes the configuration information, which includes the path to the executable code, to the plug-in's pblock structure.
To deactivate an installed plug-in, place a number sign character (#) at the beginning of its line to comment it out.
SMTP plug-in configuration data has this format:
stagepluginPathfuncs=function[,function] init=<function>
optionParam[optionParam]
The parameters have the following descriptions:optionParam=param-name=param-value
libxlate.so at the PostSMTPAccept stage of message processing to decode the message, and at the PreSMTPDeliver stage to encode it:
PostSMTPAccept /foo/bar/libxlate.so funcs=decode-euc init=decode-init
PreSMTPDeliver /foo/bar/libxlate.so funcs=encode-iso init=encode-initIn the first line of the example, the SMTP plug-in acts at the
no-xlate-domains="*.kr"
PostSMTPAccept message processing stage, and gives the full path to its library file, libxlate.so. The funcs list implements the plug-in function decode-euc. The init list implements the plug-in's initialization function, decode-init.
In the second line of the example, the SMTP plug-in acts at the PreSMTPDeliver stage and calls the plug-in by giving the full path its library file, libxlate.so. The funcs list implements the plug-in function, encode-iso. The init list implements the plug-in's initialization function, encode-init. This line sets a single option, directing the plug-in not to encode messages from the top-level domain .kr.
libxlate.dll at the PostSMTPAccept stage of message processing to decode the message, and at the PreSMTPDeliver stage to encode it:
PostSMTPAccept d:\plugins\libxlate.dll funcs=decode-euc
init=decode-init
PreSMTPDeliver d:\plugins\libxlate.dll funcs=encode-isoIn the first line of the example, the SMTP plug-in acts at the
init=encode-init no-xlate-domains="*.kr"
PostSMTPAccept message processing stage, and gives the full path to its library file, libxlate.dll. The funcs list implements the plug-in function decode-euc. The init list implements the plug-in's initialization function, decode-init.
In the second line of the example, the SMTP plug-in acts at the PreSMTPDeliver stage and calls the plug-in by giving the full path of its library file, libxlate.dll. The funcs list implements the plug-in function, encode-iso. The init list implements the plug-in's initialization function, encode-init. This line sets a single option, directing the plug-in not to encode messages from the top-level domain .kr.
NOTE: For more information about the configuration file, including its location in Messaging Server, see Chapter 7, "Working With SMTP Plug-Ins," in the Messaging Server 4.1 Administration Guide. §[Top]
makefile with the sample code file, sample.c, results in a shared object named sample.o.
NOTE: You can download a zip file,uplugin.zip, that contains the sample plug-in filesample.candmakefile. §
# Sample Makefile for Netscape Messaging Server SMTP plug-in
# Name of the plug-in to build:
TARGET=sample
# Use one of the following"
SHARED_SUFFIX=so
# Use one of the following:
CC=gcc -fPIC -I../include -shared
#CC=cc -KPIC -I../include -G
# Use one of the following:
FLAGS = -DXP_UNIX
#FLAGS = -DXP_WIN32
# Use zero or more of the following:
#FLAGS += -D_DEBUG
all: $(TARGET).$(SHARED_SUFFIX)
$(TARGET).$(SHARED_SUFFIX): $(TARGET).c ../include/msg4plugins.h
$(CC) $(FLAGS) -o $(TARGET).$(SHARED_SUFFIX) $(TARGET).c
sample.o
clean:
rm -f $(TARGET).$(SHARED_SUFFIX)
libns.lib as well as libstore.lib. You can find these in the Messaging Server installation in this directory: serverroot\plugins\lib. The result of building the sample code file, sample.c, results in a shared object named sample.dll.
NOTE: You can download a zip file,[Top] [Building the SMTP Plug-in]wplugin.zip, that contains the sample plug-in filesample.c. §
Last Updated: 05/13/99 11:41:54