[quote user="PaulW"]

[quote user="Greenman"]Generally, I have noticed that even when creating a new message with an attachment, a 15MB message will usually translate to c.20MB when sent. I see this when sending messages from my home PC too (Windows Mail, ISP=BT sending via gmail).[/quote]

Generally a 15MB file wil convert to a 20MB attachment (about 1.3 size increase) because that's how base64 encoding coverts 8-bit into 7-bit for transmission.  See the wikipedia entry (en.wikipedia.org/wiki/Base64) for more details.

[quote]I will ask 'staff' to forward the message without editing and see what happens. I am now sure after trying to replicate this that the original multiple messages must have been some sort of hiccup.[/quote]

Agreed.

Cheers to you to.

[/quote]

Thanks again, Paul.

I had misunderstood why the size of attachments was increased. I had not realised that the data was actually being converted. Another useful lesson from you people.

And, thus, when the mail message was 'bounced' to my gmail account, it was sent without any problems 'as is'.

This has been a very useful process. Enlightening for me and, I suspect, a little frustrating for you guys.

Thank you again for your help.

Hi Folks

One of our staff received a mail message that contained some photo's. The member of staff forwarded this message to an external contact. What happened is that multiple messages were sent instead of one message. I checked their Pegasus Mail settings and the option to send attachments as separate messages is not checked.

List of messages:

The red rectangle shows the original message (highlighted) and subsequent messages from the sender. The numbered messages are shown below. I have a content control rule setup with MessageLabs which blocks and returns messages over 20MB. The messages shown beyond the numbered messages include the returned messages which were identified by this rule.

This image shows the contents of the original message (highlighted in list above):

These are the forwarded messages - the numbers relate to the numbers shown in the list above:

Each of the messages shows the same identifier:
4A254451.19522.6C464AD@staff.apsarchaeology.co.uk

I'm sure someone here will be able to explain, but I don't understand why several messages were sent instead of just one. Also, I don't understand the numbers involved - why are the messages so large? Together they come to a lot more than the original message even allowing for the extra data that is normally appended. All the messages are addressed to the same person.

Can anyone help me understand this please? I don't know if this the result of other settings in Pegasus Mail or if something strange has happened. If you need more information please ask.

Thanks!

Anyone have any ideas please?

Anyone have any ideas please?

The only idea I have is that since this was a 15 MByte file the message was broken into smaller parts by a server along the line.  There are RFCs that allow this but normally the sending client has to generate the messages.  More information is really required about the path it took.

[quote user="Thomas R. Stephenson"]

Anyone have any ideas please?

The only idea I have is that since this was a 15 MByte file the message was broken into smaller parts by a server along the line.  There are RFCs that allow this but normally the sending client has to generate the messages.  More information is really required about the path it took.

[/quote]

Thanks, Thomas

All our mail goes out via MessageLabs, and I have no idea what path these messages took after Mercury sent them.

The message list that I show in the screenshot is from our 'catchall' account that shows all messages sent and received by everyone. The messages marked 1, 2, 3 etc were each created by Pegasus Mail. These are the messages that were sent by Mercury.

All our mail goes out via MessageLabs, and I have no idea what path these messages took after Mercury sent them.

The message list that I show in the screenshot is from our

'catchall' account that shows all messages sent and received by

everyone. The messages marked 1, 2, 3 etc were each created by Pegasus

Mail. These are the messages that were sent by Mercury.

PMail will never break a message into parts, it will only send the basic message and the attachments separately if it is set to send attachments rather them enclosures. I can't tell if the original message had a single enclosure of ~15 MBytes of multiple enclosures adding up to ~15 MBytes. 

If this was a message with a single single ~15 MByte file then something else broke the message into parts. 

If this was a message with multiple enclosures and was sent my PMail that was set to send attachments then there should have been a single message with the body text and separate messages each containing one complete attachment.

[quote user="Thomas R. Stephenson"]

All our mail goes out via MessageLabs, and I have no idea what path these messages took after Mercury sent them.

The message list that I show in the screenshot is from our 'catchall' account that shows all messages sent and received by everyone. The messages marked 1, 2, 3 etc were each created by Pegasus Mail. These are the messages that were sent by Mercury.

PMail will never break a message into parts, it will only send the basic message and the attachments separately if it is set to send attachments rather them enclosures. I can't tell if the original message had a single enclosure of ~15 MBytes of multiple enclosures adding up to ~15 MBytes.[/quote]

The contents of the original message that the member of staff received are shown in the second screenshot. As you can see from the first screenshot Pegasus Mail reports that this message (highlighted) is 15MB in size. It is comprised of several images.

[quote user="Thomas R. Stephenson"]

If this was a message with a single single ~15 MByte file then something else broke the message into parts. 

If this was a message with multiple enclosures and was sent my PMail that was set to send attachments then there should have been a single message with the body text and separate messages each containing one complete attachment.[/quote]

Here is a screenshot taken from the member of staff's Pegasus Mail settings:

The option to create separate messages is not checked.

This what I do not understand. The member of staff forwarded this message and Pegasus Mail created multiple messages before forwarding it. The first six that were created are shown in the numbered screenshots which relate to the numbered messages in the first screenshot.

If you would like further information, please ask.

Thanks

So, do you think this is a glitch? I've not seen Pegasus Mail do this before. It's very strange. If it's a glitch then I'll ignore it. However, if there is something wrong, then I would appreciate any help determining what the problem may be.

Thanks

I would look to the outgoing server to find out what process is involved there.  I have seen similar issues when I had a server failing to respond properly.

[quote user="PaulW"]

I would look to the outgoing server to find out what process is involved there.  I have seen similar issues when I had a server failing to respond properly.

[/quote]

Thanks

However, I do not understand what you mean. The outgoing server is Mercury/32 on a Windows 2003 server. For outgoing mail Mercury is simply setup to copy outgoing messages (and incoming) to a 'catchall' address. We've not had any problems with Mercury before or since. 

What evidence do you have when you state that 'Pegasus Mail created multiple messages before forwarding' and that it split the 15MB mail up into 6 parts totalling 163MB?  Your description shows the original message and 'subsequent messages from the sender'.  Without knowing the contents of the messages it is hard to do any diagnostics, but I have seen a similar pattern of a large message not being sent and gradually increasing in size when a server was failing.

You mention Mercury and Messagelabs.  Either one of these may have had a problem handling this message for whatever reason, or the issue may be further down the delivery chain.  You would need to see a trace or log to determine if there was an issue.  The headers of any returned mail would help to show where the message was routed.  Post one if you can, with any sensitive data x'ed out.

So, do you think this is a glitch? I've not seen Pegasus Mail do this before. It's very strange. If it's a glitch then I'll ignore it. However, if there is something wrong, then I would appreciate any help determining what the problem may be.

Glitch for sure but not for PMail and Mercury.  Again, PMail when sending attachments instead of enclosures send one mail message with the body text and one mail message for each attachment.  It does not break attachments is to separate parts. It's impossible to tell from what you are showing to determine what is going on.  PMail may be set to send separate attachments (and this can be identity specific) but it does not cause any real problems on the other end.

Thanks again for your replies.

OK. This is how our system works:

Everyone uses Pegasus Mail. All mail processing is handled by Mercury/32. All outgoing messages processed by Mercury are copied to a catchall account when they are sent and all incoming messages are copied to the same catchall account. This is achieved using the 'Always' global filtering rule. All outgoing mail is sent through MessageLabs email service and all incoming mail is received via MessageLabs.

The list of messages that is shown in the first screenshot is taken from the catchall account, sorted by subject.

All the messages enclosed in the red rectangle are from the person (original-sender, shown below) who sent the original message. The highlighted message is the one that actually contains the images. Here are the headers from the highlighted message:

X-SPAMWALL: Passed through antiSPAM test by SpamHalter 4.4.0 on apsarchaeology.co.uk (10389)
X-SPAMWALL: probability - 0.0%
X-SPAMWALL: Whitelisted
Return-path: <original-sender@aol.com>
Received: from mail188.messagelabs.com (85.158.139.163) by apsarchaeology.co.uk (Mercury/32 v4.62) ID MG0006DE;
   2 Jun 2009 14:10:47 +0100
X-VirusChecked: Checked
X-Env-Sender: original-sender@aol.com
X-Msg-Ref: server-14.tower-188.messagelabs.com!1243948279!35015028!1
X-StarScan-Version: 6.0.0; banners=-,-,apsarchaeology.co.uk
X-Originating-IP: [205.188.157.41]
X-SpamReason: No, hits=0.0 required=7.0 tests=Mail larger than max spam
  size
Received: (qmail 17825 invoked from network); 2 Jun 2009 13:11:19 -0000
Received: from imr-d03.mx.aol.com (HELO imr-d03.mx.aol.com) (205.188.157.41)
  by server-14.tower-188.messagelabs.com with SMTP; 2 Jun 2009 13:11:19 -0000
Received: from  imo-ma03.mx.aol.com (imo-ma03.mx.aol.com [64.12.78.138]) by imr-d03.mx.aol.com (v107.10) with ESMTP id RELAYIN3-44a25246f21f; Tue, 02 Jun 2009 09:09:03 -0400
Received: from original-sender@aol.com
 by imo-ma03.mx.aol.com  (mail_out_v40_r1.5.) id r.d2d.4bf9f484 (48600)
  for <staff@apsarchaeology.co.uk>; Tue, 2 Jun 2009 09:08:46 -0400 (EDT)
From: original-sender@aol.com
Message-ID: <d2d.4bf9f484.37567f23@aol.com>
Date: Tue, 2 Jun 2009 09:12:03 EDT
Subject: Fwd: re medieval jar
To: staff@apsarchaeology.co.uk
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="part1_d2d.4bf9f484.37567f23_boundary"
X-Mailer: AOL 9.0 VR sub 68
X-Spam-Flag:NO
X-AOL-IP: 64.12.78.138

--part1_d2d.4bf9f484.37567f23_boundary
Content-Type: multipart/alternative;
 boundary="-----------------------------1243948322"

-------------------------------1243948322
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

When our member of staff (staff, shown below), received the original (highlighted) message, they forwarded it to one person (recipient, shown below). Pegasus Mail created the messages you see in the list which are numbered. The numbered messages are sent messages that have been copied to the catchall account before they were sent by Mercury.

Here are headers from the first three numbered messages: 

1
From: "staff" <staff@apsarchaeology.co.uk>
To: receipient@cheshirewestandchester.gov.uk
Date: Tue, 02 Jun 2009 15:25:05 +0100
MIME-Version: 1.0
Content-type: Multipart/Mixed; boundary=Message-Boundary-13750
Subject: (Fwd) Fwd: re medieval jar
Message-ID: <4A254451.19522.6C464AD@staff.apsarchaeology.co.uk>
Priority: normal
X-mailer: Pegasus Mail for Windows (4.41)
--Message-Boundary-13750
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body

2
From: "staff" <staff@apsarchaeology.co.uk>
To: receipient@cheshirewestandchester.gov.uk
Date: Tue, 02 Jun 2009 15:25:05 +0100
MIME-Version: 1.0
Content-type: Multipart/Mixed; boundary=Message-Boundary-13750
Subject: (Fwd) Fwd: re medieval jar
Message-ID: <4A254451.19522.6C464AD@staff.apsarchaeology.co.uk>
Priority: normal
X-mailer: Pegasus Mail for Windows (4.41)

--Message-Boundary-13750
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body

3
From: "staff" <staff@apsarchaeology.co.uk>
To: recipient@cheshirewestandchester.gov.uk
Date: Tue, 02 Jun 2009 15:25:05 +0100
MIME-Version: 1.0
Content-type: Multipart/Mixed; boundary=Message-Boundary-13750
Subject: (Fwd) Fwd: re medieval jar
Message-ID: <4A254451.19522.6C464AD@staff.apsarchaeology.co.uk>
Priority: normal
X-mailer: Pegasus Mail for Windows (4.41)

--Message-Boundary-13750
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body

When MessageLabs receives a message that is larger than 20MB in size, a content control rule is triggered and the message is not sent any further but is returned to us. Here is a header from one of the returned messages:

X-SPAMWALL: probability - 0.0%
Return-path: <staff@apsarchaeology.co.uk>
Received: from mail194.messagelabs.com (85.158.140.211) by apsarchaeology.co.uk (Mercury/32 v4.62) ID MG0007E1;
   2 Jun 2009 16:13:13 +0100
X-VirusChecked: Checked
X-Env-Sender: staff@apsarchaeology.co.uk
X-Msg-Ref: server-2.tower-194.messagelabs.com!1243953152!11800733!2
X-StarScan-Version: 6.0.0; banners=apsarchaeology.co.uk,-,-
X-Originating-IP: [82.69.48.10]
X-ContentInfo: mail is outbound, sender staff@apsarchaeology.co.uk,
  mail size (32388159 bytes) exceeds 20480000 bytes, 29315 Size Rule,
  apsarchaeology.co.uk
X-Content-Flag: YES
Received: (qmail 18814 invoked from network); 2 Jun 2009 14:54:10 -0000
Received: from mail.apsarchaeology.co.uk (HELO apsarchaeology.co.uk) (82.69.48.10)
  by server-2.tower-194.messagelabs.com with SMTP; 2 Jun 2009 14:54:10 -0000
Received: from Spooler by apsarchaeology.co.uk (Mercury/32 v4.62) ID MO000791;
  2 Jun 2009 15:52:59 +0100
Received: from spooler by apsarchaeology.co.uk (Mercury/32 v4.62); 2 Jun 2009 15:29:54 +0100
From: "staff" <staff@apsarchaeology.co.uk>
To: receipient@cheshirewestandchester.gov.uk
Date: Tue, 02 Jun 2009 15:25:05 +0100
MIME-Version: 1.0
Content-type: Multipart/Mixed; boundary=Message-Boundary-13750
Subject: (Fwd) Fwd: re medieval jar
Message-ID: <4A254451.19522.6C464AD@staff.apsarchaeology.co.uk>
Priority: normal
X-mailer: Pegasus Mail for Windows (4.41)

I assumed that 'staff's' copy of Pegasus Mail created these messages because the original messages as sent exist in the catchall account. The number of returned messages matches the number of sent messages that were larger than 20MB. If MessageLabs had encountered problems sending these and had generated the extra messages, wouldn't the number of returned messages not tally with the sent messages? Out of interest, can a service do that?

In the past some members of staff have had the 'Send attachments as separate messages' option checked, but the recipients found this to be quite confusing so we have not used it for a long time.

I hope that this helps in determining what may have caused this. In all honesty, if the messages forwarded by 'staff' had not been blocked and returned, I would not have known about it.

Once again, I truly appreciate the fact that you all find the time to help.

Cheers!

Once again, I truly appreciate the fact that you all find the time to help.

You are still not telling us what each of the messages contained.  

1.  If the original 15 MByte message contained text and multiple enclosures and

2.  the multiple messages sent by PMail was one message with text and then multiple messages with single attachments

3. then this is a series of messages that can be generated by PMail when it is set to send attachments as separate messages.   

This can be set differently for each identity so when checking the setting you must check for each identity as well.

[quote user="Thomas R. Stephenson"]

Once again, I truly appreciate the fact that you all find the time to help.

You are still not telling us what each of the messages contained.  

1.  If the original 15 MByte message contained text and multiple enclosures and [/quote]

Thanks for the reply

The first post shows what the original message contained. The second screenshot in the first post shows the attachments page of the original received message.

[quote user="Thomas R. Stephenson"] 2.  the multiple messages sent by PMail was one message with text and then multiple messages with single attachments [/quote]

The first post shows this information. The screenshots numbered 1 to 6 show the contents of each message that Pegasus Mail created when the original was forwarded. The message was forwarded to just one recipient. As you can see, each message's attachment page shows 'E-Mail message' entries and a size value.

[quote user="Thomas R. Stephenson"]3. then this is a series of messages that can be generated by PMail when it is set to send attachments as separate messages.   

This can be set differently for each identity so when checking the setting you must check for each identity as well.[/quote]

Only one identity is used. Pegasus Mail is not set to send attachments in separate messages - the screenshot in my reply of 9th June shows the user's ('staff') settings for sending mail.

Cheers!

Yes, but for instance your message 3 contains two large emails.  How are they formatted?  Does the first contain the whole of the original email? Is the second one just a part of the first?  What do the other parts contain?  Were they contained in the original email?

None of these appear to be attachments being sent separately, so I doubt if that has anything to do with the problem.

Thanks for the reply

Clicking on an 'E-Mail message' entry in the attachments pane does not reveal what that attachment contains.

For example, if I select either the 15MB or 12MB 'E-Mail message' in message 3, nothing is shown in the lower pane. I don't think PM is attempting to show these as there is no wait icon displayed, and PM responds immediately to other commands - usually PM with simply appear to lock up when it is busy.

The raw view shows the written and quoted messages sent by 'staff' and then the remainder of the body contains a zillion lines of random text.

I have just asked 'staff' to forward to my personal address and see if the problem can be duplicated. I'll post back with the results.

Edit:

I had the attachment preview turned off in the catchall account... the two entries contain the same information. The first entry contains the message that was forwarded to the original sender, and the second is from the original sender to 'staff'. Both are plain text, and both, I assume, contain the images.

Edit 2:

This time Pegasus Mail created a single message of 58MB. MessageLabs returned a single message 58MB.

I'm quite happy to drop this if you guys agree. I don't see the point persuing what appears to have been an isolated glitch.

Something strange is happening to the message.  My understanding: it's a simple message containing 4 pictures each under 3MB.  You now talk about a 58MB message.  Something is wrong - do you have a real-time anti-virus on the workstation or server?

How is Pegasus forwarding the message - SMTP or directly to the queue?

Hi Paul

Real-time AV is active, but the Mercury folder and sub-folders are excluded from scanning. Mail is sent directly to the queue.

Here's a shot showing the mail in its forwarded state:

What size should the forwarded message have been? In my experience, forwarded messages usually increase by a quarter.