Or at least make the server as sick as hell
Had fun tracking this one down, our main relay wandered off into load hell
this morning for no apparent reason. After much fiddling, watching of
logs, making use of exiwhat (bloody useful script :) I tracked it down to
three queue items on a upstream MX.
The email was a spam, a typical "xxx happened to yyy please sign this
email and foward to your friends" *grumble* The problem is in the
headers.
I've munged the target address in the following extract.
--8<--
11lJqu-0003NC-00-H
mail 8 12
<MNielson@???>
942186900 0
-host_address 196.26.83.82
-host_name gollum.tns.co.za
-helo_name gollum.tns.co.za
-interface_address 195.200.0.97
-ident firewall-user
-received_protocol esmtp
-body_linecount 119
-frozen 942243167
XX
1
***@****.***
204P Received: from gollum.tns.co.za ([196.26.83.82]
ident=firewall-user)
by relay2.ftech.net with esmtp (Exim 3.03-ftechp3 #14)
id 11lJqu-0003NC-00
for CSO@???; Tue, 09 Nov 1999 22:50:15 +0000
081P Received: by gollum.tns.co.za; id KAA28121; Tue, 9 Nov 1999 10:56:46
+0200 (SAT)
062I Message-ID: <5FB8900D2A01D31183130008C709085717EEA9@BMM_MAIL>
057F From: "Nielson, Maurice (BMM)" <MNielson@???>
385846T To: "Du Plessis, Yolande" <ydplessis@???>,
&&10
<&&10@???>, &&11 <&&11@???>,
&&12
<&&12@???>, &&13 <&&13@???>,
&&15
<&&15@???>, &&16 <&&16@???>,
&&17
<&&17@???>, &&2 <&&2@???>,
&&3
<&&3@???>, &&4 <&&4@???>,
&&5
<&&5@???>, &&6 <&&6@???>,
&&7
<&&7@???>, &&8 <&&8@???>,
&&9
<&&9@???>, &&a <&&a@???>,
&&aa
<&&aa@???>, &&AAA <&&AAA@???>,
&&b
<&&b@???>, &&BB <&&BB@???>,
&&C
<&&C@???>, &&CC <&&CC@???>,
&&d
<&&d@???>, &&DD <&&DD@???>,
&&E
--8<--
and so on for about 360k....
(Full headers available on request)
The result of this mail hitting relay was to have a exim process try to
grab 100M of ram... now imagine three hitting at once :(
Not sure there's a fix or a config option I can tweak (reading docs now)
but this might be something other people haven't seen.
Mark
--
This is a sig, it's not a smart sig or an AI sig, but it's a sig to
replace the sig that died during the death of data... the sig is dead,
long live the sig
