[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference abbott::mailworks-unix

Title:Mailworks-unix
Notice:V2.0.4 now available -- see Note 4.375
Moderator:TAMARA::NEUMAN::Neumann
Created:Wed Jun 02 1993
Last Modified:Tue Jun 03 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1384
Total number of notes:5851

1361.0. "Mailworks autoforward deadlock" by NETRIX::"[email protected]" (Petr Sindelar) Fri Mar 21 1997 09:27

Hello,

We have a customer that reported a problem with Mailworks V2.0.2 
consuming a high amount of swap space ( X488grecv processes). 
The customer investigated a following scenario that causes the 
reported problem.

A TeamLinks user X sets an autoforwarding e-mail address in his
Mail profile (in TeamLinks V2.5) equal to the e-mail address
of TeamLinks user Y and vice versa. Such scenario triggers 
oscillating of one message and causing Mailworks server is 
consuming a high amount of swap space. This continues
up to 100% of swap and crash of the process.

The solution is to stop x488 processes and deleting 
the message from MTA queue, but our customer is 
unsatisfied with such solution. So, is it possible 
to detect or prevent to oscillating of such messages 
or is it a way to disable autoforwarding in user Mail profile?

The configuration of our customer is MAILworks V2.0.2, 
MB400 MTA V2.0, Digital UNIX V3.2D, DECnet/OSI V3.2B. 
MAILworks server and MTA are on the same machine. 

The other problem which customer indicates is the 
very long delay (cca 3-10minutes) on Server side 
in case that Teamlinks user attaches attachement 
bigger than 2.5MB. There is no network problems 
and it is indicated more than 80% server resources 
consuming by MailWorks process in manipulation 
with this message.

I'd be happy if someone would help me with 
solving these problems. I'll 
appreciate any information.

Regards
Petr Sindelar,
Digital Prague, CZ


[Posted by WWW Notes gateway]
T.RTitleUserPersonal
Name
DateLines
1361.1Simple solutionTAMARA::lamac.zko.dec.com::NeumannStan NeumannMon Apr 07 1997 17:5026
Sorry to take so long to answer -

You don't specify how much swap space was allocated, and how
large the mss and mcs processes got.  However, I would
assume that the customer ran out of swap space because
the processes grew too large for the swap space.

I'm afraid that I don't understand why the customer does
not accept the solution.  Clearly it does not make
sense for address x to forward to address y and vice
versa.  That configuration is going to create all kinds
of problems for both the servers and the network.  Running
out of swap space is only one of the problems you will see.

Clearly, the solution is to turn off the circular forwarding.

On the performance problem - can you have the customer run
the script suppscr.sh which is located in the directory
/usr/opt/DMW/unsupported.  (This should be run from the
root account), and send me the output. I would like to
see how the machine is configured.  You can send the file
to me at [email protected].

Thanks,

Stan
1361.2Problem Cause SpecificationNETRIX::"[email protected]"Petr SindelarThu Apr 10 1997 04:1530
Hello, 

Stan thanks for your responce

I have to specify reason for circular forwarding (causes described problems):

TeamLinks User A sets autoforward function to User B. User B dont know that it
happens and sets his autoforward to User A. This same scenario is around more
than 2 Users. At the End this functionality causes system collaps (swap is
consuming up to 100% and in case that is there no system administrator, who
detect this status, Messaging system going down).

On other site this thing, that system automatically could not detect this
status, could represent service refusal attack at system, becouse this status
could causes single user by autoforward to himself.

I think that it is very important for our (maybe for other too) to fix this
problem.

Stan, I will send you output file with configuration of system.

Thanks for responce. I'll 
appreciate any information.

Regards
Petr Sindelar,
Digital Prague, CZ


[Posted by WWW Notes gateway]