[ngw] GW 2014 to MIME or not to MIME
Georg Fritsch FCP
gf at fcp.at
Mon Jul 21 15:48:09 UTC 2014
So, if a signature has no graphic or there is no signature, NO mime.822 is created - which is correct, because there is no need to have one.
But for compatibility reasons a mime.822 is created if a signature has a graphic - making it totally incompatible to all other use cases.
Wow, a really cool feature. :-(
... Maybe it is to compensate for a LACK of compatibility. The gwia might be to 'stupid' to create a meaningful mime representation for more complex signatures or html stuff (including a picture) on the fly and relies on the client/server to do the 'hard' work ... or there is no code/data path from the client to the gwia to transport the html graphic data besides passing a full mime.822 representation - essentially more than doubling the amount of data ...
As it turns out - i just checked while is was writing this - a mime.822 part is generated if an outgoing mail has a html part which includes a picture. Nothing to do with signatures, it is a general problem --- sorry --- feature :-)
Write a html mail, just text no graphics - no mime.822
Write a html mail and include a picture, you get the image PLUS a mime.822 encoded version in your sent item - just a total waste of space.
I would prefer to have a mime.822 either in both cases or none at all.
>>> On 21.07.2014 at 16:27, in message <53CCCEE6.8F17.008A.3 at mhtn.com>, "Daniel
Wells" <Daniel.Wells at mhtn.com> wrote:
> It turns out any time a graphic is embedded in an email, the Mime.822 is
> created, i believe for message compatibility reasons. There is a logo
> graphic in our standard signature, so when the signature is used, the graphic
> causes the Mime.822 file creation, thus making the email appear larger than
> what is sent.
> Daniel Wells AIA, VCP
> Senior Associate | IT Coordinator
> MHTN Architects, Inc.
> Direct: 801.326.3215 | www.mhtn.com
> vision made real
> >>> "Ian Young" <IYoung at graphic.plc.uk> 7/18/2014 6:55 AM >>>
> I believe the mime.822 contains all the information received by the
> SMTP server, between the DATA command and the closing period. Having it
> enables you to look at the headers of an email but it does have the
> disadvantage of making all incoming emails twice as big. This can be a
> problem if you regularly receive large emails, as we do. It would be
> nice if GW just saved the headers of the email, not the whole thing.
> Ian Young
> IT Manager
> Extension 364
> DDI - 01363 778764
>>>> gf at fcp.at 18/07/2014 08:22 >>>
> My understanding is that the mime.822 attachment is the mime
> representation of the complete mail used in smtp transfers. This part is
> basically base64 coded adding approx. 35% to the size. A 5MB mail
> including the 7MB mime representation will be approx. 12MB.
> If you send an internal 1MB attachment, the sent item is aprrox. 1MB.
> Just the binary file.
> If you receive from an external address an 1MB attachment, the mail is
> approx. 2,4MB with
> a 1MB binary attachment
> a 1,4MB mime.822 representation of the whole mail. (Can be viewed in
> the message source tab)
> However, this mime.822 part is missing on my original sent items. I
> only see it for incoming stuff or anything which went through smtp.
> Nothing to do with adding a signature. But i only us a simple personal
> signature without images and no global signature.
>>>> On 17.07.2014 at 18:30, in message < 53C7A5B5.8F17.008A.3 at mhtn.com
> Wells" < Daniel.Wells at mhtn.com > wrote:
>> I had a user approach me and ask why when they added a signature to
> an email
>> with attachments, the size listed in the sent items is almost
>> I started looking and testing. I sent two emails with a 5.01 MB PDF
>> attachment, one with our standard signature one without. The
>> client listed both as 7 MB (the attachment listed as 6.9 MB).
>> Within the GroupWise client the sent items were listed differently,
>> the signature it is shown as 5.02 MB with the signature it is 11.9
>> The item sent without the signature has the message, text.htm and the
>> attached file listed. The message with the signature has the message,
>> text.htm, Mime.822, Image.gif and the attachment.
>> I understand the Image.gif is part of the signature. What is it about
>> signature that adds the Mime.822 file, but it is not there on the
>> without the signature?
>> Thanks in advance?
>> Daniel Wells AIA, VCP
>> Senior Associate | IT Coordinator
>> MHTN Architects, Inc.
>> Direct: 801.326.3215 | www.mhtn.com
>> vision made real
>> Confidentiality Notice: This e-mail, including attachments, are
>> and confidential and/or proprietary information intended solely for
> the use
>> of the individual or entity to whom this is addressed. If the reader
> of this
>> message is not the intended recipient, or the employee or agent
>> to deliver it to the intended recipient, you are hereby notified that
>> dissemination, distribution or copying of this communication is
>> prohibited. If you received this communication in error, please
>> notify sender by telephone or reply email, do not use or disclose the
>> contents to others, and delete the message and all attachments from
>> computer, system and/or network. Further, e-mail transmission cannot
>> guaranteed to be secure or error-free as information could be
>> corrupted, lost, destroyed, arrive late or incomplete, or contain
>> The sender therefore does not accept liability for any errors or
> omissions in
>> the contents of this message, which arise as a result of e-mail
>> If verification is required please request a hard-copy version.
> Graphic PLC
> Tel. +44 (0) 1363 774874
> Fax. +44 (0) 1363 775753
> Website: www.graphic.plc.uk
> Before printing this email, please consider the environment.
> This e-mail and any files transmitted with it are intended for the exclusive
> use of the addressee only and may be confidential. If you are not the
> intended recipient, you should not use the contents nor disclose them to any
> other person, and you are requested to notify the sender and delete the
> Please note that design advice is given in good faith and without prejudice.
> Graphic cannot be held responsible for any product failure, or if systems do
> not perform as expected. Information given is for the use of the recipient
> only and others within their organisation; it should not be given to a third
> party without express authorisation from Graphic plc.
> ITAR regulations stipulate that customers must inform their suppliers if
> their products are subject to ITAR regulations. If no mention of the ITAR
> regulations is made on the quote request or the order then Graphic PLC will
> assume that the ITAR regulations do not apply.
> Internet communications are not secure, and Graphic PLC is not responsible
> for any changes made to the message after it was sent. Although steps have
> been taken to ensure that this email and any attachments are virus-free,
> Graphic plc cannot guarantee this, or accept liability for any damage
> sustained as a result of a virus. Recipients are advised to carry out their
> own virus checking, especially before opening an attachment.
> Graphic PLC, registered in England no. 1036230.
> Registered office: Graphic PLC, Down End, Lords Meadow Industrial Estate,
> Crediton, Devon, EX17 1HN, England.
> Confidentiality Notice: This e-mail, including attachments, are privileged
> and confidential and/or proprietary information intended solely for the use
> of the individual or entity to whom this is addressed. If the reader of this
> message is not the intended recipient, or the employee or agent responsible
> to deliver it to the intended recipient, you are hereby notified that any
> dissemination, distribution or copying of this communication is strictly
> prohibited. If you received this communication in error, please immediately
> notify sender by telephone or reply email, do not use or disclose the
> contents to others, and delete the message and all attachments from your
> computer, system and/or network. Further, e-mail transmission cannot be
> guaranteed to be secure or error-free as information could be intercepted,
> corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
> The sender therefore does not accept liability for any errors or omissions in
> the contents of this message, which arise as a result of e-mail transmission.
> If verification is required please request a hard-copy version.
More information about the ngw