* This is the vopmailbeta mailing list *
HM> All clients are using Outlook Express 5 and were installed and configured by HM> our own personnel, they all connect to one of two servers. The missing HM> attachments are random, it's not clients on one server and not the other HM> that receive the attachments and very rarely the same person twice, HM> attachments sent direct to the clients always arrive they only go missing HM> when sent to the list. welp, that complicates things a bit, eh? :) I still am not inclined to point the fault finger at the server, just yet. My guess is that you have already been on a Branta canadensis chase with the server. First, locate a failed email. Then find in the list server logs where it sent that email. If the message byte size is the same as one that was delivered successful, we've eliminated the server. If not, now ya got something to work with when talking to vircom. Next, start with the client that you *know* failed and work backwards. Inspect its header information for clues. Here is an example of something that I sent with an attachment not too long ago to vopmailbeta, and this is the replicated broadcast header info that I got back: Return-path: <[EMAIL PROTECTED]> Received: from 216.106.78.14 (unverified [216.106.78.14]) by polaron.inet-power.net (Vircom SMTPRS 4.7.192) with ESMTP id <[EMAIL PROTECTED]> for <[EMAIL PROTECTED]>; Mon, 9 Sep 2002 11:44:06 -0500 Date: Mon, 9 Sep 2002 11:44:23 -0500 From: John Blue <[EMAIL PROTECTED]> X-Mailer: The Bat! (v1.60q) Educational Organization: Internet Power X-Priority: 3 (Normal) Message-ID: <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: [VOPmail Beta] filter troubles or Find a match and win a prize!! MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------1AAF1CC11F502FE" Reply-To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] ------------1AAF1CC11F502FE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit blah blah blah John Blue ------------1AAF1CC11F502FE Content-Type: text/plain; name="spamflt0.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="spamflt0.txt" <attachment code> ------------1AAF1CC11F502FE-- What your looking for is how the email is broken up into the different sections with the 'Content-Type boundary' hex code. In this example it is: ------------1AAF1CC11F502FE The end of the message can be found where the boundary hex code is appended with --. If your suspect email is very similar to the above structure, the attachment *is* being delivered, and the client is mangling it somehow. If it is not similar to the above, then next move futher back upstream to the server that last had its hands on it. The logs will tell you if it received an email for delivery with an attachment. Compare actual message byte sizes to a confirmed attachment delivery, and so on. John Blue ** To leave this list, send an email to [EMAIL PROTECTED] and put the word "LEAVE" in the BODY of the email.
