Page 1 of 1

[FIXED] Boundry tags showing in mail text

Posted: Thu Feb 15, 2007 11:05 pm
by gwesterberg
Using php 4.3.10, and have tried SwiftMailer 2.1.13 and 3.0

I was running along just fine with 2.1.13 for about 4 months. Recently an issue popped up. The boundary tag is showing up in the text. As an example, I'll send an email with the body of "test". The following shows up in the text portion of the email:

test --_=_swift-26624248045d1de5e80cde4.73115359--

I don't know what the boundary tag is but when I look at the raw message (not just the section displayed by the email browser) it seems to be a perfectly normal item in the message.

I tried upgrading to 3.0 and still have the same issue. Has anyone else seen this? Any idea how to make it stay invisible to the reader?

Thanks for your help.

Posted: Fri Feb 16, 2007 3:17 am
by Chris Corbyn
Can you post the full email source? What mail client do you use?

email source

Posted: Fri Feb 16, 2007 11:09 am
by gwesterberg
I use gmail and what I specifically see is this:

test2
--_=_swift-173863885645d52d27cb7fd1.84969873_=_--


A few others that I have talked to use hotmail and outlook. They do *not* see the tag.

Below is the full email source. Note that it has an embedded image. I snipped most of the image to shorten the post but let me know if you prefer to see the whole thing.

Code: Select all

Delivered-To: gwesterberg@gmail.com
Received: by 10.70.98.20 with SMTP id v20cs2030wxb;
        Thu, 15 Feb 2007 20:03:52 -0800 (PST)
Received: by 10.35.111.14 with SMTP id o14mr4995195pym.1171598632513;
        Thu, 15 Feb 2007 20:03:52 -0800 (PST)
Return-Path: <glen@durhame.org>
Received: from host12.christianwebhost.com (host12.christianwebhost.com [209.239.42.35])
        by mx.google.com with ESMTP id x48si3181686pyg.2007.02.15.20.03.51;
        Thu, 15 Feb 2007 20:03:52 -0800 (PST)
Received-SPF: neutral (google.com: 209.239.42.35 is neither permitted nor denied by best guess record for domain of glen@durhame.org)
Received: from durhame.org (durhame.org [208.56.94.196])
	by host12.christianwebhost.com (8.12.11.20060614/8.12.10) with ESMTP id l1G43pEj015955;
	Thu, 15 Feb 2007 23:03:51 -0500
Message-Id: <200702160403.l1G43pEj015955@host12.christianwebhost.com>
To: undisclosed-recipients:;
From: glen@durhame.org
Reply-To: glen@durhame.org
Subject: test2
Date: Thu, 15 Feb 2007 23:03:51 -0500
X-Mailer: Swift 3.0.0_4
MIME-Version: 1.0
Content-Type: multipart/related;
 boundary="_=_swift-3487931345d52d27cb72f3.00712698_=_"
Content-Transfer-Encoding: 8bit

This is a message in multipart MIME format.  Your mail client should not
be displaying this. Consider upgrading your mail client to view this
message correctly.
--_=_swift-3487931345d52d27cb72f3.00712698_=_
Content-Type: multipart/alternative;
 boundary="_=_swift-173863885645d52d27cb7fd1.84969873_=_"
Content-Transfer-Encoding: 8bit


--_=_swift-173863885645d52d27cb7fd1.84969873_=_
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<img src="cid:swift-file.1" alt="" />test2
--_=_swift-173863885645d52d27cb7fd1.84969873_=_
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

test2
--_=_swift-173863885645d52d27cb7fd1.84969873_=_--
--_=_swift-3487931345d52d27cb72f3.00712698_=_
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename=swift-file.1
Content-ID: <swift-file.1>

iVBORw0KGgoAAAANSUhEUgAAAyAAAAB+CAYAAADcHHVyAAAABmJLR0QA/wD/AP+gvaeTAAAA
CXBIWXMAAAsTAAALEwEAmpwYAAAAB3RJTUUH1wIGFQcIxzP15QAAIABJREFUeNrsnXecHWd1
979n5rbtu+qSZcmyLVmy5F7AphgbjKk2hgChhhZaCAQICeUlBUJJSCAQSujBAUJJYloMwtjG
BmxjXLFsy1WW1etK22+Z57x/PGfunR3du7vqkpnf53O98ty5U556fqeKqpIhQ4YMGTJkyJAh
Q4YMhwJB1gQZMmTIkCFDhgwZMmTICEiGDBkyZMiQIUOGDBkyApIhQ4YMGTJkyJAhQ4YMGQHJ

<  S  N  I  P >

mIQAwtAuYJBsINQQY0LRuqKMCUTrkqd1rxjToXTYBmM2ijEbldZboMNW0XozgHYxuhNaF2BM
AcYUYUxxSc6RDUdAHAFxcHBwcHBwcHgjkxKBXfTwAVMDoBaQiJiMtq+mGZAGAPUwpgaCWkB8
o7USAyXaSFjRgNbGBpeHIQxChLoMbXpNiG4xplu07hKt2zwdblVad4gxbcroTtG6INoUlNYV
MTbI5MX5X3dKpoMjIA4ODg4ODg4ODg4O/1woVwUODg4ODg4ODg4ODo6AODg4ODg4ODg4ODg4
AuLg4ODg4ODg4ODg4OAIiIODg4ODg4ODg4ODIyAODg4ODg4ODg4ODg6OgDg4ODg4ODg4ODg4
OALi4ODg4ODg4ODg4OAIiIODg4ODg4ODg4ODgyMgDg4ODg4ODg4ODg6OgDg4ODg4ODg4ODg4
OPwD/gf6cOa4zGKE9gAAAABJRU5ErkJggg==
--_=_swift-3487931345d52d27cb72f3.00712698_=_--

Posted: Fri Feb 16, 2007 11:29 am
by Chris Corbyn
I can confirm, when I run my smoke tests I get the image displayed as expected, and the text as expected, but there's a trailing boundary in there. This only seems to be happening with Gmail and I can't find an immediate problem with the email source code. Thunderbird, Evolution and AppleMail display the image correctly. Hotmail does, Mail2Web does. I know Google Mail is still a BETA version. I'll try sending an embedded image with some other software and see what happens. I won't rule out that it's a swift problem though... I'm looking at it now.

thanks!

Posted: Fri Feb 16, 2007 12:24 pm
by gwesterberg
Thanks so much for looking in to this. I'm not convinced it *is* a swift problem but I'm sure you know a lot more about how to look in to it than I do.

FYI, I love Swift. written well, documented well and easy to use![/syntax]

Posted: Sat Feb 17, 2007 3:49 pm
by Chris Corbyn
Just to update the thread, I have been looking at this all today and have still not come to a conclusion as to what is causing it other than the way Gmail is parsing the code. I have gone back and read 6 different MIME RFCs (2822 & 2045-2049) today and still conclude that the source is compliant. I can understand why it may be tricker to parse than a standard approach to sending an email with an embedded file because Swift actually puts a multipart/alternative body inside a multipart/related body.

I'll enhance this functionality so that if there's only one body part present, the multipart/alternative section gets simplified down to just one part. I WILL NOT be removing the ability to put multipart/alternative inside a multipart/related message however, because as I say, it's compliant, perfectly valid, and technically more accessible. It will be up to developers to decide if they wish to mix the subtypes and I'll include an explanation in the documents. It's lucky that version 3 messages are based on top of an entire MIME layer which makes restructuring messages realtively trivial.

Thanks for the heads-up on the issue... I need people to let me know niggles like this :)

Posted: Mon Feb 19, 2007 3:49 pm
by Chris Corbyn
This is fixed in subversion now.

I can also rest assured that my source was (and still is) compliant. Gmail just wanted a bit more space between my MIME boundaries, so I gave it some :)

If you don't use subversion, don't worry, I'm releasing full versions either tonight or tomorrow. I just need to prepare a few bits of the website for it first.

sweeet

Posted: Mon Feb 19, 2007 7:16 pm
by gwesterberg
Thanks so much for the fast response! I'll port over the new code sometime in the next week and will post my status.

Works just fine

Posted: Thu Mar 01, 2007 8:23 pm
by gwesterberg
I bumped up to version 3.0.1 and gmail looks fine now. Thanks again!

Re: Works just fine

Posted: Fri Mar 02, 2007 2:58 am
by Chris Corbyn
gwesterberg wrote:I bumped up to version 3.0.1 and gmail looks fine now. Thanks again!
You might want to enable Disk Caching it you're using 3.0.1. You'll get big memory improvements when sending attachments/images:

You need a writable directory on the server.... /tmp/ will usually do fine!

Code: Select all

<?php

require_once "lib/Swift.php";
require_once "lib/Swift/Connection/SMTP.php";

Swift_CacheFactory::setClassName("Swift_Cache_Disk");
Swift_Cache_Disk::setSavePath("/somewhere/writable");

$swift = new Swift(new Swift_Connection_SMTP("localhost"));

// ... snip ...