The LoadBalancedTransport can cycles through a collection of SMTP servers to distribute sending in order to reduce the load on any single server.

However, a "would-be-nice" is a flag that allowed this transport (or a subclass of it?) to actually process messages to multiple transports in parallel. Currently it waits for each server to finish sending before it moves to the next.

Obviously PHP can't multi-thread, but because SMTP connections are TCP/Socket based there may be some trickery involving non-blocking connections that can be used.

We may need to write a PIPELINING extension to do this in one-hit per server.

Original creation date: 2008-12-24T11:16:34Z
Original reporter: Chris Corbyn
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/29

Lines are not wrapping when sending via mail(). I have not set setMaxLineLength() because I am letting swift mailer use the default.

I am sending via HTML mime type.

Using latest version

Original creation date: 2009-07-23T16:52:08Z
Original reporter: Ben
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/100

Version 3 had a plugin called the FileEmbedder who's job it was to scan emails before they were sent and "inject" embedded images where it found tags.

Some users have reported issues where valid paths were not recognised by the plugin in version 3 so bear this in mind when building the plugin.

Original creation date: 2008-12-14T02:05:25Z
Original reporter: Chris Corbyn
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/4

$htmlmessage="Chinese : 网站 - Russian : сайт";
The following standard code works fine with
$htmlmessage="Chinese : 网站 - Greek : ιστοσελιδα - Russian : сайт";
But not with
$htmlmessage="çñàáâäãèéêëìíîïòóôöõùúûü Japanese : ウェブサイト - Chinese : 网站 - Greek : ιστοσελιδα - Russian : сайт";

$textmessage=ox_html2text($htmlmessage);

$transport = Swift_SmtpTransport::newInstance();
$mailer = Swift_Mailer::newInstance($transport);
$message = Swift_Message::newInstance()
->setSubject($mailsubject)
->setFrom(array(OX_FROM => 'Oxange Private Business Network'))
->setTo(array($mailto))
->setBody($textmessage, 'text/plain')
->addPart($htmlmessage, 'text/html')
->setMaxLineLength(76)
->setPriority(2)
;
if($mailer->send($message)){...

Original creation date: 2009-08-12T13:35:57Z
Original reporter: xdecock
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/106

Currently the IoBuffer interface tries to do too much. In order to do so much it uses the whacky setParams() method so that it can be told it is now a "process" rather than a "socket" and so that port numbers can be set etc. It also allows changing the cyrptography.

The IoBuffer interface exists to make testing easier so we want to keep it, but simplify it.

We don't want to have real connections being established in unit tests, so I say we change to this:

@@@ php
interface IoBuffer extends OutputByteStream, InputByteStream
{

function initialize($ioStream);
function setCrypto($crypto);
function readLine($seq);
function terminate();

}

interface StreamFactory {
createSocket($host, $port, $cyrpto, $timeout);
createProcess($command);
}
@@@

Now the SMTP Transport and the Sendmail Transport can use these two classes to create a real stream (in the PHP sense) and pass that to an IoBuffer for reading and writing.

Original creation date: 2009-01-05T09:35:43Z
Original reporter: Chris Corbyn
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/32

Hi,

I was trying to encode header value, which has "iso-2022-jp" charset and Swift_Mime_HeaderEncoder_Base64HeaderEncoder encoder.

When I looked at the source code, the subject header is going to be an object of Swift_Mime_Headers_UnstructuredHeader. In the class, encodeWords method, which has five arguments, is called in getFieldBody method. And when I looked at the encodeWords method in Swift_Mime_Headers_AbstractHeader.class.php, only three arguments are supported, and it does not encode iso-2022-jp and base64 base string.

There is a former discussion:
http://groups.google.com/group/swiftmailer/msg/7b7ace04a2d17169?pli=1
As the discussion above says, there's an useful function called mb_encode_mimeheader in mbstring extension, and I read one blog article, http://www.kuzilla.co.jp/article.php/20100301symfony ,try to avoid this cannot-encoding problem by extending Swift_Message and Swift_Mime_Headers_UnstructuredHeader, this is one way for the moment, but if the encoding works properly, I do not have to use that kind of hack.

Original creation date: 2010-03-05T03:52:25Z
Original reporter: shin
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/138

Getting the following error when running swift 4.05 Fatal error: Maximum execution time of 30 seconds exceeded in /home/worlda3/public_html/admin/swift4/classes/Swift/StreamFilters/ByteArrayReplacementFilter.php on line 136

require_once $SrcDir."swift4/swift_required.php";
require_once $SrcDir."swift4/classes/Swift/SmtpTransport.php"; // Swift_SmtpTransport
$transport = Swift_SmtpTransport::newInstance('mail.worldaffairsflorida.org', 25);
$transport ->setUsername('[email protected]');
$transport ->setPassword('xxxxxx');
$mailer = Swift_Mailer::newInstance($transport);
$mailer->registerPlugin(new Swift_Plugins_ThrottlerPlugin( 6, Swift_Plugins_ThrottlerPlugin::MESSAGES_PER_MINUTE ));

Original creation date: 2009-11-04T21:55:37Z
Original reporter: Jerry
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/114

Hello.
There is some character encoding bug I guess. I think I need output in ISO-8859-2 because the email clients here like it. UTF-8 in headers doesn't not work correct in Outlook for example.

Most of the characters are OK, but some of them are encoded differently. For example, the little "s" with cedilla is encoded as a "=9A" and the Outlook needs it to be "=B9". I don't know why it has to be B9 when 9A is right.

I would like to make some str_replace at output to solve this problem. And I would like to know, where to do it( a place where the string is encoded already). I hope it helps to others too.

Original creation date: 2009-04-20T20:26:45Z
Original reporter: Milos
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/87

Hi,

I have the same problem which explain in this thread :
http://groups.google.com/group/swiftmailer/browse_thread/thread/11d8787d047b56b0/1385c2a77f64c740?lnk=gst&q=attachment#1385c2a77f64c740

After attaching a file in a mail I can not remove the file after sending the mail.
An handle is still open in the file and so in windows it is not possible to delete a opened file.

And if i try to delete the file in another request it is work fine.

Best Regards

Original creation date: 2010-02-05T15:27:20Z
Original reporter: skelettor
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/128

The LoadBalancedTransport (and probably the FailoverTransport) should not discard the error messages from the Transports it wraps otherwise debugging becomes difficult.

Original creation date: 2009-02-10T01:57:28Z
Original reporter: Chris Corbyn
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/53

This is a massive bottleneck when comparing v3 to v4. v3 did not do anything at all to manage character encodings, and thus it has major bugs in its QP encoding logic. v4 has fixed this, but at the expense of speed.

No real research was done in the area of the algorithms used to read character streams and as such, it's more than likely an existing (object-oriented) implementation can be adapted and work a lot faster than the current implementation.

Read through the source of Java's InputStreamReader and dependencies (namely StreamDecoder):

http://www.docjar.com/html/api/java/io/InputStreamReader.java.html
http://www.docjar.com/html/api/sun/nio/cs/StreamDecoder.java.html

Follow their dependencies and try to base our implementation off of this... Java tackled this long before we ever did and their OO approach should translate quite nicely.

End-user docs for those Java classes:

http://java.sun.com/j2se/1.4.2/docs/guide/io/io.html

Don't be fooled. This is a massive undertaking that will mostly likely ripple throughout the encoder components of Swift Mailer.

Original creation date: 2009-03-09T14:25:15Z
Original reporter: Chris Corbyn
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/66

Send mail fails when recipient name (cyrillic) contains spaces.
See details in attachement.

Original creation date: 2009-04-13T06:19:51Z
Original reporter: Chris Corbyn
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/83

The following code:

@@@ php

See my logo

Outlook works, Thunderbird will fall back to plain text and show the " . "HTML body (as Part 1.2) and the image as attachments

I had a problem with subjects containing special characters.
Characters are encoded correctly, but some extra linebreaks inserted to the subject header:

@@@ header
Subject: ugyeletes abcdef #37273-Closed-Low: =?utf-8?Q?=C3=81rv=C3=AD?=
=?utf-8?Q?zt=C5=B1r=C5=91_t=C3=B6k=C3=B6rf=C3=BAr=C3=B3g=C3=A9p?=
@@@

These extra linebreaks doesn`t honored by some email clients. (Outlook Express 6.0.2900.5512)

I found a simple but ugly solution, by modifying the AbstractHeader.php: (included in symfony 1.4)

@@@ diff
--- Swift/Mime/Headers/AbstractHeader.php
+++ Swift/Mime/Headers/AbstractHeader.php
@@ -483,7 +483,7 @@
'?' . $line . '?=';
}

• return implode("\r\n ", $encodedTextLines);
• return implode(" ", $encodedTextLines);
  }

/**
@@@

Any idea for a cleaner solution?

Original creation date: 2010-03-01T13:11:15Z
Original reporter: Reilly Sweetland
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/134

This has only started recently (whereas before I was not having any problems), but now everytime SwiftMailer tries to send out an email I receive the message below and do not know why:
No authentication mechanisms were tried since the server did not support any of the ones loaded. Loaded authenticators: [CRAM-MD5, LOGIN, PLAIN]

SwiftMailer has been integrated into a product for Joomla named bfForms (phil-taylor.com) and it seems to be using version 3.3.2 of your library.

PHPMailer appears to be able to send email no problem still within Joomla using SMTP, the problem only appears to be affecting Swift Mailer.

The only thing that has changed in recent weeks has been that our Exchange 2003 email server went down so they needed to replace it with a newer box and they ended up moving to Exchange 2007, but I don't know what settings may have changed during this process to cause SwiftMailer to stop working correctly.

Nothing on the forums or on Google has been useful, but I need to find a solution to the problem since the forms are fairly important.

I can do whatever I can to help you troubleshoot the issue.

Thank you!

Omar Ramos
Webmaster
Imperial Valley College
760-355-6500

Original creation date: 2009-05-14T15:51:18Z
Original reporter: Tim Cavanagh
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/91

Hi,

I'm using a Quoted-Printable encoding type, and if I have a URL in my email body, with for example
www.milanvasic.com/test/test.jpg , surround with HTML, and if 76 character is dot '.' the SWIFT replace it with equal and break the line, that's correct but the problem is in new line SWIFT add one more dot, and on users side we have a wrong URL's with two dots, like www.milanvasic..com/test/test.jpg.

Regards,
Milan

P.S.

some header details
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Original creation date: 2009-11-03T20:04:39Z
Original reporter: Milan Vasic
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/113

I am again experiencing this bug in SwiftMailer 4.0.5.

Have there been any relevant changes in the core which could have an influence on this issue? I thought that this had been solved in 4.0.4.

Like mentioned in the old thread, the problem is suppressed by disabling the cache:

Swift_Preferences::getInstance()->setCacheType('null');

Original creation date: 2011-03-23T10:18:39Z
Original reporter: xdecock
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/115

At around line 161 it detects if we're using a sendmail call or not and replaces "\r\n" on headers and the body. However the subject, if containing utf-8 characters, could be a folded header and also contain "\r\n". Some Greek that triggers this is "Ο φίλος σας". I believe the subject, and perhaps the to, header should also be included in the line ending replacements for correct behaviour.

Original creation date: 2010-07-07T08:48:33Z
Original reporter: mcheale
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/152

Bizzae Japanese Mobile Mail Address

By historical silly misunderstandings, some of Japanese cellphone carriers (NTT Docomo and KDDI au, No.1 and No.2 market shareholders) introduced RFC violated mail addresses. Even they fixed it for new registration, they are still widely used.

1. Local part begins with period

[email protected]

2. Local part ends with period

[email protected]

3. conseqtive periods in local part

[email protected]

All of above do not follow RFC2821, so giving those mail to Swift Mailer throws Exception.

[MTA]

But are they transferred properly? It depends on MTA. On Japanese part of the internet, they are usually accepted and transferred, because hundred of thousand such users exist.

[How other mailers treat it]

[iPhone]

When you tries to send to those address on iPhone, it pops up warning dialog. But you can proceed to send them.

[Outlook]

Outlook make it strict from Service Pack 3 and now you cannot send to those mail addresses.

[Gmail]

Google once introduced strict RFC filter, but now supports those format addresses if the receipients' domains are NTT Docomo or KDDI au.

[Possible Fixes]

I think it is a business and marketing decision so just list up fix options and want core team to choose.

1. change filter and always accept them

As your products and services can be used by Japanese with their cellphone address, it is one option to make them accepted by all Swift Mailer users.

Pro:

• all Swift Mailer user applications are Japanese market compliant
  Con:
  • everyone should make effort to follow the standard way
• invalid mail may cause with others if the application developer does not know it

2. add "Japanese cellphone mode"

If you turn it on, it accepts those bad addresses.

Pro:

• only people who suffers the issue uses it
  Con:

  • the libary will not be "out of the box" for Japanese users

  2-a) set it by constructor
  2-b) set it by calling method after instantiaion
  attached test code suggests this (method acceptJapaneseCellphoneAddress)
  2-c) set it in configuration file

  If a library user wants "warning", it is good if Swift_RfcComplianceException has more info, or specific subclass for "invalid RFC, but valid as Japanese cellphone address". Then it is possible for users to differenciate procedure afterwards. But it is not so mandatory as this can be also done outside of library before calling Swift Mailer.

  And what to accept if the mode is set.

  i) accept all of those invalid local part

  ii) accept mail addresses by carriers who allowed invalid address

  like what Gmail does. The patters are, as far as I know,

  (local-part)@docomo.ne.jp
  (local-part)@ezweb.ne.jp
  (local-part)@[a-zA-Z0-9_]+.dion.ne.jp
  (local-part)@[a-zA-Z0-9_]+.auone-net.jp

I attached an unit test code.

Original creation date: 2009-10-07T08:06:10Z
Original reporter: shin
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/110

This bug is related to ticket #34 and #77.

I am trying to create a multipart/alternative email with Swift 4.0.5 with a text section and html section with embedded images.

My code looks similar to:

@@@
$message = Swift_Message::newInstance();

$message->addPart("Test text body", 'text/plain');
$cid = $message->embed(Swift_Image::fromPath("test.jpg"));
$message->addPart("Html body <img src="$cid" />", 'text/html');
@@@

When viewing the sent message in Thunderbird 3, I see the HTML version with embedded images. However if I change Thunderbird to view the plain text version, I see a Thunderbird-gernerated plain text version of the HTML, not the plain text part I added.

In Swift 3, I was able to use Thunderbird to view the html and plaintext versions.

In Swift 4.0.5, the message source looks like:

@@@
Content-Type: multipart/alternative;
boundary="a"

--a
Content-Type: text/plain

Test text body

--a
Content-Type: multipart/related
boundary="b"

--b
Content-Type: text/html

...HTML...

--b
Content-Type: image/jpeg

...JPEG...

--b

--a
@@@

In Swift 3.3.3, the message source looked like:

@@@
Content-Type: multipart/related;
boundary="a"

--a
Content-Type: multipart/alternative;
boundary="b"

--b
Content-Type: text/plain

...PLAINTEXT...

--b
Content-Type: text/html

...HTML...

--b

--a
Content-Type: image/jpeg

...JPG...

--a
@@@

Original creation date: 2009-12-31T21:44:39Z
Original reporter: Brandon
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/119

The problem is that any smtp emails with bcc addresses will create two periods from one period if a period is at the beginning of a line for the bcc email (not for the to email) This is because for the bcc email the $this->_buffer->setWriteTranslations(array("\r\n." => "\r\n..")); translation is happening twice.

This, in turn, is caused by the fact that the cache is storing the filtered (translated) version of the input stream in the toByteStream method in the class Swift_Mime_SimpleMimeEntity. So when the cache is fetched the second time (for bcc) the translation is happening again.

In turn, the cache is storing the filtered version of the stream because the unbind method in Swift_ByteStream_AbstractFilterableInputStream is filtering the stream before writing it to the mirror. I would think that the whole point of a mirror is to copy the raw not filtered contents. So my proposal is to remove the filtering in unbind. The attached patch does just that.

Please note the ArrayByteStream does not filter for mirrors neither does the unbind method in Swift_Plugins_BandwidthMonitorPlugin

Original creation date: 2009-05-21T14:18:51Z
Original reporter: cevian
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/92

PHP is running with safe_mode = off, so Swift_Transport_SimpleMailInvoker::mail() passes ExtraParams to mail() function, but it fails to send messages if sendmail_path in php.ini is set with envelope sender param:
@@@
/usr/sbin/sendmail -t -i [email protected]
@@@

I'm using Swift-4.0.6

This is uncommon case, I haven't experienced till today. The only workaround I found, is removing extraParams from passing to mail() function in Swift_Transport_SimpleMailInvoker::mail(), but it must be left there for cases when sendmail_path is set without envelope sender param. So there is need for automated sendmail_path checking or at least some fail check, for example
@@@
if(!($result = mail($to, $subject, $body, $headers, $extraParams))){
$result = mail($to, $subject, $body, $headers);
}
return result;
@@@

Original creation date: 2010-08-10T15:15:26Z
Original reporter: Didulis
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/155

Using an ESMTP extension handler, as provided by the Swift Mailer API, create an extension that manages 8BITMIME.

This may be difficult to do in a way that does not permanently modify a user's message, yet still takes advantage of caching (caching may need to be cleverly managed by the extension handler).

8BITMIME allows clients to send messages over SMTP using full 8-bit characters as opposed to the traditional restriction of allowing only 7-bit characters as specified in RFC 2822. With the exception of the headers, which must ALWAYS be 7-bit only.

The extension will need to store instances of an 8bit transfer encoder and QP transfer encoder, which it can swap-out at runtime, immediately before sending.

If the ESMTP handler API does not suffice, enhance it.

Try to make sure caching is used and is not repeatedly busted by overwriting the encoder, but at the same time, ensure that the message is not permanently modified to use 8-bit encoding (the message that is provided to send() should have the same encoding as the message after it is sent). This brings up some interesting challenges with how to manage the cache here.

8BITMIME will significantly improve performance by avoiding the use of QP encoding where available.

Full RFC:

http://tools.ietf.org/rfc/rfc1652.txt

Original creation date: 2009-03-09T14:37:11Z
Original reporter: Chris Corbyn
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/68

Depends on #32.

Use the ESMTP extension API in Swift Mailer to add support for the use of STARTTLS.

This should be easy to achieve by performing a stream_enable_crypto() call on the SMTP socket immediately after sending the STARTTLS command.

Full RFC:

http://www.ietf.org/rfc/rfc3207.txt

Original creation date: 2009-03-09T14:29:05Z
Original reporter: xdecock
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/67

This is an easy one to fix. :)

When creating an Swift_SmtpTransport it, by default, tries to use the local server name ($_SERVER['SERVER_NAME']). If this server name is "localhost" (which it often is on a developer machine) then it fails the _isFqdn() check (which it rightly should) and the transport then defaults to using $_SERVER['SERVER_ADDR']. It does not, however, check whether this address against _isFqdn which it should.

On Mac OS X 10.5, SERVER_ADDR will often be ::1 which is an IPv6 address not compatible with (some/all?) SMTP servers resulting in a "501 5.5.4 Invalid Address" response to "HELO [::1]".

The fix would be to additionally check whether SERVER_ADDR is a full qualified domain name (or valid IP) and if not then just default to 127.0.0.1 which would be better than nothing.

Original creation date: 2009-07-22T15:34:22Z
Original reporter: Patrick Hogan
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/98

Can I get messages using this library? Looks like Zend_Mail ( http://framework.zend.com/manual/en/zend.mail.read.html )

The setChildren() method makes things incredibly easy, but it doesn't need to be the public-facing method for dealing with composition.

Decompose this into addChild() and removeChild() methods which delegate to setChildren() internally.

Make setChildren() private _setChildren().

This is going to break a lot of unit tests - be warned!

Original creation date: 2008-12-26T01:18:35Z
Original reporter: Chris Corbyn
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/31

Some SMTP server might have problems using "EHLO" although "ESMTP" occurs in the server reply message. So a forced use of "HELO" instead of "EHLO" would be a nice feature and would have saved me hours of painful debuging.

Possible "quick'n'dirty" solution:

protected function handshake(Swift_Events_ResponseEvent $greeting)
{
if($this->connection->getForcedHELO() {
$this->command("HELO " . $this->domain, 250);
return;
}
if ($this->connection->getRequiresEHLO() || strpos($greeting->getString(), "ESMTP"))
$this->setConnectionExtensions($this->command("EHLO " . $this->domain, 250));
else $this->command("HELO " . $this->domain, 250);
//Connection might want to do something like authenticate now
if (!$this->hasOption(self::NO_POST_CONNECT)) $this->connection->postConnect($this);
}

Original creation date: 2009-04-29T09:41:14Z
Original reporter: andu
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/90

When I send a mail from a script that is run on the command line with popen then I get the following errors:

[07-Apr-2009 12:03:23] PHP Warning: unlink(C:\WINDOWS\TEMP/49db24eb76e13/body) [function.unlink]: Permission denied in C:\wamp\www\group-office\www\classes\mail\swift\lib\classes\Swift\KeyCache\DiskKeyCache.php on line 247
[07-Apr-2009 12:03:23] PHP Warning: rmdir(C:\WINDOWS\TEMP/49db24eb76e13) [function.rmdir]: Directory not empty in C:\wamp\www\group-office\www\classes\mail\swift\lib\classes\Swift\KeyCache\DiskKeyCache.php on line 264

Original creation date: 2009-04-07T10:21:45Z
Original reporter: Chris Corbyn
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/82

I use UTF-8 encoding for sending mails. If I add a file with the name "Řeřicha.txt" the Ř character is stripped.

Swift produces:

--=swift_v4_12456688804a3f66105fa38=
Content-Type: text/plain; name="=?utf-8?Q?e=C5=99icha=2Etxt?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename*=utf-8''e%C5%99icha.txt

How can I fix this?

Original creation date: 2009-06-22T11:10:56Z
Original reporter: Merijn
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/97

Taken from the larger scoped ticket for a full rewrite of the character handling system, is this:

Version 1 (unpack), like Swift Mailer

@@@ php

We are sending an email in text, HTML, and also embedding some images in the HTML part.

The problem is some email clients like thunderbird are not parsing these properly and only show the text part.

The content type in the headers shows:
Content-Type: multipart/related;

Does it need text/html added in there somewhere?

Original creation date: 2009-07-29T15:03:50Z
Original reporter: Ben
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/102

When using Swift_Message::embed(Swift_Image::fromPath(...)) I sometimes get trouble depending on the formating of the HTML source. The issue seems to be when the generated CID is wrapped on a new line.

The problematic part of the attached message is:
@@@
_21556100<img src=3D"cid:1265277262=
[email protected]" border=3D"0">_*<=
@@@

Where the line starts with ".." on the new-line. It seems that this happens when the
new-line is wrapped at any part of the CID that starts with ".", which is converted to "..".
E.g. cid:[email protected] becomes cid:[email protected]
or cid:[email protected] depending on the line-wrap position.

Example of part of message that works is:
@@@
_73103105<img src=3D"cid:1265277262.4b6a994e=
[email protected]" border=3D"0">_**********<=
@@@

Original creation date: 2010-02-04T09:40:57Z
Original reporter: Even André Fiskvik
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/126

So after about 5 hours of debugging (yes I don't have a debugger -- so debugging was with echos -- lame I know), I found a bug that is relatively easily fixable assuming I did not miss any places.

Server Config:

PHP 5.2.8, APC, Memcached on CentOS 5.2 64bit, Swift 4.0.2

Important part of the php.ini:
[mbstring]
; language for internal character representation.
mbstring.language = Neutral

; internal/script encoding.
; Some encoding cannot work as internal encoding.
; (e.g. SJIS, BIG5, ISO-2022-*)
mbstring.internal_encoding = UTF-8

; http input encoding.
mbstring.http_input = auto

; http output encoding. mb_output_handler must be
; registered as output buffer to function
mbstring.http_output = UTF-8

; enable automatic encoding translation according to
; mbstring.internal_encoding setting. Input chars are
; converted to internal encoding by setting this to On.
; Note: Do not use automatic encoding translation for
; portable libs/applications.
mbstring.encoding_translation = On

; automatic encoding detection order.
; auto means
mbstring.detect_order = auto

; substitute_character used when character cannot be converted
; one from another
mbstring.substitute_character = none;

; overload(replace) single byte functions by mbstring functions.
; mail(), ereg(), etc are overloaded by mb_send_mail(), mb_ereg(),
; etc. Possible values are 0,1,2,4 or combination of them.
; For example, 7 for overload everything.
; 0: No overload
; 1: Overload mail() function
; 2: Overload str_() functions
; 4: Overload ereg_() functions
mbstring.func_overload = 7

So since the strlen function is overloaded with mb_strlen the for loop in:
ArrayCharacterStream->_reloadBuffer($fp, $len)
fails to take this into account.

Reproduce with string "Táve". The for loop:
for ($i = 0, $len = strlen($bytes); $i < $len; ++$i)

exits on 4 and not 5 even though 5 bytes were read in via fread. The fix for this is the change the strlen call to include 8bit:
for ($i = 0, $len = strlen($bytes,'8bit'); $i < $len; ++$i)

Old Result: Táv
New Result with 8bit param: Táve

Please send email to: [email protected] (I actually read this one)

BTW, I must say 4.X is a HUGE improvement from 3.X -- Kudos, nice work!

I have attached some debug output for you viewing pleasure.

Original creation date: 2009-03-18T08:20:40Z
Original reporter: jason (at pirkplace)
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/75

When i use special characters in e-mails which is valid these days you get an error:

Address in mailbox given [Të[email protected]] does not comply with RFC 2822, 3.6.2.

Original creation date: 2009-05-22T11:56:20Z
Original reporter: Maciej Lisiewski
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/93

Create MTA instances running on different ports with different configurations, supporting TLS/SSL.

Notify the developers of the relevant IP addresses and port numbers for testing each MTA.

Original creation date: 2008-12-21T12:31:17Z
Original reporter: Chris Corbyn
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/28

When we using Swift_MailTransport and give in associative array "setTo" full name like "Анна Леопoльдовна Стейкс" we get fail. Error looks like:
"Array
(
[0] => [email protected]
)
"
Code is:
"<?php
require_once "Swift-4.0.6/lib/swift_required.php";

$transport = Swift_MailTransport::newInstance();

$mailer = Swift_Mailer::newInstance($transport);

$message = Swift_Message::newInstance()
->setSubject('Тема письма')
->setFrom(array('[email protected]' => 'Василий Пупкин'))
->setTo(array('[email protected]' => 'Анна Леопoльдовна Стейкс')) // no work
//->setTo(array('[email protected]' => 'Анна леопол')) // no work
// ->setTo(array('[email protected]' => 'Анна леопо')) // work
->setBody("Здравствуйте!

        Анна Леопольдовна, зайдите в мой кабинет, пожалуйста.

        -- \nВасилий.")
->addPart('<h2>Здравствуйте!</h2>
        <p><b>Анна Леопольдовна</b>, зайдите в мой кабинет,
        <i>пожалуйста</i>.</p>
        <p style="text-align: right">Василий.</p>', 'text/html');

$result = $mailer->send($message, $failures); // отправка письма

echo $result;
print_r($failures);

?>
"
PHP Version 5.2.11, Swift-4.0.6

Original creation date: 2010-08-19T09:27:44Z
Original reporter: Alien
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/157

Add the following e-mail address to a message (the utf-8 char is important!):

"Berntsen, Pål" [email protected]

Swift will create the following header string:

To: Berntsen, =?utf-8?Q?P=C3=A5l?= [email protected]

Now if you send this with postfix it will rewrite this header to:

To: Berntsen@Intermesh-1, =?utf-8?Q?P=C3=A5l?= [email protected]

The problem lies in the comma and the separated encoded string. I fixed this by always encode the entire name when encoding is needed in any part of the string.

I changed this function in Mime/Headers/AbstractHeaders.php:

protected function getEncodableWordTokens($string)
{
$tokens = array();

$encodedToken = '';
//Split at all whitespace boundaries

//Fix: don't split the string for this bug.

//foreach (preg_split('~(?=[\t ])~', $string) as $token)
    $token=$string;
{
  if ($this->tokenNeedsEncoding($token))
  {
    $encodedToken .= $token;
  }
  else
  {
    if (strlen($encodedToken) > 0)
    {
      $tokens[] = $encodedToken;
      $encodedToken = '';
    }
    $tokens[] = $token;
  }
}
if (strlen($encodedToken))
{
  $tokens[] = $encodedToken;
}

return $tokens;

}

I hope you'll fix this problem too!

Original creation date: 2010-06-14T13:47:31Z
Original reporter: aleksblendwerk
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/150

Some of the tests are subclassing abstract test cases where they shouldn't be. If this is being done to offer helper methods, create an abstract test case that includes only the helper methods and does not include a series of test methods.

Original creation date: 2008-12-21T04:41:32Z
Original reporter: Chris Corbyn
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/26

Consider:

$this->message->setCharset('iso-8859-1');
$message->setEncoder(Swift_Encoding::get8BitEncoding());
$message->setBody('foo æøå bar', 'text/html');
$message->addPart('foo æøå bar', 'text/plain');

The body correctly gets the right encoding and charset, however the alternative body (set by addPart) gets this:

Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

clearly ->addPart() does not correctly inherit the encoding and charset set in the $message class, and there is no other way to assign charset or encoding to the added part.

Thanks.

Original creation date: 2009-08-20T10:43:20Z
Original reporter: MichaelL
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/107

It can happen that, in for example the subject of an email, an utf8 character falls "between" 2 chunks (the first byte is in the first chunk, the second byte is in the second chunk) of the base64 encoded string. All email clients that I have tested (thunderbird, nokia email) don't handle this. They will show an unknown character image instead.

A (real world) example (used in the subject of a mail):

Reminder: Invitation à participer à une enquête de satisfaction

What thunderbird shows is this: "Reminder: Invitation à participer �" (it cuts off the subject)
The encoded header looks like this:

Subject: =?utf-8?B?UmVtaW5kZXI6IEludml0YXRpb24gw6AgcGFydGljaXBlciDD?=
=?utf-8?B?oCB1bmUgZW5xdcOqdGUgZGUgc2F0aXNmYWN0aW9u?=

I'm currently using swiftmailer 3.3.2, but by looking at the code I think 4.0.4 has the same problem.

Original creation date: 2009-09-04T10:31:57Z
Original reporter: E. de Ruiter
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/108

qMail can be a real pain in the ass sometimes. Make sure version 4 didn't break the ability to send mail with qMail (over SMTP and at the process-level).

Original creation date: 2008-12-14T02:06:49Z
Original reporter: Chris Corbyn
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/5

We have several email addresses which work perfectly fine but the function "getGrammar('addr-spec')" throughs an exception as if the email address was invalid.

Since the code seems to follow the RFC spec, but real-life addresses are off spec. Maybe the RFC spec is just out of date and people are using a lot more complex email addresses?

Anyway, I can give you an example: [email protected]

The above address will fail validation but its a valid email in some email servers/clients.

There should be a method to ignore invalid emails and just continue sending, instead of stopping with an exception.

Thank you.

Original creation date: 2010-04-19T17:11:49Z
Original reporter: xdecock
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/143

Multibyte support works in v4 even when the MB String extension isn't available. However, there is no optimization to use the MB String extension when it's available.

Create a MultibyteCharacterReader implementation that uses the MB String library when available. Register this class in the DI container or Swift_Preferences in the presence of the MB String library.

Original creation date: 2008-12-14T02:29:41Z
Original reporter: Chris Corbyn
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/10

Quote from http://nl3.php.net/manual/en/function.mail.php:
Second, the custom headers like From:, Cc:, Bcc: and Date: are not interpreted by the MTA in the first place, but are parsed by PHP.
As such, the to parameter should not be an address in the form of "Something [email protected]". The mail command may not parse this properly while talking with the MTA.

As a result, the following error is thrown:

mail() [function.mail]: SMTP server response: 553 5.1.3 <Name [email protected]>... Recipient address not RFC-compliant

SwiftMailer should somehow fix the mail addresses for Windows platforms.

Original creation date: 2010-03-04T22:49:47Z
Original reporter: Bouke
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/137

Sending one mail with no attaches, only one html part, to only one recipient fails if mail has more than 1.2mbytes (aproximate numbers). It fails when using sendmail or smtp transport.

I'm getting memory exhaustion (after tracing for an hour) in the following trace:

CharacterReader/Utf8Reader.php:function getCharPositions:line 136
/* Ok we got a complete char here */
$lastChar=$currentMap['p'][$charPos+$foundChars]=$startOffset+$i+$size;

Called from:

CharacterStream/NgCharacterStream.php:function write

$this->_charCount += $this->_charReader->getCharPositions(substr($this->_datas, $this->_datasSize), $this->_datasSize, $this->_map, $ignored);

Looks like getCharPositions is requesting more than 128mb (the memory limit) when parsing a 1.2mb html mail.

Is this correct? Is there any solution?

Thanks in advance!

Original creation date: 2010-11-27T19:17:31Z
Original reporter: diego
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/168

Swiftmailer-4.0.5
PHP v5.2.12

Problem:

When i tried to embed an image into html type mail, only outlook with
a low spam filter sends the mail to junk folder.Target mail has a text part,
an html part, one pdf file as an attachment and 3 embeded images (like logo).

Output of Outlook

Received: from ....

Date: Fri, 8 Jan 2010 09:14:31 +0200
From: Ocompany [email protected]
Subject: Please check the ...
To: [email protected]
Message-ID: [email protected]
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="Boundary_(ID_CRI1zed9hsGT8qmRuQcTgg)"
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - bursa.trial.com
X-AntiAbuse: Original Domain - xxx.com
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - example.com
X-NAI-Spam-Level: ***
X-NAI-Spam-Score: 3
X-NAI-Spam-Report: 4 Rules triggered

• 1 -- BODY_LONG_LINE_PARA_IMG_ATTACH_NOHTTP -- Spam trait in body
• 1 -- CT_IMG_FLAT -- Spam trait in body
• 1 -- CT_MP_MIXED_SPACE_BNDRY_IMG -- Spam trait in body
• 0 -- RV3443 -- BODY: Version number
  Return-Path: [email protected]

Output of Webmail

Return-path: [email protected]
Envelope-to: [email protected]
Delivery-date: Fri, 08 Jan 2010 08:57:09 +0200
Received: from ...
Message-ID: [email protected]
Date: Fri, 08 Jan 2010 08:57:09 +0200
Subject: Please check ...
From: Ocompany [email protected]
To: [email protected]
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="=swift_v4_12629338294b46d745129d0="

--=swift_v4_12629338294b46d745129d0=
Content-Type: multipart/related;
boundary="=swift_v4_12629338294b46d7457e02d="

--=swift_v4_12629338294b46d7457e02d=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

No visibility in plain text, in html version you will see ....

--=swift_v4_12629338294b46d7457e02d=
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

--=swift_v4_12629338294b46d7457e02d=
Content-Type: image/gif; name=newgen.gif
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename=newgen.gif
Content-ID: [email protected]

R0lGODlhUAAPAIQAAAAAAL6+vr+/v8DAwMHBwcLCwsTExMjIyMvLy87Ozt7e3u7u7vHx8fX19fj4
+Pn5+fr6+vv7+/z8/P39/f///wAAAAAAAAAAAAAA............Mjv7/vUtAgocSNBECAA7

--=swift_v4_12629338294b46d7457e02d=--

--=swift_v4_12629338294b46d745129d0=
Content-Type: application/pdf; name=1262933801_2009_09_23_cr_senkromec.pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename=1262933801_2009_09_23_cr_senkromec.pdf

JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k
ZT4+CnN0cmVhbQp4nN2dTaw1R53ej31txryK0J2JQRPC4mrMiHOdedtdH13VZY0m4TUfYcJ4PPBO
ZsFEYGxjPP7E2Mxkl0SJAsqsZoUg4k............................lRU9GCg==

--=swift_v4_12629338294b46d745129d0=--

Here is the code i used
@@@
require_once '../Swift-4.0.5/lib/swift_required.php';

$transport = Swift_SmtpTransport::newInstance('mail.example.com', 587)
->setUsername('info+example.com')
->setPassword('xxxxx');

$mailer = Swift_Mailer::newInstance($transport);
$message = Swift_Message::newInstance();

$message->setSubject($subject);
$message->setFrom(array($sender => ucfirst(strtolower($company))));
$message->setTo($m); //$m is 1 degree array of mail adresses
$headers = $message->getHeaders();
/$cidcom = $message->embed(Swift_Image::fromPath($URL_IMG_COM));/

// $URL_IMG_COM="../upload_img/".$_SESSION['companyID']."/".$logo; image path..

$message->setBody('No visibility in plain text, in html version '.
'This mail was generated for a company who is '.$sectorcom.'.'.
'Five more lines take place in here.... '.
'and close the plain text', 'text/plain');

// not whole html code, only one image embed sample is here..

$message->addPart(''.
''.
'<style type="text/css">'.
' .div_info { width:600px; margin:0px; padding:0px;'.
' padding-left:10px; line-height:140%; font-family:Verdana, Geneva, sans-serif;'.
' font-size:12px; font-style:normal; color:#150517 }'.
'</style>'.
'' .
'

Conclusion
I will appreciate if you can show me the correct way to prepare the Target Mail.

Thanks.

Ozcan

Original creation date: 2010-01-08T08:17:25Z
Original reporter: Maciej Lisiewski
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/121

Let me start by saying I love SwiftMailer. Awesome product. Have used this now for years. We have sent millions of messages using SwiftMailer.

Problem: We send out over 20,000 HTML messages per day using SwiftMailer using two different servers. One server (Mail1) has been upgraded to 4.0.6 the other (Mail0) is on the prior release. In some cases, instances of a message are received with part of the message body repeating after the "end" of the original message body.

In all cases with repeating content the final HTML tag is not closed and the repeating content begins after that. The additional content is a repeat of the original content split just after an MS Word character like a Smart quote or a curly apostrophe. Imagine using the result from list($junk,$repeatingcontent)=explode('microsoft smart quote',$messagebody,2) . The $repeatingcontent is then added to the end of the document. The final HTML tag is not closed and the same explode is done on $repeatingcontent until nothing is left and the message finally ends.

MS Word characters in the message body appear to be the cause however, this has been a tough bug to track down as it is not happening in all messages. I receive many of the messages myself and have only one instance of such a message arriving in my inbox whilst other recipients of the same message have the problem occuring in their copy

Originally I suspected email client problems and badly formed HTML tables in the message. I have eliminated all of these possibilities over a period of several weeks.

I started logging every message body after we had loaded it into SwiftMailer with the personalisation all in place to ensure it was nothing I was doing in my loop. There was not one instance at my end.

After logging enough of these events I could compare the original HTML, my log of what was loaded into swift and check which server was used. This is when I noticed that the old version on Mail0 was not causing the issue.

With more substantial series of tests I confirmed this and finally received a copy of a message with the issue from an email message I had instigated. The issue was repeatable and identical and only accured when using SwiftMailer 4.0.6.

Once I had a copy that I could repeat the bug (sending one proof message at a time) that came to my inbox I could look at the received code and find the MS Word character link.

I will make these characters safe as a probable workaround however it might be something to look at at your end also.

I would have attached the files however they are too large for this service. I can provide if required.

Thanks in advance.

Mark

Original creation date: 2010-03-07T13:19:58Z
Original reporter: Mark
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/139

I recently encountered a situation where I had to ensure that registered listener plugins were called in a specific sequence. To do this I tried creating a class which inherits from Swift_Events_SimpleEventDispatcher and which manages listener order based on a priority property.
However, in the Swift_Events_SimpleEventDispatcher class the listener fields (to be specific: the _listener array) have private visibility - is there a special reason why protected isn't used here?

Original creation date: 2010-12-09T13:45:04Z
Original reporter: martinl
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/169

Another weak point that has shown up whilst writing the documentation. It's possible to change the encoding of the message itself, but it's not possible to change the Header encoding from Q to B.

Add getQEncoding() and getBEncoding() methods to Swift_Encoding, and add setEncoder() methods to Swift_Mime_Header and Swift_Mime_HeaderSet (possibly also Swift_Mime_HeaderFactory).

Original creation date: 2009-02-18T11:29:24Z
Original reporter: Chris Corbyn
Original ticket: http://swiftmailer.lighthouseapp.com/projects/21527/tickets/58