Problem ClamAV wih MTA.

Hi Sun!
I use 5 servers for deploy messaging, 1 for MTA, 1 for message store and another server for directory, da, am, im/cal, sun convergence. MTA have a public IP address X.X.X.X, message store have a private IP Y.Y.Y.Y
I deploy a difference server for clamav with public IP Z.Z.Z.Z
File configs on MTA server as follow:
clamav.opt
debug=1
host=Z.Z.Z.Z
port=3310
mode=1 option.dat
spamfilter2_config_file=/opt/SUNWmsgsr/config/clamav.opt
spamfilter2_library=/opt/sun/comms/messaging64/lib/libclamav.so
spamfilter2_string_action=data:,require ["jettion"]; jettison;
spamfilter2_optional=1imta.cnf
! ims-ms
ims-ms defragment subdirs 20 notices 1 7 14 21 28 backoff "pt5m" "pt10m" "pt30m" "pt1h" "pt2h" "pt4h" maxjobs 2 pool IMS_POOL filein
to $U+$S@$D destinationspamfilter1optin spam destinationspamfilter2optin virus
ims-ms-daemonOn clamav server, i start clamd as follow:
/opt/ClamAV/sbin/clamdClamAV start normal and don't have any error appear. Between MTA server and ClamAV don't have firewall, on MTA server, i can telnet to clamav server with port 3310.
When I try to send an email to test clamav, in tcp_local log on MTA server, i don't see any entry about clamav.
Anyone help me !!!
./clamd --v
ClamAV 0.95.2/9843/Mon Sep 28 09:23:36 2009
./imsimta version
Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)
libimta.so 7u2-7.02 64bit (built 02:28:03, Apr 16 2009)
Using /opt/sun/comms/messaging64/config/imta.cnf (compiled)
SunOS MTA 5.10 Generic_139556-08 i86pc i386 i86pc

NguyenPhuc wrote:
When I try to send an email to test clamav, in tcp_local log on MTA server, i don't see any entry about clamav.Refer to the "Testing ClamAV" section here:
http://wikis.sun.com/display/CommSuite/Integrating+Spam+and+Virus+Filtering+Programs+Into+Messaging+Server
Did you run "./imsimta cnbuild;./imsimta restart" after changing imta.cnf?
Also please provide the mail.log_current entry matching your email delivery attempt that wasn't filtered.
Regards,
Shane.
Edited by: shjorth on Oct 19, 2009 5:10 PM

Similar Messages

Problem with firewire bus

working in final cut pro, when i now plug drives into to frontside firewire 800 port they are running very slowly and when playing a clip fcp freezes up and i have to force quit. when i plug the drives into the backside fw port or use on my macbook pro they work fine so i'm pretty sure problem is wih frontside port. the device does show up on the system profiler. is there a way to tell from that there's a performance problem. are there any easy fixes for the port? is there a way to reset the bus. thanks.

unplugging is not 100% reliable resetting the SMC.
Hitting the power on button for 10 seconds while unplugged (and everything else too) may.
The older models like 3,1 all had different directions when they came out (1,1 and 2,1 even have a physical SMC button yu can access and use).

GWIA not clearing files in MTA Outgoing Queue folders

Hi All,
I posted this in the GW8 Agents forums about a week ago, but to day no replies.
Here's my problem:
Over the last few weeks we upgraded and migrated our older Gw7Sp3 (NW65Sp8) server to GW8Sp2Hp2 on Sles10. We did have a number of teething issues, but they were resolved with a couple of configuration changes and applying Sp2 Hp2.
Now we have found a problem with incoming email. Outgoing email is not effected and we have tracked the problem to the MTA's outgoing queue which if the internet agents input queue (domain\wpgate\gwia\wpcsout\gwXXXX\0-7). The contents of the folder starts to build up as each outgoing item is processed. The MTA\Gwia is not flushing the queues, once the outgoing email is processed and sent. The email record in the queues are being left behind with a filesize of 0kb.
It is these 0kb files that is causing the problem. When the number of files builds up, delivery of email starts to slow. Either the MTA\Gwia sees the contents of the outgoing queue and is prioritising them ahead of the incoming email. The flow on affect is that the incoming email is held in the Gwia's Receive folder and only one received item is processed and relayed to the MTA at a time.
When I delete all the 0kb files in the MTA's outgoing queues, the held incoming email is cleared quite quickly.
Can anyone suggest where I should start to look at resolving this.
regards
Alan

Thanks Massimo,
I'll organise that for after work today and report back.
I am assuming that the agents are running as root, but will check.
cheers
Alan
>>> Massimo Rosen<[email protected]> 31/5/2011 3:58 PM >>>
On 31.05.2011 04:55, Alan Lew wrote:
> Hi All,
> I posted this in the GW8 Agents forums about a week ago, but to day no replies.
> Here's my problem:
> Over the last few weeks we upgraded and migrated our older Gw7Sp3 (NW65Sp8)
> server to GW8Sp2Hp2 on Sles10. We did have a number of teething issues, but they
> were resolved with a couple of configuration changes and applying Sp2 Hp2.
> Now we have found a problem with incoming email. Outgoing email is not effected
> and we have tracked the problem to the MTA's outgoing queue which if the
> internet agents input queue (domain\wpgate\gwia\wpcsout\gwXXXX\0-7). The
> contents of the folder starts to build up as each outgoing item is processed.
> The MTA\Gwia is not flushing the queues, once the outgoing email is processed
> and sent. The email record in the queues are being left behind with a filesize
> of 0kb.
> It is these 0kb files that is causing the problem. When the number of files
> builds up, delivery of email starts to slow. Either the MTA\Gwia sees the
> contents of the outgoing queue and is prioritising them ahead of the incoming
> email. The flow on affect is that the incoming email is held in the Gwia's
> Receive folder and only one received item is processed and relayed to the MTA at
> a time.
> When I delete all the 0kb files in the MTA's outgoing queues, the held incoming
> email is cleared quite quickly.
> Can anyone suggest where I should start to look at resolving this.
> regards
> Alan
I'd start with stopping groupwise, delete the whole queue directories,
then restart the agents. They'll recreate them, and it should start working.
Are the agents running as root?
CU,
Massimo Rosen
Novell Product Support Forum Sysop
No emails please!
http://www.cfc-it.de

Filter Coding Issues

I've been following (roughly) the simple virus scanner interface that SUN provides, and adapted it into a slightly heavier weight filter that interfaces with libclamav. At first both were compiled using GCC, and I thought due to some of the weird problems I had when debugging flags were inserted, maybe Sun Studio would give better results. It hasn't, and I'm at a bit of a loss as to what to do next.
The symptom is that parts of the message just dissapear, and I see the old mime boundaries within the message body, so it seems like there's some pointer indicating where the message starts that's being corrupted by something in my code.
Interestingly, if I stop processing the message while still inside the headers, there is no problem, but that's not a very effective virus scanner if it can only look at the content type and filename of the part now is it?
This happens regardless of whether I use GCC or CC, and I'm using 0.88.1 of clamav. The output message is shown last. It should be fairly obvious what's wrong with it.
Here's my code, perhaps someone can tell me what I'm doing wrong.
** WARNING ** This IS NOT polished code, so please don't expect it to be perfect. It's clean, but includes absolute pathnames, and some other nauties that should be removed before anyone even thinks of reusing this. Once it actually works, I'll do the nessisary code cleanup, and release this to the community to do whatever anyone wants with.
Makefile
SERVER_ROOT=/opt/SUNWmsgsr
INSTALL_LOCATION=/var/opt/SUNWmsgsr/site-programs/
INCLUDE=-I${SERVER_ROOT}/include
LIBPATH=-L${SERVER_ROOT}/lib
CLAMLIBS=`/usr/local/bin/clamav-config --libs` -lclamav
CLAMFLAGS=`/usr/local/bin/clamav-config --cflags`
LIBS=-lmtasdk ${CLAMLIBS}
FLAGS=${CLAMFLAGS}
all:
        cc ${FLAGS} -o msgsr_clamav msgsr_clamav.c \
                ${INCLUDE} ${LIBPATH} ${LIBS}
install:
        cp msgsr_clamav ${INSTALL_LOCATION}
        cp msgsr_clamav.cnf ${INSTALL_LOCATION}************************************************
Expansions
CLAMLIBS=-L/usr/local/lib -lz -lbz2 -lpthread -lclamav
CLAMFLAGS=-I/usr/local/include -xO4************************************************
msgsr_clamav.c
* msgsr_clamav
* Interface the Sun Java System Message Server with LibClamAV
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ctype.h>
#include <pthread.h>
#include "clamav.h"     // LibClamAV Header
#include "mtasdk.h"
* A structure to store channel options
typedef struct {
     /* Produce debug output? */
     int debug;
     // Maximum size (in bytes) attachment to scan
     int scan_maxsize;
     // Scan recursion level
     int scan_recursion_level;
     // Max files
     int scan_maxfiles;
     // Path to ClamAV Virus Database
     char db_dir[BIGALFA_SIZE+3];
     // Used Internally by ClamAV. Stored here for ease of access
     struct cl_node *root;
     unsigned int signo;
     struct cl_stat dbstat;
     pthread_mutex_t reload_mutex;
     // MIME types to ignore
     char ignore_mime_types[BIGALFA_SIZE+3];
     // Types of files to ignore
     char ignore_file_types[BIGALFA_SIZE+3];
     /* Unwanted MIME content types (ALWAYS stripped, never scanned) */
     char bad_mime_types[BIGALFA_SIZE+3];
     /* Unwanted file types (ALWAYS stripped, never scanned)*/
     char bad_file_types[BIGALFA_SIZE+3];
     /* Length of bmt string */
     size_t bmt_len;
     /* Length of bft string */
     size_t bft_len;
} our_options_t;
// A structure passed per message to contain message specific data, including open files, etc.
typedef struct {
     // The filename of the temp file in use so it can be unlinked when we're done with it.
     char temp_file_name[BIGALFA_SIZE * 2 + 10];
     // The file * to the temp file in use, so we don't have to reopen it across calls to decode_inspect
     FILE *temp_file;
     // A pointer to the single instance of our_options_t that is shared across all threads
     our_options_t * options;
} msg_temp_data_t;
* Forward declarations
static void error_exit(int ires, const char *msg);
static void error_report(our_options_t *options, int ires, const char *func);
static void error_reports(our_options_t *options, const char* errStr, const char *func);
static int is_bad_mime_type(our_options_t *options, mta_decode_t *dctx, char *buf, size_t maxbuflen);
static int is_bad_file_type(our_options_t *options, mta_opt_t *params, const char *param_name, char *buf, size_t maxbuflen);
static int load_options(our_options_t *options);
static mta_dq_process_message_t process_message;
static mta_decode_read_t decode_read;
static mta_decode_inspect_t decode_inspect;
* main() -- Initialize the MTA SDK, load our options, and then
* start the message processing loop.
int main()
     int ires,ret;
     char error_msg[BIGALFA_SIZE+3];
     our_options_t options;
     * Initialize the MTA SDK
     * See explanatory comment 1
     if ((ires = mtaInit(0)))
          error_exit(ires, "Unable to initialize the MTA SDK");
     * Load our channel options
     * See explanatory comment 2
     if ((ires = load_options(&options)))
          error_exit(ires, "Unable to load our channel options");
     * Initialize the ClamAV Virus Engine and Database
     // Preconditions to initializing the ClamAV database
     options.root=NULL; options.signo=0;
     // Load the virus database
     mtaLog("cl_loaddbdir() loading database from %s",options.db_dir);
     if ((ret = cl_loaddbdir(options.db_dir, &options.root, &options.signo)))
          sprintf(error_msg,"cl_loaddbdir() error: %s", cl_strerror(ret));
          error_exit(MTA_NO,error_msg);
     mtaLog("cl_loaddbdir() loaded %d virus definitions",options.signo);
     // Internalize the virus database structure
     mtaLog("cl_build() initializing database");
     if((ret = cl_build(options.root)))
          sprintf(error_msg,"cl_build() error: %s", cl_strerror(ret));
          error_exit(MTA_NO,error_msg);
     // Keep track of database updates
     memset(&options.dbstat, 0, sizeof(struct cl_stat));
     cl_statinidir(options.db_dir, &options.dbstat);
     // Initialize our reload mutex
     if (ret = pthread_mutex_init(&options.reload_mutex,NULL))
          sprintf(error_msg,"pthread_mutex_init() error: %d", ret);
          error_exit(MTA_NO,error_msg);
     * Now process the queued messages. Be sure to indicate a
     * thread stack size sufficient to accomodate message
     * enqueue processing.
     * See explanatory comment 3
     if ((ires = mtaDequeueStart((void *)&options,
     process_message, NULL, 0)))
     error_exit(ires, "Error during dequeue processing");
     * All done
     cl_free(options.root);
     mtaDone();
     return(0);
*Reloads the virus database and re-initializes the in memory structure
* Loads a new virus database, then if all succeeds, it
* swaps the new database with the old one. It's assumed
* clamav releases the database gracefully, but another mutex
* may be required if this is not the case.
static int reload_database(our_options_t *options)
     struct cl_node *newroot = NULL,*oldroot;
     char error_msg[BIGALFA_SIZE+3];
     int ret;
     unsigned int signo=0;
     if (pthread_mutex_trylock(&options->reload_mutex)) {     // Only one reload at a time thank you.
          if(cl_statchkdir(&options->dbstat) == 1) {     // Make sure we actually need an update
               mtaLog("reload_database() Virus database is stale... reloading");
               mtaLog("cl_loaddbdir() reloading database from %s",options->db_dir);
               // Load the new virus database
               if ((ret = cl_loaddbdir(options->db_dir, &newroot, &signo)))
                    mtaLog("cl_loaddbdir() error: %s", cl_strerror(ret));
                    return (-1);
               mtaLog("cl_loaddbdir() loaded %d virus definitions",options->signo);
               // Internalize the virus database structure
               mtaLog("cl_build() re-initializing database");
               if((ret = cl_build(newroot)))
                    mtaLog("cl_build() error: %s", cl_strerror(ret));
                    mtaLog("reload_database() Database reload aborted");
                    cl_free(newroot);
                    return (-2);
               // Save a pointer to the old root
               oldroot = options->root;
               // Swap in the new root and signo
               options->root = newroot;
               options->signo = signo;
               // Release the old root
               cl_free(oldroot);
               mtaLog("database_reload() Successfully loaded new virus database");
               // Keep track of database updates
               cl_statfree(&options->dbstat);
               cl_statinidir(options->db_dir, &options->dbstat);
          pthread_mutex_unlock(&options->reload_mutex);
* process_message() -- This routine is called by
* mtaDequeueStart() to process each queued
* message. We don稚 make use of ctx2, but
* ctx1 is a pointer to our channel options.
* See explanatory comment 4
static int process_message(void **ctx2, void *ctx1, mta_dq_t *dq, const char *env_from, size_t env_from_len)
     const char *adr;
     int disp, ires;
     size_t len;
     mta_nq_t *nq;
     msg_temp_data_t msg_data;
     * Initializations
     nq = NULL;
     msg_data.options = (our_options_t *)ctx1;
     msg_data.temp_file = NULL;
     * Check the virus database to make sure it isn't stale
     * If it it's not currently reloading, and is stale, reload it.
     //if(cl_statchkdir(&(msg_data.options->dbstat)) == 1)
     //     reload_database(msg_data.options);
     * A little macro to do error checking on mta*() calls
     #define CHECK(f,x) \
     if ((ires = x)) { error_report(msg_data.options, ires, f); goto \
          done_bad; }
     * Start a message enqueue. Use the dequeue context to copy
     * envelope flags fromt the current message to this new
     * message being enqueued.
     * See explanatory comment 5
     CHECK("mtaEnqueueStart", mtaEnqueueStart(&nq, env_from, env_from_len, MTA_DQ_CONTEXT, dq, 0));
     * Process the envelope recipient list
     * See explanatory comment 6
     while (!(ires = mtaDequeueRecipientNext(dq, &adr, &len, 0)))
          * Add this envelope recipient address to the message
          * being enqueued. Use the dequeue context to copy
          * envelope flags for this recipient from the current
          * message to the new message.
          ires = mtaEnqueueTo(nq, adr, len, MTA_DQ_CONTEXT,
          dq, MTA_ENV_TO, 0);
          /* See explanatory comment 7 */
          disp = (ires) ? MTA_DISP_DEFERRED : MTA_DISP_RELAYED;
          CHECK("mtaDequeueRecipientDisposition", mtaDequeueRecipientDisposition(dq, adr, len,disp, 0));
     * A normal exit from the loop occurs when
     * mtaDequeueRecipientNext() returns an MTA_EOF status.
     * Any other status signifies an error.
     if (ires != MTA_EOF)
          error_report(msg_data.options, ires, "mtaDequeueRecipientNext");
          goto done_bad;
     * Begin the MIME decode of the message
     * See explanatory comment 8
     CHECK("mtaDecodeMessage",
          mtaDecodeMessage(
          /* Private context is our message data structure */
          (void *)&msg_data,
          /* Input is the message being dequeued */
          MTA_DECODE_DQ, (void *)dq,
          /* Output is the message being enqueued */
          MTA_DECODE_NQ, (void *)nq,
          /* Inspection routine */
          decode_inspect,
          /* Convert non-MIME formats to MIME */
          MTA_DECODE_THURMAN,
          0));
     * Finish the enqueue
     * NOTE: IT担 IMPORTANT TO DO THIS before DOING THE
     * DEQUEUE. YOU WILL LOSE MAIL IF YOU DO THE DEQUEUE FIRST
     * and then THE ENQUEUE FAILS.
     * See explanatory text 9
     CHECK("mtaEnqueueFinish", mtaEnqueueFinish(nq, 0));
     nq = NULL;
     * Finish the dequeue
     CHECK("mtaDequeueFinish", mtaDequeueMessageFinish(dq, 0));
     * All done with this message
     return(MTA_OK);
done_bad:
     * Abort any ongoing enqueue or dequeue
     if (nq)
          mtaEnqueueFinish(nq, MTA_ABORT, 0);
     if (dq)
          mtaDequeueMessageFinish(dq, MTA_ABORT, 0);
     * And return our error status
     return(ires);
#undef CHECK
* decode_inspect() -- This is the routine that inspects each
* message part, deciding whether to accept
* or reject it.
* See explanatory comment 10
static int decode_inspect(void *ctx, mta_decode_t *dctx, int data_type,const char *data, size_t data_len)
     char buf[BIGALFA_SIZE * 2 + 10];
     const char *virname;
     int i;
     static unsigned int part_c = 1;
     msg_temp_data_t *msg_data = (msg_temp_data_t *)ctx;
     strncpy(buf,data,data_len);
     buf[data_len] = 0;
     mtaLog("decode_inspect() (%d,%ud): %s",data_type,dctx,buf);
     switch (data_type)
          case MTA_DATA_HEADER:
          * See if the part has:
          * 1. A bad MIME content-type,
          * 2. A bad file name extension in the (deprecated)
          * NAME= content-type parameter, or
          * 3. A bad file name extension in the
          * FILENAME= content-disposition parameter.
          i = 0;
          if ((i = is_bad_mime_type((void *)msg_data->options, dctx, buf, sizeof(buf))) ||
               is_bad_file_type((void *)msg_data->options,mtaDecodeMessageInfoParams(dctx,MTA_DECODE_CTYPE_PARAMS, NULL),"NAME", buf, sizeof(buf)) ||
               is_bad_file_type((void *)msg_data->options,mtaDecodeMessageInfoParams(dctx,MTA_DECODE_CDISP_PARAMS, NULL),"FILENAME", buf, sizeof(buf)))
               char msg[BIGALFA_SIZE*4 + 10];
               * Replace this part with a text message indicating
               * that the part痴 content has been deleted.
               * See explanatory comment 11
               if (i)
                    i = sprintf(msg,
                         "The content of this message part has been removed.\n"
                         "It contained a potentially harmful media type of %.*s",
                         strlen(buf)-2, buf+1);
               else
                    i = sprintf(msg,
                         "The content of this message part has been removed.\n"
                         "It contained a potentially harmful file named '%s'", buf);
               mtaLog("decode_inspect(): %s",msg);
               return(mtaDecodeMessagePartDelete(dctx,
                    MTA_REASON, msg, i,
                    MTA_DECODE_CTYPE, "text", 4,
                    MTA_DECODE_CSUBTYPE, "plain", 5,
                    MTA_DECODE_CCHARSET, "us-ascii", 8,
                    MTA_DECODE_CDISP, "inline", 6,
                    MTA_DECODE_CLANG, "en", 2, 0));
          } break; // case MTA_DATA_HEADER:
          case MTA_DATA_TEXT:
          case MTA_DATA_BINARY:
               if (msg_data->temp_file == NULL)
                    sprintf(msg_data->temp_file_name,"/tmp/%i.tmp",part_c++);
                    mtaLog("messageDecode(): Opening Temp File %s",msg_data->temp_file_name);
                    msg_data->temp_file = fopen(msg_data->temp_file_name,"wb");
               fwrite(data,data_len,1,msg_data->temp_file);
               return(MTA_OK);
               break;
          case MTA_DATA_NONE:
               fflush(msg_data->temp_file);
               fclose(msg_data->temp_file);
               msg_data->temp_file = NULL;
               struct cl_limits limits;
               memset(&limits, 0, sizeof(struct cl_limits));
               /* maximal number of files in archive */;
               limits.maxfiles = 1000;
               /* maximal archived file size */
               limits.maxfilesize = 10 * 1048576; /* 10 MB */
               /* maximal recursion level */
               limits.maxreclevel = 5;
               /* maximal compression ratio */
               limits.maxratio = 200;
               /* disable memory limit for bzip2 scanner */
               limits.archivememlim = 0;
               i = cl_scanfile(msg_data->temp_file_name, &virname, NULL, msg_data->options->root,&limits,CL_SCAN_STDOPT);
               unlink (msg_data->temp_file_name);
               if(i == CL_VIRUS) {
                    char msg[BIGALFA_SIZE*4 + 10];
                    size_t idlen;
                    i = sprintf(msg,
                         "The content of this message part has been removed.\n"
                         "It contained the virus %s in a file named '%s'", virname,buf);
                    mtaDequeueInfo(dctx,MTA_ENV_ID,&buf,&idlen);
                    buf[idlen] = '\0';
                    mtaLog("decode_inspect(): Detected %s virus in part %i of msg ID %s",virname,0,buf);
                    return(mtaDecodeMessagePartDelete(dctx,
                         MTA_REASON, msg, i,
                         MTA_DECODE_CTYPE, "text", 4,
                         MTA_DECODE_CSUBTYPE, "plain", 5,
                         MTA_DECODE_CCHARSET, "us-ascii", 8,
                         MTA_DECODE_CDISP, "inline", 6,
                         MTA_DECODE_CLANG, "en", 2, 0));
               } else {
                    if(i != CL_CLEAN)
                         mtaLog("decode_inspect() Error: %s scanning file %s",cl_strerror(i),msg_data->temp_file_name);
                    else
                         mtaLog("decode_inspect(): Part in file %s is clean",msg_data->temp_file_name);
                    //return(mtaDecodeMessagePartCopy(dctx, 0));
                    return(MTA_OK); break;
     return(MTA_OK);
* is_bad_mime_type() -- See if the part痴 media type is in our
* bad MIME content types, for example:
* application/vbscript
* See explanatory comment 13
static int is_bad_mime_type(our_options_t *options,
mta_decode_t *dctx, char *buf,
size_t maxbuflen)
     const char *csubtype, *ctype;
     size_t i, len1, len2;
     char *ptr;
     * Sanity checks
     if (!options || !options->bmt_len ||
          !options->bad_mime_types[0] ||
          !dctx)
          return(0);
     * Get the MIME content type
     ctype = mtaDecodeMessageInfoString(dctx, MTA_DECODE_CTYPE,NULL, &len1);
     csubtype = mtaDecodeMessageInfoString(dctx,MTA_DECODE_CSUBTYPE,NULL, &len2);
     * Build the string: <0x01>type/subtype<0x01><0x00>
     ptr = buf;
     *ptr++ = (char)0x01;
     for (i = 0; i < len1; i++)
          *ptr++ = tolower(*ctype++);
     *ptr++ = '/';
     for (i = 0; i < len2; i++)
          *ptr++ = tolower(*csubtype++);
     *ptr++ = (char)0x01;
     *ptr = '\0';
     * Now see if the literal just built occurs in the list of
     * bad MIME content types
     return((strstr(options->bad_mime_types, buf)) ? -1 : 0);
* is_bad_file_type() -- See if the part has an associated file
* name whose file extension is in our list
* of bad file names, such as .vbs.
* See explanatory comment 14
static int is_bad_file_type(our_options_t *options,
mta_opt_t *params,
const char *param_name, char *buf,
size_t maxbuflen)
     const char *ptr1;
     char fext[BIGALFA_SIZE+2], *ptr2;
     size_t i, len;
     * Sanity checks
     if (!options || !options->bft_len || !params || !param_name)
          return(0);
     len = 0;
     buf[0] = '\0';
     if (mtaOptionString(params, param_name, 0, buf, &len,
          maxbuflen - 1) ||
          !len || !buf[0])
          * No file name parameter specified
          return(0);
     * A file name parameter was specified. Parse it to
     * extract the file extension portion, if any.
     ptr1 = strrchr(buf, '.');
     if (!ptr1)
          * No file extension specified
          return(0);
     * Now store the string created earlier in fext[]
     * Note that we drop the ・・from the extension.
     ptr1++; /* Skip over the ・・*/
     ptr2 = fext;
     *ptr2++ = (char)0x01;
     len = len - (ptr1 - buf);
     for (i = 0; i < len; i++)
          *ptr2++ = tolower(*ptr1++);
     *ptr2++ = (char)0x01;
     *ptr2++ = '\0';
     * Now return -1 if the string occurs in
     * options->bad_file_types.
     return((strstr(options->bad_file_types, fext)) ? -1 : 0);
* load_options() -- Load our channel options from the channel痴
* option file
* See explanatory comment 15
static int load_options(our_options_t *options)
     char buf[BIGALFA_SIZE+1];
     size_t buflen, i;
     mta_opt_t *channel_opts;
     int ires;
     const char *ptr0;
     char *ptr1;
     * Initialize the our private channel option structure
     memset(options, 0, sizeof(our_options_t));
     * Set internal defaults for important features
     options->scan_maxsize = 10 * 1024 * 1024; // 10 MB
     options->scan_recursion_level = 10;
     options->scan_maxfiles = 200;
     strcpy(options->db_dir,cl_retdbdir()); // Default ClamAV Directory
     * Access the channel痴 option file
     * See explanatory comment 16
     channel_opts = NULL;
     if ((ires = mtaOptionStart(&channel_opts, "/var/opt/SUNWmsgsr/site-programs/msgsr_clamav.cnf", 0, 0)))
          mtaLog("Unable to access our channel option file");
          return(ires);
     * DEBUG=0|1
     options->debug = 0;
     mtaOptionInt(channel_opts, "DEBUG", 0, &options->debug);
     if (options->debug)
          mtaDebug(MTA_DEBUG_SDK, 0);
     * BAD_MIME_TYPES=type1/subtype1[,type2/subtype2[,...]]
     buf[0] = '\0';
     mtaOptionString(channel_opts, "BAD_MIME_TYPES", 0, buf,
     &buflen, sizeof(buf));
     * Now translate the comma separated list:
     * Type1/Subtype1[,Type2/Subtype2[,...]]
     * to
     *<0x01>type1/subtype1[<0x01>type2/subtype2[<0x01>...]]<0x01>
     ptr0 = buf;
     ptr1 = options->bad_mime_types;
     *ptr1++ = (char)0x01;
     for (i = 0; i < buflen; i++)
          if (*ptr0 != ',')
               *ptr1++ = tolower(*ptr0++);
          else
               *ptr1++ = (char)0x01;
               ptr0++;
     *ptr1++ = (char)0x01;
     *ptr1 = '\0';
     options->bmt_len = ptr1 - options->bad_mime_types;
     * BAD_FILE_TYPES=["."]Ext1[,["."]Ext2[,...]]
     buf[0] = '\0';
     buflen = 0;
     mtaOptionString(channel_opts, "BAD_FILE_TYPES", 0, buf,
     &buflen, sizeof(buf));
     * Now translate the comma separated list:
     * ["."]Ext1[,["."]Ext2[,...]]
     * to
     * <0x01>ext1[<0x01>ext2[<0x01>...]]<0x01>
     ptr0 = buf;
     ptr1 = options->bad_file_types;
     *ptr1++ = (char)0x01;
     for (i = 0; i < buflen; i++)
          switch(*ptr0)
               default : /* copy after translating to lower case */
                    *ptr1++ = tolower(*ptr0++);
                    break;
               case '.' : /* discard */
                    break;
               case ',' : /* end current type */
                    *ptr1++ = (char)0x01;
                    ptr0++;
               break;
     *ptr1++ = (char)0x01;
     *ptr1 = '\0';
     options->bft_len = ptr1 - options->bad_file_types;
     * Dispose of the mta_opt_t context
     * See explanatory comment 17
     mtaOptionFinish(channel_opts);
     * And return a success
     return(MTA_OK);
* error_report() ・Report an error condition when debugging is
* enabled.
static void error_report(our_options_t *options, int ires,
const char *func)
     if (options->debug)
          mtaLog("%s() returned %d; %s",
               (func ? func : "?"), ires, mtaStrError(ires,0));
static void error_reports(our_options_t *options, const char* errStr,
const char *func)
     if (options->debug)
          mtaLog("%s() reported: %s",
               (func ? func : "?"), errStr);
* error_exit() -- Exit with an error status and error message.
static void error_exit(int ires, const char *msg)
     mtaLog("%s%s%s", (msg ? msg : ""), (msg ? "; " : ""),
     mtaStrError(ires,0));
     exit(1);
msgsr_clamav.cnf
DEBUG=1
BAD_MIME_TYPES=application/vbscript
BAD_FILE_TYPES=bat,pif,vb,vbs,chs,exe************************************************
broken message
Return-path: <[email protected]>
Received: from virusscan-daemon.apple.california.com by apple.california.com
(Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
id <[email protected]> for [email protected]; Thu,
20 Apr 2006 07:30:13 -0700 (PDT)
Received: from california.com ([209.159.129.16])
by apple.california.com (Sun Java System Messaging Server 6.2-3.04 (built Jul
15 2005)) with ESMTP id <[email protected]> for
[email protected]; Thu, 20 Apr 2006 07:30:05 -0700 (PDT)
Received: from [61.23.221.222] by apple.california.com (mshttpd); Thu,
20 Apr 2006 14:30:05 +0000 (GMT)
Content-return: allowed
Date: Thu, 20 Apr 2006 14:30:05 +0000 (GMT)
From: [email protected]
Subject: Re: testing
In-reply-to: <[email protected]>
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-3.04 (built Jul 15 2005)
Content-type: multipart/alternative;
boundary="Boundary_(ID_iOVR4MBjhWJn/mh7Ij+BUQ)"
Content-language: en
X-Accept-Language: en
Priority: normal
References: <[email protected]>
Original-recipient: rfc822;[email protected]
This is a multi-part message in MIME format.
--Boundary_(ID_iOVR4MBjhWJn/mh7Ij+BUQ)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Content-disposition: inline
Data is missing from here
----ec04832708e231d6e2f
--Boundary_(ID_iOVR4MBjhWJn/mh7Ij+BUQ)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: quoted-printable
Content-disposition: inline
Data is missing from here
nal Message -----=3Cbr=3EFrom=3A chales=40california=2Ecom=3Cbr=3EDate=3A=
Thursday=2C April 20=2C 2006 11=3A19 pm=3Cbr=3ESubject=3A testing=3Cbr=3E=
To=3A chales=40california=2Ecom=3Cbr=3E=3Cbr=3E=26gt=3B 2=3Cbr=3E=26gt=3B=
3=3Cbr=3E=26gt=3B 4=3Cbr=3E=26gt=3B 5=3Cbr=3E=26gt=3B 6=3Cbr=3E=26gt=3B=
7=3Cbr=3E=26gt=3B 8=3Cbr=3E=26gt=3B 9=3Cbr=3E=26gt=3B 0=3Cbr=3E=26gt=3B=
1=3Cbr=3E=26gt=3B 2=3Cbr=3E=26gt=3B 3=3Cbr=3E=26gt=3B 4=3Cbr=3E=26gt=3B=
5=3Cbr=3E=26gt=3B 6=3Cbr=3E=26gt=3B 7=3Cbr=3E=26gt=3B 8=3Cbr=3E=26gt=3B=
9=3Cbr=3E=26gt=3B 0=3Cbr=3E=26gt=3B 1=3Cbr=3E=26gt=3B 2=3Cbr=3E=26gt=3B=
3=3Cbr=3E=26gt=3B 4=3Cbr=3E=26gt=3B 5=3Cbr=3E=26gt=3B 6=3Cbr=3E=26gt=3B=
7=3Cbr=3E=26gt=3B 8=3Cbr=3E=26gt=3B 9=3Cbr=3E=26gt=3B 0=3Cbr=3E=26gt=3B=
1=3Cbr=3E=26gt=3B 2=3Cbr=3E=26gt=3B 3=3Cbr=3E=26gt=3B 4=3Cbr=3E=26gt=3B=
5=3Cbr=3E=26gt=3B 6=3Cbr=3E=26gt=3B 7=3Cbr=3E=26gt=3B 8=3Cbr=3E=26gt=3B=
9=3Cbr=3E=26gt=3B 0=3Cbr=3E=26gt=3B 1=3Cbr=3E=26gt=3B 2=3Cbr=3E=26gt=3B=
3=3Cbr=3E=26gt=3B 4=3Cbr=3E=26gt=3B 5=3Cbr=3E=26gt=3B 6=3Cbr=3E=26gt=3B=
7=3Cbr=3E=26gt=3B 8=3Cbr=3E=26gt=3B 9=3Cbr=3E=26gt=3B 0=3Cbr=3E=26gt=3B=
1=3Cbr=3E=26gt=3B 2=3Cbr=3E=26gt=3B 3=3Cbr=3E=26gt=3B 4=3Cbr=3E=26gt=3B=
5=3Cbr=3E=26gt=3B 6=3Cbr=3E=26gt=3B 7=3Cbr=3E=26gt=3B 8=3Cbr=3E=26gt=3B=
9=3Cbr=3E=26gt=3B 0=3Cbr=3E=26gt=3B 1=3Cbr=3E=26gt=3B 2=3Cbr=3E=26gt=3B=
3=3Cbr=3E=26gt=3B 4=3Cbr=3E=26gt=3B 5=3Cbr=3E=26gt=3B 6=3Cbr=3E=26gt=3B=
7=3Cbr=3E=26gt=3B 8=3Cbr=3E=26gt=3B 9=3Cbr=3E=26gt=3B 0=3Cbr=3E=26gt=3B=
1=3Cbr=3E=26gt=3B 2=3Cbr=3E=26gt=3B 3=3Cbr=3E=26gt=3B 4=3Cbr=3E=26gt=3B=
5=3Cbr=3E=26gt=3B 6=3Cbr=3E=26gt=3B 7=3Cbr=3E=26gt=3B 8=3Cbr=3E=26gt=3B=
9=3Cbr=3E=26gt=3B 0=3Cbr=3E=26gt=3B 1=3Cbr=3E=26gt=3B 2=3Cbr=3E=26gt=3B=
3=3Cbr=3E=26gt=3B 4=3Cbr=3E=26gt=3B 5=3Cbr=3E=26gt=3B 6=3Cbr=3E=26gt=3B=
7=3Cbr=3E=26gt=3B 8=3Cbr=3E=26gt=3B 9=3Cbr=3E=26gt=3B 0=3Cbr=3E=26gt=3B=
1=3Cbr=3E=26gt=3B 2=3Cbr=3E=26gt=3B 3=3Cbr=3E=26gt=3B 4=3Cbr=3E=26gt=3B=
5=3Cbr=3E=26gt=3B 6=3Cbr=3E=26gt=3B 7=3Cbr=3E=26gt=3B 8=3Cbr=3E=26gt=3B=
9=3Cbr=3E=26gt=3B 0=3Cbr=3E=26gt=3B 1=3Cbr=3E=26gt=3B 2=3Cbr=3E=26gt=3B=
3=3Cbr=3E=26gt=3B 4=3Cbr=3E=26gt=3B 5=3Cbr=3E=26gt=3B 6=3Cbr=3E=26gt=3B=
7=3Cbr=3E=26gt=3B 8=3Cbr=3E=26gt=3B 9=3Cbr=3E=26gt=3B 0=3Cbr=3E=26gt=3B=
1=3Cbr=3E=26gt=3B 2=3Cbr=3E=26gt=3B 3=3Cbr=3E=26gt=3B 4=3Cbr=3E=26gt=3B=
5=3Cbr=3E=26gt=3B 6=3Cbr=3E=26gt=3B 7=3Cbr=3E=26gt=3B 8=3Cbr=3E=26gt=3B=
9=3Cbr=3E=26gt=3B 0=3Cbr=3E=26gt=3B 1=3Cbr=3E=26gt=3B 2=3Cbr=3E=26gt=3B=
3=3Cbr=3E=26gt=3B 4=3Cbr=3E=26gt=3B 5=3Cbr=3E=26gt=3B 6=3Cbr=3E=26gt=3B=
7=3Cbr=3E=26gt=3B 8=3Cbr=3E=26gt=3B 9=3Cbr=3E=26gt=3B 0=3Cbr=3E=26gt=3B=
1=3Cbr=3E=26gt=3B 2=3Cbr=3E=26gt=3B 3=3Cbr=3E=26gt=3B 4=3Cbr=3E=26gt=3B=
5=3Cbr=3E=26gt=3B 6=3Cbr=3E=26gt=3B 7=3Cbr=3E=26gt=3B 8=3Cbr=3E=26gt=3B=
9=3Cbr=3E=26gt=3B 0=3Cbr=3E=26gt=3B 1=3Cbr=3E=26gt=3B 2=3Cbr=3E=26gt=3B=
3=3Cbr=3E=26gt=3B 4=3Cbr=3E=26gt=3B 5=3Cbr=3E=26gt=3B 6=3Cbr=3E=26gt=3B=
7=3Cbr=3E=26gt=3B 8=3Cbr=3E=26gt=3B 9=3Cbr=3E=26gt=3B 0=3Cbr=3E=26gt=3B=
1=3Cbr=3E=26gt=3B 2=3Cbr=3E=26gt=3B 3=3Cbr=3E=26gt=3B 4=3Cbr=3E=26gt=3B=
5=3Cbr=3E=26gt=3B 6=3Cbr=3E=26gt=3B 7=3Cbr=3E=26gt=3B 8=3Cbr=3E=26gt=3B=
9=3Cbr=3E=26gt=3B 0=3Cbr=3E=26gt=3B =3Cbr=3E=26gt=3B
----ec04832708e231d6e2f
--Boundary_(ID_iOVR4MBjhWJn/mh7Ij+BUQ)
Content-type: text/x-vcard; name=chales.vcf; charset=us-ascii
Content-transfer-encoding: base64
Content-disposition: attachment; filename=chales.vcf
Content-description: Card for <[email protected]>
bA0KdGVsO3dvcms6NTEwLTI4Ny04NDUwDQp1cmw6aHR0cDovL3d3dy5jYWxpZm9ybmlh
LmNvbS8NCm9yZzpDYWxpZm9ybmlhQ29tLCBJbmM7DQp2ZXJzaW9uOjIuMQ0KZW1haWw7
aW50ZXJuZXQ6Y2hhbGVzQGNhbGlmb3JuaWEuY29tDQp0aXRsZTpTeXN0ZW0gQWRtaW5p
c3RyYXRvcg0KZW5kOnZjYXJkDQo=
----ec04832708e231d6e2f--
Boundary_(ID_iOVR4MBjhWJn/mh7Ij+BUQ)

Ok, so it's not my code. Using the virus_scanner_simple.c example from SUN, if you change the decode_inspect routine to return MTA_OK for every call (which should technically just let the message pass) it has the same behavior as my program. (Not all that suprising since mine is a derivative of said program)
That said, this now looks like a library issue. I'm using Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005) according to the SMTP prompt, and was wondering if perhaps I should apply:
http://sunsolve.sun.com/search/document.do?assetkey=1-21-118207-42-1&searchclause=6306404
The issue seems to be in the mtaDecodeMessage function, and occurs when the decode_inspect function is allowed to parse the message body, not just the message headers.
The machine is a Sun Ultra 4500 running Solaris 10. Here's the banner:
SunOS cookie 5.10 Generic_118822-23 sun4u sparc SUNW,Ultra-Enterprise
Has anyone else had similar problems using the MTA SDK? Is there anything I'm missing here (besides the above mentioned patch) that might fix this?

Windows XP on Macbook Pro - Control Panel settings

I've been a Windows user for years, and now find that I still require my Toshiba laptop on my desk beside my Macbook Pro.
My problem today wih the MBP is problems while in Windows XP with the Control Panel. I continually reset the regional time zone settings, apply, and the computer resets back to its "own" region as soon as it is shutdown. The settings won't keep also if using screen savers, etc. in the Windows environment. I've looked through the questions in the forum, and this seems to be minor and of no problem to anyone else, but I am totally frustrated. Any help is greatly appreciated!
I also thought the infrared in the MBP which allows use of the remote, would also work in Windows. It does not which creates a problem for accessories that require infrared transmission which won't transmit on the MBP in either environment. Back to the old computer for that problem.
Thanks.

I would make sure that you have run the latest MacBook Pro Firmware upgrade from the apple support site
http://www.apple.com/support/downloads/macbookproefifirmwareupdate12.html.
This may fix certain issues with those settings not saving. Also try resetting the PRAM. From what I have been told the infrared port on the intel Macs only works with the Apple Remote.
Hope this helps.

Early 2011 macbook pro, windows 8.1 bootcamp crashes

Hi,
I have some problems with running windows 8.1 on my macbook. I have managed to manipulate Bootcamp so I can create a bootable USB, the installation went fine and windows is booting correctly. The problem I have is with the installation of the bootcamp drivers. During the installation of the intel Video drivers I get a BSOD and shows me the following SYSTEM_THREAD_EXCEPTION_NOT_HANDLED(igdkmd64.sys). I already troubleshooted the problem and now the problem is wih the intel hd graphics 3000 drivers. and tried the following to fix the problem.
-     Follow the normal apple bootcamp installation.
-     Try the installation of the newest intel drivers.
-     Use windows update to search for drivers
-     Tried multiple installation and windows 8.1 copies.
this all ended in the same result during the installation, a crash with the same error. This crash also happens when I am not trying to install anything.
Here is some more information about my setup.
-      macbook pro 15 inch early 2011
-      2 hard drives 1 ssd for my windows installation and the other for OS X Yosemite
-     Windows 8.1 enterprise ISO
-     Newest bootcamp Drivers
I am stuck here and can find nothing that works, I have now tried the installation about 20 times but every time the same thing. I know this configuration works becuase I had it before.
Thanks in advance!

I tried this solutions but not resulted:
1 - MacBook Pro audio sound fix
http://realitypod.com/2010/07/macbook-pro-no-sound-in-windows-7-final-fix/
2- Cirrus Logic CS4206A (AB 11)
I tried downloading the "High Definition Codecs" driver from Cirrus Logic's website but the download link doesn't work.
http://www.cirrus.com/en/support/lic/lic3.html?uri=/en/pubs/software/CS4207WinVi sta_Win7_32-64-bit6-6001-1-30.zip
3- Have already the latest Bootcamp drivers http://support.apple.com/kb/DL1720?viewlocale=pt_PT Boot Camp 5.1.5621
Any idea how to get the sound drivers up ?
Thanks
Max

How to just save a document without having to "save as"?

I just want to save changes in exisitng documents, but a Save as window pops up and I am forced to save as with the same name and replace the document I modified. Is there any way of just saving a document, like in previous versions of InDesing?

Is this a file you are converting to the new version? ID always treats the first save of an existing file iin a newer version as a new document with Save As, to protect you from overwriting the old version. This should revert to a regular save on subsequent times.
If you always get a Save As dialog, there's a problem, eihter wih permissions someplace or a conflict with other software, or perhaps just corrupt prefs. See Replace Your Preferences

Power Adapters

hi,
I just bought a new ibook g4 I've been on the computer that is listed for 2 years, and it was 3 years old when I got it, it recently died...
However my problem lies wih the power adapter on my new iBook. After plugging the computer in I have found that the indicator light goes out after less than a second. (the green/orange light) I have tried my mom's adapter and It has worked (she has a 14" same generation (mines a 12")). I have tried replacing all the heads etc but it still doesn't work. I've tried the help article but no luck. What I want to know is if there is anything else I can do. I noticed that it works properly when I push the adapter against the outlet. This is very strange and I don't understand it.
--Thanks,
Ben

Sounds like a flaw in the adapter. Call Apple and return it.

Async os 6.5.1

Just after the new year started, I upgraded my first of three x1050s to 6.5.0. A few days later after no issues were encountered by this first upgrade, I processed upgrades to my remaining two X's and my M. Unfortunately, on one of these X's I upgraded straight to 6.5.1. Fast forward a few days and another admin went to recreate the cluster, to process some rules, and encountered the out of sync AsyncOSs. A panic ensues and upgrades are applied to the remaining three, all to 6.5.1.
I ran this past through a support ticket and found the actual problem with another MTAs TLS config. Here we check for TLS and require if available. Outside MTAs is available but broken. Prior to upgrades, unsecure email processed through to my internal users without issue. After the upgrades, all messages failed. Support reports that they attempted email with this domain using earlier Async OS versions and all comm still failed.
Allegedly no change on outside MTA. They have broken TLS, know it, have experienced it with other MTAs as well. They are not fixing their corrupt TLS deployment. However, unsecure still worked. Outside MTA domain is sigc.us.
Are my tracking logs gone after an AsyncOS upgrade? Can I recover?
Was TLS enhanced to fail with broken outside TLS config, from 6.4.x to 6.5.1?
6.5.1 is a maintenance release? Should I be running it?
Can I get the bound version of the Ironport AsyncOS 6.5 users guide and advanced users guide? Can I download? I have 5.1 literature. I'd really like to get my ironports dialed in to 6.5.x.
Thanks,
-bear

So I take it from thsi that all systems in the cluster are now running 6.5.1-004, and the cluster is intact?
Absolutely. No problems really before or after the upgrade, and once the cluster was recreated after the final 6.5.1-004 push, everything has been characteristcally stable.
By require if available, do you mean TLS preferred-verify? And by all messages, you mean all messages to one domain? It sounds like you should get back in touch with support. They will have access to your configuration.
Actually just prefer. No verify. By all messages, I mean all messages from sigc.us to us (all messages from anyone to us [we listen for a few domains] we prefer TLS). I think support did what they could, and did a great job at that. I'm just stuck in this "it worked/didn't work quandry," with the only definite change being me upgrading. Without the worked/didn't work data slice, everything support provided is spot on. Sigc.us' TLS is broken..that's not in dispute. It's the behaviour now of my ironports, to their error, that appears to have changed. I have added a destination control specifically for this domain, to not use TLS but these one off fixes trouble me.
Your tracking logs should survive an upgrade. Whether you still have data from prior to the upgrade will depend on your mail volume. The tracking database will purge the oldest records when it gets full.
OK. I only seem to be going back to my upgrade date. Actually rechecking my tracking history has shrunk. Now only goes back a little more then a week. That's another obstacle, as I haven't been able to confirm the sigc.us report of success prior to the upgrade.
There were no enhancements or bug fixes that would cause the appliance to be more picky about who to send encrypted mail to. If the remote MTA advertises STARTTLS, we will attempt to negotiate a TLS connection. There are a number of reasons this can fail. If you are using TLS Required, the mail will be bounced. If it is TLS Preferred, then it will be delivered plain text.
There's my problem. It doesn't revert to plain text, it just fails. Like this:
Message 109885282 to [email protected] received remote SMTP response '2.6.0 <49F384F3EE03C14886B2F0F78A53B5432FB803> Queued mail for delivery'.
I don't even think a hard or soft bounce occurs? Just no one receives it.
Absolutely. If you saw it in early January, you must have been on the early availability list. Just this week we released it to all customers.
Whew...
How did this work? We defintitely didn't request anything. What's the early availability list inclusion criteria?
You can see all of the Documentation in the online help on your appliance. You can alos download PDFs from the Support Portal. If you prefer the printed copies, I'll check and see how you can order that.
I'd love the printed versions if available for a reasonable price. Downloads are adequate, but there's nothing quite like a well creased and dog-eared bound reference on my bookshelf.
Thanks Karl.
-bear

Changes not synchronizing

Good day everyone. We are on GroupWise 7.0.3 SuSE server using ConsoleOne to Admin. Clients are Windows based.
Approximately two or three weeks ago I began noticing that any sort of change made within ConsoleOne takes an extra long time for them to synchronize with the system/client.
Examples are adding a new user to the system. I added a user this morning and it took 30 minutes for me to finally be able to log into the account. I kept getting the "User ID 'user' not found" message even though they were fully visible in ConsoleOne.
If I change a users password it can take several hours for it to finally sync.
If I make a change to the users account, such as phone number or title, it can take several hours to sync.
None of this was happening before. Changes would update within a couple of minutes. The only change that I am aware of is I added POA audit maintenance at around the same time but I have since revoke this maintenance and have stopped the POA, deleted the ngwcheck.db and started the POA.
I have found that in some cases stopping and starting the MTA seems to help.
I have to believe that one of you geniuses will have an idea of how to cure.
Thanks in advance.

I don't know what is happening in this case, but think through what
the process is and a) you will understand where to look and b)
probably be able to direct us better :-)
When you create a new user (or change a password) you open ConsoleOne
and that connects to the wpdomain.db file and reads the records. This
is either on the server using VNC or SSH -X or from a workstation via
some kind of share (SAMBA/NFS/???)
You create the new user, and that is added to the wpdomain.db file,
and an admin message is generated that is then placed in the queue for
the post office in wpcsout. That message is then transmitted from the
mta to the poa and written out to the wpcsout queue in the PO data
structure, that is then processed and the new account created and once
that is completed the user can connect.
So if there are problems with the MTA-POA communication there can be
issues with the length of time taken, if there is a samba or NFS lock
there can be a time issue, if the file system is full where the PO or
Domain reside there can be a time issue... You get the drift :-)
The most likely is a communication issue with the domain and PO and to
check that you would want to ensure that both have been set to bind
exclusivly to the specified IP number and that the domain uses port
7100 and the PO 7101 for their message transfer.
HTH
T
On Mon, 25 Oct 2010 20:36:02 GMT, gecco
<[email protected]> wrote:
>
>Good day everyone. We are on GroupWise 7.0.3 SuSE server using
>ConsoleOne to Admin. Clients are Windows based.
>
>Approximately two or three weeks ago I began noticing that any sort of
>change made within ConsoleOne takes an extra long time for them to
>synchronize with the system/client.
>
>Examples are adding a new user to the system. I added a user this
>morning and it took 30 minutes for me to finally be able to log into the
>account. I kept getting the "User ID 'user' not found" message even
>though they were fully visible in ConsoleOne.
>
>If I change a users password it can take several hours for it to
>finally sync.
>
>If I make a change to the users account, such as phone number or title,
>it can take several hours to sync.
>
>None of this was happening before. Changes would update within a couple
>of minutes. The only change that I am aware of is I added POA audit
>maintenance at around the same time but I have since revoke this
>maintenance and have stopped the POA, deleted the ngwcheck.db and
>started the POA.
>
>I have found that in some cases stopping and starting the MTA seems to
>help.
>
>I have to believe that one of you geniuses will have an idea of how to
>cure.
>
>Thanks in advance.

SRS Encoding cannot be done

Hi,
We have messaging server 6.3-8.03. Because of our users who use Mail Forwarding facility in sun java system communication express, our server has to send outgoing mails which have envelope from: addresses those don' t belong to us. Most server administrators like Yahoo' s use spf and normally these mails don' t pass spf check. Because of lots of mail from us to Yahoo like these, Yahoo blacklisted us and doesn' t accept any mail from us(sends 4xx error messages in every try) including mails which are not forwarded and normally which can pass spf check.
To be able to pass spf checks, after some research i learned that messaging server has srs support. In 819-4428 it is written that, in order to do srs encoding we need to add SRS_DOMAIN, SRS_SECRETS and SRS_MAXAGE to options.dat file; sourcesrs, destinationsrs, and addresssrs to tcp_local channel. Although we wrote these keywords to our configuration we saw that there is no envelope from: address change in forwarded mails.
Our configuration is:
mappings file:+
+...+
+...+
INTERNAL_IP
+$(193.255.244.136/32) $Y+
+127.0.0.1 $Y+
* $N
+...+
+...+
options.dat file:+
+...+
+...+
USE_REVERSE_DATABASE=4
+...+
+...+
SRS_DOMAIN=ogrenci.selcuk.edu.tr
SRS_SECRETS=testtest
SRS_MAXAGE=14
imta.cnf file:+
+...+
+...+
tcp_local smtp mx single_sys remotehost inner switchchannel identnonenumeric subdirs 20 maxjobs 7 pool SMTP_POOL maytlsserver maysaslserver saslswitchchannel tcp_auth missingrecipientpolicy 0 loopcheck notices 1 6 24 48 72 vrfyhide expndisable destinationfilter file:///mail/opt/SUNWmsgsr/config/tcp_local.filter sourcesrs destinationsrs addresssrs
tcp-daemon
+...+
+...+
tcplocal.filter file:_+
require ["regex", "jettison", "envelope", "addheader"];
+if header :regex ["Subject"] "^{Spam\\?}" {+
+jettison;+
+stop;+
+}+
+if header :regex ["Subject"] "^{Mpam\\?}" {+
+jettison;+
+stop;+
+}+
+if allof (+
+not envelope :matches "from" "*@ogrenci.selcuk.edu.tr*",+
+not envelope :matches "to" "*@ogrenci.selcuk.edu.tr*"+
+)+
+{+
+if header :matches "sender" "*"+
+{+
+addheader "Resent-Sender" "Selcuk_Unv_Mesaj_Aktarma_Servisi <[email protected]>";+
+}+
+else+
+{+
+addheader "Sender" "Selcuk_Unv_Mesaj_Aktarma_Servisi <[email protected]>";+
+}+
+}+
NOTE 1: The purpose of tcp_local.filter file is to add a sender or resent-sender header (which has a domain part that is our server is authoritative to send mail as) to forwarded mails plus prevent sending spam mails out.
NOTE 2: We didn' t forget to compile configuration after these changes(imsimta cnbuild, imsimta restart, stop-msg, start-msg)
Any ideas about why server doesn' t do srs encoding? Is there something forgotten or any misconfiguration in our configuration, or something forgotten to be written to book 819-4428 by sun?
Thanks a lot.

MuammerCerci wrote:
Any ideas about why server doesn' t do srs encoding? Is there something forgotten or any misconfiguration in our configuration, or something forgotten to be written to book 819-4428 by sun?You need to upgrade your MTA to MS7 update 1 (patch -03) and above which has the fix for bug #6772550 - "Various problems with the MTA's SRS support".
You can upgrade to MS7 update 2 by using the "./commpkg upgrade" command with Communication Suite 6 update 2 (http://wikis.sun.com/display/CommSuite6U2/Get+the+Software).
Regards,
Shane.

Messages with large attachements not being received

# ./imsimta version
Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)
libimta.so 7u2-7.02 64bit (built 02:28:03, Apr 16 2009)
Using /opt/sun/comms/messaging64/config/imta.cnf (compiled)
I have a user that is trying to receive an email with a somewhat sizable .tif image attached and he has not received it. Upon digging through the log file, I noticed the following errors. Any idea what is going on here?
05-Jan-2011 10:38:33.37 tcp_local ims-ms V 0 [email protected] mailto:rfc822,[email protected] spn@ims-ms-daemon psmtp.com ([unknown] [64.18.3.167]) Error reading SMTP packet
05-Jan-2011 10:39:27.60 tcp_local ims-ms E 9 [email protected] mailto:rfc822,[email protected] spn@ims-ms-daemon psmtp.com ([unknown] [64.18.3.70])
05-Jan-2011 10:39:27.71 ims-ms D 9 [email protected] mailto:rfc822,[email protected] spn@ims-ms-daemon
05-Jan-2011 10:46:07.67 tcp_local ims-ms V 0 [email protected] mailto:rfc822,[email protected] spn@ims-ms-daemon psmtp.com ([unknown] [64.18.3.179]) Timeout after 5 minutes trying to read SMTP packet

Does this indicate a problem going outbound?
05-Jan-2011 12:43:45.47 tcp_local QEQ 22 ... smtp;250 2.1.5 Recipient Accepted: Error reading SMTP packet; response to dot-stuffed message expected; likely probYes, similar problem. The MTA's smtp_client process has connected to the remote MTA, sent the MAIL FROM, RCPT TO, started the DATA phase, sent the data, and sent the "." to end the DATA phase and is now waiting for the response from the remote SMTP server acknowledging it has accepted the message. Something went wrong in receiving that acknowledgement. You could add the master_debug option to that channel definition in imta.cnf, cnbuild, and restart job_controller. That would create master debug log files which would have more info about what is happening. Or you could look at it with snoop. Or, if the remote MTA is your postini server, perhaps look at logs on that side.

Coldfusion 8 Not sending email

Coldfusion is not sending emails and is showing a java error
in the coldfusion administrator if the "verify mail server" box is
checked when submitting the mail settings.
The mail settings are right (they work on our production
server), and I can send mail from the command line on the machine
so there are no problems with the MTA or with a firewall.
I am running coldfusion 8 on SuSE 10 enterprise server.
Any suggestions would be greatly appreciated.
Thanks
Warwick Manns

I also have a send problem. I have been sending and receiving emails from several accounts on my new iPad2 for several weeks. Last night I accidentally left my computer on and the battery ran down-dead as a doornail. I plugged it in right away this morning. I use my iPad2 frequently from the couch. I wrote 9 emails and they didn't send. I checked everything I knew to check-passwords, account settings, turn wi-fi on an off. I've been reading the tech sheets and Apple Help but I cannot resolve the problem. I took Apple's advice and added the account manually with password and correct settings. It is still not sending. It is a pop3 account. I've reset my router and powered the computer, router, and iPad up and down numerous times. The computer sends and receives email just fine. I turn off Outlook so as to not have two devices trying to access the server at once. I don't think it is an embarqmail (provider) problem if I can send and receive on the computer. Originally I got an error about the same IP being used by another device. I have checked the IP addresses and they are not the same. I got a new computer Windows 7 and after 2 weeks I got everything set up. I have an iCloud account but do not put my email through it. I can't see taking the iPad to an Apple store when the iPad is the only device not working. I can send email from my iPhone 3G. This does not seem to be a computer problem. What am I missing? Thanks for any help anyone can give me.
Message was edited by: sunseeker

Sun*MS body rewriting -- relay implementation per RFCs

I read and understand RFC 2821 to mean that relays should generally try to leave messages alone. To quote just one section of the RFC...
   A 'relay' SMTP system (usually referred to just as a 'relay') receives
   mail from an SMTP client and transmits it, without modification to
   the message data other than adding trace information, to another SMTP
   server fo r further relaying or fo r delivery.There are 76 character length references in RFC2045, but that refers to the encoded body lines and not headers/boundaries nor SMTP.
S1MS rewrites From: lines, message boundaries?, and wraps longish lines (76?). Most of the time, this rewriting is unnecessary and IMHO violates RFC2821 (and RFC2045 is not relevant, reread) and does nothing except involve more work and no doubt reduce throughput.
I can understand the option to rewrite long lines if they are exceptionally long (1000 characters per RFC), but S1MS seems to break all lines longer than 76 characters. I can understand rewriting local From: addresses if needed, but it seems to rewrites all From: lines remote or otherwise. I've also noticed different S1MS sometimes also rewrite Content boundaries as "Boundary_(ID_blah)". I'm wondering what exactly is rewritten, controlled by what options, and under what circumstances? Why the extra work? Because any subsequent smtp server will still need to parse everything anyways, I don't appreciate all the work and don't understand why it is done.
The crux of this was a recent incident where an 83 character attachment filename was wrapped across two lines causing problems with third party software (it has been fixed, but we both looked at RFCs and I felt S*MS was in the wrong on two counts).
Despite this particular incident, I've long had other reservations (delays, truncated messages) along with the how/why modifications. The end result obfuscates spam with each line that is modified (or corrected, dates inserted, etc).
I looked through this message base looking for other posts perhaps related to this and nothing stuck out. It seems from the messages I saw that S*MS only bothers with the exceptionally long 1000 character lines so I'm now wondering what is exactly is responsible for changing the Content Boundary and wrongly wrapping all lines longer than 76 lines which I see time and time again on many different S*MS systems.

Authoratative answers:
The customer is correct that the MTA will under a number of circumstances
rewrite boundary markers, force wrapping of "long" lines, etc. In general, we
process all outermost header lines coming through the MTA, and may well process
inner header lines as well.
We are fully aware of the RFC 2821 wording regarding relay SMTP machines
"leaving messages alone". The problem is that in our experience, that does
not in fact work well. There are NUMEROUS, NUMEROUS message problems that
our MTA "fixes up", without customers ever having been aware of there having
been a problem in the first place. The sorts of problem we used to encounter
tended to be with messages gatewayed in from non-Internet environments; I consider
nowadays the problems tend to be more with messages submitted from "light weight",
and unfortunately sloppy, e-mail clients. (The MTA does in fact have a configurable
approach for "leave relayed messages entirely alone". We've left it undocumented,
and so far continue to leave it undocumented, and beyond strongly discouraging use
of it don't even talk about it with customers, because in real life, it tends to
not work well.)
Customers, being unaware of how much is getting "fixed up", tend to think that
things would be "better" if we'd "just leave the messages alone". Or rather,
what customers really want is "fix up (a), (b), and (c) problems, but leave
(d) alone, except when it's coming from (e) or going to (f), or except on
every other Thursday when the moon is full..." blah, blah. In other words,
customers want to have their cake and eat it too, when it comes to message
"fix up". Our overwhelming experience is that our fix up is overall
beneficial -- and that the supposed "downsides" of message fixup are mostly
bogus: that inherent processing that customers do in fact want gets you so
far down the road of message processing that the supposed "extra" overhead
is not in fact "extra" because it's already had to be incurred, and that
most of the supposed "problems" of the fixup are due to broken other
e-mail software that's not correctly handling the correct message forms
(and that for every one case of broken software that's stumbling on the
corrected message form, there were NUMEROUS cases of which the customer
was blissfully unaware where our correction of the message form improved
interoperability). Also, the MTA has numerous configuration "knobs" that
can affect exactly what we emit, so even when the real problem is a bug
(lack of standards-compliance) on the remote side, it's often possible
to configure something on the MTA side to emit a form that the broken
remote side will be able to handle.
Now it is true that we try to avoid any more processing than necessary
-- but the fact is that there are extremely many cases, triggered by a
wide variety of original message factors and configuration choices, where
processing is necessary.
As regards line folding: Please refer the customer to section 2.1.1
Line Length Limits, of RFC 2822, in particular the second sentence:
Each line of characters MUST be no more than 998 characters and
SHOULD be no more than 78 characters, excluding the CRLF.
Also see 3.5 Overall message syntax, in particular the second sentence:
Lines in a message MUST be a maximum of 998 characters
excluding the CRLF, but it is RECOMMENDED that lines be limited to 78
characters excluding the CRLF.
The MTA's default is therefore to fold header lines at 80 characters,
though this is configurable via the headerlinelength channel keyword
(or individually for individual header lines via header trimming
and the LINELENGTH header trimming option).
Now as regards clients not being able to correctly handle the
correctly wrapped header lines -- well, that I can certainly
believe since correct implementation of header line unfolding
rules (especially when combined with use of RFC 2047 encoded-words
in header lines) seems to be an area where client implementations are
WOEFULLY poor. It is really very irritating: the standards exist
exactly so that data can be preserved, and the clients just get this
area so wrong.
(And by the way, it is legal to wrap within quoted-strings.)
As for message bodies line wrapping -- that is controlled by factors
such as whether the contents had to be encoded with an encoding (such
as QUOTED-PRINTABLE or BASE64) that requires also keeping the lines
short, and note that such encoding can be triggered by use of the
linelength channel keyword. But lacking a need, body lines can
normally be up to the 998 legal limit and the MTA won't be folding
them. If the customer thinks they are seeing something different,
then I would want to see lots of details.
As for what can trigger the MTA to use its own boundary markers:
that would be anything that triggers MIME processing, including
(a) routing through the conversion channel, (b) use of the "thurman"
keyword, (c) application of a CHARSET-CONVERSION, (d) incoming
raw (illegal) 8 bit data, (e) the "inner" keyword, etc., etc.
They're all useful, and typically needed by customers at-some
-time-or-another, for-some-purpose-or-another, sorts of features,
that inherently require that the MTA do MIME processing, at which
point we redo the boundary markers.
Oh, other comments: Yes, the MTA does reorder all the headers.
We output them in an order that the MTA considers default, though
that order is extremely configurable: see header trimming and
the PRECEDENCE header trimming option. And yes, we change
the case on header line names; although the names are per the
standards case-insensitive, we have encountered quite a few cases
of broken software that (incorrectly) expects a particular case,
so what we emit tends towards the "seems to be most interoperable"
case. And that also can be configured, via header trimming and
the RELABEL header trimming option.
Anyhow, Jay, it's perhaps unfair to just dump this information on
you, but I'm not certain I have the patience at the moment
to go through all the questions the customer raised one by one and
point out how each one is either: (a) possibly interesting (e.g.,
supposedly "lost" e-mail) though we'd have to get lots of details
(since as I think you wrote, it's pretty dubious that the messages
were actually lost by the MTA), or (b) the customer is wrong in
their understanding of the RFCs, or (c) the customer is dealing
with standards-incompliant other software, or (d) explain
exactly why the MTA does what it does, or etc...Each question
probably ought to be dealt with as a separate question. The
customer appears to have lumped a bunch of (from my point of view)
separate issues together and decided that "MTA processing of messages
is bad -- the MTA should be leaving the messages alone". I completely
disagree with their conclusion, although many of the details that the
customer has observed are correct -- but it's probably going to take
discussion of each issue individually to enlighten the customer.
and
(Basic complaint) .. . ... almost entirely at odds with reality. For starters, he begins by assuming
we operate as a relay. We don't and have never claimed to. As such, any
restrictions that apply to "relays" don't apply to us. So the argument that
we're incompliant with the relevant RFCs is completely specious.
The role of iMS fills is closest to what the RFCs call a "gateway", although in
practice few sites these days take advantage of the full gateway functionality
we provide. But by the same token, most sites find at least some of the various
operations we perform on messages useful and don't disable them (although most
of them can in fact be disabled). So in practice most sites operate something
that falls between a "relay" and "gateway". (There's also the issue of the
specific operations a submission server is supposed to perform but I don't want
to get into that here.)
He goes on to argue that the various processing steps we perform on messages
are unnecessary and/or result in unacceptable loss of performance. Wrong on
both counts. Everything we do is done because there's been a demonstrable need
for it. We don't spend time implementing stuff nobody wants. Indeed, a lot of
people find many of the operations we perform to be essential and purchase our
product because it has rewriting and message alteration capabilities lacking in
other messaging servers. As for performance, we have one of the fastest MTAs
around. I'd say that pretty much proves the performance impact is negligable.
A specific point of complaint is that we change boundary markers. The reason for
this is simple: When performing MIME processing the only way to do it correctly
in a single pass is to randomize the boundary markers. (I'll leave it as an
exercise to the reader to figure out why if you're so inclined.) In any case,
I see no evidence that there is anything wrong in our boundary handling.
He then starts complaining about header wrapping and reorderng. Header
wrapping and rewrapping is (a) Entirely legal and (b) Wrapping at 80 columns
or less is strongly encouraged by the relevant RFCs.
This brings me to the one point he makes that I think is somewhat valid: Header
reordering. We're RFC compliant here as well: If you read the relevant RFCs
you'll find that reordering of trace (Received:) fields is forbidden and
certain headers are required to be prepended, but aside from that pretty much
anything goes. We conform to all this but I don't think the RFCs are stringent
enough in this area. Accordingly, changes have been made for JES 5 that will
result in our preserving header order by default. (Obviously this all goes
out the window if you explicit request header reordering of some sort.)
One final point. Much of the behavior he doesn't like can easily be disabled in
iMS. If all this stuff is really so abhorrent, you'd think we'd see the
majority of sites turning it off. But what we see in practice is exactly the
opposite: Not only do sites not disable this stuff, they spend a considerable
amount of time yoeling and howling about we don't do enough of these things.
The addition of disclaimers is an excellent example of this: We don't think
this is a good idea and try to discourage it, but our customers seem not to
agree...

Hello!, my name is jan and i am using lightroom 2 for many years. I have an original set-up disk with a 24 digit serial number. I had never problems wih installation of lightroom. suddenly lightroom refuses to start when I try to from a picture i have tak

Hello!, my name is jan and i am using lightroom 2 for many years. I have an original set-up disk with a 24 digit serial number. I had never problems wih installation of lightroom. suddenly lightroom refuses to start when I try to from a picture i have taken with my nikon D500 and transferred to WINDOWS 8.1. i have tried to re-install lightroom : the procedure asks for the serieal number , but refuses to accept the number that always worked. PLEASE help!! jan

If you are certain you have the right serial number, there really isn't much we can help you with here. You might try downloading and installing the last version of Lightroom 2. It will be the trial version, but when the trial screen appears there is an option to indicate that you have a serial number. Incidentally, Lightroom serial numbers start with the first four digits being 1160.
Adobe - Lightroom : For Windows : Adobe Photoshop Lightroom 2.7 - English, French, German

Problem ClamAV wih MTA.

Similar Messages

Maybe you are looking for