Subject: RE: MTA stopping frequently - msg#00062

Previous Message by Date: click to view message preview

Re: Communication express - vacation message - sieve filter

Hello, We are testing the new version of Communication Express -bash-3.00# imsimta version Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit) libimta.so 6.3-3.01 (built 20:00:00, Jul 12 2007; 32bit) SunOS mmp-1-2 5.10 Generic_118855-14 i86pc i386 i86pc -bash-3.00# showrev -p | grep SUNWuwc Patch: 122794-10 Obsoletes: 118541-22, 117288-99, 117820-13, 119157-07, 119160-07 Requires: Incompatibles: Packages: SUNWuwc Patch: 122794-14 Obsoletes: 118541-43, 117288-99, 117820-13, 119157-07 Requires: Incompatibles: Packages: SUNWuwc I have defined a sieve filter which puts all messages tagged {Spam?} in a SPAM folder. The rule has been created with the Communication Express interface where I don't see any button which says that if the rule is applied, the filters should stop but the stop is really there : #RULE: $Name="SPAM" $Order=1 $Type="DEFAULT_TYPE" require "fileinto"; #BEGINFILTER if anyof(header :contains ["Subject"," Comments"," Keywords"] "\{Spam \?\}"){ fileinto "SPAM"; stop; } #ENDFILTER I note in passing that while the literalizing \s are allowed they are superfluous and really shouldn't be there. The anyof is also superfluous. If we define also a vacation message where we could'nt specify any condition about the message, ie the rule will applied to all messages, That's an inherent limitation of using the separate LDAP atrribute approach to enable vacation - it cannot qualify the decision to invoke the vacation action in any way other than by time. So it cannot be used to say something like: if not(header :contains ["Subject"," Comments"," Keywords"] "{Spam?}"){ vacation ... } when a mail comes with a {Spam?} in the Subject, the message is well dropped into the SPAM folder but the automatic answer is also sent to the sender. Correct. In that case, every time we create a vacation message, we will answer to the spammers and then validate the email address they use. There are legitimate reasons not to want to send vacation responses to suspected spam, but this isn't one of them. In particular, you have already "validated" the email address by accepting mail for it. So you're not denying the spammers any information - indeed, since the MAIL FROM address in the message is almost certainly forged the spammer is never going to see the vacastion message. The main reasons you don't want to send a vacation response in this case are that such repsones clog up your queues for no purposes and often as not annoy whoever's address the spammer stole to put in the MAIL FROM. Questions - is that a way to avoid this ? Sure. The simplest is to simply disable vacation unconditionally for all suspected spam messages. You could implement this by having a system sieve that says: if header :contains ["Subject"," Comments"," Keywords"] "{Spam?}" { novacation; } Alternately, you could use some other method to build a user sieve that conditionalizes the vacation action in some way. AFAIK CE always uses the LDAP attributes for this and hence cannot be used to do this. - As the stop is put by default in the rule, how could we suppress it ? The stop has nothing to do with the vacation action - removing it will not have any effect on whether or not the vacation message is sent. In some case, a rule is applied and the message should go through the following rule. If the "stop" is added by default, that will not be the case. Correct, but since the vsacation action effectively preceeds anything else in the resulting sieve whether or not subsequent rules are applied has no effect. - What is the difference between a rule which "forward to an email address" in the "Mail Filters" and the "Mail forwarding" we find in the "Settings". Seems that in the "Settings" we can't restrict the application of the rule to some criteria. Is it the only difference ? I have no idea. Ned

Next Message by Date: click to view message preview

Re: Communication express - vacation message - sieve filter

As regards forwarding -- if you're referring to "forwarding" from the settings, that's likely causing a mailDeliveryOption: forward, mailForwardingAddress: <whatever> setting in LDAP -- causing unconditional, MTA-level forwarding, of a copy of every message, whereas the "mail forwarding" from the Sieve filters page, would likely cause a "redirect" Sieve action. If so, the two types of forwarding do have some functional differences. Regards, Kristin On Sep 15, 2007, at 7:59 AM, Ned Freed wrote: Hello, We are testing the new version of Communication Express -bash-3.00# imsimta version Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit) libimta.so 6.3-3.01 (built 20:00:00, Jul 12 2007; 32bit) SunOS mmp-1-2 5.10 Generic_118855-14 i86pc i386 i86pc -bash-3.00# showrev -p | grep SUNWuwc Patch: 122794-10 Obsoletes: 118541-22, 117288-99, 117820-13, 119157-07, 119160-07 Requires: Incompatibles: Packages: SUNWuwc Patch: 122794-14 Obsoletes: 118541-43, 117288-99, 117820-13, 119157-07 Requires: Incompatibles: Packages: SUNWuwc I have defined a sieve filter which puts all messages tagged {Spam?} in a SPAM folder. The rule has been created with the Communication Express interface where I don't see any button which says that if the rule is applied, the filters should stop but the stop is really there : #RULE: $Name="SPAM" $Order=1 $Type="DEFAULT_TYPE" require "fileinto"; #BEGINFILTER if anyof(header :contains ["Subject"," Comments"," Keywords"] "\{Spam \?\}"){ fileinto "SPAM"; stop; } #ENDFILTER I note in passing that while the literalizing \s are allowed they are superfluous and really shouldn't be there. The anyof is also superfluous. If we define also a vacation message where we could'nt specify any condition about the message, ie the rule will applied to all messages, That's an inherent limitation of using the separate LDAP atrribute approach to enable vacation - it cannot qualify the decision to invoke the vacation action in any way other than by time. So it cannot be used to say something like: if not(header :contains ["Subject"," Comments"," Keywords"] "{Spam?}"){ vacation ... } when a mail comes with a {Spam?} in the Subject, the message is well dropped into the SPAM folder but the automatic answer is also sent to the sender. Correct. In that case, every time we create a vacation message, we will answer to the spammers and then validate the email address they use. There are legitimate reasons not to want to send vacation responses to suspected spam, but this isn't one of them. In particular, you have already "validated" the email address by accepting mail for it. So you're not denying the spammers any information - indeed, since the MAIL FROM address in the message is almost certainly forged the spammer is never going to see the vacastion message. The main reasons you don't want to send a vacation response in this case are that such repsones clog up your queues for no purposes and often as not annoy whoever's address the spammer stole to put in the MAIL FROM. Questions - is that a way to avoid this ? Sure. The simplest is to simply disable vacation unconditionally for all suspected spam messages. You could implement this by havinga system sieve that says: if header :contains ["Subject"," Comments"," Keywords"] "{Spam?}" { novacation; } Alternately, you could use some other method to build a user sieve that conditionalizes the vacation action in some way. AFAIK CE always uses the LDAP attributes for this and hence cannot be used to do this. - As the stop is put by default in the rule, how could we suppress it ? The stop has nothing to do with the vacation action - removing it will not have any effect on whether or not the vacation message is sent. In some case, a rule is applied and the message should go through the following rule. If the "stop" is added by default, that will not be the case. Correct, but since the vsacation action effectively preceeds anything else in the resulting sieve whether or not subsequent rules are applied has no effect. - What is the difference between a rule which "forward to an email address" in the "Mail Filters" and the "Mail forwarding" we find in the "Settings". Seems that in the "Settings" we can't restrict the application of the rule to some criteria. Is it the only difference ? I have no idea. Ned

Previous Message by Thread: click to view message preview

Re: MTA stopping frequently

It would be the dispatcher process which accepts the SMTP connection and then hands it off to a tcp_smtp_server process. It sounds like the dispatcher must still be running but having some trouble. If you could try telnet to port 25, that might give more details than your mail client is giving. If telnet gets connected but you do not get a banner, that means one thing. If telnet immediately fails with some error, that means something else. Also try telnet to port 587. If telnet gets connected and gets a banner, then you need to go on to try to send a message and see where it fails and provide details. Kelly Mike Garner wrote: Hi All- Recently the MTA on my messaging server (Sun Java System Messaging Server 6.2-3.05 (built Nov 23 2005)) has been stopping daily. This is running on Windows Server 2003. What happens is I come into work and nobody can send email. POP and IMAP clients are receiving email, though there isn't much to receive. If I tried to send from a POP or IMAP client I get SMTP errors they aren't exactly the same because each error is unique to each client though the errors generally indicate that no SMTP service is running. If I log into the Sun Java System Messenger Express and compose an email (to either local or non-local recipient) I get a "SMTP Error" box when I click send and the message doesn't leave the screen. My resolution is: From the server, on the command line: Stop-msg mta Start-msg mta The output is as follows: C:\Documents and Settings\adp_admin>stop-msg mta Connecting to watcher ... Stopping job_controller server 1980 ... done Stopping dispatcher server 3412 ... done C:\Documents and Settings\adp_admin>start-msg mta Starting mta daemon... Connecting to watcher ... Starting dispatcher server .... 5568 Starting job_controller server .... 4772 If I try just start-msg mta (without first stopping) it indicates that all the services are "already running". After the stop and start everything works great again...for awhile. It's really quite inconvenient because there is no consistent time that this fails though usually in the early morning hours between midnight and 8am. This means each morning we've got a back log of email and delayed deliveries. Where can I look to troubleshoot this? As to the question of what changed recently, not much. I'm pretty good about applying Windows updates, etc. but haven't done much else for the last few months. Additionally, this isn't a NEW problem. Off and on, this has happened with the mta, imap, and pop service since the "upgrade" to 6.2 though usually once the services are running they run fine for weeks until one dies. Then I reboot the server, stop and restart things enough times to get it all running and then leave it for several weeks. Having the MTA die unexpectedly isn't terribly new but having it do it over and over again each night for a week is a worsening of the problem. Any pointers would be much appreciated. ~Mike ---------------------------------------- Mike Garner IT, Western State College of Colorado mgarner-Jkm/SPrVjP2Vc3sceRu5cw@xxxxxxxxxxxxxxxx 970.943.3331 970.943.7069 (fax)

Next Message by Thread: click to view message preview

Re: MTA stopping frequently

Mike Garner wrote: When the MTA is in the state of failure here are the results of my telnet attempts: Telnet to port 25 connects, never times out but I never get a banner or other return. This indicates that the dispatcher process is listening on port 25. So the MTA has not "stopped", per se. Telnet to port 587 connects and I get a Sun Java ... banner. And this indicates that dispatcher is working properly and able to hand connections off to a worker process. Together they would indicate the problem is in the worker processes for the SMTP service as opposed to a general problem with the dispatcher. If you have RBL checking enabled (or perhaps something else like that), the DNS service being used may be having troubles. That could cause the tcp_smtp_server threads to hang waiting on that service and therefore the SMTP service would not be able to accept more connections after it reaches MAX_PROCS x MAX_CONNS. Or it could be that you are just handling that many connections from remote MTAs. Though, this port is not permitted from my users to the server in our firewall. Should it be? This is the submit service. See dispatcher.cnf and http://www.ietf.org/rfc/rfc2476.txt I also have the logging keyword on the defaults channel. Is there something in my mail.log that would be of help? If you add LOG_CONNECTION=3 and LOG_PROCESS=1 to option.dat (and cnbuild and restart the MTA) you will get more details about which processes are handling what connections and what is happening with those connections. But I would first suggest you investigate what sort of RBL service you are using and your connection rate, etc. Kelly Thanks, ~Mike -------------------------- Mike Garner IT, Western State College of Colorado 970-943-3331 ________________________________________ From: Kelly.Caudill-UdXhSnd/wVw@xxxxxxxxxxxxxxxx [Kelly.Caudill-UdXhSnd/wVw@xxxxxxxxxxxxxxxx] Sent: Friday, September 14, 2007 9:46 AM To: Info-iMS-QMRIvgJGioDQT0dZR+AlfA@xxxxxxxxxxxxxxxx Subject: Re: [Info-iMS] MTA stopping frequently It would be the dispatcher process which accepts the SMTP connection and then hands it off to a tcp_smtp_server process. It sounds like the dispatcher must still be running but having some trouble. If you could try telnet to port 25, that might give more details than your mail client is giving. If telnet gets connected but you do not get a banner, that means one thing. If telnet immediately fails with some error, that means something else. Also try telnet to port 587. If telnet gets connected and gets a banner, then you need to go on to try to send a message and see where it fails and provide details. Kelly Mike Garner wrote: Hi All- Recently the MTA on my messaging server (Sun Java System Messaging Server 6.2-3.05 (built Nov 23 2005)) has been stopping daily. This is running on Windows Server 2003. What happens is I come into work and nobody can send email. POP and IMAP clients are receiving email, though there isn't much to receive. If I tried to send from a POP or IMAP client I get SMTP errors they aren't exactly the same because each error is unique to each client though the errors generally indicate that no SMTP service is running. If I log into the Sun Java System Messenger Express and compose an email (to either local or non-local recipient) I get a "SMTP Error" box when I click send and the message doesn't leave the screen. My resolution is: From the server, on the command line: Stop-msg mta Start-msg mta The output is as follows: C:\Documents and Settings\adp_admin>stop-msg mta Connecting to watcher ... Stopping job_controller server 1980 ... done Stopping dispatcher server 3412 ... done C:\Documents and Settings\adp_admin>start-msg mta Starting mta daemon... Connecting to watcher ... Starting dispatcher server .... 5568 Starting job_controller server .... 4772 If I try just start-msg mta (without first stopping) it indicates that all the services are "already running". After the stop and start everything works great again...for awhile. It's really quite inconvenient because there is no consistent time that this fails though usually in the early morning hours between midnight and 8am. This means each morning we've got a back log of email and delayed deliveries. Where can I look to troubleshoot this? As to the question of what changed recently, not much. I'm pretty good about applying Windows updates, etc. but haven't done much else for the last few months. Additionally, this isn't a NEW problem. Off and on, this has happened with the mta, imap, and pop service since the "upgrade" to 6.2 though usually once the services are running they run fine for weeks until one dies. Then I reboot the server, stop and restart things enough times to get it all running and then leave it for several weeks. Having the MTA die unexpectedly isn't terribly new but having it do it over and over again each night for a week is a worsening of the problem. Any pointers would be much appreciated. ~Mike ---------------------------------------- Mike Garner IT, Western State College of Colorado mgarner-Jkm/SPrVjP2Vc3sceRu5cw@xxxxxxxxxxxxxxxx 970.943.3331 970.943.7069 (fax)