David Young wrote: > > Hi Andre, > > Attached are the headers of one of the suspect emails. Regrettably, I > have no qmail-send logs of the incident, because they were rotated > before I became aware of the problem. I've now drastically increased > multilog's MAXFILESIZE variable, so that I my logs will "go further back" :) > > Summary of the headers below... > > - the user at Afgri was not intended to receive the email. > - bob.net.lithotech.co.za is our primary mail server, all outgoing mail > goes via this server. It is running qmail-ldap 20030801 > - enzo.net.lithotech.co.za is a clusterhost at another branch, running > 20030501. > - The email was sent from [EMAIL PROTECTED] (a user on > enzo) to [EMAIL PROTECTED] > - I've added "nospam" to the email addresses, to protect the users > from spambots
Up to bob everthing looks fine. The sender and recipient are transmitted fine and correctly. Thus the problem, if any, must be at bob. However, there are some strange things: - The communication between enzo and bob is via SMTP instead of QMQP (which would be normal for clusters). - The communication between enzo and bob uses SMTP DATA compression which was added in 20030801. But enzo is supposed to run 20030501. Could you do a ldap search on your entire ldap directory on the field 'mailForwardingAddress' with "[EMAIL PROTECTED]" and look whether you find some match. -- Andre > Received: from afgri-relay (192.168.170.15 [192.168.170.15]) by > afgri-exch.otk.co.za with SMTP (Microsoft Exchange Internet Mail Service > Version 5.5.2653.13) > id RHHFTYVV; Mon, 29 Sep 2003 13:24:24 +0200 > Received: from bob.net.lithotech.co.za ([165.233.49.45]) by afgri-relay with > InterScan Messaging Security Suite; Mon, 29 Sep 2003 13:23:15 +0200 > Received: (qmail 16427 invoked from network); 29 Sep 2003 07:11:32 -0000 > Received: from unknown (HELO enzo.net.lithotech.co.za) ([172.16.41.62]) > (envelope-sender <[EMAIL PROTECTED]>) > by bob.net.lithotech.co.za (qmail-ldap-1.03) with DES-CBC3-SHA > encrypted compressed SMTP > for <[EMAIL PROTECTED]>; 29 Sep 2003 07:11:25 -0000 > Received: (qmail 6360 invoked from network); 29 Sep 2003 07:12:57 -0000 > Received: from unknown (HELO bisheng) ([172.16.41.197]) > (envelope-sender <[EMAIL PROTECTED]>) > by enzo.net.lithotech.co.za (qmail-ldap-1.03) with SMTP > for <[EMAIL PROTECTED]>; 29 Sep 2003 07:12:54 -0000 > Reply-To: <[EMAIL PROTECTED]> > From: "Bishen" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Subject: did we look at this one? > Date: Mon, 29 Sep 2003 09:14:36 +0200 > Message-ID: <[EMAIL PROTECTED]> > MIME-Version: 1.0 > Content-Type: multipart/alternative; > boundary="----=_NextPart_000_0027_01C3866A.1A52DF80" > X-Priority: 3 (Normal) > X-MSMail-Priority: Normal > X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) > Importance: Normal > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 > > Andre Oppermann wrote: > > David Young wrote: > > > >>Hi All, > >> > >>I'm also experiencing this problem... > > > > > > We have had a bug in 20030901 which caused some cluster problems. > > This is one is going to be fixed in 20031001. > > > > I can't image what could be the cause of this for release 20030801a. > > There aren't any changes in the recipient handling functions compared > > to 20030501. > > > > While running different versions of qmail-ldap within a cluster should > > as such not be a problem, I don't recommend it. It might be that > > different clusterhosts have different handling of some ldap attributes > > (due to bug fixes or feature enhancements). > > > > It would be really helpful if you could provide some email headers and > > qmail logs which correspond to this incident. > > > > ------- > This e-mail and attachments are confidential/legally privileged and any > unauthorised use, distribution or disclosure thereof, in whatever form, > by anyone other than the addressee is prohibited. If you have received > this e-mail in error, please destroy it. The views and opinions in this > e-mail and attachments may not necessarily be those of the Directors and > Management of the Lithotech Group of Companies. The aforementioned does > not accept any liability for any damage, loss or expense arising from > this e-mail and/or from accessing any attachments.
